On 16/02/2017 10:34, otroan@xxxxxxxxxxxxx wrote: > Brian, > >>>>>> Brian, changing the 64 bit boundary is such a big change that I would >>>>>> claim it is far outside the scope of advancing 4291 to Internet standard. >>>>>> >>>>> >>>>> Agreed. >>>> >>>> Of course. The point is only that it's a parameter in the design of SLAAC, >>>> whose value is set by the address architecture. >>> >>> If your statement is that we only have the 64 bit boundary because of SLAAC I believe you are wrong. >>> Can you provide any support for that view? >> >> No, that's not what I'm saying. I'm saying that SLAAC - by design - would work >> with any reasonable IID length, but we've chosen to fix it at 64. >> >>> If I understand you correctly, your proposal is to change the fixed 64 bit Interface-ID length in IPv6 to a variable one, with an exception for links where SLAAC is used. >> >> No. At least not in the foreseeable future. But we should allow for the fact that if >> prefixes between /64 and /127 are used, routing needs to just work. That's all. >> >>> How do you practically suggest to do this, given the issues raised in https://tools.ietf.org/html/rfc7421#section-4.1 ? >> >> I'm not suggesting any change to normal subnets, where all those issues apply. >> I can't see how /64 can be changed for them, without changing a great many >> things. >> >>> Do you think this change is appropriate in the context of advancing 4291? >> >> I don't think I have suggested text that would lead to a single instruction in >> running code being changed. > > CURRENT (RFC4291bis): > > 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] > > PROPOSED: > > 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 unicast > addresses used for Stateless Address Autoconfiguration [RFC4862] is required > to be 64 bits long. The rationale for the 64 bit > boundary in IPv6 addresses can be found in [RFC7421] > > > My reading of the proposed text, which certainly may be wrong, given that English is not my first language, is that it leaves the Interface-ID length of links _not_ using SLAAC undefined, i.e. not fixed at 64. Is there any other way to interpret this sentence? > > The proposed text appears to make the Interface-ID length an operational choice. Ah, yes, there is a slight loophole there (but I think that somewhere else we require all nodes to implement SLAAC, so maybe there isn't a real loophole.) I would certainly agree to wording that closes that loophole. But the anomalies people noted around the '000' subset need to fixed. Brian > How is that _not_ changing the 64 bit boundary? > > Best regards, > Ole >