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