Re: [v6ops] RFC4861 question - short prefixes in PIOs

[Mark Smith <[e-mail]>]

On Thu., 27 Jun. 2019, 05:02 David Farmer, <[e-mail]> wrote:

> Some additional comments regarding questions #3 and #4 are below;
>
> On Wed, Jun 26, 2019 at 11:23 AM 神明達哉 <[e-mail]> wrote:
>
>> (I'm only copying 6man, as I believe it's purely a protocol spec
>> question)
>>
>> At Wed, 26 Jun 2019 15:56:36 +0000,
>> "Templin (US), Fred L" <[e-mail]
>> <Fred.L.Templin@boeing..com>> wrote:
>> >
>> > I have an RFC4861 question (several actually) on short prefixes in RA
>> PIOs:
>> >
>> > 1) If a PIO includes a prefix with length less than 64 (e.g.,
>> 2001:db8::/32) and with L=1, does it
>> >
>> > mean that 2001:db8::/32 should be added to the interface prefix list?
>>
>> In my interpretation (ditto for subsequent questions), yes.
>>
>
> +1
>

+1

RFC 5942 clarifies these sorts of questions well, and is an update to RFC
4861.

 Subnet Model: The Relationship between Links and Subnet Prefixes



>
>> > 2) If yes to 1), does it mean that packets forwarded to the interface
>> for any destination covered
>> >
>> > by 2001:db8::/32 will trigger Address Resolution instead of forwarding
>> to a default router?
>>
>> Yes.
>>
>
> +1
>

That's really what the L bit is saying to the host - for the address space
specified in the PIO, perform Neighbour Discovery because those addresses
are being explicitly asserted to be directly reachable over the link.

A bit clumsy, however a better name for the L bit might have been "Perform
ND".

As RFC 5942 says, the on link information for a prefix could be manually
configured in a host, which is why the L bit in a PIO not being set is not
an absolute statement that addresses from within the PIO prefix are not on
the link.





>
>> > 3) If the PIO instead has L=0, does it mean that 2001:db8::/32 is
>> “associated” with the link but
>> > not necessarily “on-link”?
>>
>> I'm not sure how to interpret it (in particular I'm not sure what
>> "associated with the link" means), but my interpretation of L=0 is
>> that the RA doesn't say anything about the on-link-ness of that
>> prefix.  See also the description of the L flag in RFC4861:
>>
>>       L              1-bit on-link flag.  [...]  When
>>                      not set the advertisement makes no statement about
>>                      on-link or off-link properties of the prefix.  In
>>                      other words, if the L flag is not set a host MUST
>>                      NOT conclude that an address derived from the
>>                      prefix is off-link.  That is, it MUST NOT update a
>>                      previous indication that the address is on-link.
>>
>
> RFC 8028 updates RFC4861 and talks about A=L=0, it talks about this in
> Section 2.1;
>
>    In some circumstances, both L and A might be zero.  If SLAAC is not
>    wanted (A=0) and there is no reason to announce an on-link prefix
>    (L=0), a PIO SHOULD be sent to inform hosts that they should use the
>    router in question as the first hop for packets with source addresses
>    in the PIO prefix.  An example case is the MIF router in Figure 1,
>    which could send PIOs with A=L=0 for the common prefix.  Although
>     this does not violate the existing standard [RFC4861], such a PIO has
>    not previously been common, and it is possible that existing host
>    implementations simply ignore such a PIO or that existing router
>    implementations are not capable of sending such a PIO.  Newer
>    implementations that support this mechanism should be updated
>    accordingly:
>
>    o  A host SHOULD NOT ignore a PIO simply because both L and A flags
>       are cleared (extending Section 6.3.4 of [RFC4861]).
>
>    o  A router SHOULD be able to send such a PIO (extending
>       Section 6.2.3 of [RFC4861]).
>
>
>> > 4) If yes to 3), does it mean that 2001:db8::/32 should be added to the
>> IPv6 forwarding table
>> >
>> > as a “route-to-interface” with the receiving interface as the next hop?
>>
>> No.  See the second MUST NOT of the RFC4861 text cited above.
>>
>
> I wouldn't call it a “route-to-interface” it should be a route pointing to
> the route as the next-hop.
>
>
>> > 5) Does A=1 have any meaning for prefixes with length less than 64? Or,
>> must prefixes with
>> >
>> > length less than 64 set A=0?
>>
>> As far as RFC4861 is concerned, the A flag has no meaning, regardless
>> of the prefix length.  It only matters in RFC4862.  In terms of
>> RFC4862, whether "A=1 has any meaning for prefixes with length less
>> than 64" depends on the length of the IID of the link; if the prefix
>> length != 128-IIDLength, the validation rule 5.5.3 d) of RFC4862 makes
>> the prefix ignored.  If non-64 prefix length is invalid in terms of
>> RFC4862 in that sense, it'd be *safe* to avoid setting the A flag, but
>> the protocol specification doesn't say it *must* be so.
>>
>
> +1
>
>
>> You may also want to check
>> https://tools.ietf.org/html/draft-jinmei-6man-prefix-clarify-00
>> I believe it clarifies many of the above questions.
>>
>> --
>> JINMEI, Tatuya
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>