RE: Review of draft-ietf-v6ops-nap-02.txt

["Walt Lazear" <lakematesw@comcast.net>]

I agree!  I'm a firm believer in the need for IPv6, but
I get a deja-vu knot in my stomach when I hear some IPv6
evangelists (such as at an IPv6 Summit) talking about the infinite 
address space and great applications it enables.  There is 
breast beating about Jon Postel wantonly handing out 
Class A's to buds in IPv4 land and yet I see the same kind 
of large chunks of IPv6 land being distributed freely.  
Perhaps we're letting the RIR's head down the same road?
/64's for serial links!  15 quintillion addresses where 2-4 
will suffice?!?!?!

What's scary are the applications that give addresses to every 
retail item so it can be tracked during it's lifetime.  No
reuse of addresses is contemplated (because they're infinite).
Imagine the ultimate usage, where nano-things in aerosol sprays each 
have an address that is literally "cast to the wind".  Is there a
/70 or /80 in every can of this stuff?  Why is there no built-in
mandatory recycling of address space for these applications?

We're undoing CIDR-like usage.  Hierarchical addressing is
going to be wasteful by nature.  I don't know how the IETF 
can influence the RIR allocation policy, but it's scary 
how much history seems to be repeating itself.  We're
at the early end of the cycle, so it may not seem to some 
that we're handing out addresses with both hands, but we are.

Walt Lazear


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
> Sent: Wednesday, May 31, 2006 11:49 AM
> To: Thomas Narten
> Cc: Jim Bound; Tony Hain; Brian E Carpenter; EricLKlein; 
> gunter@cisco.com; Ralph Droms; v6ops@ops.ietf.org; Lindqvist 
> Erik Kurt; Margaret Wasserman
> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt 
> 
> 
> Havard Eidnes read the numbers a little closer than I did: 
> yes, 10^38  
> is approximately 2^128.
> 
> I think the point remains that the requirement originally stated was  
> this:
> 
>     CRITERION
>        The IPng Protocol must scale to allow the identification and
>        addressing of at least 10**12 end systems (and preferably much
>        more).  The IPng Protocol, and its associated routing protocols
>        and architecture must allow for at least 10**9 individual  
> networks
>        (and preferably more).  The routing schemes must scale 
> at a rate
>        that is less than the square root of the number of constituent
>        networks [10].
> 
> http://www.ietf.org/rfc/rfc1726.txt
> 1726 Technical Criteria for Choosing IP The Next Generation (IPng). C.
>       Partridge, F. Kastenholz. December 1994. (Format: 
> TXT=74109 bytes)
>       (Status: INFORMATIONAL)
> 
> Without running through all the history, and the arguments of 
> whether  
> in 2006 the numbers selected in 1994 are adequate, the fact is that  
> we support a very large number of enumerable networks, on the order  
> of the square of the original requirement, and not only do we 
> support  
> 10^12 hosts in the address space, we support that many and quite a  
> few more on each LAN.
> 
> Yes, we support about 3 * 10^38 addresses in the address space. That  
> is a mathematically accurate statement.
> 
> I think the point you're asking is "does that mean we should throw  
> the addresses away with both hands?". And I would say, no, that's  
> what we did with the IPv4 address space, and we eventually learned  
> the error of those ways. It does make sense to think about rational- 
> sized address blocks, but frankly I would expect that this is 
> more of  
> an RIR issue than an IETF issue. They are currently handing out /32s  
> to ISPs, and more if the ISPs can justify it. That means that they  
> are allowing for ~4 billion address allocations, each of which is  
> presumably enough for 2^16 ISP customers, each of which potentially  
> has 2^16 LANs. I do believe that there is a question of market  
> dynamics there - if the customer is unlikely to create more than 256  
> LANs, selling them a /56 makes sense, and helps with the overall  
> address usage density, and if the customer really only needs a  
> single /64 or to be a member of a /64, I think those should be  
> options the customer can buy. saying "ISPs should only ever 
> under any  
> circumstances hand out a /48" seems a trifle over the top.
> 
> And I do remember this thing about CIDR, that it removed the 
> classful  
> address straight-jacket, which at least at the time some of us  
> thought was a good thing, and I wonder why we seem to be re-creating  
> it here. But that wasn't your question.
> 
> 
> 
> 
>