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

[David Farmer <[e-mail]>]

Actually, I misspoke a little in my response to #4, it's not setting the
next-hop destination for a destination prefix, for that you would use RIOs.
It about setting the next-hop destination for traffic sourced from
addresses covered by PIOs and this would override RFC4191 default router
preferences. The gory details are discussed in section 3 of RFC8028.

In other words, RFC8028 is about the routing of sources in PIOs, including
ones with A=L=0, the routing of destinations is a subject of RIOs.

Brain and Fred, as the authors, can probably explain it better than I can.

But, hope that helps.

On Wed, Jun 26, 2019 at 3:22 PM Templin (US), Fred L <
[e-mail]> wrote:

> Thanks for your response, David:
>
>
>
> >> RFC 8028 updates RFC4861 and talks about A=L=0, it talks about this in
> Section 2.1;
>
>
>
> That does indeed look like the kind of behavior I am after, but how is it
> different than
>
> RFC4191 RIOs? RIOs include a Preference value for each router that
> advertises the
>
> prefix. Do we lose that feature by going with PIOs per RFC8028?
>
>
>
> Thanks - Fred
>
>
>
> *From:* David Farmer [mailto:[e-mail]]
> *Sent:* Wednesday, June 26, 2019 12:01 PM
> *To:* 神明達哉 <[e-mail]>
> *Cc:* Templin (US), Fred L <[e-mail]>; 6man <
> [e-mail]>
> *Subject:* Re: [v6ops] RFC4861 question - short prefixes in PIOs
>
>
>
> 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
> ===============================================
>


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