Re: [v6ops] RFC4861 question

Le 27/06/2019 à 10:01, Mark Smith a écrit :
> On Thu, 27 Jun 2019 at 16:14, Alexandre Petrescu 
> <alexandre.petrescu@gmail.com> wrote:
>> 
>> With respect to backwards compatibility: some implementations of
>> RIO require PIO to be present too.   That is a problem of forward
>> compatibility, because it does not allow for RIO (the new feature)
>> to be present just itself, it requires the PIO (the old feature).
>> 
>> I would like to ask whether RIO is allowed to exist in itself,
>> without PIO.
>> 
> 
> See RFC 4191. PIOs aren't required, related to, involved in or a 
> dependency for RIO processing. The implementations you're referring
> to sound like they have a bug.

Thank you for the reply.

Friendly note: what I discuss here may be subject to IPR that I may author.

You are saying that PIOs are not required to, related to or involved in 
a dependency for RIO processing, and that the implementation is wrong. 
I do not disagree with the spirit.

On another hand, I think like this: SLAAC was invented to connect Hosts 
to the Internet.  That is obtained typically by giving it a PIO and a 
default route.  If it only gives it a PIO then it's not really 
sufficient.  If it only gives it a defroute it's not really sufficient 
either.

For this reason the chain of programming instructions on Host's SLAAC 
puts these things one after the other (defroute and PIO); which one 
comes first varies, but they are always one after the other, not in 
parallel.  If one is there, the other is there too, and vice-versa.

RIO is a kind of PIO.  It was implemented starting from PIO.  That 
inherited it that dependency on the default route.  Which makes it that 
RIO depends on PIO and default route presence, in some implementations.

If the RIO were implemented from scratch, then there would be no 
dependency on PIO or defroute,  indeed.

In V2V networks: in there, there are no default routes and no PIO on the 
OCB link.  But we need RIO to exchange and propagate routes between cars.

I am not insisting to explain, and I will not write a draft about this.

But we have an implementation between 3 cars and it works.  We struggled 
a lot with the openwrt open source implementation of odhcp client in 
order to make it work.  And that was the problem: the dependency between 
RIO, PIO and defroute code.

The spec can stay as it wants to stay.

Alex

>> 
>> Le 26/06/2019 à 23:01, Dave Thaler a écrit :
>> 
>> ➢  Is there some reason to prefer RIOs?
>> 
>> 
>> 
>> RFC 4191 says:
>> 
>> There are several reasons for using a new Route Information Option
>> 
>> instead of using flag bits to overload the existing Prefix
>> 
>> Information Option:
>> 
>> 
>> 
>> 1. Prefixes will typically only show up in one option, not both, so
>> a
>> 
>> new option does not introduce duplication.
>> 
>> 
>> 
>> 2. The Route Information Option is typically 16 octets while the
>> 
>> Prefix Information Option is 32 octets.
>> 
>> 
>> 
>> 3. Using a new option may improve backwards-compatibility with
>> some
>> 
>> host implementations.
>> 
>> 
>> 
>> Then see all of section 3 of that RFC for the analysis of
>> compatibility.
>> 
>> 
>> 
>> Dave
>> 
>> 
>> 
>> From: Templin (US), Fred L <Fred.L.Templin@boeing.com> Sent:
>> Wednesday, June 26, 2019 1:18 PM To: Dave Thaler
>> <dthaler@microsoft.com>; 神明達哉 <jinmei@wide.ad.jp> Cc: 6man
>> <6man@ietf.org> Subject: RE: [v6ops] RFC4861 question - short
>> prefixes in PIOs
>> 
>> 
>> 
>> Hi Dave,
>> 
>> 
>> 
>> I agree that what I want is more akin to RIO than to “traditional”
>> PIO, but then I saw
>> 
>> David Farmer’s note about RFC8028 and that seems to be more in line
>> with what I am
>> 
>> looking for.
>> 
>> 
>> 
>> Certainly, multi-homing needs to be accommodated and RFC8028 seems
>> to support
>> 
>> that while using the ubiquitous standard PIO albeit with A=L=0. Is
>> there some reason
>> 
>> to prefer RIOs?
>> 
>> 
>> 
>> Thanks - Fred
>> 
>> 
>> 
>> From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Wednesday,
>> June 26, 2019 10:40 AM To: Templin (US), Fred L
>> <Fred.L.Templin@boeing.com>; 神明達哉 <jinmei@wide.ad.jp> Cc: 6man
>> <6man@ietf.org> Subject: RE: [v6ops] RFC4861 question - short
>> prefixes in PIOs
>> 
>> 
>> 
>> RIO should add a route with the next hop of the router, where the
>> prefix is not an on-link prefix.
>> 
>> PIO should be for on-link prefixes, i.e., either the receiver
>> should create a SLAAC address or the receiver should add an on-link
>> route, or both.
>> 
>> 
>> 
>> Dave
>> 
>> 
>> 
>> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Templin (US), Fred
>> L Sent: Wednesday, June 26, 2019 9:52 AM To: 神明達哉
>> <jinmei@wide.ad.jp> Cc: 6man <6man@ietf.org> Subject: RE: [v6ops]
>> RFC4861 question - short prefixes in PIOs
>> 
>> 
>> 
>> OK, thanks. Then, it seems to me that what I really want is a Route
>> Information Option
>> 
>> (RIO) [RFC4191] because what I am looking for is a way to establish
>> a short prefix in the
>> 
>> IPv6 forwarding table that directs packets to a specific outgoing
>> interface (or, more
>> 
>> precisely, to a specific router on a specific outgoing interface).
>> 
>> 
>> 
>> But, with RIO, the prefix would not be added to the interface
>> prefix list in the same
>> 
>> way as for PIO - correct?
>> 
>> 
>> 
>> Thanks - Fred
>> 
>> 
>> 
>> 
>> 
>> From: 神明達哉 [mailto:jinmei@wide.ad.jp] Sent: Wednesday, June 26,
>> 2019 9:23 AM To: Templin (US), Fred L <Fred.L.Templin@boeing.com> 
>> Cc: 6man <6man@ietf.org> Subject: Re: [v6ops] RFC4861 question -
>> short prefixes in PIOs
>> 
>> 
>> 
>> (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> 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.
>> 
>>> 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.
>> 
>>> 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.
>> 
>>> 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.
>> 
>>> 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.
>> 
>> 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 Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>>
>>
>> 
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>

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