Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

[Timothy Winters <[e-mail]>]

Hi Fernando,

IPv6 Ready Logo have a test that advertises a prefix length of /96 for
SLAAC, with the a flag set and we check that it's used for on-link
determination as per 4862.

"In fact, the advertised length has non-trivial meaning for on-link
      determination in [RFC4861] where the sum of the prefix length and
      the interface identifier length may not be equal to 128.

If you read 5.5.3 of 4862 it has some text about prefix length and
interface-id having to add up to 128.

"If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored."

We haven't tried /3 but I'd be happy to try it on implementations to see
what they do if it's interesting to the working group.   My guess is they
will ignore it for SLAAC but use it for on-link.

~Tim

On Tue, Jan 17, 2017 at 9:04 PM, Fernando Gont <[e-mail]>
wrote:

> On 01/17/2017 09:16 PM, Manfredi, Albert E wrote:
> >> -----Original Message----- From: ipv6
> >> [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> >
> >> I think that the discussion on the IETF list has already shown that
> >> there is no consensus for the current text. I don't agree with it
> >> any more, either. It hides the tension between CIDR and the
> >> consistent length needed for SLAAC.
> >>
> >> Hence I'm still proposing that we change it. I think the median
> >> view at the moment is for the version that runs
> >>
> >> ...  For all currently allocated unicast addresses, except those
> >> that start with the binary value 000, that length should be 64
> >> bits.
> >
> > I think that as things are today, for unicast addresses allocated
> > that may use SLAAC, the "should" might not be strong enough. We have
> > no other implementation of SLAAC, other than one that uses 64-bit
> > IIDs. But I agree with you, when you said that future implementations
> > may not require 64-bit IIDs for SLAAC.
> >
> > But I completely concur with your point about tension with CIDR. In
> > fact, one thing that has always bothered me about the wording "all
> > currently allocated unicast addresses, except those that start with
> > the binary value 000," is that it sounds like the 64-bit IID rule
> > holds for the majority of the unicast address space. But that's not
> > true. Only 1/8 of the total address space is "currently assigned to
> > unicast," and a subset of that 1/8th has the stipulation that the
> > IIDs can be of any length.
> >
> > But the majority of the unicast address space is unconstrained, as it
> > should be. Somehow, it always ends up sounding the 64-bit IID is a
> > fixture, in most IPv6 unicast.
>
> Has anyone tred what happens if a prefix from::/3 is advertised for slaac?
>
> I wouldn't be surprised if, if we happen to want to use non-64 IIDS for
> ::/3, we find that we cannot because this 64-bit value is hardcoded
> everywhere.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR