Re: RFC4861 question - short prefixes in PIOs

[Mark Smith <[e-mail]>]

On Fri., 28 Jun. 2019, 07:41 Michael Richardson, <[e-mail]>
wrote:

>
> Templin (US), Fred L <[e-mail]> 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.
>

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



>
> Hairpin'ing all traffic through the advertising router when L=0 seems like
> 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
> 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.
>

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
>     > 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 <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>