Subject: Re: router behaviour with prefixes longer than /64

From: Ran Atkinson <[email-masked]>
Date: Fri, 14 Mar 2014 08:45:45 -0400

Much Earlier, Brian Carpenter wrote:
>>  4. Some routers are less efficient for prefixes longer than 64.

Yes.  

I'd probably make some minor edits:

   "4. Many deployed routers" (e.g., see Steve Blake's 
       estimate from yesterday) 

and also append 

   "and the IPv6 FIB may scale less well for large numbers 
    of IPv6 prefixes longer than 64".

Subsequently, Steinar Haug wrote:
> Regarding the last point - it is my impression that some people
> in this discussion are really stating a stronger version:
>   Prefixes longer than 64 (with the possible exception of 127 and 128)

In the list archives that I read (IETF web server), everyone agrees
that router support for /127 prefixes is required by RFC-6164.
RFC-6164 is quite clear, although the RFC also is very precise in
saying /127 specifically and NOT saying "prefixes longer than /64"
or such like.

So I believe there is consensus about /127.  At least one
implementation handles the RFC-6164 as /126 (I think this 
is due to a bug, but I am not certain of the details).

As far as I am aware, nothing chokes on a /126 either.

However, /127 (and /126) might not be supported for some 
older (i.e., deployed before RFC-6164) IPv6 routers.

> *are not expected to work* with VLSM / longest prefix match.

Rough-Cut Pre-Coffee Edit:

  'are not required by IETF RFCs to support arbitrary IPv6 prefix
  lengths between /64 and /127 exclusive, but are required by
  IETF RFCs to support arbitrary prefixes between /0 and /65 
  exclusive and also are required to support the /127 prefix 
  for the RFC-6164 scenarios'

If operators want all IPv6 routers to support arbitrary prefix
lengths between /0 and /128 exclusive for use in today's 
deployed IPv6 Internet, then I believe that an IETF standards-track 
specification change is needed.  

Note well, if such a change were made, then operators also should 
expect (non-consumer-grade) IPv6 router hardware to cost visibly more 
than it does today.  My guess is that if that change were made, 
then consumer grade IPv6 routers will probably cost the same, 
but have reduced performance.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 14 Mar 2014 08:48:26 -0400

Yes.  

and also append 

If operators want all IPv6 routers to support arbitrary prefix
lengths between /0 and /128 exclusive for use in today's IPv6
Internet, then I believe that an IETF standards-track RFC
with a clear/crisp specification change will be needed.  

Note well, if such a change were made, then operators also should 
expect (non-consumer-grade) IPv6 router hardware to cost more 
than it does today.  My guess is that if that change were made, 
then consumer grade IPv6 routers will probably cost the same, 
but would have reduced IPv6 performance (which might not
matter in a home with consumer-grade equipment).

Yours,

Ran

---

From: [email-masked]
Date: Fri, 14 Mar 2014 15:08:12 +0100 (CET)

> is due to a bug, but I am not certain of the details).

Do you believe there is consensus about /128 (e.g. for loopbacks)?

> but have reduced performance.

It may be the case that operators are able to change their networks
such that arbitrary prefix lengths in the range 65 to 125 (inclusive)
are not needed. For such a change to happen, I expect we would need
at least the following:

1. Equipment vendors need to start publishing information about what
kind of limits you're likely to hit if these prefix lengths are used,
and probably also give an explicit *warning* if the user tries to
configure such prefix lengths.
2. /127 must be supported on relevant hardware (including Ethernet
point-to-point links). Equipment vendors must state that /127 is
actually supported.
3. An RFC must be published which states in very clear terms that
VLSM/longest prefix match is not expected to work for prefixes in
the range 65 to 125 (inclusive).

I'm saying 125 and not 126 because we have IP transit links today
that use /126.

Steinar Haug, AS 2116

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 14 Mar 2014 12:04:35 -0400

> Do you believe there is consensus about /128 (e.g. for loopbacks)?

All the RFCs are clear about Loopback, but those same RFCs also 
are clear that both Loopback and Unspecified are special-case
addresses.  

As noted previously, one can be RFC compliant for Loopback without 
necessarily using VLSM as the implementation method.  As a trivial 
example, here is some pseudo-code that could be used:

	if (IPv6_Address == Loopback) {
			do special Loopback stuff
	} else 
			do normal stuff
	}

As far as I know, every IPv6 implementation (host, router,
other) supports Loopback and Unspecified as per the RFCs.

> configure such prefix lengths.

I agree that a CLI warning might be a good idea.
Normally, user interfaces are outside the scope of IETF.

In any case, I'm an independent consultant, and I am not
working for an equipment vendor/manufacturer just now.

> point-to-point links). Equipment vendors must state that /127 is

As far as I know, most vendors state this type of information
by having product spec sheets that cite the supported RFCs.  
One could look at a product's spec sheet to see whether they 
list the RFC that explicitly requires /127.  If they don't, 
then as a customer I would ask whether the product did.

Put another way, if I were running an RFP to buy IPv6 routers,
I'd be sure to cite the RFC on IPv6 /127s for point-to-point
links as a "MUST SUPPORT" item.

Yours,

Ran