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

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 <ek.ietf@gmail.com> wrote:

>
>
> On Thu, Mar 12, 2020 at 2:36 PM Toerless Eckert <tte@cs.fau.de> wrote:
>
>> 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.
>>
>
> My personal experience is that 255 is standard for link-local unicast
> communications, and 1 is commonly used for link-local multicast.
>
> > 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
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>