Subject: IPv6 link-local traffic questions

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

Sorry for cross posting, but this is both ops and arch questions.

I was trying to find any generic description that/if link-local IPv6
traffic MUST/SHOULD use Hop-count 1, but could not find one in
rfc8200 or rfc4291 and its updates. Instead, text like
MUST set Hop-limit to 1 is repeated in various RFCs using link-local
IPv6 traffic.

Am i overlooking something ? Or is this intentional in the IPv6 architecture ?

If intentional, i guess it means: Any RFC introducing some type of link-local
traffic can specify Hop-limit requirements for its traffic. As in
"our WG likes 42 as the Hop-limit" (silly to me, but should be fine with
IPv6 architecture then, right ?).

In one of my draft document reviews using such link-local IPv6 traffic,
EricV brought up the Q if that traffic shouldn't use RFC5082 instead
of Hop-Count 1 too. But given how we do not seem to have architectural
recommendations for TTL=1 (unless, quite likely i overlook something),
and given how i am not aware of any actual use of GTSM, i am quite
weary to go down that route. Aka: Would like learn of actual uses of
GTSM with IPv6.

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!

Thanks!
    Toerless

---

From: Jen Linkova <[email-masked]>
Date: Thu, 12 Mar 2020 11:33:37 +1100

> MUST set Hop-limit to 1 is repeated in various RFCs using link-local

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

> weary to go down that route. Aka: Would like learn of actual uses of

Neighbor Discovery.

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

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.

-- 
SY, Jen Linkova aka Furry

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Mar 2020 12:18:32 +1100

Hi Toerless,

> MUST set Hop-limit to 1 is repeated in various RFCs using link-local

RFC4007  allows packets with link-local destinations to be forwarded
by a router, but only back onto the same link:

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

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

Regards,
Mark.

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

---

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

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

> For example, see RFC4861 Section 3.1

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.

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

> too big) from their link-local addresses but it was not very common

Agree. same here.

Thanks & Cheers
    Toerless

-- 
---
[email-masked]

---

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

> by a router, but only back onto the same link:

Oh, my favourite coffin nail RFC.

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

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 14 Mar 2020 01:43:03 -0400

Interesting question.

So IPv4 and IPv6 header both have an 8 bit field with maximum TTL of 255.
The initial TTL for a flow is usually set to 60 and is decremented hop by
hop by the router till the packet reaches its final destination.

Distance vector based routing protocols are based on hop count such as RIP
and link state protocols such as OSPF and ISIS are based on a topological
link state database and path vector protocols such as BGP based on BGP path
selection algorithm.

IPv6 control plane packets such as ICMPv6 ND packets NS NA type 135/136 and
RD RS/RA type 133/134 all have a hop count limit of 255.

Since RD RS/RA and ND NS/NA packets all have a link local source IPv6
address and multicast  destination  FF02.  I am not sure why the TTL is 255
as the packet has local scope only to be forwarded on the local subnet.  I
would thin the TTL for these packets should be 1.

OSPF packets have ttl of 255
ISIS packets have ttl 1

BGP packets have ttl 1

As far as GTSM, it is an alternative to cryptography option for securing
routing protocols.  Most enterprises and SPs in general use cryptography to
secure routing protocol adjacencies.  I don’t know of any implementation or
operator using GTSM.

With GTSM the idea is to use an expected TTL value configured by adjacent
peers to be set to different from the default value.  So that value can be
any value other then the default value.

Thanks

Gyan

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 14 Mar 2020 02:07:34 -0400

Jen

I always wondered why RFC 4862 states that ND & RD packets have TTL 255.
We have run into so many PSIRT bugs with ND which makes it more problematic
having the TTL 255.

Since ND & RD packets would always be local scope in your response to
Toreless you mentioned that GTSM that ND using 255 is kind of an example of
GTSM in the sense that the TTL is set to 255 for a direct neighbor
adjacency.  I think though the security issues of TTL 255 with ND/RD
packets seem to make security a bigger issue then just leaving TTL=1.

Gyan

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Karl Auer <[email-masked]>
Date: Sat, 14 Mar 2020 19:11:14 +1100

>From RFC4861:

   "By setting the Hop Limit to 255, Neighbor Discovery
    is immune to off-link senders that accidentally or
    intentionally send ND messages.  In IPv4, off-link
    senders can send both ICMP Redirects and Router
    Advertisement messages."

RFC4861 also requires RA and NA packets with any other TTL value to be
silently discarded by any receiving node.

I can't find my original source, but my notes in a training course I
developed a while ago have this to say about why:

   "Why does 255 mean “local source”? Because routers
    decrement the hop limit on packets passing through
    them, and discard packets where the hop count
    decrements to zero. It is impossible to decrement
    a one-byte counter to 255 without passing through
    zero, because 255 is the maximum value such a counter
    can have. So the value 255 means that the packet must
    have been generated on the local link."

Probably would be better expressed as "must have originated on the
local link".

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D

---

From: Ole Troan <[email-masked]>
Date: Sat, 14 Mar 2020 09:30:17 +0100

Gyan,

ND packets have a hop limit of 255 for security. A receiver of an ND packet is required to verify hop limit == 255. This protects against off-link attacks. 

That is not possible with hop limit 1.

Cheers 
Ole

> On 14 Mar 2020, at 09:12, Karl Auer <[email-masked]> wrote:
>

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Mar 2020 09:39:56 +0100

Hi,

> We have run into so many PSIRT bugs with ND which makes it more problematic

Read what has been written in this thread.

On the *receiving end* you MUST filter on TTL=255 for ND packets, to ensure
that these packets can never be send from an off-link node.

Consequently, you MUST send with TTL=255, so that the filter on the receiving
end can work.

> packets seem to make security a bigger issue then just leaving TTL=1.

You do not seem to understand the security issues involved :-)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 14 Mar 2020 10:26:02 -0400

Thanks Ole

Gyan

On Sat, Mar 14, 2020 at 4:30 AM Ole Troan <[email-masked]> wrote:

> Gyan,
>
> ND packets have a hop limit of 255 for security. A receiver of an ND
> packet is required to verify hop limit == 255. This protects against
> off-link attacks.
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 14 Mar 2020 10:31:43 -0400

Makes sense.

Thanks

Gyan

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 14 Mar 2020 13:38:19 -0400

Toreless & Tony

I read through the draft for BIER over IPv6.

https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06

So since the BIER header bitmask that denotes the BFERs in the Domain to
replicate the multicast packets is encoded in the DestOp processed by the
BFER, the packets should not be forwarded past the BFER is my guess is with
ttl 255.  With IPv6 ND with ttl 255 example the packet can be forwarded
past the adjacent node but I have not seen that happen.  I believe Jen
Linkova on this thread has seen that. Since the BFER dest options has to
have the BIER bit mask encoding or the packet is dropped I believe is your
security protection from forwarding past the BIER with 255 ttl if you
decided to go that route.

Under BIERv6 packet processing should help if ttl 255 is used to prevent
forwarding outside of bier domain

A packet having a 'BIER Specific Handling' indication but not having
   a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
   and the process can be refered to the example in section 3.2
<https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06#section-3.2>.

   A packet not having a 'BIER Specific Handling' indication but having
   a BIER option SHOULD be processed normally as unicast forwarding
   procedures, which may be a behavior of drop, or send to CPU, or other
   behaviors in existing implementations.

Under 5.3 security considerations should also help with ttl 255 and
forwarding outside of BIER domain

For a router incapable of BIERv6, such BIERv6 packet will not be
   processed by the procedure described in this document, but be
   processed as normal IPv6 packet with unknown option, and the existing
   security considerations for handling IPv6 options apply.  Possible
   way of handling IPv6 packets with BIER option may be send to CPU for
   slow path processing, with rate-limiting, or be discarded according
   to the local policy.

   For a router capable of BIERv6, such BIERv6 packet MUST NOT be
   forwarded, but should be processed as a normal IPv6 packet with
   unknown option, or additionally and optionally be countered and
   logged if the router is capable of doing so.

Kind regards

Gyan

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 20 Mar 2020 15:30:09 +0100

> We have run into so many PSIRT bugs with ND which makes it more problematic

Is there anything that would makes you think 255 is a worse
choice for security than 1 ? Or is it just implementation bugs ?

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 20 Mar 2020 15:19:07 +0000

> On 20 Mar 2020, at 14:30, Toerless Eckert <[email-masked]> wrote:
> 

1 anyone can fake.

255 can only come from a neighbour which it is used as a simple security check.

Stewart

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 21 Mar 2020 02:21:07 +0100

Thank, Stewart,

Yes, i know.

My question was specifically wrt. mentioning of PSIRT bugs by Gyan,
sorry if my reply was unclear. Of course only interested in 
any additional security insight that is public and related to the
choice of TTL by ND, not any vendor internal / implementation
bug issues.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 20 Mar 2020 18:57:30 -0700

Yepp, that's personally I prefer on multicast TTL=1 (and also on ISIS &
e.g. on expired draft where we were carrying ISIS natively over IP). The
cost of a frame running away unintended multiple-hops in a control protocol
without a tunnel are simply NOT fun.  The cost of such a thing (and it
happened MORE than once) outweighs IMO the minor security advantage.

If you read v6 BIER drafts you should read
https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has been
published much, much earlier ...

--- tony

On Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra <[email-masked]> wrote:

>    and the process can be refered to the example in section 3.2 <https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06#section-3.2>.
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Mar 2020 22:58:50 -0400

On Fri, Mar 20, 2020 at 9:59 PM Tony Przygienda <[email-masked]> wrote:

> TTL security is a necessity for ND with limited risk of run away ND
> packets as it’s  minimal bandwidth usage.
>

   With a multicast stream the risk is much greater if forwarded multiple
hops past the BFER PE as stated and maybe a high data rate stream so
undesirable to ever happen.

 ND is the only protocol I know of that uses TTL security.

I would go with TTL=1.

If security is a concern in the v6 tunnel, is it possible to add
cryptography to BIER or even setting security TLV in the BIER header
encoded in the DO on the BFIR and then validate the TLV encoding on the
BFER destination endpoint.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Mark Smith <[email-masked]>
Date: Sat, 21 Mar 2020 14:21:51 +1100

On Sat, 21 Mar 2020, 14:00 Gyan Mishra, <[email-masked]> wrote:

>> https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has
>> been published much, much earlier ...
>>
>> --- tony
>>

Can you guarantee a received packet with a Hop Count value of 1 hasn't been
forwarded?

You can when the received packet has a Hop Count of 255.

>> On Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra <hayabusagsm@gmail..com
>> <[email-masked]>> wrote:
>>
>>>
>>> Toreless & Tony
>>>

---

From: Erik Kline <[email-masked]>
Date: Mon, 23 Mar 2020 22:47:06 -0700

>  ND is the only protocol I know of that uses TTL security.

Certainly RFC 4861 message validation sections say the message has to have
a hop limit of 255, so it should go without saying that the spec should be
followed where such text exists.

Also BGP and other routing protocols can use hop limit security.  GTSM (
https://tools.ietf.org/html/rfc5082).  Specifically:
https://tools.ietf.org/html/rfc5082#section-5.1

---

From: Owen DeLong <[email-masked]>
Date: Tue, 24 Mar 2020 15:51:05 -0700

> 
> TTL security is a necessity for ND with limited risk of run away ND packets as it’s  minimal bandwidth usage.
> 
>    With a multicast stream the risk is much greater if forwarded multiple hops past the BFER PE as stated and maybe a high data rate stream so undesirable to ever happen.
> 

If you think this through, it depends on which problem you are trying to solve.

If you are looking to make sure that your packet won’t get accidentally forwarded by a non-malicious router, then a hop limit of 1 works best.
If you are looking to make absolutely certain that the packet didn’t come from a non-local source, then a hop limit of 255 is the only choice.

If you use a hop limit of 1, then a remote attacker only needs to craft a packet with the correct initial hop limit to ensure that it arrives on
your link what the appropriate remaining hop limit of 1.

OTOH, if you require a hop limit of 255 on the receive side (thus requiring that the sender use a hop limit of 255), there’s no way to get
a crafted packet through a (non-malicious) router and still have the packet retain a hop limit of 255.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Mar 2020 15:03:45 +1300

Owen,

> your link what the appropriate remaining hop limit of 1.

Only if the router violates the spec:
"  Routers must not forward any packets with Link-Local source or
   destination addresses to other links." [RFC4291]
Do we have any evidence of routers that are broken in this way?

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Tue, 24 Mar 2020 19:20:02 -0700

> On Mar 24, 2020, at 19:03 , Brian E Carpenter <[email-masked]> wrote:
> 
> Owen,
> 

Point is I don’t see how a TTL of 1 is better regardless of this… A TTL of 255 guarantees that the packet doesn’t get through, even if it doesn’t
have LL Source or destination. (Imagine a poorly crafted host that doesn’t check NA or RA packets to ensure LL addresses in header?).

Don’t really want the data from those packets in the neighbor table, do you?

Owen

---

From: Gert Doering <[email-masked]>
Date: Wed, 25 Mar 2020 07:48:55 +0100

Hi,

> Do we have any evidence of routers that are broken in this way?

Yes.  Last time we checked, Juniper routers just forward(ed) packets based
on destination address, period.

(This was a few years ago, when trying to figure out what to do against
the then-current resource attacks against IOS XR LPTS with "too many ND
packets", so it might have changed in the meantime)

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2020 09:21:40 +1300

> on destination address, period.

I'm curious. Since link-local addresses are, er, link-local, how would
such a router choose the outgoing interface?

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Wed, 25 Mar 2020 13:35:28 -0700

> On Mar 25, 2020, at 13:21 , Brian E Carpenter <[email-masked]> wrote:
> 

I think that the point of the message is that if the packet has LL Source and non-LL
destination… It could get erroneously forwarded.

Owen

---

From: Gert Doering <[email-masked]>
Date: Wed, 25 Mar 2020 22:05:08 +0100

Hi,

> such a router choose the outgoing interface?

Well, there was an "or" in the paragraph above that I neglected.

Junipers (used to) forward to non-link-local destinations without checking
source address.  So they (used to) violate the "Routes must not forward any
packets with Link-Local source [...] to other links" part.

We noticed when we installed "deny ipv6 fe80::/8 $our_ripe_space::/32"
filters at our edge routers, and saw quite a few hits there, coming
in via transit networks not being numbered from this /32.

As I said, this was a few years ago, we had no Juniper routers ourselves
back then, and no contacts to get this properly addressed.  It might
be fixed by now, or not.  Fairly easy to test, though.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Thu, 26 Mar 2020 14:24:09 +0100

>be fixed by now, or not.  Fairly easy to test, though.

I just noticed that my ISP is sending me those packets. So yes, this
behavior is still alive on todays internet.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2020 08:57:00 +1300

> behavior is still alive on todays internet.

Words fail me. So it seems that setting the hop limit to 255 and
checking on receipt really is desirable.

   Brian

---

From: Jen Linkova <[email-masked]>
Date: Mon, 30 Mar 2020 15:43:58 +1100

> Do we have any evidence of routers that are broken in this way?

I've seen it a few years ago - a few routers (same vendor, based on
EUI-64 based interface IDs) somewhere far far away were sending ICMPv6
errors (packet too big) to my border routers using their link-local
addresses as a source. Those packets successfully reached my network
and got dropped...It was while ago but I'm not sure how much the
situation has improved.