Re: [v6ops] RFC4861 question

On 27-Jun-19 09:17, David Farmer wrote:
> 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.

I think that's right. The thrust of RFC8028 is to ensure that source address selection works appropriately in a multihomed host, as well as picking the appropriate first hop router. Fred Templin's requirement seems to be a little different.

   Brian

> 
> But, hope that helps.
> 
> On Wed, Jun 26, 2019 at 3:22 PM Templin (US), Fred L <Fred.L.Templin@boeing.com <mailto:Fred.L.Templin@boeing.com>> 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:farmer@umn.edu <mailto:farmer@umn.edu>]
>     *Sent:* Wednesday, June 26, 2019 12:01 PM
>     *To:* 神明達哉<jinmei@wide.ad.jp <mailto:jinmei@wide.ad..jp>>
>     *Cc:* Templin (US), Fred L <Fred.L.Templin@boeing.com <mailto:Fred.L.Templin@boeing..com>>; 6man <6man@ietf.org <mailto:6man@ietf.org>>
>     *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 神明達哉 <jinmei@wide.ad.jp <mailto:jinmei@wide.ad.jp>> 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" <Fred.L.Templin@boeing.com <mailto: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
>         ipv6@ietf.org <mailto:ipv6@ietf.org>
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>         --------------------------------------------------------------------____
> 
> 
>     ____
> 
>     __ __
> 
>     -- ____
> 
>     ===============================================
>     David Farmer               Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
>     Networking & Telecommunication Services
>     Office of Information Technology
>     University of Minnesota  
>     2218 University Ave SE        Phone: 612-626-0815
>     Minneapolis, MN 55414-3029   Cell: 612-812-9952
>     =============================================== ____
> 
> 
> 
> -- 
> ===============================================
> David Farmer               Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota  
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 