Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

Lorenzo Colitti <lorenzo@google.com> Tue, 29 October 2013 05:14 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C278121E80AC for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2013 22:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt+tmrYf32YT for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2013 22:14:00 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8402921F9CB5 for <v6ops@ietf.org>; Mon, 28 Oct 2013 22:14:00 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id ar20so13335193iec.12 for <v6ops@ietf.org>; Mon, 28 Oct 2013 22:14:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+2Ejj8RzT0CxY/9s7aiPG/TnT2/AtQsXAFS1ecO/6OE=; b=pQn2F31STfu6y+PP6qvsCwdUfMX0vX5DfFM1evtDdEEAle3dm0OliaCcx6A+NVxBYw iiCgWxHx5pBKLisGgR3MD916bB4G+7UgLcXt6l5pRNwB0336UbtYjCPZujM1LzBo3A9q ldsfSJhq8WeI00b9CJEQce4p8mf8b05bWd7lY/ty9N4T9fSD1yrRTRlJ40Q4B8vwmCBy ktBx19uuw+Hidrp/UQ0NMc6NsdB9N1brnjgXf41kVeYxO20q5z6WiDt21DFk674ICLZP M0oRhLfzCtPcTnwa924Qqgb8EvQcjcmkLoe1uR6MFAfoDPKJVOBHISILRDZ9ompEAxov fi8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+2Ejj8RzT0CxY/9s7aiPG/TnT2/AtQsXAFS1ecO/6OE=; b=IYXw1wMqT2SYQHMa1cHYn8TaBgGmPfW0N8WtUDBtPS9mYZcP0XA4286lZjIqn8XvJh ETKjOxXvAUUvaVi4C5hEkX1rQlxK1gjiEYSmWQq42YBFD01a3xVvUujOvV9fX9zbUuDE s/u1fb97AJ5GGcF6Ca/nUOJmkUcPL7v5bjEJF/PKmtDHgCViSafcDPUEaDeBRJrfUq9e AK+V6Cv6SnTbpkUT+WZZDiKIWMWVCC+Zf8p9pokgy9xG8Qm7IzrbMJ7/GTsC7gY34qDm eCGqRVdwk9JpMu8wa3UNAk5DuapzEQFz6jBzQWLpqq+wpA0y8ck1mOPMjYH5ycFT+7TC L0Dw==
X-Gm-Message-State: ALoCoQlV4mjcZCyiOAycQQ0Qyn/yhUGITVUgXbrRx5lP/BDabAqnLQmlXhn029UIWNUEXPhFvVkosIrUOd7zsTeTnGNZg57Nkz/GKUASEHNaGHHcvHP7n1KzL/mMzgZznDoCbdc2BOeK4Zt0+WlYpRKzydTp0pfpMTns7JsoNWpIvT5V6vzK+uLpO/SYEIhaK5K3NpLe6LHE
X-Received: by 10.50.153.50 with SMTP id vd18mr11096194igb.6.1383023639973; Mon, 28 Oct 2013 22:13:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.86.106 with HTTP; Mon, 28 Oct 2013 22:13:39 -0700 (PDT)
In-Reply-To: <alpine.OSX.2.00.1310281905440.11422@ayourtch-mac>
References: <CE8E8EC3.59F3A%victor@jvknet.com> <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <alpine.OSX.2.00.1310281905440.11422@ayourtch-mac>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 29 Oct 2013 14:13:39 +0900
Message-ID: <CAKD1Yr3ivNEzMFOCkxe2EcLYr=x2x1ThdB9AqYsyU96ZZ9UGqg@mail.gmail.com>
To: Andrew Yourtchenko <ayourtch@cisco.com>
Content-Type: multipart/alternative; boundary=089e013a009ec6f30304e9da48b4
Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, Ted Lemon <mellon@fugue.com>, "Ole Troan \(otroan\)" <otroan@cisco.com>, Dave Thaler <dthaler@microsoft.com>
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 29 Oct 2013 05:14:01 -0000

Comments inline.

On Tue, Oct 29, 2013 at 4:17 AM, Andrew Yourtchenko <ayourtch@cisco.com>wrote;wrote:

> This is where the p2p, acknowledged nature of DHCPv6 may be beneficial -
> on a crowded large-scale WiFi, without dirty tricks, you simply will not
> get the SLAAC working because the multicast RAs will get crunched by the
> interference.
>

Well, but multicast NS won't work either, so the network is pretty broken
at this point. You can also send solicited RAs unicast, of course.


> 2) Acknowledged vs. unacknowledged
>
> DHCPv6 needs at least 2 packets. RA is just one packet.
>
> RA Plus: RA is quicker
>
> RA Minus: you have to take care that it is legitimate router and not your
> evil neighbor sending you the RAs you take the configuration from.
>

But you can't authenticate in DHCPv6 either, right? Whether you get an
unsolicited "here's some config parameters" RA or a unicast "thank you for
your request, here's some config parameters" DHCPv6 reply, the problem is
the same: is the source trustworthy? AIUI we don't have any solution for
this except DHCPv6 guard and RA guard, which are effectively the same
solution. I mean - we do have SEND and DHCPv6 authentication, but does
anyone implement those?


> 3) Client initiated vs. server initiated
>
> Despite of the division above, RA can be client-initiated, to some extent,
> with RS, and DHCPv6 can be server-initiated, to some extent, with
> "Reconfigure" messages.
>
> If we treat these as "nudge" messages, the behavior of the sending and
> receiving parties is similar - the "nudge" message causes the orderly
> protocol exchange to occur before the due time.
>
> The part that is different, though, is that RA, due to its "send once,
> receive many" nature, can aggregate the "nudge" messages, so intuitively
> seems best for a scenario with a very large number of the hosts, as it
> should have self-stabilizing properties, compared to DHCPv6.
>

RAs also allow someone who's not the original server to send you a nudge.
In DHCPv6 you need to know the client's DUID to send a nudge, which is hard
(impossible?) to do unless the client has talked to you before, or you've
at least seen a multicast solicit from it.


> 4) Centralized coordination vs. distributed coordination
>
> RA, due to its "send once, receive many" nature, in its pure form
> necessarily can not dictate a per-client settings, but rather can only
> advise the domain the client would pick from (SLAAC).
>

You can dictate per-client settings via unicast RA. But it's true that you
can't dictate per-client addressing, because RAs don't support that.


> DHCPv6 on the other hand, due to its p2p nature is by default well suited
> for the individual per-client tweaking.
>

I agree that it's more suited. A lot of this is not due to the protocol
itself, but due to the fact that we have a lot of infrastructure (protocol
and implementation) built around this: we have relays, relay-inserted
options, sophisticated DHCPv6 servers with per-client configuration, etc.


> 5) Involvement or not into routing
>
> RAs are a mechanism to provide some form of reliability for the routing in
> an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was
> specifically denied any involvement in the routing.
>
> While architecturally "pure", the reliability and timing of the routing
> resiliency provided by the RAs is far below those achieved by FHRP
> protocols which are used in today's networks predominantly.
>

This is a fairly complex issue. It very much depends on what network you're
building.

If you're in a wired environment, it doesn't matter - send RAs every 3
seconds with lifetimes of 6 seconds and you're doing roughly as well as
VRRP. (Yes, you can crank VRRP timers down lower than that, but in a large
network with lots of VLANs, that will cause too much control plane load).
All else being equal, I think multicast RA should be more scalable because
it just requires the router to periodically spit out identical packets,
whereas VRRP requires group coordination and state machines. But that might
be in the noise.

If you're in a home environment, the coordination required to use VRRP
might not be available, but having multiple routers send RAs is quite easy.

In a battery-constrained setting, sending frequent RAs is expensive. You
can use NUD with low timers to do failover, but that can get expensive if
you have many clients. So there are lots of tradeoffs here.



> 6) Server locality
>
> Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6
> has a means to "jump" over multiple hops by use of the relays. This means
> RA *has* to be distributed, while DHCPv6 can be both centralized and
> distributed. Frequently it is made centralized because of other benefits
> that centralized administration brings, but almost any router today can run
> a DHCPv6 server on the box with no problem.
>

I've built networks that send radius requests on receipt of RSes and then
send unicast RAs to the client. So it's possible to do this via RA as well.
It's true that we have a lot more infrastructure to do this in DHCPv6 as
well.


> 7) Programming: UDP vs. ICMP
>
> For a random programmer today, coding a server to receive the data on a
> UDP socket is a more familiar exercise than working with ICMP. Disclaimer:
> the value of "random" was chosen to be "me" for arbitrary reasons. This
> point is more of a rathole and a personal preference, probably. I think I
> remember Dave Thaler saying one of the mechanisms in Windows was way easier
> to extend than the other, but I do not remember which.
>

ICMP is harder than UDP to implement; it often requires raw sockets or
kernel collaboration (e.g., on Linux RDNSS information can be read using
netlink. UDP is much simpler). On the other hand, I think stateful DHCPv6
is a more complicated protocol to implement than RAs, with more message
types and so on.


> 8) Separate vs. unified management
>
> If DHCPv4 and routing is managed by the different groups in the
> organization, then conceivably the "server" people will not like to have
> their work go away and similarly "router" guys are happy to get rid of yet
> another point of coordination and argument. This is where the "I hate
> $protocol" should definitely pop up. Add here the concerns from the
> previous 7 points.
>

Agreed. This is mostly true in an enterprise environment though. You don't
get turf wars at home. :-) On the other hand, in some enterprises, it's
possible that the "server" people might relish the chance of not having to
support DHCPv6 at all. If everything the client needs can be done via RA -
they might just say "great, one less thing we have to do to move to IPv6".