Subject: Forwarding Packets With Link Local Destination Addresses

From: Ron Bonica <[email-masked]>
Date: Thu, 7 Jan 2021 17:53:51 +0000

Folks,

According to RFC 4291, "routers must not forward any packets with Link-Local source or destination addresses to other links".

I interpret this statement to include packets that contain routing headers. For example, it forbids an SRv6 packet whose final segment has a locator that begins with FE80.

Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 make this sufficiently clear?

                                                                                                   Ron

Juniper Business Use Only

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Jan 2021 10:08:38 -0800

At Thu, 7 Jan 2021 17:53:51 +0000,

> Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 make this sufficiently clear?

I believe Section 9 of RFC4007 answers the question.  In short, you're
*basically* correct.

I said *basically* because there can be an exception that makes it
legitimate, but I suspect that usually doesn't apply in practice.

--
jinmei

---

From: Ron Bonica <[email-masked]>
Date: Thu, 7 Jan 2021 18:24:10 +0000

Jinmei,

Thanks! I think that the following text from RFC 4007 covers the issue:

"   A node that receives a packet addressed to itself and containing a
   Routing Header with more than zero Segments Left (Section 4.4 of [3])
   first checks the scope of the next address in the Routing Header.  If
   the scope of the next address is smaller than the scope of the
   original destination address, the node MUST discard the packet. "

                                                                   Ron

-----Original Message-----
From: 神明達哉 <[email-masked]> 
Sent: Thursday, January 7, 2021 1:09 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: Forwarding Packets With Link Local Destination Addresses

[External Email. Be cautious of content]

I said *basically* because there can be an exception that makes it legitimate, but I suspect that usually doesn't apply in practice.

--
jinmei

---

From: Fred Baker <[email-masked]>
Date: Thu, 7 Jan 2021 10:29:13 -0800

I would think the RFC is pretty clear on the topic.

Sent from my iPad

> On Jan 7, 2021, at 9:54 AM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> 
> Folks,
>  
> According to RFC 4291, “routers must not forward any packets with Link-Local source or destination addresses to other links”.
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Thu, 7 Jan 2021 10:45:43 -0800

> According to RFC 4291, “routers must not forward any packets with Link-Local source or destination addresses to other links”.

This, of course, imposes a requirement that no routers I’m aware of carry out absent explicit configuration, which is to make a forwarding decision (in this case a filter) based on the source address. Reverse forwarding lookups *might* accomplish this by associating link local addresses with the interface the packet it was received on, but that would only happen if reverse address lookups (normally associated with BCP 38) were enabled. 

So one could argue that RFC 4291 goes beyond its remit in this regard.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2021 19:59:22 +0100

Le 07/01/2021 à 18:53, Ron Bonica a écrit :
> Folks,
> 
> According to RFC 4291, “routers must not forward any packets with 
> Link-Local source or destination addresses to other links”.
> 
> I interpret this statement to include packets that contain routing 
> headers. For example, it forbids an SRv6 packet whose final segment has 
> a locator that begins with FE80.

It's easy to say that 'it begins with fe80' but that is hard to 
implement unless the programmer knows precisely the prefix length.

Some might implement it with a /64 plen, others with a /10 plen, 
depending on which RFC and IANA table one looks at more trustfully.

If one takes literally 'begins with fe80' then it would be a /16, but 
probably that is less likely to be considered seriously.

It might be a problem more of basic link-local address format, and 
probably also of a SRv6 interest.

Alex

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Jan 2021 20:02:17 +0100

On Thu, Jan 07, 2021 at 10:45:43AM -0800, Fred Baker wrote:
> > According to RFC 4291, ???routers must not forward any packets with Link-Local source or destination addresses to other links???.
> 
> This, of course, imposes a requirement that no routers I???m aware of carry out absent explicit configuration, which is to make a forwarding decision (in this case a filter) based on the source address.

The words are english. The sentence structure looks more german, but i still can't parse it.

I also thought we had (source/mask,dest/mask) forwarding for IPv6 multi-homing somehwere in Homenet at some point in time. Without explicit config, just to enable to use source address to steer packets towards the desired ISP exit point.

> Reverse forwarding lookups *might* accomplish this by associating link local addresses with the interface the packet it was received on, but that would only happen if reverse address lookups (normally associated with BCP 38) were enabled. 
> 

"beyond its remit" for mentioning source address ? 

Cheers
    toerless

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jan 2021 20:05:47 +0100

Le 07/01/2021 à 19:24, Ron Bonica a écrit :
> "   A node that receives a packet addressed to itself and containing
> a Routing Header with more than zero Segments Left (Section 4.4 of
> [3]) first checks the scope of the next address in the Routing
> Header.  If the scope of the next address is smaller than the scope
> of the original destination address, the node MUST discard the
> packet. "

Are scopes bigger one than another?

In multicast that may be true, but in unicast it's hard to say a scope
might be smaller or bigger than another scope.

In unicast, there might be only two scopes: LL and global.  It might be
that there is no inclusion from one into another, or it might be that a
size comparison might not be possible.

Intuitively, one might consider that LL scope to be smaller than Global
scope, because of the reach.  But knowing that each iface must have an
LL address whereas not all ifaces have a Global address it might be that
the number of assigned LL addresses is larger than the number of
assigned Global addresses at one point in time.  In that sense, it might
be that the set of LL addresses is much larger (bigger) than the set of
Global addresses.

That is one reason that is hard to implement the paragraph cited in the
beginning of this message.

There is no number in an address that says 'scope', and that could be
used to compare two addresses, and to decide that one address is of a
larger scope than another.

Alex

> -----Original Message----- From: 神明達哉 <[email-masked]> Sent:
> Thursday, January 7, 2021 1:09 PM To: Ron Bonica
> <[email-masked]> Cc: [email-masked] Subject: Re: Forwarding
> Packets With Link Local Destination Addresses
> 
> At Thu, 7 Jan 2021 17:53:51 +0000, Ron Bonica
> <rbonica=[email-masked]> wrote:
> 
>> According to RFC 4291, "routers must not forward any packets with
>> Link-Local source or destination addresses to other links".
>> 
>> headers. For example, it forbids an SRv6 packet whose final segment
>> has a locator that begins with FE80.
>> 
> I believe Section 9 of RFC4007 answers the question.  In short,
> you're *basically* correct.
> 
> -- jinmei 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Jan 2021 09:01:43 +1300

Ron,

 
> Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 make this sufficiently clear?

Yes, and the ensuing discussion about the metaphysics of scope is irrelevant.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Jan 2021 18:40:18 -0300

Hi, Ron,

> make this sufficiently clear?

Let me ask a different question:
Why should this be any different for a routing header? The specs still 
apply.

I'd say that the case of link-locals is probably even "worse", because 
it would mean a link-local address was included in a routing header, to 
be processed by some router elsewhere in the networks. Something that 
doesn't seem to make any sense to me.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 7 Jan 2021 18:45:41 -0500

Ron

In-line

I agree that RFC 4291 although could have been written better.

On Thu, Jan 7, 2021 at 12:54 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Gyan>“ Link local source or destination to any other link” it is trying to
> imply “off link”. Link local cannot be used in an off link scenario.
>

 I agree the verbiage includes an SRv6 SRH inclusive that the final SID
> cannot be a link local address.  As the final SID is copied to the
> destination address of the IPv6 header during processing that would be
> construed as explicit forwarding of a packet which is forbidden.  Link
> local due to “local scope” on link non routable scope, so therefore the
> packet cannot be forwarded using destination link local.  Since this is an
> SRV6 SRH steered transitive path and not packets that are transmitted
> locally between two adjacent nodes such as ND or OSPF for example, this is
> clearly forbidden.  I think the  transitive nature even though it’s hop by
> hop steering, makes it off link routed thus link local destination  is not
> in scope for final SID.
>

> headers. For example, it forbids an SRv6 packet whose final segment has a
> locator that begins with FE80.
>
>
>
>  Agreed.  I think it could be much clearer per my note above.
>
>
>                                                             Ron
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Jan 2021 16:56:45 -0800

At Thu, 7 Jan 2021 18:40:18 -0300,

> Why should this be any different for a routing header? The specs still

The RFC 4291 spec still applies, but if it were only with RFC 4291, we
could allow the following:

- A node sends a packet with a routing header that would route the
  packet to a global address (D1) and then to a link-local (final)
  destination (D2).
- The packet leaves the source link and is delivered to the interface
  corresponding to the global address D1.
- The receiving node now sets D2 as the destination address of the
  IPv6 header and forwards the packet to the link where the packet is
  delivered to D2 (so it does not forward the packet to "other link").

RFC 4007 makes it clearer that this scenario is forbidden.

> doesn't seem to make any sense to me.

Actually, I can imagine a source routing usage where all intermediate
and final destination addresses are link-local, and the packet is
forwarded through nodes within the same link.  It may still be an
imaginary scenario, but it still makes some sense to me (I don't
intend to champion that usage though).

--
JINMEI, Tatuya

---

From: Alejandro Acosta <[email-masked]>
Date: Thu, 7 Jan 2021 21:34:28 -0400

Hello,

   My apologies for using this thread, I have a valid point. My comment 
inline:

> has a locator that begins with FE80.
   In LACNIC we ran a project called Natmeter [1] for about 2 years, we 
obtained a lot of interesting data during this period [2].

   The case is the following, we detected some end-user devices with 
only Link Local addresses (exactly, no GUA nor ULA) that were 
successfully natted and using the web.

   Is it ok?, do you consider it as a forwarding of a packet? was it a 
crazy result? (we saw few samples of this)

Thanks,

[1] 
https://prensa.lacnic.net/news/en/research/lacnic-project-detects-massive-presence-of-nat-boxes-in-the-region

[2] Well, actually it still available with much less successful measurement

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Jan 2021 21:52:13 -0800

At Thu, 7 Jan 2021 20:05:47 +0100,

> size comparison might not be possible.

RFC 4007 explicitly defines the size relationship between scopes:

   There is a size relationship among scopes:

   o  For unicast scopes, link-local is a smaller scope than global.

   o  For multicast scopes, scopes with lesser values in the "scop"
      subfield of the multicast address (Section 2.7 of [1]) are smaller
      than scopes with greater values, with interface-local being the
      smallest and global being the largest.

The above cited text should be interpreted with this definition.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jan 2021 10:32:51 +0100

Le 08/01/2021 à 06:52, 神明達哉 a écrit :
> At Thu, 7 Jan 2021 20:05:47 +0100, Alexandre Petrescu
> <[email-masked]> wrote:
> 
>>> "   A node that receives a packet addressed to itself and
>>> containing a Routing Header with more than zero Segments Left
>>> (Section 4.4 of [3]) first checks the scope of the next address
>>> in the Routing Header.  If the scope of the next address is
>>> smaller than the scope of the original destination address, the
>>> node MUST discard the packet. "
>> 
>> In multicast that may be true, but in unicast it's hard to say a
>> scope might be smaller or bigger than another scope.
>> 
>> In unicast, there might be only two scopes: LL and global.  It
>> might be that there is no inclusion from one into another, or it
>> might be that a size comparison might not be possible.
> 

I do not disagree with you, and I think many more people than just me
understand that ok.

This is about the semantics of words.

'Smaller' scope is not clear what it means.  These unicast addresses
dont have a number in them that is called 'scope' and that could be
compared.

Other RFC uses also the term 'broader' scope, instead of 'larger' scope.

Other RFC also tells that the IID itself (not the address) could be of a
certain scope, which we usually assume to be a characteristic of the
address not just the IID part.  Or says 'local scope' vs 'universal
scope', neglecting that the Globe and the Universe might be not the same
thing.  A Global scope on an IPv6-enabled Mars lander might have a
strange meaning.

Maybe the scope comparison in unicast could make sense when there were
were site-locals, but no more site-locals.

It's the notion of type that makes sense in comparing unicast addresses,
not that of scope.

And, when trying to identify whether a particular address is of a
particular type one absolutely needs the value and the number of bits to
compare.  For LLs one does not have the precise number of bits to
compare, because some RFC says that is 64 others say that is 10.  In
this situation it is impossible to precisely answer whether a particular
address is a link-local address or not.

Of course, we could say  that all addresses that start with fe80 are LLs
but then there are too counter-intuitive examples too that one could
easily build.

> smallest and global being the largest.

Yes, for multicast addresses the notion of scope is different than for
unicast addresses.  In these mcast addresses there is a number that
represents scope and that could be compared and issue results like
'bigger than' or 'smaller than'.

Alex

> -- JINMEI, Tatuya

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Jan 2021 10:45:03 +0100

On 8. Jan 2021, at 01:56, 神明達哉 <[email-masked]> wrote:
> we
>  delivered to D2 (so it does not forward the packet to "other link”).

This is about a hypothetical, but:
How would it know which of its many links that is?

(Imagine D2 being …::1, or some other likely If-ID.
Even if not: Would D1 have to ND that address on all its links?)

(And how exactly would D2 reply?)

Grüße, Carsten

---

From: Markku Savela <[email-masked]>
Date: Fri, 8 Jan 2021 13:13:46 +0200

Uhh,

I think the limitation (don't forward from higher scope to local on 
routing header) should be kept and made extremely strong rule, 
especially if the final address is a link local. No exceptions, ever.

ND is already open to local attacks on local network, but this is 
accepted. But, if random person on internet anywhere can inject ND 
packets via routing header from outside the local network, it would be 
very bad...

regards,
-- Markku Savela

---

From: Philip Homburg <[email-masked]>
Date: Fri, 08 Jan 2021 13:05:11 +0100

>packets via routing header from outside the local network, it would be 

It should not affect ND. ND requires the hop limit to be 255 on the receiving
node.

Beyond that, if routing headers do not cross security boundries, then
I don't see a problem.

If routing headers do cross security boundaries, then you may have bigger
problems already.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 8 Jan 2021 06:40:53 -0800

At Fri, 8 Jan 2021 10:45:03 +0100,

> How would it know which of its many links that is?

It would be "the link where the packet is delivered to D2".

> (And how exactly would D2 reply?)

It's tricky (and nearly impossible in practice) as RFC 4007 explains:

   [...]  This will help the receiving node send a
   "response" packet with the final destination of the received packet
   as the source address without breaking its source zone.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Jan 2021 08:37:13 +1300

On 08-Jan-21 14:34, Alejandro Acosta wrote:
> Hello,
> 
>   My apologies for using this thread, I have a valid point. My comment inline:

Subject header tweaked accordingly...

>   In LACNIC we ran a project called Natmeter [1] for about 2 years, we obtained a lot of interesting data during this period [2].
> 
>   The case is the following, we detected some end-user devices with only Link Local addresses (exactly, no GUA nor ULA) that were successfully natted and using the web.
> 
>   Is it ok?, do you consider it as a forwarding of a packet? was it a crazy result? (we saw few samples of this)

NAT66 is not defined and not recommended, so there really isn't an answer to your questions. I can't think of a reason why such a hack wouldn't work, though. As long as the LL address is translated, it will not escape from the LAN.

Regards
     Brian

> 
> 
> Thanks,
> 
> 
> [1] https://prensa.lacnic.net/news/en/research/lacnic-project-detects-massive-presence-of-nat-boxes-in-the-region
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Jan 2021 16:51:12 -0300

On 8/1/21 16:37, Brian E Carpenter wrote:
[...]
> NAT66 is not defined and not recommended, so there really isn't an answer to your questions. I can't think of a reason why such a hack wouldn't work, though. As long as the LL address is translated…

I would expect that something else (other than IPv6 NAT) is going on. IN 
that sense, it would be interesting to know more details about the 
methodology they employ to measure the use of NATs.

Thanks!

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Jan 2021 09:43:36 +1300

> methodology they employ to measure the use of NATs.

Well, the host has not disabled IPv6, but neither has it processed an RA
to generate a routeable address. So the UE configuration is apparently a
bit strange: WAN-side IPv6 is up, but no LAN-side RAs, and a NAT66 hack
enabled.

https://natmeter.labs.lacnic.net/ gives some details. It includes
a client-side script.

(Unfortunately https://natmeter.labs.lacnic.net/charts/ seems to be broken.)

   Brian

---

From: Alejandro Acosta <[email-masked]>
Date: Fri, 8 Jan 2021 16:48:13 -0400

Hello Fernando, All,

   Here are few links if you want to check out:

https://github.com/LACNIC/natmeter

https://www.youtube.com/watch?v=XbMW0shzrPQ

https://www.youtube.com/watch?v=UTP_sOehrxU

Thanks,

Alejandro,

On 8/1/21 3:51 PM, Fernando Gont wrote:
>>>    In LACNIC we ran a project called Natmeter [1] for about 2 years, 
>>> we obtained a lot of interesting data during this period [2].
>>>
>>>    Is it ok?, do you consider it as a forwarding of a packet? was it 
>>> a crazy result? (we saw few samples of this)
>>
>> NAT66 is not defined and not recommended, so there really isn't an 
>> answer to your questions. I can't think of a reason why such a hack 
>> wouldn't work, though. As long as the LL address is translated, it 
>> will not escape from the LAN.
>
> I would expect that something else (other than IPv6 NAT) is going on. 
> IN that sense, it would be interesting to know more details about the

---

From: Alejandro Acosta <[email-masked]>
Date: Fri, 8 Jan 2021 16:49:22 -0400

On 8/1/21 4:43 PM, Brian E Carpenter wrote:
> {...}

Point taken.., we will be back soon.