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

[David Farmer <[e-mail]>]

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


> > 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


> > 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
===============================================