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

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Sun, 27 October 2013 20:20 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
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 101D011E81B4 for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2013 13:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.824
X-Spam-Level:
X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5]
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 hRsdZJzG84p7 for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2013 13:20:10 -0700 (PDT)
Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id F423911E8198 for <v6ops@ietf.org>; Sun, 27 Oct 2013 13:20:09 -0700 (PDT)
Received: from [98.139.212.153] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 20:20:09 -0000
Received: from [98.139.212.221] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 20:20:09 -0000
Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 20:20:09 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 507360.5798.bm@omp1030.mail.bf1.yahoo.com
Received: (qmail 68107 invoked by uid 60001); 27 Oct 2013 20:20:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382905209; bh=dPOTuvxlNQvYl+6QzWCaMG+tnplSAyQltnEOUf3+SZg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3Wlf8hr8uj6M/dpYsMn1REU3DGkxv4DUJefws5Mvc/PdoFskcrNR+qbcme5RRNT6qxgmHDC4+Jlih52prYhJy3qrwlZTy92PIlHGoaRMQShDpcxSLaTKzp92FFquXa3WVbvRmRBINcYigaaa3/sXdheWnvbtUqyLiRr5MoaGDhw=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fP5ygUiJBdKpdWunR7cFwO2h+KS9N2KFcET7ZHBx3/YY3qx+VfgzE55mOj5vSJL8Hz8uh1xSqN8m/9RfV0BApZc/OZ/7GJUGaPctSIz8x+XW8iBl1CYa02UP8EW0EemhXo/54RsaMa2cac8lR1Qj4DpR/47DhbW6XzkFkPD/nRU=;
X-YMail-OSG: Ku_LtR0VM1lavHqI3zayhNeTYEunMd9z0DL_yIpiy3aofH9 2NLQQs5.5MrjKiwp8nljYNULYU3C86OIMv.jmi.1weC.SNUUaKm5oJBAVWFs WQzkn9zTWh6jex6xRA76I7GMrG3WIeEngKbvo7yNpt96EpZpT9VK4HHhsb1B 4CflSM4Di8jzS6odCR0SZTpEnshAL1GQbB5taKLcbNNNzSdh1Q1AHH5O6.D. u2JZc2MSOucdktlq1fuMzuaReu5.ZAl6kvZPctEoT0SGBJl8p8v1n6Siq3O8 UNeoGrOE_QeVAijhvmCsxtyPDO8K1DXEophyZhscHw363mBohI8M28nlWTsf ur8DZFJcTNVXWedZxcNzXfIANypfw3cM4WBaicVBDJr3efrI_ju8aBxxO21v .san2kCgVZIfUW3sT.yP3BEYyNjQ2IfTmuPMzmkYnwryI3vpcPMtlTQYiAUr kI6w1UWqDFwMaV7EVZcZjs8EpbXaR.XNvzyB2reC9Yu3tzprEqEyHhZeMolq c_9_fNOrtZJhn68BprNPnvtwLrSUGwqIO_8EfzUzCPu.8ls3HBzfAed1meD1 UYR1l6MTkzJC6cw_3yPV3tmiSyMUM7Yl.lnlW.meZeZYS
Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Sun, 27 Oct 2013 13:20:07 PDT
X-Rocket-MIMEInfo: 002.001, U28gd2hhdCBJIHJlYWxseSB3YW50IHRvIHNlZSBpcyBhbiBhY3R1YWwgYW5kIHNwZWNpZmljIGRlZmluaXRpb24gb2YgdGhlIHByb2JsZW0gd2l0aCBSQXMgZm9yIGNvbnZleWluZyBsYXllciAzIHByb3RvY29sIHBhcmFtZXRlcnMsIG5vdCB0aGUgYXNzZXJ0aW9uIHRoYXQgdGhlcmUgYXJlIHByb2JsZW1zLCBhbmQgdGhlbiB0aW1lIHNwZW50IHNwZWN1bGF0aW5nIG9uIHdheXMgb2YgYWNoaWV2aW5nIGl0LgoKSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgdGhpbmdzIHBlb3BsZSBjb21wbGFpbiBvciBtaWdodCABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.160.587
References: <CE8E8EC3.59F3A%victor@jvknet.com> <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> <C8C148BF-08F0-488A-BF1A-8B4BEAC39156@fugue.com> <526D18F2.8040103@cernet.edu.cn> <20131027145224.GT50205@Space.Net> <CAKD1Yr13YGiRfHm0RoOoGe+02SCXcPFE7rgBG=RiT1-dTfEnrg@mail.gmail.com>
Message-ID: <1382905207.67992.YahooMailNeo@web142503.mail.bf1.yahoo.com>
Date: Sun, 27 Oct 2013 13:20:07 -0700 (PDT)
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: Lorenzo Colitti <lorenzo@google.com>, Gert Doering <gert@space.net>
In-Reply-To: <CAKD1Yr13YGiRfHm0RoOoGe+02SCXcPFE7rgBG=RiT1-dTfEnrg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
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: Sun, 27 Oct 2013 20:20:15 -0000

So what I really want to see is an actual and specific definition of the problem with RAs for conveying layer 3 protocol parameters, not the assertion that there are problems, and then time spent speculating on ways of achieving it.

It seems to me that the things people complain or might complain about RAs are :

(1) it is different to how it is done in IPv4, which is therefore asserting that IPv4 DHCP is the best way to solve the address configuration problem (which is different to the way the problem has been previously solved in every other protocol, including original IPv4, and needs to be considered in the context of when it was developed (IIRC, the primary thing DHCPv4 solved at the time, over bootp from which it is derived, was the ability to have more physical hosts than addresses, as long as the number of active hosts was less than or equal to the number of addresses. )

(2) it is database driven, so there are records of active addresses in use (which isn't actually the case, because DHCPv6 won't capture link-local addresses in use, or statically configured addresses)

(3) periodic unsolicited multicasts

So I think (2) is invalid, as it won't record link-local or static addresses in use. A better method would be to have the routers on the link monitor DADs, and them via some other method.

I think (3) is invalid, as by default RAs are announced once every 10 minutes, which means is RA multicasts are likely to be lesser of multicast traffic on the network. That timer can be changed to up to once very 30 minutes.

Which leaves (1). I don't think just because something is different is a reason to change it, when it has been shown to work.

The costs of providing two different methods for layer 3 network to host configuration would now be huge. It isn't just a matter of defining the methods in the IETF, which is cheap. For it to be useful and effective, it needs to be developed, debugged, deployed and supported/troubleshooted on hosts. Specifically, *all* possible hosts that might be exposed to the new method, which includes the billion+ IPv6 capable smartphones and tablets that are already deployed. Any IPv6 segment that a host might attach to might be using one or the other of these methods. To facilitate a smooth transition to DHCPv6 for everything, RAs will have to be enabled anyway ...


I don't think the argument that this decision is isolated to a network is valid. I'm guessing the example people are thinking of is the IS-IS vs OSPF vs other IGPs choice inside a network. However, that is nicely partitioned and isolated to a network using BGP (a single protocol between two different parties), and the only people who are impacted by the choice are the same people who choose, deploy and operate the devices in question, and their vendors (and the vendors won't provide that choice unless their are enough paying customers). A host to network interaction is very different when hosts are commonly owned, operated and developed by parties that are both exposed to the choice of the protocol between the host and the network but have no or very little say in it.

So provide evidence that RAs are inadequate, and that the huge time, effort and cost involved in moving to a dual RA and DHCPv6 method is worth while. Justify why creating more reasons not to deploy IPv6, by creating more choice and therefore more uncertainty, are worthwhile.

Create a problem statement before working on a solution to it.

Regards,
Mark.




>________________________________
> From: Lorenzo Colitti <lorenzo@google.com>
>To: Gert Doering <gert@space.net> 
>Cc: "v6ops@ietf.org" <v6ops@ietf.org>rg>; Ted Lemon <mellon@fugue.com>om>; Ole Troan (otroan) <otroan@cisco.com>om>; Dave Thaler <dthaler@microsoft.com>om>; "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org> 
>Sent: Monday, 28 October 2013 1:58 AM
>Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft:    draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
>
>
>On Sun, Oct 27, 2013 at 11:52 PM, Gert Doering <gert@space.net> wrote:
>
>> > I do not think that I made an actual proposal here.
>>> I mean "Stateful RA could actually be piggybacked onto DHCP, so that the
>>> router just creates a DHCP message and forwards it upstream, or answers
>>> it locally, depending on the circumstances." xing
>>
>>This is called "DHCP relay or DHCP server on the router".  I can't see
>>what this has to do with RA ("periodically multicasted to everyone who
>>wants to receive it").
>>
>>This idea is... completely lacking the understanding of the difference
>>between solicited and unsolicited information, and also of the existing
>>possibilities of just having a DHCPv6 server (or relay) on the router
>>itself.
>>
>
>
>The way I read that was:
>
>
>1. Host sends RS.
>
>2. Router gets RS, encapsulates it in DHCPv6 option to DHCPv6 server.
>3. Server replies with RA parameters.
>4. Router sends unicast RA to host.
>
>
>The unicast RA would have more information than the multicast RA (e.g., more specific routes). The idea being that you if you do this you can send different clients different information (which is one of the things that DHCPv6 offers but RAs typically do not).
>
>
>So it's basically a RA-to-DHCPv6 translator in the router.
>
>
>If you want to do it this way, I don't see why you would use DHCPv6 and not something like radius, but I suppose you might want to do that if you need to keep state on the server (radius is stateless).
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>