North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Scalability issues in the Internet routing system

  • From: Rubens Kuhl Jr.
  • Date: Wed Oct 26 22:06:08 2005
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mCVXMamjyxOmcxeybThw+QSJHCMWzPv+F2pmHQlnJ4mfxOM4spQwesx/J15X0hm31f1ljIdytCr8Ur5TgLnCq1tSxpF7BDRnvS+6kHUSVMuWOAYvl1h2pLHQ/VrFj0o7aTYejXkj4paX2DXRsmuqvzZwnQEjNFzKMa5G1DlP9Vc=

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

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( 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