Re: ICMPv6 question

[Brian E Carpenter <[e-mail]>]

On 01/09/2017 12:26, Mark Smith wrote:
> 2001:db8::f00
> 
> On 1 September 2017 at 09:07, Templin, Fred L <[e-mail]> wrote:
>> 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?
>>
> 
> 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.)

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