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

Lorenzo Colitti <lorenzo@google.com> Mon, 16 December 2013 10:48 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C524F1AE19C for <v6ops@ietfa.amsl.com>; Mon, 16 Dec 2013 02:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PYHPGwCTJ1Am for <v6ops@ietfa.amsl.com>; Mon, 16 Dec 2013 02:48:53 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1740D1AE1B0 for <v6ops@ietf.org>; Mon, 16 Dec 2013 02:48:53 -0800 (PST)
Received: by mail-ig0-f179.google.com with SMTP id hk11so3491828igb.0 for <v6ops@ietf.org>; Mon, 16 Dec 2013 02:48:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=FB/oxZCdXbRKx4tcUTGalxqrIH+kKMCo8r1YTkm1E20=; b=ksc4e/7tJyl9RIMGKs8FT2XXFhKad8YppZPiTvSHXQh+dGAZcrVeS3Gox8cEnh2tqo dKX/S9GdDWoV0g7Nmx7Aq+Ao+vdX2uoinfvKEbFTmUFyj9U9QTMj9tK/OCoffIUeXhgh 9lP1ilN6njRKPSnl3QDMjdplFAk6MrMtCeBnHIcgZOckj9Q5Q6JMrWsJ995fWpg1lSh9 YoPlS0uzH6e766wvwWMJN+4oIwX0ddyojclQa5P/sRff7DxDAcwiNhwRYODnhWtY30Uw R7sif4HEI0Ctk4hldwyKZcAWYEu/18YA5Oka2hLLzWemuTDzdent4Cqb1azViydha9TE hx9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=FB/oxZCdXbRKx4tcUTGalxqrIH+kKMCo8r1YTkm1E20=; b=gLBYY/DhSAqFss9H6hhge59JwDsiGsFk557TmGhOppZ0zqbcUd/3CehOFIAM+857Mx CXB2KNxntgaXLLrA3if0YbMvdilyFuDSbAhTbQE5K4+VbRLFqQoh2B+4c8uhirZNN87c fAAzyKuxw+imh7pTJSQdHum+bQ6Xv4dEXKaKKDB9pvYIjcsHgPLZYl0yIDHdDVAJp0hs xeaN1xc3n5LMA7OoiG2oWvu0i3jHE7Dlc/Fdl0IAOQ7hWZyMb0Gc4pykF4sl33Nsif4b KK8Nmjq4v6Bt/+os1iqkasRiaY1i0vO7+yjmDbmMMkl9EcB36V3m5tcjPeG4nB+QXK4i wEoQ==
X-Gm-Message-State: ALoCoQluO5g4qczhaOP/SZkAb/AjQnlajH7Zv0WZbjRgQ3vyAgQhgAB6RlRBun8SZoU22uYTMjO7kKuDIszgUex+6KzlJ34fGtAsu+YjNoPHaOdYlbJ+6gBCFwdIkV+5sskzgHaE1ywyKs0BLJVfeUaZC+igNKfEPkV+8YPyv7e2nYDA4Sl8kKedVXFGJorn3usxA9pwSIuJ
X-Received: by with SMTP id x6mr14048953igp.31.1387190932312; Mon, 16 Dec 2013 02:48:52 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Dec 2013 02:48:30 -0800 (PST)
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 16 Dec 2013 19:48:30 +0900
Message-ID: <CAKD1Yr0evKjEEvErq3T=nU6_joat8duseraJJDZ4OHPK9NGWDA@mail.gmail.com>
To: Yourtchenko Andrew <ayourtch@cisco.com>
Content-Type: multipart/alternative; boundary=089e0158b05ec1b3db04eda48e4f
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2013 10:48:58 -0000


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

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.

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