Subject: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Dec 2013 19:48:30 +0900

Andrew,

finally found the time to put down some thoughts on this.

First, I think the goal ("How do I know which of the two to use") is not
what we should aim for, at least initially, because it's too controversial.
I think that at least initially, what we should try to achieve is a
comparison of the properties of the protocols themselves, not make
recommendations of which to use. If we agree on the properties, then later
on we might be able to make recommendations, but I think even agreeing on
the properties will be quite a bit of work.

Second: some of the text you have now deals with link-layer performance.
However, I think that since these are configuration protocols, the
attributes that are important are primarily semantics, not performance or
implementation. So we should focus on the information that the protocols
are able to express rather than the mechanics of how they express it. For
example: "an RA is a multicast packet" is an implementation detail, but "an
RA can update configuration information even if it's sent by a different
entity than the one that sent the original RA" is a semantic property.

Third: there's a lot of text here that could be seen as subjective or a
value judgment. I think a document like this is more likely to reach
consensus if a lot of the text is removed and each section starts from the
basic properties of the protocols, which are hopefully less subject to
disagreement.

With that in mind:

1. There's a lot of controversial and non-objective text here. I think a
lot of it should be deleted, and the section should be stripped down to
saying that:

- Current IPv4 deployments use only DHCP
- IPv6 was designed to use RA for connectivity and addressing, which has
semantic differences.
- Other IPv6 parameters can only be configured via DHCPv6
- That this document aims to describe the properties of the two protocols

2.1. I think this section should be removed. There is basically no
difference between RA with unicast reply and DHCPv6 - both are a multicast
solicit and a unicast reply. It's true that the DHCPv6 client retries more,
but draft-ietf-6man-resilient-rs is making RAs use the same retry
algorithm. It's also true that an RA also causes periodic multicasts, but
the frequency of those multicasts is entirely under the control of the
operator. It's true that sending solicited RAs multicast is a waste of
bandwidth, but that's not a feature of the protocol itself, it's a feature
of the implementation.

2.3. I think this is mostly incorrect. In practice, RA also needs two
packets. Also, "you have to take care that it is legitimate router" applies
to DHCPv6 just as well as RA, and the solution is the same - RA/DHCP guard.

2.4 I don't understand the point here. What are you trying to say? Compare
scaling properties between RA and DHCP on a busy network?

2.5. I would suggest "configuration" instead of "control". You should also
note that this can be done via unicast RA as well.

2.6.
- I think we should stay away from "good" and "bad". Just stick to the
facts. Less to argue about later.
- Where you say "a router can spoof another router" - that affects DHCP and
RA in the same way, and the solution is the same - RA/DHCP guard.

2.7. You should note that stateless DHCP cannot configure addresses. (And
perhaps also that stateful is the basic mode of DHCPv6 operation).

2.8. I don't we should attempt to reach consensus on what to use the
protocols for. It's true that DHCPv6 cannot currently configure routing,
and multiple attempts to make it to do so have failed due to lack of
consensus. However, I think we should just avoid considerations about
whether this should be possible or not, because that isn't a property of
the protocol, it's a question about what we decide to do with the protocol.
Instead, I'd stick to the protocol properties, which as I see them are:

- RAs have to be sent out by the routers themselves, which make them a bit
more robust with respect to misconfiguration than DHCP. In DHCP, the server
might be several hops away might not know what routers are on the link, or
the server entry could be typo'd. It's true that this doesn't happen often
in IPv4, but I think that's mostly because people scream when it does. Fate
sharing avoids this problem entirely.
- To a large extent, RAs share fate with the routers that send them; for
example, if a router loses power, then it will stop sending RAs. It's true
that we address both of these in IPv4, but typically we do so by using
protocols like VRRP.

2.10. The current text seems to say that the implementation work is roughly
equal, and since implementations aren't written very often, it's not really
as important as the properties of the protocols themselves. So I don't
think this section ads much.

2.11. I'm not sure this section is fit for an RFC :)

2.12. I don't think it's realistic to try to get consensus on this
initially. Perhaps later :)

2.13. I think what people mostly want here is address tracking (i.e., "who
had this IP address at this time?"). In a case where the network wants to
know what addresses have been requested by hosts, then using DHCP for
address assignment makes this easy because all you need to do is look at
the server logs. However, this in itself is not secure, because the host
could just pick another of the 2^64 addresses on the subnet and use that.
To make it secure, the router must watch address registrations and enforce
that unregistered addresses can't send packets. So you need first-hop
security too. Once you have first-hop security, you don't necessarily need
to use DHCP though - you can do it for SLAAC and manually-configured
addresses as well.

Finally, a couple of things you don't mention:

- If you want hosts to be able to use a number of different IPv6 addresses
(e.g., to change them periodically for privacy, or to use different
addresses for different apps or different destinations), you can't do that
with DHCPv6.
- In fact, I don't think DHCPv6 can be used to assign multiple addresses
(more than 2) to a host at all. Can it?
- In DHCPv6, if the server crashes there's no way to update the information
in the client, because RECONFIGURE requires a DHCPv6 nonce that only the
server has.
- It might be worth mentioning that SLAAC is a MUST in the host
requirements, and DHCPv6 is A SHOULD. Not sure.

Cheers,
Lorenzo

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 16 Dec 2013 13:42:09 +0000 (WET)

Lorenzo,

First: thanks for the very detailed and specific comments, given that this 
is probably the biggest change, I've decided to get it in first before the 
other pending updates. (Sander's comments were in <!-- --> so I mostly 
took care of them as well). The latest head on github reflects this.

There're some questions/comments though, inline below.

On Mon, 16 Dec 2013, Lorenzo Colitti wrote:

> First, I think the goal ("How do I know which of the two to use") is not what we should aim for, at least initially, because
> it's too controversial. I think that at least initially, what we should try to achieve is a comparison of the properties of
> the protocols themselves, not make recommendations of which to use. If we agree on the properties, then later on we might be
> able to make recommendations, but I think even agreeing on the properties will be quite a bit of work.

Yes, I think it certainly makes sense.

> 
> Second: some of the text you have now deals with link-layer performance. However, I think that since these are configuration
> protocols, the attributes that are important are primarily semantics, not performance or implementation. So we should focus on
> the information that the protocols are able to express rather than the mechanics of how they express it. For example: "an RA
> is a multicast packet" is an implementation detail, but "an RA can update configuration information even if it's sent by a
> different entity than the one that sent the original RA" is a semantic property.

Yes, especially that the lower layers can and do create abstractions with 
different underlying properties.

> 
> Third: there's a lot of text here that could be seen as subjective or a value judgment. I think a document like this is more
> likely to reach consensus if a lot of the text is removed and each section starts from the basic properties of the protocols,
> which are hopefully less subject to disagreement.

Yes, I think the approach of pretty much direct pasting of the text from 
the conversation has proven to be wrong.

> 
> 
> With that in mind:
>
> 
> 1. There's a lot of controversial and non-objective text here. I think a lot of it should be deleted, and the section should
> be stripped down to saying that:
> 

I suppose I also mention RFC 1256 which was defined, but not adopted ?

> - IPv6 was designed to use RA for connectivity and addressing, which has semantic differences.

uhm two immediate counter-examples: RDNSS & individual address 
assignments.

> - That this document aims to describe the properties of the two protocols

yup.

> 
> 2.1. I think this section should be removed. There is basically no difference between RA with unicast reply and DHCPv6 - both
> are a multicast solicit and a unicast reply. It's true that the DHCPv6 client retries more, but draft-ietf-6man-resilient-rs
> is making RAs use the same retry algorithm. It's also true that an RA also causes periodic multicasts, but the frequency of
> those multicasts is entirely under the control of the operator. It's true that sending solicited RAs multicast is a waste of
> bandwidth, but that's not a feature of the protocol itself, it's a feature of the implementation. 
>

done.

> 2.3. I think this is mostly incorrect. In practice, RA also needs two packets. Also, "you have to take care that it is
> legitimate router" applies to DHCPv6 just as well as RA, and the solution is the same - RA/DHCP guard.

I was trying to say that RA works, albeit degraded, with one packet only. 
DHCP does not. Edited to have it captured better. 
I've removed the security-related stuff - Sander mentioned it earlier as well, fully agree.

> 
> 2.4 I don't understand the point here. What are you trying to say? Compare scaling properties between RA and DHCP on a busy
> network?

2 things:
- you can initiate either protocol from either side
- RA protocol, due to one-to-many approach, is much harder to cause 
snowball-type of failure (where your central device has to queue packets 
to process them, and then the queued packets go out of date, so the 
clients retransmit, retransmits get queued, etc.)

> 
> 2.5. I would suggest "configuration" instead of "control". You should also note that this can be done via unicast RA as well.
>

The latest text says "coordination": I did not want to write 
"configuration", because the RA does not configure the address, rather the 
prefix.

Also: unicast RAs with per-client info ?

> 2.6.
> - I think we should stay away from "good" and "bad". Just stick to the facts. Less to argue about later.

yup. removed.

> - Where you say "a router can spoof another router" - that affects DHCP and RA in the same way, and the solution is the same -
> RA/DHCP guard.

I was trying to emphasize the operation after you have received your 
address.

With DHCP, your vulnerability window is during the initial address 
assignment. With RA - all the time.

> 
> 2.7. You should note that stateless DHCP cannot configure addresses.

ack.

> (And perhaps also that stateful is the basic mode of
> DHCPv6 operation).

"first defined" != "basic".

There's RFC3736 which specifically describes just stateless-only mode of 
operation. It's only 9 pages.

> 
> 2.8. I don't we should attempt to reach consensus on what to use the protocols for. It's true that DHCPv6 cannot currently
> configure routing, and multiple attempts to make it to do so have failed due to lack of consensus. However, I think we should
> just avoid considerations about whether this should be possible or not, because that isn't a property of the protocol, it's a
> question about what we decide to do with the protocol. Instead, I'd stick to the protocol properties, which as I see them are:
> 
> - RAs have to be sent out by the routers themselves, which make them a bit more robust with respect to misconfiguration than
> DHCP. In DHCP, the server might be several hops away might not know what routers are on the link, or the server entry could be
> typo'd. It's true that this doesn't happen often in IPv4, but I think that's mostly because people scream when it does. Fate
> - To a large extent, RAs share fate with the routers that send them; for example, if a router loses power, then it will stop
> sending RAs. It's true that we address both of these in IPv4, but typically we do so by using protocols like VRRP.

Yeah this was the section with a massive copypaste which I still had to 
edit, and the discussion was a bit emotional, and I think this layout 
summarizes the essence well. So I put it in with very very light editing 
and deleted the rest.

> 
> 2.10. The current text seems to say that the implementation work is roughly equal, and since implementations aren't written
> very often, it's not really as important as the properties of the protocols themselves. So I don't think this section ads
> much.
>

I think it's worth keeping, at least for the time being, since it provides 
what I think as at least one useful pointer to RFC3542 ?

> 2.11. I'm not sure this section is fit for an RFC :)

Wait, we can't have L8 considerations ?!? :-) deleted.

> 
> 2.12. I don't think it's realistic to try to get consensus on this initially. Perhaps later :)

+1. It's gone.

> 
> 2.13. I think what people mostly want here is address tracking (i.e., "who had this IP address at this time?"). In a case
> where the network wants to know what addresses have been requested by hosts, then using DHCP for address assignment makes this
> easy because all you need to do is look at the server logs.

Yes, totally agree here.

> However, this in itself is not secure, because the host could just
> pick another of the 2^64 addresses on the subnet and use that. To make it secure, the router must watch address registrations
> and enforce that unregistered addresses can't send packets. So you need first-hop security too. Once you have first-hop
> security, you don't necessarily need to use DHCP though - you can do it for SLAAC and manually-configured addresses as well.

Yes, totally agree here as well. That's what I also say.

But, immediately after saying that I think that in the bigger picture 
of things, this imperfection of the "common wizdom" status quo may be a 
blessing.

> - If you want hosts to be able to use a number of different IPv6 addresses (e.g., to change them periodically for privacy, or
> to use different addresses for different apps or different destinations), you can't do that with DHCPv6.

You can, at least in the standard - RFC3315 defines IA_TA 
precisely for this:

       Identity association for temporary addresses (IA_TA) An IA that
                                 carries temporary addresses (see RFC
                                 3041 [12]).

> - In fact, I don't think DHCPv6 can be used to assign multiple addresses (more than 2) to a host at all. Can it?

RFC3315, beginning of page 73:

    An IA_NA option may only appear in the options area of a DHCP
    message.  A DHCP message may contain multiple IA_NA options.

This to me implies the DHCP can be used to assign multiple non-temporary 
addresses.

> - In DHCPv6, if the server crashes there's no way to update the information in the client, because RECONFIGURE requires a
> DHCPv6 nonce that only the server has.

I've mentioned it earlier in the text:
    in the scenario of the DHCPv6 server sending the RECONFIGURE
    message to the client, DHCPv6 server must keep some knowledge of the
    client - which means it might need to keep some state.

But I've added this:

Thus if there is a requirement to keep the ability for the DHCPv6 server
infrastructure to retain the ability of sending the RECONFIGURE message, this 
state needs to be kept across the server crashes and reboots.

> - It might be worth mentioning that SLAAC is a MUST in the host requirements, and DHCPv6 is A SHOULD. Not sure.

Thanks! I added to "Asymmetric external standards requirements" section. 
(as well as renamed this section to not have "external" in it).

--a

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Dec 2013 08:49:01 -0500

On Dec 16, 2013, at 5:48 AM, Lorenzo Colitti <[email-masked]> wrote:
> I think that at least initially, what we should try to achieve is a comparison of the properties of the protocols themselves, not make recommendations of which to use. 
+1

> Second: some of the text you have now deals with link-layer performance. However, I think that since these are configuration protocols, the attributes that are important are primarily semantics, not performance or implementation.

Lorenzo, this is kind of a puzzling position to take.   There are lots of ways to do things with really nice semantics that fall on their face for performance reasons.   So I think performance questions are in scope.

Thanks for the thorough review!

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 16 Dec 2013 14:09:01 +0000 (WET)

On Mon, 16 Dec 2013, Ted Lemon wrote:

> Lorenzo, this is kind of a puzzling position to take.   There are lots 
>of ways to do things with really nice semantics that fall on their face 
>for performance reasons.   So I think performance questions are in scope.

Ted,

I've taken the interaction with the underlying levels out for now:

pragmatically, it reduces the number of things to have the consensus on 
(assuming that there is a consensus that we need to have a consensus :).

When/if we discover that everyone's in violent agreement, we add them 
back. What do you think ?

--a

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Dec 2013 23:12:52 +0900

On Mon, Dec 16, 2013 at 10:49 PM, Ted Lemon <[email-masked]> wrote:

> implementation.
> Lorenzo, this is kind of a puzzling position to take.   There are lots of
> ways to do things with really nice semantics that fall on their face for
> performance reasons.   So I think performance questions are in scope.
>

Oh, of course - in general, they are. But here the protocols used are so
similar that there is little substantive difference in performance.

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Dec 2013 15:25:05 +0100

Lorenzo,

> Oh, of course - in general, they are. But here the protocols used are so similar that there is little substantive difference in performance.

could you expand on that?
I see the scaling properties on a multicast capable link very different between the two.
take a multicast capable link with 10K nodes on it, where power has just come back.
a few hundred RS/RA messages, at least 40K DHCPv6 messages.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Dec 2013 09:46:31 -0500

On Dec 16, 2013, at 9:09 AM, Andrew Yourtchenko <[email-masked]> wrote:
> When/if we discover that everyone's in violent agreement, we add them back. What do you think ?

Sure.   I don't mean to pressure you to add or remove anything—I just think it's worth mentioning substantive performance issues, of which some exist.   It's definitely not worth listing anything that is controversial—I think there are some known performance issues that everybody agrees exist, and I think those are arguably worth mentioning.

But if you think the document stands without them, that's fine with me too.

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 16 Dec 2013 17:05:50 +0000 (WET)

On Mon, 16 Dec 2013, Ted Lemon wrote:

> Sure.   I don't mean to pressure you to add or remove anything—I just 
> think it's worth mentioning substantive performance issues, of which 
> some exist.   It's definitely not worth listing anything that is 
> controversial—I think there are some known performance issues that 
> everybody agrees exist, and I think those are arguably worth mentioning.
>
>

I think I made a mistake of adding too much at once, this was a good 
way to cut some of the more controversial parts, at least for now.

It's easy to re-add later if we find a clear wording that has consensus.

--a

---

From: Owen DeLong <[email-masked]>
Date: Mon, 16 Dec 2013 12:46:15 -0800

> a few hundred RS/RA messages, at least 40K DHCPv6 messages.

I'm trying to think of a multi-user network technology still in use today where 40,000 packets over a couple of minutes time is likely to be a significant load and I'm failing to come up with one.

Care to elaborate?

Owen

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Dec 2013 22:46:03 +0100

Owen,

> I'm trying to think of a multi-user network technology still in use today where 40,000 packets over a couple of minutes time is likely to be a significant load and I'm failing to come up with one.

indeed, I wasn't thinking of link-congestion, but processing time. on the DHCP server and the first-hop switches and routers.
do you agree that RS/RA and DHCP scales quite differently in this scenario?
(then we can argue later if the differences matter or not).

cheers,
Ole

---

From: Owen DeLong <[email-masked]>
Date: Mon, 16 Dec 2013 15:44:51 -0800

> do you agree that RS/RA and DHCP scales quite differently in this scenario?

Meh... I think most modern DHCP servers could actually take that kind of load without too much problem. In any real world scenario, 10,000 hosts that are all DHCP clients on the same segment isn't all that likely. However, even if we forego that reality for a moment, they won't likely be homogeneous which means that they will take different amounts of time to get to where they want to make their DHCP requests. Can we agree that the spread would be at least 45 seconds and more likely somewhere in the neighborhood of 120 seconds from the time of the first host requesting to the last?

If so, then you're talking about 40,000 packets (10,000 requests) over 45 seconds = <1,000 PPS. If your switch and/or DHCP server can't handle 1,000 PPS from 10,000 nodes, I'm mystified as to how you expect that network to work when the power hasn't failed recently.

I think in terms of the switch, there are a number of problems that are more impactful than DHCP that would prevent me from attempting to put 10K nodes on a single network segment.

So, yes, I suppose, technically, there is a valid argument that the scaling properties of RA and DHCP are different. However, I think it's kind of the networking equivalent of Zeno's paradox... At some point you have to just accept that close enough is close enough and splitting the hair any further is pointless. I think this goes beyond that point.

> (then we can argue later if the differences matter or not).

I guess I'll concede that there is a theoretical difference, but I remain unconvinced of an actual difference. I'm pretty sure that the theoretical difference doesn't really matter.

To know whether the actual one did or not, I'd have to see an example where it might.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Dec 2013 10:04:48 +0900

> a few hundred RS/RA messages, at least 40K DHCPv6 messages.

True. On the other hand, on wifi, multicast is expensive, both in terms of
shared channel bandwidth and in terms of impact on device battery life if
solicited RAs are sent to all-nodes multicast. Of course, you can avoid
this by sending solicited RAs unicast.

In the grand scheme of things I think these link-layer concerns are not the
most important factors here. That said, if they're not controversial, then
perhaps it's good to document them.