Subject: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2014 12:18:19 +0100

Hello,

draft-boucadair-6man-prefix-routing-reco-03 is a new draft telling that 
forwarding processes should work with _arbitrary_ prefix lengths, and 
not be bound by particular limits, as an autoconfig process like 
SLAAC/Ethernet is bound by a prefix len max 64.

The draft was presented in 6MAN WG at the last IETF meeting in 
Honolulu[*].  The recommendation was to bring it to v6ops WG.

A glimpse to some topics discussed:
- worth or not having an RFC, since Internet acted this way since ever.
- cheaper searches below 64 and trends.
- Interface ID length vs. forwarding recommendation.

What do you think?

Alex
[*] the slides are at
http://www.ietf.org/proceedings/91/slides/slides-91-6man-6.pdf
Minutes are at:
http://www.ietf.org/proceedings/91/minutes/minutes-91-6man
(search for 'prefix')

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 20 Dec 2014 01:35:35 +0000

</chair>
What I think, #1, is that any assumptions about link layer addresses and their effect on the IID should be related first to the link layer in use, and its address. If it’s a five-and-a-half bit address, SLAAC-or-whatever should presume a five-and-a-half bit address. The fact that someone globally thinks in terms of a certain length of prefix or IID disjoint from the underlying MAC address the IID is derived from mostly wastes bits with no obvious ROI.

<chair>
#2, v6ops’ charter allows it to generate BCPs and informational documents, and give advice to other working groups - of which 6man is mentioned specifically. 

</chair>
I have no problem with the IID being a random number or derived from something fundamental such as the MAC Address. What is necessary for SLAAC-bis is that the RA contain the length of the prefix, giving the system the remainder to fill as it sees fit.

<chair>
I’m not entirely sure why 6man would refer this to v6ops, given that v6ops is not allowed by charter to solve the problem, and the specification in question came from 6man...

> On Dec 19, 2014, at 3:18 AM, Alexandru Petrescu <[email-masked]> wrote:
> 
> Hello,
> 
> draft-boucadair-6man-prefix-routing-reco-03 is a new draft telling that forwarding processes should work with _arbitrary_ prefix lengths, and not be bound by particular limits, as an autoconfig process like SLAAC/Ethernet is bound by a prefix len max 64.
> 
> The draft was presented in 6MAN WG at the last IETF meeting in Honolulu[*].  The recommendation was to bring it to v6ops WG.
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 20 Dec 2014 12:47:36 +0900

On Sat, Dec 20, 2014 at 10:35 AM, Fred Baker (fred) <[email-masked]> wrote:
>
> I’m not entirely sure why 6man would refer this to v6ops, given that v6ops
> is not allowed by charter to solve the problem, and the specification in
> question came from 6man...

AIUI the intent of this document is not to redefine SLAAC, the IPv6
addressing architecture, or anything of the sort.

I believe this is just intended to be guidance to router implementors that
just because the IID length is 64 bits does not mean that routers can
restrict themselves to supporting only prefix lengths of /0-/64 and /127 (a
MUST in RFC6164), but must also support forwarding to prefixes of arbitrary
other lengths such as /93.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 20 Dec 2014 06:50:11 +0000

> On Dec 19, 2014, at 7:47 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> AIUI the intent of this document is not to redefine SLAAC, the IPv6 addressing architecture, or anything of the sort.
> 
> I believe this is just intended to be guidance to router implementors that just because the IID length is 64 bits does not mean that routers can restrict themselves to supporting only prefix lengths of /0-/64 and /127 (a MUST in RFC6164), but must also support forwarding to prefixes of arbitrary other lengths such as /93.

No doubt. But 2460, 4291, and all the rest came from IPv6 or 6man. Why on earth would they ask *us* to say that?

When I refer to the charter, our charter allows us to do three things: publish as informational, publish as BCP, or refer to some other working group with our comments. This draft asks for Proposed Standard status.

https://datatracker.ietf.org/doc/draft-boucadair-6man-prefix-routing-reco
https://tools.ietf.org/html/draft-boucadair-6man-prefix-routing-reco
  "IPv6 Prefix Length Recommendation for Forwarding", Mohamed Boucadair,
  Alex Petrescu, 2014-09-24,

The text, if shortened at all, would be literally the words you spoke. I’ll repeat it in this email.

Tell you what. Between now and 12/31, many of us are going to be out of sight and out of mind. I’ll run a WGLC, starting 1/4/2015 and running for two weeks. If we have any disagreement beyond nits, I’ll express amazement, and if we don’t, I’ll do what I think the 6man chairs should have done, which is send it to my favorite AD for publication. In the same call, I’ll ask whether it should be adopted as a working group document, and if (as I expect) we’re all OK with that, I’ll ask Mohamed to file the update-to-pick-up-comments as draft-ietf-v6ops-cidr-prefix.

<rant #1>
We have a convention that calls for a 64 bit IID on unicast addresses, but are quite happy to use, to pick one documented example, 127 bit prefixes among consenting adults. If someone used DHCP to assign addresses and chose to use a 79 bit prefix, would we know? Would we care? It’s a CIDR prefix, for crying out loud. 
</rant>

<rant #2>
Of course, I have the same question about bit 70 and 71 of the address (bit’s 6 and 7 of the RFC 4291 IID). In what case, specified in what RFC and/or implemented in what hardware or software, do we extract an EUI-64 or EUI-48 from the IID? If it was a Privacy/Temporary address, or a SEND CGA Address, or something out of RFC 6052, what would we get if we did? Why, oh why, does it matter, and who actually cares, whether the IID is a locally-significant or globally significant value, or whether someone thought it came from a multicast MAC address?
</rant>

OK, sanity slowly returning...

I’ll state two nits here: 

1) I don’t know why this isn’t a BCP - a one-shot standard. It’s not like we’re going to demonstrate interoperable implementations and bump it from Proposed Standard to Standard. That’s not a strongly held opinion, but it is a question, and it’s mine.
2)   == Outdated reference: A later version (-08) exists of draft-ietf-6man-why64-05

Abstract

   The length of IP prefixes is an information used by forwarding and
   routing processes is policy-based.  As such, no maximum length must
   be assumed by design.

   Discussions on the 64-bit boundary in IPv6 addressing revealed a need
   for a clear recommendation on which bits must be used by forwarding
   decision-making processes.  This document sketches a recommendation
   to be followed by forwarding and routing designs with regards to the
   prefix length.  The aim is to avoid hard-coded routing and forwarding
   designs that exclude some IP prefix lengths.

Requirements Language

[snip]

1.  Introduction

   Recent discussions on the 64-bit boundary in IPv6 addressing
   ([I-D.ietf-6man-why64]) revealed a need for a clear recommendation on
   which bits must be used by forwarding decision-making processes.

   A detailed analysis of the 64-bit boundary in IPv6 addressing, and
   the implication for end-site prefix assignment, is documented in
   [I-D.ietf-6man-why64].  No recommendation is included in
   [I-D.ietf-6man-why64].

   It is fundamental to not link routing and forwarding to the IPv6
   prefix/address semantics [RFC4291].  This document includes a
   recommendation for that aim.

   Forwarding decisions made by routers primarily rely upon a longest
   prefix-match algorithm.  Like in IPv4, the IPv6 prefix-match
   algorithms involve one critical operation which is the comparison of
   a destination address with a prefix present in a routing table (e.g.,
   compare the 2001:db8::1 address with the 2001:db8::/64 prefix).  The
   recommendation of this document is to be followed by that critical
   operation.

   It is important that the compare operation be a bit-wise comparison,
   and not a byte-wise comparison.

2.  Recommendation

   Forwarding decision-making processes MUST NOT restrict by design the
   length of IPv6 prefixes.  In particular, forwarding processes MUST be
   designed to process prefixes of any length up to /128, by increments
   of 1.

   Obviously, policies can be enforced to restrict the length of IP
   prefixes advertised within a given domain or in a given
   interconnection link.  These policies are deployment-specific and/or
   driven by administrative (interconnection) considerations.

   This recommendation does not conflict with the 64-bit boundary
   involved when IPv6 stateless address autoconfiguration (SLAAC,
   [RFC4862]) is used on links such as Ethernet [RFC2464].

   Some lookup algorithm implementations (find the prefix matching a
   given destination address) may be affected by this recommendation,
   even more so for IPv6 than IPv4.  The performance of some
   implementations may be degraded when prefix lengths are longer than
   /64.

3.  IANA Considerations

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Dec 2014 08:15:43 +1300

> No doubt. But 2460, 4291, and all the rest came from IPv6 or 6man. Why on earth would they ask *us* to say that?

Because, I think, there was a feeling that there's nothing wrong with the
standards track documents, but something wrong with the way some parts
of the industry have interpreted them.

It's been clear to me since 1994 that IPv6 shares the CIDR/VLSM model
with IPv4 and therefore any length prefix is routeable. But I must say
that when we drafted RFC-to-be draft-ietf-6man-why64 (which has just
reached AUTH48), we didn't find anywhere that this is stated in detail.
There is this in RFC 4291:

"2.5.  Unicast Addresses

   IPv6 unicast addresses are aggregatable with prefixes of arbitrary
   bit-length, similar to IPv4 addresses under Classless Inter-Domain
   Routing."

We state it more extensively in the first paragraph of
draft-ietf-6man-why64,
but that's Informational.

> Tell you what. Between now and 12/31, many of us are going to be out of sight and out of mind. I’ll run a WGLC, starting 1/4/2015

Being European, I read that as 1st of April but maybe that's not what
you mean ;-)

> and running for two weeks. If we have any disagreement beyond nits, I’ll express amazement, and if we don’t, I’ll do what I think the 6man chairs should have done, which is send it to my favorite AD for publication. In the same call, I’ll ask whether it should be adopted as a working group document, and if (as I expect) we’re all OK with that, I’ll ask Mohamed to file the update-to-pick-up-comments as draft-ietf-v6ops-cidr-prefix.
> 
> <rant #1>

Read draft-ietf-6man-why64, which may even be RFC7xxx before the holidays.
There is breakage in some scenarios (but *not* routing protocol breakage).

> Of course, I have the same question about bit 70 and 71 of the address (bit’s 6 and 7 of the RFC 4291 IID). In what case, specified in what RFC and/or implemented in what hardware or software, do w…

Read RFC 7136. The answer: you're right, nobody should care.

> 1) I don’t know why this isn’t a BCP - a one-shot standard. It’s not like we’re going to demonstrate interoperable implementations and bump it from Proposed Standard to Standard. That’s not a stron…

I agree. I think this is addressed mainly to implementers and BCP
would be appropriate. The sentence I quoted from RFC 4291 is
the standards-track backing for the correct implementation practice.

> 2)   == Outdated reference: A later version (-08) exists of draft-ietf-6man-why64-05

And it will be RFC7xxx well before this draft is done.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Dec 2014 19:57:39 -0300

Fred,

On 12/20/2014 03:50 AM, Fred Baker (fred) wrote:
> No doubt. But 2460, 4291, and all the rest came from IPv6 or 6man.
> Why on earth would they ask *us* to say that?

IMO, this should really be considered a clarification of the standard,
and done in 6man. But, at the end of the day, it's better to do it
wherever than bouncing the doc back and forth from one wg to another.

> <rant #1> We have a convention that calls for a 64 bit IID on unicast
> addresses, but are quite happy to use, to pick one documented
> example, 127 bit prefixes among consenting adults.

Some see the /127 thing as a kludge to mitigate a bug in router
implementations (namely, NCE).

> <rant #2> Of course, I have the same question about bit 70 and 71 of
> the address (bit’s 6 and 7 of the RFC 4291 IID). In what case,
> specified in what RFC and/or implemented in what hardware or
> software, do we extract an EUI-64 or EUI-48 from the IID?

Some people reportedly use this for trouble-shooting. -- IMO, they
shouldn't, but...

> If it was a
> Privacy/Temporary address, or a SEND CGA Address, or something out of
> RFC 6052, what would we get if we did?

Garbage. But is' even simpler than that. MS Windows does not use the
traditional SLAAC scheme (i.e. "embed the MAC address") for the stable
addresses. -- so you don't even need to think of CGAs or temp addresses.

> Why, oh why, does it matter,
> and who actually cares, whether the IID is a locally-significant or
> globally significant value, or whether someone thought it came from a
> multicast MAC address? </rant>

FWIW, while arguing the same thing that you're arguing (i.e., I'm with
you here), some people have argued that MAC addresses are printed in
boxes, and that they like to "predict" the IPv6 addresses that will be
employed by these boxes.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Randy Bush <[email-masked]>
Date: Mon, 22 Dec 2014 18:42:41 -0500

i think i have already voiced my strong support of this draft.  but it
seems to be bouncing around wgs, so i'll give it a shot here.

this is a no-brainer, but i am confident we can make it a religious war.

randy