[ppml] IPv6>>32

Stephen Sprunk stephen at sprunk.org
Thu May 12 17:21:55 EDT 2005


Thus spake <Michael.Dillon at radianz.com>
> > The only comment I have received on my draft so far is that
> > we probably need to add /44 for very large organizations.
>
> Very large organizations are not very static places. They split off
> bits of themselves into other organizations and aggregate other
> organizations into themselves on a regular basis.

Right, but that's orthogonal to the size of the prefixes.  Renumbering is a
fact of life regardless of prefix size when organizations split or merge,
and so far IPv6 doesn't make that any easier (unfortunately) or harder
(thankfully).

> I don't think there is any case for allowing for more than a
> /48 to large organizations. Most large organizations are more
> likely to approach providers for several /48's with each
> /48 used to service some subset of the whole organization.
> I just can't see a scenario in which all traffic in a large
> organization will want to use a single gateway.

They don't want to use a single gateway; they want multiple vendors at each
of several geographically diverse locations all using the same prefix.  This
implies PI, which is why 2005-1 was proposed.

If organizations are forced to use a different /48 for each upstream link,
then they're going to be forced into IPv6 NAT at each gateway with ULAs on
the inside.  More likely they'll just keep using RFC1918 and NAT.

> Any alternatives to /48 need to be clearly explained with
> many examples.

Agreed.  Assignments shorter than /48 should be possible if the HD ratio
warrants, but I don't see much need for anything between /48 and /64.  I
also think we need to clarify when a /64 or longer can be assigned, if
that's what makes the most technical sense or if it's what the customer
requests.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov




More information about the ARIN-PPML mailing list