Subject: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ]

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2015 18:03:32 +0100

>This is starting to diverge from the case I originally intended this discussion
> to
>examine. The case I am interested in is as follows:
>
>- Node N receives a /64 prefix delegation for prefix P over interface eth0.
>- N assigns P to the lo interface as a /64 route. This is done to black-hole
>   unused portions of P.
>- N configures address A from prefix P, and assigns it to eth0.
>- N need not perform DAD for A over eth0, because the delegating router
>   has made sure that the routing system will route all packets with a
>   destination address from P to node N, and not to any other node.
>
>In this way, N can function as an ordinary host according to the strong end
>system model even though it acted as a "requesting router" in procuring a
>prefix from the delegating router. No other node X on the same link as
>N can therefore configure an address from P and have the routing system
>return packets to X. In fact, any node X that configures an address from P
>can be considered an "attacker", and the use or non-use of DAD has no
>way of preventing that. In fact, the use of DAD could give X a clue as to
>which addresses from P are ripe for attacking. So, it is in fact better to
>NOT do DAD.

I have a two questions about this, sort of unrelated to DAD (so I changed the
subject).

1) How do packets reach the host. Is that documented somewhere?
   I assume that in this case a router will send packets with destination
   prefix P to the link local address of N. But is that specified somewhere?

2) If a node M on the same ethernet link wants to communicate with address
   A, it creates a destination cache entry for A picking a default router
   as next hop (because P is not onlink). Later, A can send the reply 
   directly to M if M's address is onlink. That is likely to cause a
   neighbor cache entry for A at M, which will not be used because the 
   destination cache entry is still in place.

   Not good if you ever want to debug something.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Nov 2015 17:26:22 +0000

Hi Philip,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Monday, November 16, 2015 9:04 AM
> To: [email-masked]
> Cc: Templin, Fred L; Hemant Singh (shemant)
> Subject: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ]
> 

RFC3633 is largely silent on this, but when P is delegated to N, it is
implied that the delegating router must somehow inject information
into the routing system that will guide packets with destination
address A to N.

>    prefix P to the link local address of N. But is that specified somewhere?

That is correct, but again RFC3633 is largely silent.

>    destination cache entry is still in place.

In this instance, the default router would return a Redirect to M to inform
it that N is a better first hop for reaching address A. The Redirect would
cause M to update its destination cache accordingly.

Thanks - Fred
[email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2015 18:53:57 +0100

>into the routing system that will guide packets with destination

I wonder where this should be documented. There seem to be some other
interesting interactions: a DHCPv6 server running on a host should not
hand out a PD to a host (because it doesn't work), but can hand it out to
a router. And can hand it out when there request comes through a relay agent.

A relay agent running on a router should install a routing table entry
if the PD request comes from a host.

There might be more interesting details.

>> 2) If a node M on the same ethernet link wants to communicate with addres=
>s

I wondered about redirect just after I hit sent. The neighbor discovery RFC
is very explict about the IsRouter flag in the neighbor cache.
In this case M has to set the IsRouter flag for A.

I wonder if A should then always set the Router flag in neighbor advertisements
as well. It looks like it has to, otherwise the neighbor cache will be
flushed.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Nov 2015 18:12:18 +0000

Hi Philip,

> Sent: Monday, November 16, 2015 9:54 AM
> To: [email-masked]
> Cc: Templin, Fred L
> Subject: Re: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ]
> 
> I wonder where this should be documented.

The documentation or non-documentation considerations are exactly the
same whether N is a host or a router. RFC3633 chooses to remain silent,
and I have not seen errata filed nor updates to document routing.

> There seem to be some other

DHCPv6 server runs either on the delegating router or (if the delegating
router is a relay) on another server somewhere else in the network.
Host vs. router considerations are one and the same as for standard
PD to any type of "requesting router".

> if the PD request comes from a host.

That's what AERO does, yes.

> There might be more interesting details.

AFAICT, the case is clean. But, certainly, we should look at it from all
angles yes.

> as well. It looks like it has to, otherwise the neighbor cache will be

Section 8.3 of RFC4861 says:

   "If the Target and Destination Addresses are the same, the host MUST
   treat the Target as on-link.  If the Target Address is not the same
   as the Destination Address, the host MUST set IsRouter to TRUE for
   the target.  If the Target and Destination Addresses are the same,
   however, one cannot reliably determine whether the Target Address is
   a router.  Consequently, newly created Neighbor Cache entries should
   set the IsRouter flag to FALSE, while existing cache entries should
   leave the flag unchanged.  If the Target is a router, subsequent
   Neighbor Advertisement or Router Advertisement messages will update
   IsRouter accordingly."

and Appendix D. of RFC4861 says:

   " - The target of the redirect, when the target is the same as the
      destination, does not carry any host vs. router information.  All
      that is known is that the destination (i.e., target) is on-link
      but it could be either a host or a router."

In this case, the Target and Destination Address are the same. So, there is
no host vs. router information, and the default value for isRouter is FALSE.

Thanks - Fred

---

From: [email-masked]
Date: Mon, 16 Nov 2015 19:37:16 +0100 (CET)

> a router. And can hand it out when there request comes through a relay agent.

The difference between host and router seems to be getting more and
more artificial, what with servers running lots of VMs etc.

I find it much more logical to simply assume that if *some* client
asks for a PD, it knows how to use it. Whether the client is a host or
a router is rather irrelevant.

Steinar Haug, AS 2116

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 Nov 2015 23:14:59 +0100

>> I wonder if A should then always set the Router flag in neighbor advertis=
>ements
>no host vs. router information, and the default value for isRouter is FALSE=

Target and Destination are the same if the router sending the redirect 
considers the Destination to be on-link.

Given that the router has a link local next hop, I wonder if that's the
case.

In general after prefix delegation, the delegating router is supposed to
assume that the prefix is not on-link but used on other links.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Nov 2015 23:09:09 +0000

Hi Philip,

> Sent: Monday, November 16, 2015 2:15 PM
> To: [email-masked]
> Cc: Templin, Fred L

Yes, you are right; the target address will be the link-local address of
N on the eth0 link, and the destination address will be A. So, to the
outside world, N would look like a router. Do you see a problem
with that?

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Nov 2015 11:56:55 +0100

Hi Fred,

>outside world, N would look like a router. Do you see a problem

The problem is that other hosts will clear their destination caches if they
receive a NA without the router bit set. So a host trying to communicate 
with an address taken from the prefix will constantly go back to the default
router, get a redirect, do a neighbor discovery probe and clear the
destination cache for that address.

Maybe all nodes that receive a prefix using PD have to behave as routers for the
purposes of (at least) ND.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 Nov 2015 12:08:03 +0100

> 1) How do packets reach the host. Is that documented somewhere?

No.

>     prefix P to the link local address of N. But is that specified somewhere?

It is not specified.  But I agree it should act as you say above.

Alex

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 Nov 2015 12:09:43 +0100

Le 16/11/2015 18:26, Templin, Fred L a écrit :
> RFC3633 is largely silent on this,

Yes, and the forthcoming DHCPv6 update integrating PD will also be 
silent I believe (they try pure tex integration, little if any new text).

> but when P is delegated to N, it is

Yes, I agree.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 Nov 2015 12:11:33 +0100

Le 16/11/2015 18:53, Philip Homburg a écrit :
>> RFC3633 is largely silent on this, but when P is delegated to N, it
>> is implied that the delegating router must somehow inject
>> information into the routing system that will guide packets with
>> destination address A to N.
>

I agree it shoul dbe documented.

> There seem to be some other interesting interactions: a DHCPv6 server
> running on a host should not hand out a PD to a host (because it
> doesn't work), but can hand it out to a router. And can hand it out
> when there request comes through a relay agent.
>
> A relay agent running on a router should install a routing table
> entry if the PD request comes from a host.

Certainly yes.

In the past we tried a problem statement draft about how PD impacts 
routing at Relay.

> There might be more interesting details.

Which ones?

Alex

>>> A, it creates a destination cache entry for A picking a default
>>> router as next hop (because P is not onlink). Later, A can send
>>> the reply directly to M if M's address is onlink. That is likely
>>> to cause a neighbor cache entry for A at M, which will not be
>>> used because the destination cache entry is still in place.
>>
>> In this instance, the default router would return a Redirect to M
>> to inform it that N is a better first hop for reaching address A.
>> The Redirect would cause M to update its destination cache
>> accordingly.
>
> I wondered about redirect just after I hit sent. The neighbor
> discovery RFC is very explict about the IsRouter flag in the neighbor
> cache. In this case M has to set the IsRouter flag for A.
>
> I wonder if A should then always set the Router flag in neighbor
> advertisements as well. It looks like it has to, otherwise the
> neighbor cache will be flushed.
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: <[email-masked]>
Date: Tue, 17 Nov 2015 15:39:34 +0000

Hi Alex, all,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Alexandre
> Petrescu
> Envoyé : mardi 17 novembre 2015 12:12
> À : [email-masked]
> Objet : Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-
> host-addr-availability discussion] ]
> 
> 
> 

[Med] Better with pointers: 

* https://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00 

And 

* https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-03

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Nov 2015 17:35:52 +0000

Hi Philip,

> Sent: Tuesday, November 17, 2015 2:57 AM
> To: [email-masked]
> Cc: Templin, Fred L

Yes, you are right about the IsRouter flag. But, I think all that means is that
node N simply needs to leave "ip forwarding" turned on so that IsRouter
will be set in ND messages.

Internally, however, N can still assign address A from prefix P to the eth0
interface so that applications will believe that they are running on an
ordinary host that observes the strong end system model. I have this
working in linux and android.

Leaving "ip forwarding" turned on I think also allows N to send ICMP
unreachables when it receives packets with destination address
B from prefix P, where B is not an address that N has configured on
any interface. So, it is somewhat router-like in that sense also.

Thanks - Fred