Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Address

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.
How is that _not_ changing the 64 bit boundary?

Best regards,
Ole

signature.asc
Description: Message signed with OpenPGP