APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists global-v6 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [GLOBAL-V6]IPv6 Allocation Policy



Craig,


> 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.


                       _   ____  __      __  ____   _    _   _    _
                      | | |  _ \ \ \    / / / ___| | \  / | | |  | |
Michel Py             | | | |_| | \ \  / / | |__   |  \/  | | |__| |
Sr. Network Engineer  | | |  __/   \ \/ /  |  _ \  | \  / | |  __  |
CCIE #6673            | | | |       \  /   | |_| | | |\/| | | |  | |
mpy@ieee.org          |_| |_|        \/     \___/  |_|  |_| |_|  |_|
                                IPv6 Multihoming Solutions
                        http://arneill-py.sacramento.ca.us/ipv6mh
                     http://arneill-py.sacramento.ca.us/public/ipv6mh/