----- Original Message -----
From: "Sander Steffann" <sander(_at_)steffann(_dot_)nl>
Sent: Sunday, February 19, 2017 9:48 PM
Sorry, replying to myself. An off-list discussion made me realise I made
an error.
IPv6 unicast routing is based on prefixes of any valid length up to
128 bits [BCP198]. However, in accordance with the reasoning explained
in [RFC7421], the Interface ID part of host interface addresses is
generally 64 bits, with exceptions only provided in special cases
expressly recognized in IETF standards track documents.
Sounds good to me. It's clear on routing, it's clear on IIDs being 64
bits long except in special standards-track cases without trying to
enumerate them and it provides an informational reference to explain why
it should be 64 bits.
I have to clarify this a little bit. When reading it I was focusing on
the "is generally 64 bits" part. In hindsight the exceptions clause is
too strict though. See below for the rest.
For my personal part, I’d prefer to see a clear statement here using
RFC 2119 requirements language keywords, but I recognize that consensus
probably requires compromise on that point. Hence, the proposed
refinement above, which does not use RFC 2119 keywords. (Here is how I
would write this with keywords: “IPv6 unicast routing is based on
network prefixes that MAY have any valid length up to 128 bits [BCP198].
However, in accordance with the reasoning explained in [RFC7421], the
Interface ID part of host interface addresses SHOULD be 64 bits with
exceptions only provided in special cases expressly recognized in IETF
standards track documents.”)
I'm a bit worried that the "MAY have any valid length up to 128 bits"
definition is too loose when read by router vendors, but otherwise that
version sounds good as well. I like to see explicit clear guidance in
standards documents.
I like the SHOULD. It allows for exceptions.
<tp>
Sander
Note that 4291bis does not use the language of RFC2119 and does not even
include a reference to it.
This reflects the consensus of the WG; to introduce such language now
would, IMHO, open up another can of worms, of which we already have
quite a few.
Tom Petch
Such special case are recognised by the IETF and documents in
standards track. Still good. There should be a clear guidelines to
network operators. I have seen too many beginners mess up their
addressing plans because they think they know better.
But on the other hand the text above limits exceptions to ONLY the IETF
standards track, and that is too strong. Operators who know what they
are doing must not be limited.
When writing my previous email I was focusing on giving guidance to
operators, and thinking about inexperienced operators. When I saw that
exceptions were taken into account I thought that that was good, but in
hindsight the exceptions as written are too limited.
So to summarise I think we need to state that in general the IID SHOULD
be 64 bits, exceptions MAY be defined, preferably in IETF standards
track documents, equipment MUST allow operators to use any prefix length
up to 128, and routing MUST support those prefix lengths.
Sorry if my series of messages were confusing. I'm trying to strike a
balance between giving good guidance while allowing well-informed
deviations, making sure that the text doesn't unnecessarily limit
network operators while also protecting users so that ISPs don't start
delegating them /96s "because it's more than enough and the RFC allows
it" etc. (if you think that last argument is farfetched, sorry, I've
seen too many ISPs start from there and only make a more reasonable
addressing plan because the "/64 is the standard", so we shouldn't be
too loose about that)
When reading the different arguments on this list I often find myself
agreeing to most of them, even the conflicting ones, because I
understand where the different viewpoints are coming from. And they are
all important. It's difficult enough to try to fit everything together
in my head, and I hope that this time I did a better job of writing it
down in this email :)
Cheers,
Sander