RE: ICMPv6 question

["Templin, Fred L" <[e-mail]>]

Thanks Mark and Bert for the insights and thanks Brian for the actual experiments;
your time and efforts are appreciated.

To Bert's question, my concern is for a packet arriving with the link-layer destination
address matching the host's MAC address and an IPv6 destination address *not*
matching one of the host's IPv6 addresses. The packet would be handed up to
the IP layer (i.e., whether or not it is also handed up to the packet filter) and
would be dropped silently in the IP layer per Brian's verifications.

Now I need to piece together what this means for a node that acts a little bit
like a host and a little bit like a router...

Fred

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Thursday, August 31, 2017 6:21 PM
> To: Mark Smith <[e-mail]>; Templin, Fred L <[e-mail]>
> Cc: 6man WG <[e-mail]>
> Subject: Re: ICMPv6 question
> 
> 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
> 
>