Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Le 24/02/2017 à 08:15, David Farmer a écrit :


On Thu, Feb 23, 2017 at 9:13 PM, Fernando Gont
<fgont@xxxxxxxxxxxxxxx <mailto:fgont@xxxxxxxxxxxxxxx>> 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.

Well, in a sense yes.

I had an addressing architecture discussion today with a novice
practitioner and she was surprised to hear that
2001:db8:0:cd30::/60 is the same as
2001:db8:0:cd31::/60, as
2001:db8:0:cd32::/60,... yet we can't say
2001:db8:0:cd3::/60

which makes one wonder why dont we say 2001:db8:0:cd3*::/60?

An architecture document would be a good guidance on this.

But an architecture document that starts to qualify deployments as more
important than others, or cellular vs dsl, or ptp vs shared... or give
implementation guidance, it's maybe beyond archi, IMHO.

Alex

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

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@xxxxxxx
<mailto:Email%3Afarmer@xxxxxxx> Networking & Telecommunication
Services Office of Information Technology University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
<tel:(612)%20626-0815> Minneapolis, MN 55414-3029   Cell:
612-812-9952 <tel:(612)%20812-9952>
===============================================




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]