Subject: [v6ops] 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: 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
> --------------------------------------------------------------------
> 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.

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