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

[Brian E Carpenter <[e-mail]>]

On 20/12/2014 19:50, Fred Baker (fred) wrote:
> 
>> On Dec 19, 2014, at 7:47 PM, Lorenzo Colitti <[e-mail]> wrote:
>>
>> On Sat, Dec 20, 2014 at 10:35 AM, Fred Baker (fred) <[e-mail]> 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.
> 
> 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.

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

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

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

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

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

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

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