Scalability issues in the Internet routing system

Thu Oct 27 06:04:16 UTC 2005

I think that to be "technically correct" is appropriate to say that we can
have almost 2^64 networks (having reserved space doesn't mean that we can't
use it in the future), and each network can accommodate up to 2^64 nodes.
But is also true that it seems difficult in reality to reach that number of
nodes.

So it is so much inaccurate to say that IPv4 has 2^32 addresses than to say
that IPv4 has 2^128, even if theoretically both figures are correct, because
practical issues.

Regards,
Jordi

> De: "Rubens Kuhl Jr." <rubensk at gmail.com>
> Responder a: <owner-nanog at merit.edu>
> Fecha: Thu, 27 Oct 2005 00:04:58 -0200
> Para: James <james at towardex.com>
> CC: Lincoln Dale <ltd at interlink.com.au>, <nanog at nanog.org>
> Asunto: Re: Scalability issues in the Internet routing system
> 
> 
>>> IPv6 will someday account for as many IPv4 networks as would exist
>>> then, and IPv6 prefixes are twice as large as IPv4 (64 bits prefix vs
>>> 32 bits prefix+address, remainder 64 bits addresses on IPv6 are
>>> strictly local), so despite a 3x cost increase (1 32 bit table for
>>> IPv4, 2 for IPv6) on memory structures and 2x increase on lookup
>>> engine(2 engines would be used for IPv6, one for IPv4), the same
>>> techonology that can run IPv4 can do IPv6 at the same speed. As this
>>> is not a usual demand today, even hardware routers limit the
>>> forwarding table to the sum of IPv4 and IPv6 prefixes, and forward
>>> IPv6 at half the rate of IPv4.
>> 
>> s/64/128/
>> 
>> ...and total, complete, non-sense.  please educate yourself more on reality
>> of inet6 unicast forwarding before speculating.  Thank you.
> 
> From RFC 3513(Internet Protocol Version 6 (IPv6) Addressing Architecture):
>   "For all unicast addresses, except those that start with binary value
>    000, Interface IDs are required to be 64 bits long and to be
>    constructed in Modified EUI-64 format."
> 
> If Interface ID is 64 bits large, prefix would be 64 bits max,
> wouldn't it ? Usually it will be somewhere between 32 bits and 64
> bits.
> 
> As for 000 addresses:
> 
> "  Unassigned (see Note 1 below)         0000 0000      1/256
>    Unassigned                            0000 0001      1/256
>    Reserved for NSAP Allocation          0000 001       1/128 [RFC1888]
>    Unassigned                            0000 01        1/64
>    Unassigned                            0000 1         1/32
>    Unassigned                            0001           1/16
> 
>   1. The "unspecified address", the "loopback address", and the IPv6
>       Addresses with Embedded IPv4 Addresses are assigned out of the
>       0000 0000 binary prefix space.
> "
> 
> Embedded IPv4 can be forwarded using IPv4 lookup, and all other 000
> cases can be handled in slow-path as exceptions. IANA assignment
> starts at 001 and shouldn't get to any of the 000 sections.
> 
> One interesting note though is Pekka Savola's RFC3627:
> "Even though having prefix length longer than /64 is forbidden by
>    [ADDRARCH] section 2.4 for non-000/3 unicast prefixes, using /127
>    prefix length has gained a lot of operational popularity;"
> 
> Are you arguing in the popularity sense ? Is RFC 3513 that apart from
> reality ? An October 2005(this month) article I
> found(http://www.usipv6.com/6sense/2005/oct/05.htm) says "Just as a
> reminder, IPv6 uses a 128-bit address, and current IPv6 unicast
> addressing uses the first 64 bits of this to actually describe the
> location of a node, with the remaining 64 bits being used as an
> endpoint identifier, not used for routing.", same as RFC 3513.
> 
> Limiting prefix length to 64 bits is a good thing; it would be even
> better to guarantee that prefixes are always 32 bits or longer, in
> order to use exact match search on the first 32 bits of the address,
> and longest prefix match only on the remaining 32 bits of the prefix
> identifier.
> 
> 
> Rubens

************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
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.