Subject: RFC4861 question - short prefixes in PIOs

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 26 Jun 2019 15:56:36 +0000

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?

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?

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

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?

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?

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Wed, 26 Jun 2019 09:22:56 -0700

(I'm only copying 6man, as I believe it's purely a protocol spec
question)

At Wed, 26 Jun 2019 15:56:36 +0000,
> mean that 2001:db8::/32 should be added to the interface prefix list?

In my interpretation (ditto for subsequent questions), yes.

> by 2001:db8::/32 will trigger Address Resolution instead of forwarding to
a default router?

Yes.

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

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

> 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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 26 Jun 2019 16:52:07 +0000

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:[email-masked]]
Sent: Wednesday, June 26, 2019 9:23 AM
To: Templin (US), Fred L <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs

Yes.

--
JINMEI, Tatuya

---

From: Dave Thaler <[email-masked]>
Date: Wed, 26 Jun 2019 17:40:11 +0000

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 <[email-masked]> On Behalf Of Templin (US), Fred L
Sent: Wednesday, June 26, 2019 9:52 AM
To: 神明達哉 <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: [v6ops] RFC4861 question - short prefixes in PIOs

Thanks - Fred

From: 神明達哉 [mailto:[email-masked]]
Sent: Wednesday, June 26, 2019 9:23 AM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs

Yes.

You may also want to check
https://tools.ietf.org/html/draft-jinmei-6man-prefix-clarify-00<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-jinmei-6man-prefix-clarify-00&data=02%7C01%7Cdthaler%40microsoft.com%7C8553bcb309874f844e9408d6fa56b303%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636971647627136134&sdata=AQ8dP3HU4UonvrTkx5TMKYxgS%2FI%2BAxkImKLi%2B9M8aBk%3D&reserved=0>
I believe it clarifies many of the above questions.

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Wed, 26 Jun 2019 14:01:10 -0500

Some additional comments regarding questions #3 and #4 are below;

On Wed, Jun 26, 2019 at 11:23 AM 神明達哉 <[email-masked]> wrote:

> "Templin (US), Fred L" <[email-masked]
> <Fred.L.Templin@boeing..com>> wrote:
> >

+1

> > by 2001:db8::/32 will trigger Address Resolution instead of forwarding

+1

>                      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]).

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

> the protocol specification doesn't say it *must* be so.

+1

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
===============================================
David Farmer               Email:[email-masked]
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
===============================================

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 26 Jun 2019 20:17:51 +0000

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:[email-masked]]
Sent: Wednesday, June 26, 2019 10:40 AM
To: Templin (US), Fred L <[email-masked]>; 神明達哉 <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: [v6ops] RFC4861 question - short prefixes in PIOs

Dave

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Templin (US), Fred L
Sent: Wednesday, June 26, 2019 9:52 AM
To: 神明達哉 <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] RFC4861 question - short prefixes in PIOs

Thanks - Fred

Yes.

--
JINMEI, Tatuya

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 26 Jun 2019 20:22:03 +0000

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:[email-masked]]
Sent: Wednesday, June 26, 2019 12:01 PM
To: 神明達哉 <[email-masked]>
Cc: Templin (US), Fred L <[email-masked]>; 6man <[email-masked]>
Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs

On Wed, Jun 26, 2019 at 11:23 AM 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:
(I'm only copying 6man, as I believe it's purely a protocol spec
question)

+1

Yes.

+1

RFC 8028 updates RFC4861 and talks about A=L=0, it talks about this in Section 2.1;

I wouldn't call it a “route-to-interface” it should be a route pointing to the route as the next-hop.

+1

--
JINMEI, Tatuya
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

David Farmer               Email:[email-masked]<mailto:[email-masked]>

---

From: Dave Thaler <[email-masked]>
Date: Wed, 26 Jun 2019 21:01:24 +0000

Ø  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 <[email-masked]>
Sent: Wednesday, June 26, 2019 1:18 PM
To: Dave Thaler <[email-masked]>; 神明達哉 <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: [v6ops] RFC4861 question - short prefixes in PIOs

Hi Dave,

Thanks - Fred

To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; 神明達哉 <[email-masked]<mailto:[email-masked]>>

Dave

Thanks - Fred

Yes.

You may also want to check
https://tools.ietf.org/html/draft-jinmei-6man-prefix-clarify-00<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-jinmei-6man-prefix-clarify-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ca4ed3a82231c4312e3e508d6fa736514%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636971770868375490&sdata=TqUONb7gp99ceqpcgKZXYrSEnBZq8uUPk3FJJIuot8c%3D&reserved=0>
I believe it clarifies many of the above questions.

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Wed, 26 Jun 2019 16:17:35 -0500

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 <
[email-masked]> wrote:

> *From:* David Farmer [mailto:[email-masked]]
> *Sent:* Wednesday, June 26, 2019 12:01 PM
> *To:* 神明達哉 <[email-masked]>
> *Cc:* Templin (US), Fred L <[email-masked]>; 6man <
> [email-masked]>
> *Subject:* Re: [v6ops] RFC4861 question - short prefixes in PIOs
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jun 2019 11:03:43 +1200

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

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 <[email-masked] <mailto:[email-masked]>> 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:[email-masked] <mailto:[email-masked]>]
>     *To:* 神明達哉<[email-masked] <mailto:[email-masked]..jp>>
>     *Cc:* Templin (US), Fred L <[email-masked] <mailto:Fred.L.Templin@boeing..com>>; 6man <[email-masked] <mailto:[email-masked]>>
>     *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 神明達哉 <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>         "Templin (US), Fred L" <[email-masked] <mailto:Fred.L.Templin@boeing..com>> wrote:
>         >
>         In my interpretation (ditto for subsequent questions), yes.____
> 
>     __ __
> 
>     +1____
> 
>      ____
> 
>         Yes.____
>     __ __
>     +1____
>      ____
>                              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;____
> 
>     __ __
> 
>           Section 6.2.3 of [RFC4861]).____
> 
>      ____
> 
>         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.____
> 
>      ____
> 
>         the protocol specification doesn't say it *must* be so.____
> 
>     __ __
> 
>     +1 ____
> 
>      ____
> 
>         JINMEI, Tatuya____
>         [email-masked] <mailto:[email-masked]>
>         --------------------------------------------------------------------____
> 
> 
>     ____
> 
>     __ __
> 
>     -- ____
> 
>     David Farmer               Email:[email-masked] <mailto:[email-masked]>
>     =============================================== ____
> 
> 
> 
> -- 
> David Farmer               Email:[email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Thu, 27 Jun 2019 11:04:26 +1000

+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

>> > by 2001:db8::/32 will trigger Address Resolution instead of forwarding

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.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 27 Jun 2019 08:13:55 +0200

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.

Alex

Le 26/06/2019 à 23:01, Dave Thaler a écrit :
>
> ➢Is there some reason to prefer RIOs?
>
> RFC 4191 says:
>
> *From:*Templin (US), Fred L <[email-masked]>
> *Sent:* Wednesday, June 26, 2019 1:18 PM
> *To:* Dave Thaler <[email-masked]>; 神明達哉<[email-masked]>
> *Cc:* 6man <[email-masked]>
> *Subject:* RE: [v6ops] RFC4861 question - short prefixes in PIOs
>
> Hi Dave,
>
> *From:*Dave Thaler [mailto:[email-masked]]
> *Sent:* Wednesday, June 26, 2019 10:40 AM
> *To:* Templin (US), Fred L <[email-masked] 
> <mailto:[email-masked]>>; 神明達哉<[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* 6man <[email-masked] <mailto:[email-masked]>>
> *Subject:* RE: [v6ops] RFC4861 question - short prefixes in PIOs
>
> 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 <[email-masked] <mailto:[email-masked]>> *On 
> Behalf Of *Templin (US), Fred L
> *Sent:* Wednesday, June 26, 2019 9:52 AM
> *To:* 神明達哉<[email-masked] <mailto:[email-masked]>>
> *Cc:* 6man <[email-masked] <mailto:[email-masked]>>
> *Subject:* RE: [v6ops] RFC4861 question - short prefixes in PIOs
>
> *From:*神明達哉[mailto:[email-masked]]
> *Sent:* Wednesday, June 26, 2019 9:23 AM
> *To:* Templin (US), Fred L <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* 6man <[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked]>> wrote:
> >
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-jinmei-6man-prefix-clarify-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ca4ed3a82231c4312e3e508d6fa736514%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636971770868375490&sdata=TqUONb7gp99ceqpcgKZXYrSEnBZq8uUPk3FJJIuot8c%3D&reserved=0>

---

From: Mark Smith <[email-masked]>
Date: Thu, 27 Jun 2019 18:01:18 +1000

On Thu, 27 Jun 2019 at 16:14, Alexandre Petrescu
<[email-masked]> 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).
>

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.

> ➢  Is there some reason to prefer RIOs?
>
>
>
> RFC 4191 says:
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Jun 2019 17:40:34 -0400

Templin (US), Fred L <[email-masked]> wrote:
    > 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”?

As others have said, and I find the RFC rather obtuse in this way, I think
that only thing one can say is that if L=1, then devices in that indicated
PIO can be found using ND (appropriately multicast).

I think that when it is associated with the link, one can use SLAAC to assign
interfaces, but can't use ND to find neighbours.

Hairpin'ing all traffic through the advertising router when L=0 seems like
the only general solution.  But, I can imagine many situations where if a
Neighbour Cache entry somehow existed, then it could be used.

I think that hairpin'ing all traffic has many interesting uses when it comes
to providing firewalling (such as RFC8520) between devices.

    > as a “route-to-interface” with the receiving interface as the next hop?

I don't think so.
That would imply it was on-link, and L=0 means it isn't.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mark Smith <[email-masked]>
Date: Fri, 28 Jun 2019 14:24:51 +1000

> interfaces, but can't use ND to find neighbours.

I see it as three separate things:

1. During IP address planning, assign a quantity of address space (prefix)
to the link.

2. if SLAAC is to be used within that prefix, A=1 (the RFC 4861 default).

3. if hosts are to consider addresses within the link's address
space/prefix to be directly reachable over the link, then L=1 (the RFC 4861
default).

> the only general solution.

You can't hairpin literally all traffic via a router using the PIO L=1 or 0
mechanism, because the Link-Local prefix has L=1 set in all hosts per RFC
5942, and it isn't currently possible to change it.

This can cause problems as it conflicts with IPv6 address selection, which
says LLs are preferred over GUA/ULA addresses. So if a host was presented
with a set of DAs that includes LLs and GUA or ULAs, the LL would be
preferred and fail, while if it chose a GUA or ULA DA it would work.

Some might argue that's good for security, however I think LLs are more
secure and reliable addresses for applications to use over GUAs and ULA
addresses. I think that is why LLs are preferred in IPv6 default address
selection.

  But, I can imagine many situations where if a
> to providing firewalling (such as RFC8520) between devices.

Per-device traffic accounting performed by a router could be another use
case e.g. BRAS exporting that information via RADIUS accounting.

>     > 4) If yes to 3), does it mean that 2001:db8::/32 should be added to
> the
>     > IPv6 forwarding table

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 28 Jun 2019 14:39:59 +0200

Le 27/06/2019 à 10:01, Mark Smith a écrit :
>> 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).
>> 
> 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

>> From: Templin (US), Fred L <[email-masked]> Sent:
>> Wednesday, June 26, 2019 1:18 PM To: Dave Thaler
>> <[email-masked]>; 神明達哉 <[email-masked]> Cc: 6man
>> <[email-masked]> Subject: RE: [v6ops] RFC4861 question - short
>> prefixes in PIOs
>> 
>> 
>> 
>> Hi Dave,
>> 
>> 
>> 
>> From: Dave Thaler [mailto:[email-masked]] Sent: Wednesday,
>> June 26, 2019 10:40 AM To: Templin (US), Fred L
>> <[email-masked]>; 神明達哉 <[email-masked]> Cc: 6man
>> <[email-masked]> Subject: RE: [v6ops] RFC4861 question - short
>> prefixes in PIOs
>> 
>> 
>> 
>> 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 <[email-masked]> On Behalf Of Templin (US), Fred
>> L Sent: Wednesday, June 26, 2019 9:52 AM To: 神明達哉
>> <[email-masked]> Cc: 6man <[email-masked]> Subject: RE: [v6ops]
>> RFC4861 question - short prefixes in PIOs
>> 
>> 
>> 
>> From: 神明達哉 [mailto:[email-masked]] Sent: Wednesday, June 26,
>> 2019 9:23 AM To: Templin (US), Fred L <[email-masked]> 
>> Cc: 6man <[email-masked]> Subject: Re: [v6ops] RFC4861 question -
>> short prefixes in PIOs
>> 
>> 
>> 
>> At Wed, 26 Jun 2019 15:56:36 +0000, "Templin (US), Fred L"
>> <[email-masked]> wrote:
>>> 
>> 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.
>> 
>> 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.
>> 
>> https://tools.ietf.org/html/draft-jinmei-6man-prefix-clarify-00 I
>> believe it clarifies many of the above questions.
>> 
>> -- JINMEI, Tatuya
>> 
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Philip Homburg <[email-masked]>
Date: Fri, 28 Jun 2019 18:32:14 +0200

>Neighbour Cache entry somehow existed, then it could be used.

Note that the router may send redirects. So in theory it is only the
first packet to a neighbor that needs to go through the router.

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Jun 2019 10:49:37 +1000

> first packet to a neighbor that needs to go through the router.

You'd have to switch them off in this case,.

That has also been a common thing to do in IPv4 in general. I can't exactly
remember why, because it is so long ago that I learned to do it, however I
expect it is to stop packets being punted to the control plane for redirect
generation. Non-optimal forwarding or dropping, in particular in forwarding
hardware, is cheaper than optimal forwarding and control plane load of
generating redirects. It also probably creates a control plane DoS attack
vector.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 29 Jun 2019 05:04:48 +0000

Hello Mark

Please keep in mind the use case is wireless (802.11OCB) and the router is a L3 AP. To your point:

On .11 the only direct connectivity that is known is STA to AP. A STA may or may not be reachable from another STA at the PHY layer depending on their relative location. In usual .11 they will not have unicast keys to talk to one another anyway. The L3 AP MUST NOT use redirects.

On OCB in particular there is neither L2 association nor L2 security. The only way for a L3 AP to know who’s there is the L3 association (aka registration, RFC 8505).

A fixed L3 AP (an RSU in OCB) may provide L3 connectivity to vehicles.

If the vehicle moves then it needs heuristics to figure the best router e.g., the most recently seen. When I implemented Mobile IP and NEMO in our routers some 15 years ago I had to place a number of non-standard heuristics in ND to make that work. One of them was to use the router that exposes a PIO as GW for packets that are sourced on the prefix in the PIO.

I started an IPv6 over wireless draft. There’s a lot that needs saying in there.

All the best,

Pascal

Le 29 juin 2019 à 02:50, Mark Smith <[email-masked]<mailto:[email-masked]>> a écrit :

That has also been a common thing to do in IPv4 in general. I can't exactly remember why, because it is so long ago that I learned to do it, however I expect it is to stop packets being punted to the control plane for redirect generation. Non-optimal forwarding or dropping, in particular in forwarding hardware, is cheaper than optimal forwarding and control plane load of generating redirects. It also probably creates a control plane DoS attack vector.