[ppml] IPv6>>32

[JORDI PALET MARTINEZ]

We have lots of examples of people don't following RFCs, and I don't mean I
agree with that, but is real life.

Keeping 128 bits in the lookup tables of core routers has been seen by some
chip set vendors as not useful, very expensive and time consuming, while
they only handle actually 64 bits routes in that part of the network.

Those routers don't expect to see the 64 bits of the host field to be
required for the routing, because they look into the aggregated route
towards the PoP, access network, or whatever is next.

I think this 64 bits usage is not in conflict with RFC3177, but actually it
sound to me that this part of the text in the RFC3177 could require a
clarification.

The point is that if those routers are forced to route, in the core, per 128
bits, then the trouble is a different one, of a much bigger magnitude.

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 13:09:45 -0400
> Para: <ppml at arin.net>
> Asunto: Re: [ppml] IPv6>>32
> 
> 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




************************************
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.