----- Original Message -----
From: "David Farmer" <farmer(_at_)umn(_dot_)edu>
Sent: Friday, February 24, 2017 7:15 AM
On Thu, Feb 23, 2017 at 9:13 PM, Fernando Gont wrote:
I'd remove a few sentences here, as in:
IPv6 unicast routing is based on prefixes of any valid length up
to
128 [BCP198]. Subnet prefixes of /64 are RECOMMENDED for general
purpose use, subnet prefixes of /127 are RECOMMENDED for point-
to-point router links [RFC6164]. The rationale for the 64 bit
boundary in IPv6 addresses can be found in [RFC7421].
The problem is you have stripped out all the implementation guidance
and
only left operational guidance. But maybe the the right idea is to
separate the two, putting the operational guidance in Section 2.4
where we
are talking about prefixes and the implementation guidance in section
2.4.1
where we are talking about IIDs.
2nd Paragraph of 2.4;
IPv6 unicast routing is based on prefixes of any valid length up to
and including 128 [BCP198]. However, subnet prefixes of 64 bits in
length are REQUIRED for use with Stateless Address
Autoconfiguration
(SLAAC)[RFC4862] and are RECOMMENDED for all other general purpose
use. The rationale for the 64 bit boundary in IPv6 addresses can be
found in [RFC7421].
David
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. It would beg the question as
to why this one paragraph, or set of paragraphs, use this language when
all the others do not. That is, it will cause us to discuss all the
other places where such language might have been used but was not; 10,
20 50 ... Well, at a quick glance, I reckon there are about 60 such
places, 60 more discussions?
Tom Petch
4th paragraph of 2.4.1
For all unicast addresses, except those that start with the binary
value 000, support for Interface IDs that are 64 bits long is
REQUIRED, support for other Interface IDs lengths is OPTIONAL. The
rationale for the 64 bit boundary in IPv6 addresses can be found in
[RFC7421].
This clearly say that implementations that only support 64 bit IID
lengths
are just fine, but also says implementations that allow IID lengths
other
than 64 bits are just fine too. I think the current and historic text
actually implies implementations are not to allow other IID lengths,
is
that what we really intended to say? A lot of implementations seem to
allow other IID lengths, are they wrong? I don't think so.
This also gives strong operational guidance that 64 bit length subnet
prefixes are expected in most situations. Reinforcing the 64 bit
boundary,
however without outlawing the use of other subnet prefix lengths when
implemented and they could be useful. This is done without
distracting
from the 64 bit boundary, by not directly calling attention to RFC6164
or
the other longer prefix lengths. Since BCP198 and RFC7421 both
reference
RFC6164 calling it out here doesn't seem necessary, and would
unnecessarily
weaken the focus on the 64 bit boundary that I'm trying to maintain.
I don't see how this text would require changes in any code, nor does
it
imply other IID lengths are not allowed operationally, again which a
lot of
implementations seem to allow.
Thanks.
--
===============================================
David Farmer Email:farmer(_at_)umn(_dot_)edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
===============================================