On Tue, Feb 21, 2017 at 2:56 PM, Mark Smith <markzzzsmith(_at_)gmail(_dot_)com>
wrote:
On 22 February 2017 at 06:21, Karsten Thomann
<karsten_thomann(_at_)linfre(_dot_)de>
wrote:
Am Dienstag, 21. Februar 2017, 18:27:39 schrieb Job Snijders:
On Tue, Feb 21, 2017 at 09:49:32AM +0900, Lorenzo Colitti wrote:
On Tue, Feb 21, 2017 at 8:57 AM, Job Snijders <job(_at_)ntt(_dot_)net>
wrote:
<snip>
-------
OLD:
IPv6 unicast routing is based on prefixes of any valid length up to
128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes
on inter-router point-to-point links. However, the Interface ID of
all unicast addresses, except those that start with the binary value
000, is required to be 64 bits long. The rationale for the 64 bit
boundary in IPv6 addresses can be found in [RFC7421]
NEW:
IPv6 unicast routing is based on prefixes of any valid length up to
128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface ID
of unicast addresses is required to be 64 bits long. In other use
cases different prefix sizes may be required. For example [RFC6164]
standardises 127 bit prefixes on inter-router point-to-point links.
For most use cases, prefix lengths of 64 bits is RECOMMENDED, unless
there are operational reasons not to do so.
Satisfies my desired outcome of the text, but I would like to modify it:
IPv6 unicast routing is based on prefixes of any valid length up to
128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface ID
of unicast addresses is required to be 64 bits long. An exception is
for
example [RFC6164] which standardises 127 bit prefixes on
point-to-point
links. The RECOMMENDED prefix length is 64 bit,
Firstly, the last update to the suggested text seems great to me. As I see
it, operating a reasonably large mixed-mode network... and some smaller
networks around the place... There are operational reasons why /64 makes
sense, for instance: "I just want all these things to get a v6 address, I
don't really care which one" and SLAAC fits that bill.
For my network interfaces I may (for my own reasons) decide that /127 is
perfect for me, and roll out all NNI type interfaces as /127's (hey, I even
helped with the rfc about this) ... for 'operational reasons' I don't care
about SLAAC, so I don't care about /64... and having to 'break the
standard' seems silly. Yes, this case is already taken care of by
RFC6164... but i have servers on which I don't need SLAAC to manage
addressing and simply assign addresses according to some other
systems-management automation... I even limit the number of devices per
subnet for internal reasons, so I don't need a /64 there, I just need a
/124.
I think the idea that some 'applications' need /64 is fine... but making
'all the things must be /64' just silly, in light of the actual deployment
and use-cases today. Therefore, the text as proposed above seems on target.
There have certainly been plenty of baked-in (to asics and/or software)
assumptions about /64 over the years, we shouldn't want that to happen
longer term and wording like:
"However, the Interface ID of
all unicast addresses, except those that start with the binary value
000, is required to be 64 bits long"
ends up letting people make assumptions again, which get baked into
code/asics :(
It has to be stronger than a RECOMMENDED, because that implies it is
an arbitrary choice that won't have any protocol operational and
privacy or security impacts. That is not the case.
Someone else pointed out that the 2119 language isn't used/referenced in
4291, looking quickly:
$ grep MUST rfc4291.txt
$
seems to agree with that assertion... so I don't think "RECOMMENDED" is
right here, I think: "recommended" is correct.. and that since 2119 isn't
used you can't expect anything in the document to actually be binding :(
whoops! Also, /64 really was an 'arbitrary choice' ... more or less anyway.
Trusting in people to follow without MUST/SHOULD/RECOMMENDED seems a bit
crazy, but :)
thanks job@ for making a suggested fix here, I too am troubled by the
'classful' ideas in the ipv6 space, those didn't seem useful long-term in
ipv4 so I can't see how they would be useful in the short-term here in
v6-land.
I'm really not a fan of the: "But this makes subnetting easy!" arguments...
i don't think those hold water since we have tooling to do subnetting, it's
just not a problem looking for a solution anymore.
-chris