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

[Andrew Yourtchenko <[e-mail]>]

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:

> 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.

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:
> 
> - Current IPv4 deployments use only DHCP

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.
> - Other IPv6 parameters can only be configured via DHCPv6

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
> 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.

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.

> 
> 
> 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.

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

> 
> Cheers,
> Lorenzo
> 
>