Re: [v6ops] IPv6 link-local traffic questions

[Toerless Eckert <[e-mail]>]

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

-- 
---
[e-mail]