Subject: Re: notes on 6man-why64

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2014 23:02:42 +1300

Hi,

On 05/03/2014 22:46, 神明達哉 wrote:
> (I'm restating what I tried to say at the mic yesterday as suggested)
> 
> 1. In Section 5.1, the draft says
> 
>    This section provides a survey of the processing of Neighbor
>    Discovery options which include prefixes that are different than /64.
> [...]
>    o  the "A" bit in the Prefix Information Options is honored only if
>       the prefix length is 64.
> 
> This could read as if the implementation hardcodes the magic number
> of 64 and rejects other values for PIO-A.  But at least in case of
> BSDs (and I suspect it's the same for other implementations), I
> suspect it ignores the A-flag aspect of PIO simply applying Section
> 5.3 of RFC4862:
> 
>    If the sum of the link-local prefix length and N is larger than 128,
>    autoconfiguration fails and manual configuration is required.  The
>    length of the interface identifier is defined in a separate link-
>    type-specific document, which should also be consistent with the
>    address architecture [RFC4291] (see Section 2).
> 
> where the length of the IID *happens to be* 64 bits per the
> corresponding IPv6-over-foo specification (I guess it's ethernet in
> the experiment).

That makes sense. Indeed that is why, if you wanted to change this,
you would have to change all the IPv6-over-foo drafts as well as
the addressing architecture (and then change the -over-foo code).

> 
> 2. ISC DHCPv6 client unconditionally installs a /64 prefix as on-link when it
> configures an interface with an address (some specific OS vendors seem
> to change this default behavior by tweaking a client-side script).  It
> does this (even if technically it violates the protocol) because if
> there's no router in the link the hosts effectively wouldn't
> communicate each other with the configured addresses since the
> "on-link assumption" was removed in RFC4861.  This is not really about
> the magic number of 64, but an implementation may sometimes pick up a
> specific value of prefix length due to the removal of the on-link
> assumption, and the value chosen will be most likely to be 64.  So the
> draft may want to refer to this incident.

Yes, that also makes sense.

Thanks!

   Brian

> --
> JINMEI, Tatuya