[v6ops] I-D Action:draft-azinger-scalable-addressing-00.txt

[Templin, Fred L]

> -----Original Message-----
> From: v6ops-bounces at ietf.org [mailto:v6ops-bounces at ietf.org] 
> On Behalf Of Fred Baker
> Sent: Saturday, September 25, 2010 1:04 PM
> To: Brian E Carpenter
> Cc: IPv6 Operations; S.P.Zeidler; IPv6 operators forum
> Subject: Re: [v6ops] I-D 
> Action:draft-azinger-scalable-addressing-00.txt
> 
> >> Overall document:
> >> Given that even huge ASes will only originate a small number of
> >> prefixes in v6 compared to dozens to hundreds in v4 now, 
> what problem
> >> exactly is this trying to fix?
> > 
> > That depends entirely on user sites and ISPs following good 
> (CIDR-like)
> > practice. So I think encouraging that is the useful goal of 
> this draft.
> 
> Which is where the draft is trying to go.
> 
> >> As long as getting PI space is bound to getting or having 
> an AS I don't
> >> really see the scaling problem.
> > 
> > Well, unless it encourages a gold rush on AS numbers.
> 
> >> The danger of every corner shop in the world trying to get 
> PI is not
> >> actually there IMHO.
> > 
> > Again, I hope you're correct, but why not document the fact 
> that it's
> > highly undesirable?
> 
> We are in fact seeing quite a growth in AS numbers and in 
> requests for PI allocation. You might look at
> 
>      http://www.potaroo.net/tools/asn16/
> 
> The growth rate of the AS number space is not spiking up per 
> se, but it is non-linear, with increases in rate circa 2000 
> (with the dot-com bubble bursting, there was an increase in 
> the assignment rate of AS numbers) and 2009-2010. I would 
> imagine these are not "to get PI space" but "to multihome 
> using BGP". If anything, I see that as the argument for 
> solutions like ILNP or NAT66 (the draft, which does stateless 
> prefix translation, not the idea of making stateful IPv6/IPv6 
> network ADDRESS translators). They enable the transit 
> operators to view their networks as PA while their customers 
> view themselves as pseudo-PI. Yes, it has issues similar to 
> those described in RFC 2993.

This is actually the same situation as for IRON. End user
networks perceive what they get from their IRON service
arrangements as PI, but all that gets presented to the BGP
are highly-aggregated prefixes that are indistinguishable
from PA.

IRON solves the whole package of IPv6 transition and
coexistence requirements - not just bits and pieces like
some others that seem to be getting lots of popular hype.
IMO, it is worth a closer look.

Fred
fred.l.templin at boeing.com

> _______________________________________________
> v6ops mailing list
> v6ops at ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>