On Tue, Feb 21, 2017 at 2:56 PM, Mark Smith <markzzzsmith@xxxxxxxxx> wrote:
On 22 February 2017 at 06:21, Karsten Thomann <karsten_thomann@xxxxxxxxx> 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@xxxxxxx> 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
"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