Subject: Re: [Bier] [v6ops] IPv6 link-local traffic questions

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Mar 2020 22:09:54 +0100

On Thu, Mar 12, 2020 at 11:33:37AM +1100, Jen Linkova wrote:
> I believe it depends what you are trying to achieve. If you want to
> make sure that the traffic never leaves the network - then hop limit =
> 1 helps. But using link-local sources/destinations would help even
> better if the routers comply with RFC4291 Section 2.5.6

Yes, i am assuming 2.5.6 is mandatory given how this is standards track
and how abence of RFC2119 langauge does not render "must" into a non
standard requirement.

> If you want to make sure those packets are not sent by a malicious
> party from outside - hop limit shall be 255.
> For example, see RFC4861 Section 3.1
> Neighbor Discovery.

Ah, nice. I never looked into all those encoding details. Thanks.

Preceeding RFC5082 and hence not referring to it, and neither does
RFC5082 refer to RFC4861, thats why i couldn't easily find it by sea4rching.

> > There is an additional set of consideration re. link-local traffic
> > when trying to use it as a HW accelerated tunneling mechanism across links,
> > a use we both have in ANIMA, and maybe get the same in BIER (probably
> > other WGs too, not sure).
> >
> > In implementations, i have seen quite a range of issues with
> > accelerated forwarding planes across link-local addressed tunnels,
> > and when using non-link-local addresses (loopback addresses),
> > the HW plane forwarding might have issues doing HW forwarding, because
> > usually TTL=1 is only used for control plane traffic. Of course,
> > this is not a good architectural argument, but if given architectural
> > leeway to even choose 42, maybe GTSM/255 is easier to be supported
> > across various HW accelerated forwarding planes than 1.
> >
> > Opinions and experiences welcome!
> 
> If you control the router I'd say 'link-local source/destination,
> HL=255 AND RFC4291 would be the best option.

RFC4291 seems redundant given how its mandatory anyhow, but of course
helpfull to remind readers of new specs.

Given how 4291 is widely deployed it certainly qualifies well as
sufficient proof of the mechanism widely deployed - for control plane.

So, effectively, architcturally, the sending TTL is a choice of the application,
and for control plane apps, we evolved choosing from 1 first and now BCP
is 255.  Coming from multicast, i kinda grew up with the
belief there is a MUST use TTL=1 somewhere for a long time (when using
link-local addresses), but never verified that belief.

Still hesitant of prescribing 255 for hardware accelerated forwarding 
plane use case, but given how link-local tunnels aren't really a thing
it would be hard to find prior evidence of successful wide deployment.
Given how i tinkered with them, i've seen all type of troubles,
including TTL ones.

> I did see a few devices somewhere far away sending me ICMPv6 (packet
> too big) from their link-local addresses but it was not very common
> case.

Agree. same here.

Thanks & Cheers
    Toerless

> 
> -- 
> SY, Jen Linkova aka Furry

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Mar 2020 22:36:01 +0100

On Thu, Mar 12, 2020 at 12:18:32PM +1100, Mark Smith wrote:
> RFC4007  allows packets with link-local destinations to be forwarded
> by a router, but only back onto the same link:

Oh, my favourite coffin nail RFC.

> "Thus, if a
>    router receives a packet with a link-local destination address that
>    is not one of the router's own link-local addresses on the arrival
>    link, the router is expected to try to forward the packet to the
>    destination on that link (subject to successful determination of the
>    destination's link-layer address via the Neighbor Discovery protocol
>    [9]).  The forwarded packet may be transmitted back through the
>    arrival interface, or through any other interface attached to the
>    same link."
>
> 
> I think in theory that could also mean forwarded to another router on
> the link that then forwards back again onto the link etc., so it is
> valid for a packet with a link-local destination address to have an
> initial Hop Count value that allows it to be forwarded by multiple
> routers, all limited to being forwarded within the same link.

So this behavior breaks both TTL=1 and RFC5082 packets.

Nice. This RFC is getting better every time i learn more of it.

> This draft might be useful, as it collects together and summarises
> information about using Link-Local Addresses (and is something I've
> been meaning to get back to updating, suggestions welcome):
> 
> How to use IPv6 Link-Local Addresses in Applications
> https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00

Nice.

Let me split that off.

cheers
    Toerless

---

From: Erik Kline <[email-masked]>
Date: Thu, 12 Mar 2020 16:49:39 -0700

> Nice. This RFC is getting better every time i learn more of it.

My personal experience is that 255 is standard for link-local unicast
communications, and 1 is commonly used for link-local multicast.

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

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 12 Mar 2020 17:05:01 -0700

interesting exchange and Erik's last observation (ttl=1 and LL for
multicast) puts it on the point, we are talking here a suggestion for BIER
control plane where the contained packet is multicast. I would hate to see
a multicast packet due to TTL > 1 end up in funky place and replicated
there.

Another interesting question is what if the LL source and destination are
the same and TTL>1 but AFAIK that cannot happen since LL is generated using
EUI-64 (albeit to my surprise I saw enough customers running same LL
address on all links of a device & this is valid :-/

That aside, as I mentioned to Toerless that LL with TTL=1 is usual stuff
since long time, we are talking here either something like BFD router to
router or now in case of BIER it's suggested to be used as "implicit one
hop tunnel" basically carrying BIER frame router-to-router instead of ether
encaps (since BIER is L2.5, strictly speaking "abusing" v6 as transport is
bit rich but it satisfies things like HOMENET which need mutlicast very
nicely where the silicon doesn't need to process BIER but processes naive
v6 easily, after v6 decaps it can go to slow path since HOMENET doesn't
need any serious mcast throughtput [but nothing special AFAIS if the
silicon chooses to process it after the decaps when demand arises or when
used e.g. in core])

thanks

--- tony

On Thu, Mar 12, 2020 at 4:50 PM Erik Kline <[email-masked]> wrote:

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 13 Mar 2020 03:00:43 +0100

Tony:

> a multicast packet due to TTL > 1 end up in funky place and replicated

I was actually talking about the "TTL=1" (*) requirement in 
section 2 of draft-zhang-bier-bierin6, and that is an IPv6 unicast
data plane packet, not a multicast packet. It just carries a mlticast packet.

Which packet where you talking about ?

But your point about possible undesirable replication if TTL>1 for
link-local multicast packets is interesting. I had actually not thought
about that, and can not remember an example. Do you have one ?
RFC5082 for once does not mention the words multicast or unicast,
si it's anybody's guess how it feels its recommendation should be
applied (usually mentioning nothing means unicast only, so in that
sense it could be argued to not be intended to apply to multicast).

> address on all links of a device & this is valid :-/

Probably not an issue for the v6 encap layer, but the multicast
layer: RPF failure, or bit-reset in BIER for multicast payloads.

> router

Yes, has been forever for IPv4 multicast link-local and all the
IPv6 link-local i know (e.g.: OSPF). But i just learned from this
thread that IPv6 Neighbor Discovery multicast packets use 255
(predating RFC5082).

I was also interested i there are any rules which HC to use, but
seemingly it is a free choice of the application,  so we (BIER in IPv6)
can decide as we please, we just may need to beat up the 1 vs 255
argument from their technical proc/cons. 

> or now in case of BIER it's suggested to be used as "implicit one

May sales pitch would be : Putting something new over L2 can be harder for
wide-ranging adoption, and you need to start thinking about possible L2
differences. Being able tto run it over link-local IPv6 is a nice way
to avoid those issues. I dor for example also have a draft in ANIMA
doing exactly the same thing (not for multicast).

Thanks
    Toerless

> --- tony

(*) standard disclaimer: Yes, i do complain to authors using IPv4 terms
for equivalent IPv6 functions, but i complain even more to IPv6 for the gratuitous
renaming of perfect names in IPv6.