Subject: ICMPv6 question

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Aug 2017 23:07:22 +0000

I have a question. If an IPV6 host with address 2001:db8::f00 assigned to an interface
receives a packet with destination address 2001:db8::baa over that interface, what
should it do? Drop the packet silently, or drop and return an ICMPv6 Destination
Unreachable?

Thanks - Fred

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 31 Aug 2017 23:35:44 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Templin, Fred L

> I have a question. If an IPV6 host with address 2001:db8::f00
> assigned to an interface receives a packet with destination address
> 2001:db8::baa over that interface, what should it do? Drop the
> packet silently, or drop and return an ICMPv6 Destination
> Unreachable?

You said host and not router. Assuming that the prefix length is the same for the intended destination of the packet and for the host that received the packet, so the packet is not misrouted, then this sounds like what you'd frequently expect to see in older Ethernets, either coax Ethernets or half duplex ones that use hubs. But why didn't the Ethernet interface discard the packet? The MAC address should not have matched. Was it a ND failure scenario of some kind?

(In general, I don't see why a host should send host unreachable ICMP messages.)

Bert

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Aug 2017 23:51:12 +0000

HI Bert,

> From: Manfredi, Albert E
> Sent: Thursday, August 31, 2017 4:36 PM
> To: Templin, Fred L <[email-masked]>; 6man WG <[email-masked]>
> Subject: RE: ICMPv6 question
> 
> You said host and not router.

Yes - host.

> Assuming that the prefix length is the same for the intended destination of the packet and for the host
> that received the packet, so the packet is not misrouted,

Yes - assume that the prefix 2001:db8::/64 is assigned to the incoming interface.

> then this sounds like what you'd frequently expect to see in older Ethernets,
> either coax Ethernets or half duplex ones that use hubs. But why didn't the Ethernet interface discard the packet? The MAC address
> should not have matched. Was it a ND failure scenario of some kind?

I am assuming that the bogus packet uses a correct MAC destination address
but with an incorrect IPv6 destination address. So, the packet gets handed
up to the IPv6 layer.

> (In general, I don't see why a host should send host unreachable ICMP messages.)

Drop silent would make sense to me, too - but do others think an ICMP
should be generated?

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Fri, 1 Sep 2017 10:26:48 +1000

2001:db8::f00

> should it do? Drop the packet silently, or drop and return an ICMPv6 Destination

Hmm, at face value it appears to be a simple question and the answer
would be DU.

Looking at RFC4443, it limits generation of DUs to routers or the
packet source host:

"A Destination Unreachable message SHOULD be generated by a router, or
   by the IPv6 layer in the originating node, in response to a packet
   that cannot be delivered to its destination address for reasons other
   than congestion.  (An ICMPv6 message MUST NOT be generated if a
   packet is dropped due to congestion.)A Destination Unreachable
message SHOULD be generated by a router, or
   by the IPv6 layer in the originating node, in response to a packet
   that cannot be delivered to its destination address for reasons other
   than congestion.  (An ICMPv6 message MUST NOT be generated if a
   packet is dropped due to congestion.)"

Per RFC8200 (a.k.a. new RFC2460), we have these definitions for a
router and a host

   router       a node that forwards IPv6 packets not explicitly
                addressed to itself.  (See Note below.)

   host         any node that is not a router.  (See Note below.)

A host is therefore to ignore "IPv6 packets not explicitly addressed
to itself", which I think means a host does not generate a DU for
misdirected packets.

I was wondering about how this could happen and I think there could be
two possible causes,

- incorrect ND cache entry for 2001:db8::baa2001:db8::baa, somehow
with the link layer address of 2001:db8::f00

- host attached to one end of a point-to-point link, and the upstream
device (likely router) is blindly forwarding packets over the p2p link
assuming the destination is at the other end rather than performing ND
to discover and continue to verify the presence of the specific
addresses at the other end of the link (That's why I think ND should
be performed on p2p links. Even a /127 configured on one end of the
link doesn't guarantee the other address within the /127 is present.
If a router performed ND on p2p links, it could discover the DA for a
packet is not present and generate a DU for it.)

Regards,
Mark.

> Thanks - Fred
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 1 Sep 2017 00:44:38 +0000

-----Original Message-----
From: Templin, Fred L 

> I am assuming that the bogus packet uses a correct MAC destination
> address but with an incorrect IPv6 destination address. So, the packet
> gets handed up to the IPv6 layer.

Or maybe there's another more or less legitimate reason, Fred. Ethernet in promiscuous mode. In which case, it's working as intended. Still, like Mark showed aptly, a destination host wouldn't be sending host unreachable ICMP messages.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Sep 2017 13:20:41 +1200

> packet is not present and generate a DU for it.)

You can induce this trivially with a /128 host route to 2001:db8::baa
via 2001:db8::f00 (or via its LL address).

I just tested this on a Windows machine, with the innocent victim being 
a Linux machine. TL;DR: The result was silent discard.

Here's what happens in detail. I slightly obscured the GUA prefix:

1. No route installed, just sending a bogus ping:

C:\windows\system32>ping 2406:e007:59ce:1::f00

Pinging 2406:e007:59ce:1::f00 with 32 bytes of data:
Destination host unreachable.

(In this case there was a failed Neighbor Discovery, of course.)

2. Install a host route via the GUA of the target:

C:\windows\system32>route add 2406:e007:59ce:1::f00/128 2406:e007:59ce:1:5967:affa:3750:b289
 OK!

C:\windows\system32>ping 2406:e007:59ce:1::f00

Pinging 2406:e007:59ce:1::f00 with 32 bytes of data:
Request timed out.

3. Replace that with a host route via the LLA of the target:

C:\windows\system32>route delete 2406:e007:59ce:1::f00/128 2406:e007:59ce:1:5967:affa:3750:b289
 OK!

C:\windows\system32>route add 2406:e007:59ce:1::f00/128 fe80::9051:543a:4c9e:e93e
 OK!

C:\windows\system32>ping 2406:e007:59ce:1::f00

Pinging 2406:e007:59ce:1::f00 with 32 bytes of data:
Request timed out.

I checked with WireShark, and the ICMP Echo Request messages were definitely
sent to 2406:e007:59ce:1::f00 at the MAC address of the host known as
2406:e007:59ce:1:5967:affa:3750:b289 or fe80::9051:543a:4c9e:e93e, and
there were no reply packets.

   Brian