IP renumbering timeframe

Wed Jun 5 23:45:35 UTC 2002

Leo Bicknell wrote:

> In a message written on Fri, May 31, 2002 at 02:35:18PM
> -0700, Tony Hain wrote:
> > The only reason for an ASN is the need to globally announce routing
> > policy due to multihoming. Unless policy changes, this
> community tends
> > to insist that the prefix length announced via that ASN
> corresponds to a
> > site, not a single subnet. For IPv6 that means a /48 makes
> sense as an
> > initial allocation with a new ASN, and a /64 does not.
>
> In IPv4 land people generally filter on what the registries assign,
> or on some looser policy.  In my /24 per ASN proposal for IPv4, I
> expected that /8 to be filtered on a /24 boundry.
>
> Similarly in IPv6, I would expect the /32 to be filtered on a /64
> boundry.

And the result would be a multi-homed single subnet. I don't really care
if that is the goal, but you will have a hell of a time filling that 64
bits in a way that justifies more address space. If the allocation were
a /48 the chances of demonstrating reasonable use are much better.

>
> In a message written on Fri, May 31, 2002 at 06:09:03PM
> -0400, Marshall Eubanks wrote:
> > This is _not_ the service model of RFC2374, which envisions
> 8192 top
> > level routing aggregators (TLA's), with other entities
> getting their
> > address blocks from one of the TLA blocks.
>
> This is an excellent point.  I'll be the first to step forward to say
> that while this is all good in theory, the likelyhood that the market
> will accept the structure imposed by the IPv6 designers is near zero.
> That's not saying we might be able to do things more
> intelligent with a
> new system, but the grand goal is a pipe dream.

This is written as if the design were done in a vacuum. This was not
something being imposed by the designers. The response at the time of
RFC2374, from both the operators involved and the registries, was that
strict provider aggregation was the right course, and that means you get
blocks allocated from your upstream. At that time it was not expected
that there would ever be more than 8k top level transit providers, but
space was left to grow that number if necessary.

In any case, over the last couple of years it has been recognized that
address allocation policy should not be in the architecture document,
and that is why those original documents are being reworked as:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.tx
t
is the replacement for 2373
http://www.ripe.net/ipv6/global-ipv6-assign-2002-04-25.html
is the replacement for 2374

As Bill pointed out, RIR docs don't always make it to RFC, but the
important thing is that the policy is documented. As long as the
allocation policy stays within the scope of the architecture, there
shouldn't be any operational issues.

Tony