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

Andrew Yourtchenko <ayourtch@cisco.com> Tue, 29 October 2013 13:37 UTC

Return-Path: <ayourtch@cisco.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 1DBA411E823D for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2013 06:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
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 TnBFCK2ETrMA for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2013 06:37:13 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFEB21F9EC8 for <v6ops@ietf.org>; Tue, 29 Oct 2013 06:37:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11235; q=dns/txt; s=iport; t=1383053825; x=1384263425; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=B6b9Dcj/CFFNsqlf+IDLrQC6MK3i/v5PRr25TNUdvfo=; b=HWNis5ZBYTIEgHoMN015wbER7iqu7z48qJ6m2VjtyuAVBOQeusbQeG27 K1DaL4NcGAr2IG9D77rRijInREncg1S94ST2f8FiigBdhn3wR/vNKmCTc oTwujX84fzHRup69b8jq22Sk2FtAP6220Ko3GV0uVyfHsPhfACuMivIKD I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAJS5b1KtJV2d/2dsb2JhbABZgwc4VL8xgSgWdIIlAQEBAwEBAQE1AjQLBQsLGBUOCyciAQ0GDgUZh2gGDblXBI9HBwqEIgOeRotMgWiBP4Ip
X-IronPort-AV: E=Sophos;i="4.93,593,1378857600"; d="scan'208";a="277977506"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 29 Oct 2013 13:37:04 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9TDb39m018978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 13:37:03 GMT
Received: from [10.61.170.92] (10.61.170.92) by xhc-rcd-x09.cisco.com (173.37.183.83) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 29 Oct 2013 08:37:02 -0500
Date: Tue, 29 Oct 2013 14:36:43 +0100
From: Andrew Yourtchenko <ayourtch@cisco.com>
X-X-Sender: ayourtch@ayourtch-mac
To: Lorenzo Colitti <lorenzo@google.com>
In-Reply-To: <CAKD1Yr0qLd7syFizEUMa6DM2a2LY6Rv5GSFyoQAs4Pir6gcNkA@mail.gmail.com>
Message-ID: <alpine.OSX.2.00.1310291143190.31066@ayourtch-mac>
References: <CE8E8EC3.59F3A%victor@jvknet.com> <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <alpine.OSX.2.00.1310281905440.11422@ayourtch-mac> <CAKD1Yr0qLd7syFizEUMa6DM2a2LY6Rv5GSFyoQAs4Pir6gcNkA@mail.gmail.com>
User-Agent: Alpine 2.00 (OSX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format=flowed
X-Originating-IP: [10.61.170.92]
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 13:37:18 -0000

Ted, Lorenzo,

Given the submission tool is for now closed, I've whipped up the 
xml+txt and a git repo and put it onto https://github.com/ayourtch/ra-dhcpv6/
I also tried to express/generalize Lorenzo's points below and put them 
into a separate new sections.

More inline..

On Tue, 29 Oct 2013, Lorenzo Colitti wrote:

> Andrew, those are good points, though from the perspective of protocol design I think semantics and functionality are a bit more important than performance. Once you have the semantics
> right you can look at improving performance (e.g., via QoS, prioritization, queue isolation, etc. etc.), but if the semantics are wrong it's hard to fix that.
> So, semantics I think you forgot:
> 1. DHCPv6 makes it very hard to update client information from the network side.
> 
> You can use reconfigure, but that requires authentication (clients MUST discard reconfigure messages that aren't authenticated). I don't know if anyone actually implements
> authentication.

Agreed. This is something that needs testing.

> Also, it requires that the server know the DUID of the client. How do you 
> do this if the client has never talked to you before, (e.g., if you 
> booted after the client)?
> You'd have to have all the DHCPv6 servers on link communicate with each other.

Yes, you will need some form of redundancy, and means you can not be fully 
"stateless".

But if we are going the road of extending things, we might come up with a 
multicast RECONFIGURE message, which would specify the time interval 
within which the clients should come back and report their DUID.

I can't argue too hard on this one because I never tested this in real 
life.

>
> Also, it's not clear to me how you would implement reconfigure in a stateless environment, since the server doesn't know which clients are still there and not all clients (none?)
> implement RFC 4242.
> 
> For an example of why this is useful, consider a homenet. You have two routers on the same link that share state via a routing protocol. Router A is unplugged. Router B knows this and
> wants to tell the client "don't use router A as DNS server any more". How do you do this? Using an RA you can just send out a message with a lifetime of zero. How do you do it with
> DHCPv6?

I agree this is definitely a useful scenario. I've added it under a new 
section "Single Source of Truth vs. Multiple sources".

> 
> 
> 2. DHCPv6 doesn't support multiple sources of information.
> 
> In particular, stateful DHCPv6 requires that the client choose one of the advertise messages it receives. The spec doesn't prevent it from starting a new transaction with a transaction
> ID, but I don't know what the original server would do if it received such a message. The RFC doesn't seem to specify this very well, if at all.
>

I think this is conceptually, again, "single source of truth" problem.

> 
> 3. You can do per-client configuration using RA as well.
> 
> There's nothing preventing routers from replying to RS packets with unicast RAs, so per-client configuration is possible. There's also nothing stopping you from causing an RS to trigger
> a provisioning (e.g., radius) request to a server asking for configuration parameters for that client - for example, giving it its own VLAN and its own /64. (I've built networks that do
> this, so I know it works). So your "it's not possible to jump" assertion is not entirely true. It's true that RAs can't jump by themselves, but the information requests can.
>

yeah. I did not go into this in my write-up, but it is entirely possible 
to morph RA so it becomes some kind of DHCPv6, and it is likewise possible 
to morph DHCPv6 so it becomes some kind of RA. To some extent, you can do 
it without the host modifications. Full conversion of either would require 
host mods. This was beyond what I aimed for - merely a comparison of the 
protocols 'as is'.

> 
> I'm also don't think the "multicast doesn't work in congested networks" argument is valid. In a network where multicast is so overloaded that it's completely broken, it's not just RAs
> that will fail. NSes will get dropped too; MDNS won't work; basically, the network is broken. That said, unicast RAs don't have this problem.

IPv4 does not have this problem. your DHCPv4 will complete. After a 
minute, but it will complete. Your client has only one ARP entry (default 
gateway). The connectivity sucks big time, but it survives.

Contrary to that, in IPv6 the very first RS is lost and if the client is 
not persistent enough, this is where it ends (Hoping the hosts get 
draft-ietf-6man-resilient-rs implemented so it is less of a problem)

> 
> I'd be happy to contribute to a draft documenting these issues. Andrew, were you going to start one?
>

Sure, github above. feel free to clone/edit/send pull requests :)

--a


> 
> On Tue, Oct 29, 2013 at 4:17 AM, Andrew Yourtchenko <ayourtch@cisco.com> wrote:
>       On Thu, 24 Oct 2013, Ted Lemon wrote:
>
>             Anyway, that's the rhetorical position I'm going to stake out for now. I'm curious to see if anybody can come up with a reason to disagree that doesn't simplify
>             to either "I hate RA" or "I hate DHCP."
> 
> 
> I'll take a shot at outlining the differences as I see them between the two, and the factors that may influence the "I hate RA" or "I hate DHCP" reply in each particular case...
> 
> 1) Interworking with different L2 topologies
> 
> RA is "server-initiated, send once, receive many, no confirmation" abstraction - something that works well on the 10base2-type shared bus and even the today's wired ethernet, but
> looks quite miserable on the WiFi media without the ugly special tricks (802.11 provides reliable delivery for unicast frames, and does not provide one for multicast frames, also
> the physical speeds are different and even the contention management and the speed/modulation can be different as well).
> 
> DHCPv6 is "client-initiated, send once, receive once, confirmation" abstraction. This may be wasteful on the low-bandwidth links that provide bus topology, but maps extremely well
> onto scenarios like WiFi - as it allows to maintain somewhat familiar mode of operation to wired ethernet.
> 
> 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.
> 
> Alternatively, in a very mobile environment and the RFC-compliant router, multicast solicited RAs might make a significant portion of your traffic - which, due to a difference in
> modulation, etc. may eat way more bandwidth than if they were sent unicast.
> 
> 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.
> 
> DHCPv6 Plus: works well in the noisy/lossy environments
> 
> DHCPv6 minus: takes at least 1 RTT to the server.
> 
> 
> 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.
> 
> This "self-stabilizing" property intuitively seems to make RA safer to use, IFF it is used in purely "multicast" fashion.
> However, refer to (1) for the interaction with the underlying media.
> 
> 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).
> 
> DHCPv6 on the other hand, due to its p2p nature is by default well suited for the individual per-client tweaking.
> 
> The distributed nature can be a blessing if you do not care about who gets which address and a curse if you need to account everyone strictly.
> 
> NB: address assignment does not mean that the hosts will always use those addresses - e.g. it's perfectly possible to statically configure a different address, but we talk just
> homogenous standards-compliant well-behaved hosts for simplicity sake).
> 
> That's why I do not use the word "control" but use the word "coordination".
> 
> 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 might create a dissonance between those who want to ensure RAs are used for routing, and those who do not see any use of them in that regard - with the corresponding
> contention of adding anything routing-related into DHCPv6.
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> HTH.
> 
> 
> --a
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
>