Subject: [v6ops] Routers forwarding packet with link local source

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Nov 2011 16:06:04 +0100

Looking at some traceroute output, I found a link local address. This is 
rather surprising given that RFC-4291 (Internet Protocol Version 6 (IPv6)
Addressing Architecture) says:

"2.5.6. Link-Local IPv6 Unicast Addresses
[...]
"Routers must not forward any packets with Link-Local source or
"destination addresses to other links.

The surprising thing is that the router that originates the packet is about
9 hops away from me.

Are router vendors deliberately ignoring this requirement?

---

From: Hermin Anggawijaya <[email-masked]>
Date: Wed, 23 Nov 2011 13:41:17 +1300

I assume that none of the 9 routers in the path carry the "IPv6 Ready Logo" ?
not that I claim the IPv6 Ready Logo is good or otherwise - debate
this somewhere else,
but at least to obtain the logo, any router must past self conformance
tests which include
link-local addressed packet forwarding requirement as specified in the RFC.

Speaking as a vendor, no we don't ignore the requirement deliberately.

H. Anggawijaya

On Wed, Nov 23, 2011 at 4:06 AM, Philip Homburg
<[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 23 Nov 2011 12:04:52 +0100

>Speaking as a vendor, no we don't ignore the requirement deliberately.

It looks like the routers are all Juniper, belonging to 3 different
origanisations. I've no idea whether they are 'IPv6 Ready' or not. :-)

One question is whether this is a bug or a feature. The effect is that the 
error ICMP arrives. Which is good, but proper (ingress) filtering is also good.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 24 Nov 2011 11:09:52 +1100

> Are router vendors deliberately ignoring this requirement?

Such a coincidence, I've spent some time on the similar issue
recently. I don't know if vendors are ignoring RFC4291 (and some other
RFCs as 4007) deliberately or unintentionally, but there are a lot of
routers in Internet forwarding packets with link-local src to global
destination IPs.  I've even seen routers sending ICMPv6 type 2 (packet
too big) using link-local src IP to destination address of global
scope ;-\

>error ICMP arrives. Which is good, but proper (ingress) filtering is also good.

I'd consider it as a bug indicating that RFCs aren't properly
implemented and more bugs related to address selection and scoped
architecture might exist in the code..

-- 
SY, Jen Linkova aka Furry

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Nov 2011 15:49:02 +1300

>> "destination addresses to other links.

That refers to the source or destination address of the packet, not
to the address of the interface forwarding or receiving the packet.
What you see in the trace is surely the address of the router interface,
which can perfectly well be a link-local address on an unnumbered link
between two routers.

In a similar confusion, I have been mystified by IPv6 traceroutes
including addresses assigned to an ISP that was not on the path.
That was simply because the router handling a particular hop did have
an interface numbered from the other ISP, and chose to report that as
its own address in its traceroute replies.

This is just a consequence of multiple addresses being a standard
feature of any IPv6 node, including routers. Some of those addresses
can be link locals.

(You sometimes see RFC 1918 addresses in the middle of an IPv4 trace, and
that's roughly the same thing.)

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Thu, 24 Nov 2011 08:52:04 +0100

>its own address in its traceroute replies.

I'm not complaining about the router that originated the packet. That can
happen, no problem.

But for that packet to arrive at my laptop, it must have been forwarded by
quite a few routers. And each of those routers forwarded a packet with
link-local source, in direct violation of what it specified in RFC-4291.

---

From: Gert Doering <[email-masked]>
Date: Thu, 24 Nov 2011 13:55:45 +0100

Hi,

> I'm not complaining about the router that originated the packet. That can

I tend to disagree.  Unless the router has no single global IPv6 address,
it should never send out packets to a global scoped IPv6 address sourced
from a link-local address.

... while I'm not sure that there is an RFC that explicitely says that
this is a MUST NOT, it should be self-explanatory, given that other routers
are expected to drop these packets in-transit...

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

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

---

From: Philip Homburg <[email-masked]>
Date: Thu, 24 Nov 2011 14:01:33 +0100

>are expected to drop these packets in-transit...

True. But I cannot complain about that, unless I know for certain that the
router actually has a global IPv6 address. Worse is that the router sent me
a truncated error ICMP. The link-local address has the MAC address included,
so I know which brand to avoid :-(

---

From: Hermin Anggawijaya <[email-masked]>
Date: Fri, 25 Nov 2011 10:55:17 +1300

> so I know which brand to avoid :-(

If the trace is done using the hop limit exceeded method (I presume it
is), the ICMPv6 'Hop limit exceeded in transit'
message (Type 3/Code 0) should be generated with source IP address
following RFC4443 Sec 2.2.b, which says

---
If the message is a response to a message sent to any other address, such as....
       - a unicast address that does not belong to the node
the Source Address of the ICMPv6 packet MUST be a unicast address
belonging to the node.  The address SHOULD be chosen according to
the rules that would be used to select the source address for any
other packet originated by the node, given the destination address of the packet
---

Thus, IMHO, the source address should not be link local address -
unless the trace originate
one hop away, with the destination address of the link-local address
of the target node (ie. the tracer
and the target are on the same link).

This would presumably mean that with router implementation which
supports the rule RFC-4291 sec 2.5.6,
on the near path, any ICMP hop limit exceeded message sent from
routers further along the path with link local addresses
will be dropped and not be seen by the trace originator.

On unnumbered link, the router sending the ICMPv6 packet would need to
select other
interfaces address which makes sense for the destination address (ie.
the source address of the trace packet).
I am not sure what implementations (should) do if there are no
numbered links on the router in question.....

So maybe the path that Philip has on the trace include routers with
unumbered links only, and just so happens that
nearer routers happily pass the ICMP replies along.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Nov 2011 11:11:30 +1300

On 2011-11-25 10:55, Hermin Anggawijaya wrote:
...
> nearer routers happily pass the ICMP replies along.

Exactly. And just maybe, that is preferable to never receiving
the ICMPv6 reply at all. This seems to be a genuine hole in
our specs.

   Brian

---

From: Jen Linkova <[email-masked]>
Date: Fri, 25 Nov 2011 11:45:16 +1100

> from a link-local address.

I was going to say 'exactly so we are dealing either with broken
address selection or with an internet-connected router
w/o *any* global-scope IPv6 address' but then I looked into RFC 3484:

"It is RECOMMENDED that the candidate source addresses be the set of
   unicast addresses assigned to the interface that will be used to send
   to the destination.  (The "outgoing" interface.)  On routers, the
   candidate set MAY include unicast addresses assigned to any interface
   that forwards packets, subject to the restrictions described below.

     [skip]
     Implementations that wish to support the use
      of global source addresses assigned to a loopback interface should
      behave as if the loopback interface originates and forwards the
      packet."

So looks like that if router has link-local address only on the
outgoing interface
even with global IP on the loopback might include only link-local to
the list of candidate source addresses..

Although I still have a hope that most implementations are more
reasonable and do include at least the loopback IP into the list..

> are expected to drop these packets in-transit...

"5. Source Address Selection:
...
 If the eight rules fail to choose a
   single address, some unspecified tie-breaker should be used."

Looks like it isn't prohibited, the behavior is undefined.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 25 Nov 2011 12:27:43 +1100

On Wed, Nov 23, 2011 at 10:04 PM, Philip Homburg
<[email-masked]> wrote:
> One question is whether this is a bug or a feature.

1) a router sending ICMPv6 using link-local as a source. Might be a
bug, might be a lazy implementation, or might be a legitimate behavior
(in the last case I'm inclined to blame the network design..).
Not explicitly prohibited but shall be avoided as it contradicts common-sense.

2) other routers on the path forwarded such packets. Indubitably, this
is a direct violation of at least two RFCs.

This should be fixed (for non-ICMP packets the gateway shall also
respond with ICMPv6 type 1 code 2 to the host, AFAIR).

>The effect is that the

This is about 'security vs usability' tradeoff.  In this particular
case I'd take security side providing such packets shouldn't normally
appear in the network and can be used for attacks.