ietf
[Top] [All Lists]

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

2017-02-15 15:53:03
On 16/02/2017 10:34, 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.

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


<Prev in Thread] Current Thread [Next in Thread>