[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.50.56.38 with SMTP id x6mr14048953igp.31.1387190932312; Mon, 16 Dec 2013 02:48:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.36 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
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
- [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-c… Lorenzo Colitti
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Andrew Yourtchenko
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Ted Lemon
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Andrew Yourtchenko
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Lorenzo Colitti
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Ole Troan
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Ted Lemon
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Andrew Yourtchenko
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Owen DeLong
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Ole Troan
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Owen DeLong
- Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcp… Lorenzo Colitti