RE: [GLOBAL-V6]IPv6 Allocation Policy

  • To: "Craig A. Huegen" <chuegen at cisco dot com>
  • Subject: RE: [GLOBAL-V6]IPv6 Allocation Policy
  • From: "Michel Py" <michel at arneill-py.sacramento dot ca dot us>
  • Date: Wed, 21 May 2003 21:00:58 -0700
  • Cc: "Pekka Savola" <pekkas at netcore dot fi>, "Brian Carpenter" <brian at hursley dot ibm dot com>, <global-v6 at lists dot apnic dot net>
  • List-archive: <>
  • List-help: <>
  • List-id: Discussion of new global IPv6 policy development <>
  • List-post: <>
  • List-subscribe: <>,<>
  • List-unsubscribe: <>,<>
  • Sender:
  • Thread-index: AcMfpZ4Z6MKmDeypTkC1yvojRiyawwAauIpg
  • Thread-topic: [GLOBAL-V6]IPv6 Allocation Policy
      > Craig A. Huegen wrote:
      > At the moment we're trying to split the /32 to /35's, hoping
      > that everyone will at least permit the original /35 that was
      > used. If we run into cases, then I'll have to submit
      > applications for multiple /32's.
      I appreciate your efforts to preserve space. That being said, and hoping
      you don't mind my bluntness, I think this is a somehow risky strategy
      and that's not what I would do if I was in your shoes (I would request
      multiple /32s up front). Here's the rationale:
      /35s are not supposed to exist anyway. As far as I know, all /35s have
      been extended to /32s without the need to renumber; just extend the
      prefix. I acknowledge that there has been prefix withdrawal issues
      attributed to an antique version of mrtd, but as of today the only
      excuse one has to still announce a /35 is "I've been really swamped, I'm
      working on it". In a year, I'm sorry to say that I will likely
      categorize as a bozo someone that still announces a /35 when it has been
      upgraded to a /32 last year.
      There is no relation whatsoever between announcing a /35 as originally
      assigned (because it does not exist anymore, anyway) and announcing a
      /35 as a specific of a /32 for geographical separation purposes. With
      this in mind, it is my evaluation that there will always be people that
      will continue to filter your /35s on the grounds that a) you "pollute"
      the GRT with your specifics b) /32 is way bigger than you need c) they
      don't like Cisco d) name it....
      Although you do have the privilege of having your own Globally Routable
      Prefix as an early adopter, the hypocrisy that has always accompanied
      routing and filtering policies says that, unless there is a common
      filtering policy adopted by all 4 RIRs (and possibly that could be
      insufficient), there will always be people to filter your /35s just
      because they can do it if lacking a better reason.
      By looking what is at stake, I do prone address space conservation but
      the long-term problem we are having is the size of the Global Routing
      Table. WRT this issue, announcing eight /35s or eight /32s does not
      change anything.
      By weighing the pros and cons of Cisco announcing multiple /35s vs.
      announcing multiple /32s I found this:
      Annoucing multiple /35s:
      Pros: address conservation (saves 7x /32)
      Cons: - Even if there is a common policy, not guaranteed to work.
            - The common policy will inevitably create a precedent to
              allow specifics to be announced. Today, /35s. Tomorrow, what?
      Announcing multiple /32s:
      Pros: - Guaranteed not to have filtering.
      Cons: - Wastes 7x /32.
      I will conclude with this: no matter what I like, Cisco could find 8x
      200 customers and becomes 8x a LIR. When I weigh the potential dangers
      of creating a policy that would allow announcing specifics longer than
      the minimum allocation and the loss of 7x /32 out of 512 Million of
      them, my position is clear: I will continue to oppose any policy that
      proposes to announce longer prefixes and look the other way when Cisco
      asks for a /29 when a /44 would have been enough.
      Would have been enough if a multihoming solution was deployed, that is.
                             _   ____  __      __  ____   _    _   _    _
                            | | |  _ \ \ \    / / / ___| | \  / | | |  | |
      Michel Py             | | | |_| | \ \  / / | |__   |  \/  | | |__| |
      Sr. Network Engineer  | | |  __/   \ \/ /  |  _ \  | \  / | |  __  |
      CCIE #6673            | | | |       \  /   | |_| | | |\/| | | |  | |
      mpy at ieee dot org          |_| |_|        \/     \___/  |_|  |_| |_|  |_|
                                      IPv6 Multihoming Solutions