On 15/02/2017 22:31, otroan(_at_)employees(_dot_)org 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.
Brian
Do you have implementation reports and are there not interoperability
problems here?
Best regards,
Ole