[ppml] IPv6>>32

Mon May 9 11:56:10 EDT 2005

Hi Leo,

Apart for technical issues, I will say that is too late, years late, to
change the host length.

There has been a strong effort in coding and deployment. May be not so much
in US, but definitively in AP and Europe, which can't be changed so easily.

On the other side, you're probably missing the picture of the hardware
issues, I mean silicon implementations of IPv6, which mean a huge investment
and years to be replaced in the market.

I don't really think that's possible, and probably all those are the reasons
why the people that you could have asked in IETF have in mind to avoid going
into this direction.

Instead, I feel much more realistic to reconsider the HD-ratio for IPv6.

Final consideration, do you really believe in 50-100 years we will still be
using IP at all ?.

Regards,
Jordi

> De: Leo Bicknell <bicknell at ufp.org>
> Organización: United Federation of Planets
> Responder a: <owner-ppml at arin.net>
> Fecha: Mon, 9 May 2005 11:12:18 -0400
> Para: <ppml at arin.net>
> Asunto: [ppml] IPv6>>32
> 
> 
> 
>                              IPv6>>32
> 
> There has been a lot of talk about IPv6 addressing, and how well
> it will scale.  Geoff Houston (David Conrad) presented a very well
> researched paper at the Orlando meeting which documented the use
> of address space.  You can read a copy of it here:
> http://www.arin.net/meetings/minutes/ARIN_XV/PDF/wed/Round_Table.pdf
> 
> The net result is that we're poised to burn through a /1 to a /4
> of the IPv6 address space in the next 60 years based on our best
> current guesses.  This makes me extremely nervous.  If anything the
> past shows that we are generally poor predictors of the future, and
> also that more often than not we predict too low.  I also believe
> that we should be able to do much better than 60 years.  IPv4 is
> conservatively going to last at least 30 years before it is replaced,
> and likely more like 40+ years.  To expect that with those 30-40
> years experience that we can only double the life of the next
> protocol is a poor target.
> 
> Fortunately, there is no fundamental design flaw.  The protocol is
> not broken, the addressing design is not broken.  Indeed, the basic
> IPv6 architecture documents call for a "variable length subnet mask"
> basic implementation.  If we look at RFC 3513, we see that in section
> 2.5 standard behavior is a variable length subnet mask sort of
> behavior, but later in section 2.5.4 we see where 64 bits are
> dedicated to the host function.  See: http://www.faqs.org/rfcs/rfc3513.html
> 
> What the IETF has done is separate a "host portion" and a "routing
> portion" on a /64 boundary.  Having a fixed host portion is convenient
> for many reasons.  It allows for autoconfiguration (a la RFC 2462).
> It also allows the mapping of a globally unique identifier into the
> address.  In the IPv6 case they chose the IEEE's EUI-64 ID (see
> http://standards.ieee.org/regauth/oui/tutorials/EUI64.html).
> 
> However, now that the host is guaranteed globally unique, it raises
> new privacy concerns.  Indeed, these have already been recognized
> by the IETF, and are addressed in RFC 3041 (see
> http://www.faqs.org/rfcs/rfc3041.html).  Without trivializing the
> work in the paper, the solution is basically to use randomized
> addresses.  As there is a 64 bit space to work with the probability
> of collision is low, and IPv6 already requires Duplicate Address
> Detection (DAD) to prevent duplicates from occurring.
> 
> One item not addressed in any IETF documents is that most sites
> will probably continue to use DHCP to assign addresses.  While IPv6
> allows a host to obtain an IPv6 address and determine its default
> gateway, it does not pass any of the other information administrators
> have come to rely on being in DHCP.  These features include, but
> are not limited to DNS information, services information including
> boot servers, WINS servers and the like, and time servers.  DHCP
> servers also generally update dynamic DNS, allowing the host to
> have a stable DNS entry.  All of these point to administrators still
> using DHCP even where autoconfiguration is available.
> 
> With that background out of the way, a picture is formed where there
> is 64 bits of routing information, and 64 bits of host information.
> Geoff's paper and proposals for HD ratio address only the 64 bits
> of routing information, and how we can recover bits on that side
> of the equation.  That's good, and gains us some headroom, but
> leaves half of the problem unaddressed.  To address the host portion,
> we need to look at the good parts of what the IETF has done:
> 
> - Autconfiguration is a nice feature, and may be useful for some
>   devices.
> - Fixed size host portions facilitate renumbering and easy
>   administration.
> - Byte boundaries are good.
> 
> However, we also have to look at the bad parts:
> 
> - EUI-64 addresses are Globally Unique, which is not necessary for
>   the host portion.
> - EUI-64 in the address raises privacy concerns.  - EUI-64 depends
>   on the continued maintenance and management of the
>   IEEE.
> 
> There is also the unknown:
> 
> - It has been stated that there may be future applications developed
>   around the fact that the host portion is globally unique.
> - It has been stated that it is useful to have the routing portion and
>   the host portion be the same bit size, so that one can be embedded in
>   the other.
> 
> To preserve the good, and eliminate the bad, I propose a simple
> change.  Shift all of the current policies to the right by 32 bits.
> That is, the host portion becomes a 32 bit quantity.  EUI-64's
> would no longer be used, all hosts would simply randomly generate
> addresses for autoconfiguration.  This is already the direction the
> privacy work is going.  32 bits is more than enough to allow random
> address selection on extremely large lans (10-50,000 addresses)
> with minimal collisions.  The host portion would still be fixed,
> allowing for easy renumbering, autoconfiguration, and similar
> features.
> 
> All other boundaries move down as well:
> 
> - A /64 subnet becomes a /96 subnet.
> - A /48 assignment becomes a /80 assignment.
> - A /32 ISP allocation becomes a /64 ISP allocation.
> 
> Coming back to Geoff's numbers.  If he's right about a /1, the
> entire routing system will now fit in a /33 in 60 years, without
> changing the HD Ratio.  Less space than we use for a single ISP
> today is enough to number the entire world based on our current
> understanding.  Note also that the byte boundaries are preserved
> allowing for easy DNS administration and other features.
> 
> More importantly, if Geoff is off by an order of magnitude (which
> is about 3.2 bits), under the current system we'd be short about 2
> bits to number everything.  With this change, we would simply consume
> a /29.
> 
> The largest down side I can find is the unknowns listed above.  It
> appears some people are thinking of applications that require the
> host portion to be globally unique, and/or applications that depend
> on being able to imbed a prefix in the host portion, or a host
> portion in the prefix portion.  I have been unable to find any hard
> documentation on either of these applications, and I would be
> extremely interested in any defined uses of these behaviors.
> 
> To me, a change such as this provides several safety nets:
> 
> - If we're off by an order of magnitude or more, we don't run out
>   of space.
> - If we've gotten this 100% wrong, we will have used around a /32 in
>   60 years allowing us to adjust the addressing plan without having to
>   deploy an entirely new protocol to do it.
> - It allows a large amount of growth room for the unknown.
> - IPv6 should be able to last significantly longer than 60 years.
> 
> Obviously, there are a few down sides:
> 
> - The specification and code to do autoconfiguration will have to be
>   changed.
> - This leaves enough free bits on the top end to further subdivide the
>   address space (one proposal would be to assign a /24 for "country
>   specific" prefixes, with the next 8 bits being a country identifier
>   [there are currently 191 UN members], allowing each country to have a
>   /32, which is now enough space to address the entire world).
> - ISP's that have already received a /32 (or larger) have made a
>   successful land grab if those addresses are not reclaimed.
> 
> Finally, I'd like to close with a discussion of why I'm posting
> this to PPML.  I've spoken with a number of people about the IETF
> process, and what has been made abundantly clear to me is that the
> IETF is not even remotely interested in opening this issue for
> discussion.  They feel the current proposal out there is the best
> proposal, they have fought their war to decide on it and will now
> fight to leave the issue sealed.
> 
> I also think it's clear the community has some serious concerns
> with the current proposal.  Geoff's paper is an illustration, and
> I commend him for his work on the routing portion.  I think the
> community should also take a hard look at the host portion before
> it's too late.  Right now IPv6 deployment is limited, and so it's
> not too late to make a change.  Another few years may get us to a
> point where it is too late though, with too much inertia behind
> the 64 bit boundary.
> 
> This is why PPML is involved.  I think the community needs to think
> about this issue and if it is worth discussing.  I'm not sure my
> proposal is "the best" or even good, but without a straw man to
> dissect the discussion will not be complete.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org

************************************
Barcelona 2005 Global IPv6 Summit
Registration open. Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.