[ppml] IPv6>>32

[Leo Bicknell]

In a message written on Mon, May 09, 2005 at 05:56:10PM +0200, JORDI PALET MARTINEZ wrote:
> 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.

While I can't argue the deployment aspect, as there is an intertia
there, the software and hardware aspect I can address.  Already per
RFC 3177, software and hardware limits on prefix lengths are verboten.
I quote from section 4:

      -  We are highly confident in the validity of this analysis, based
         on experience with IPv4 and several other address spaces, and
         on extremely ambitious scaling goals for the Internet amounting
         to an 80 bit address space *per person*.  Even so, being
         acutely aware of the history of under-estimating demand, the
         IETF has reserved more than 85% of the address space (i.e., the
         bulk of the space not under the 001 Global Unicast Address
         prefix).  Therefore, if the analysis does one day turn out to
         be wrong, our successors will still have the option of imposing
         much more restrictive allocation policies on the remaining 85%.
         However, we must stress that vendors should not encode any of
         the boundaries discussed here either in software nor hardware.
         Under that assumption, should we ever have to use the remaining
         85% of the address space, such a migration may not be devoid of
         pain, but it should be far less disruptive than deployment of a
         new version of IP.

Note that they stress vendors should not encode any of the boundaries
in software or hardware.  Those writing software, or spinning silicon
with built in limitations are already violating the RFC's, even if
no changes are made at this time.

-- 
       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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050509/28980b46/attachment.sig>