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

"Weil, Jason" <jason.weil@twcable.com> Wed, 30 October 2013 14:28 UTC

Return-Path: <jason.weil@twcable.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 1DBB011E8252 for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2013 07:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.363
X-Spam-Level:
X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
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 j6iPh7Meo7yv for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2013 07:28:27 -0700 (PDT)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id B994D21F9FE9 for <v6ops@ietf.org>; Wed, 30 Oct 2013 07:27:58 -0700 (PDT)
X-SENDER-IP: 10.136.163.10
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.93,601,1378872000"; d="scan'208";a="46080522"
Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 30 Oct 2013 10:27:38 -0400
Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 30 Oct 2013 10:27:57 -0400
From: "Weil, Jason" <jason.weil@twcable.com>
To: Nick Hilliard <nick@inex.ie>, "v6ops@ietf.org" <v6ops@ietf.org>
Date: Wed, 30 Oct 2013 10:27:56 -0400
Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
Thread-Index: Ac7VfDp60V5ctKc8RFOMPNQPMzzaSg==
Message-ID: <CE968F85.20826%jason.weil@twcable.com>
In-Reply-To: <52702DC2.1080507@inex.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 30 Oct 2013 14:28:31 -0000

Silly Nick!

Operational reality never factored into this equation. It is a thought
project.

Jason

On 10/29/13 5:50 PM, "Nick Hilliard" <nick@inex.ie> wrote:

>On 29/10/2013 20:20, Andrew Yourtchenko wrote:
>> debate - maybe worth just folding it back into a pure factual "It was
>> decided that RA does routing, DHCPv6 does not, by the way RA does a slow
>> redundancy, which people do not like, therefore they think DHCPv6
>>should do
>> routing".
>
>WFM, and I very much like your draft so far, btw.
>
>Later on in the text, it says:
>
>>    However, the "single source of truth" nature of DHCPv6 prevents the
>>    successful operation in case of multiple servers on the segment
>>    supplying different information. RAs in this case may still work.
>>
>>    Some consider the inability to support this scenario crucial, and
>>    some think it is not useful. This creates contention between the
>>    proponents of those who want DHCPv6 deal with routing, and those who
>>    think RA is the single possible candidate for that.
>>
>>    The other aspect is that because RA ties in the routing and
>>    addressing information, one can say "RA shares the fate with
>>    routing". However, this distinction is merely because of the
>>    decision to explicitly keep DHCPv6 away from routing - so can not be
>>    considered a true property of the protocol.
>
>The premise that many people in the IETF seem to be working on is that the
>typical - or even a common - deployment case of ipv6 will involve multiple
>routers per lan segment.  I say this because every time the issue of DHCP
>providing a defgw comes up, one of the main arguments that's trotted out
>is
>that it will break the multiple-routers-per-lan-segment scenario.  The
>above 3 paragraphs also strongly hint at this as being the target
>deployment.
>
>Well maybe dhcpv6 doesn't do that, but the operational reality is that
>multiple gateways on the same lan is going to be the rare exception rather
>than the rule. The reason why I think this is because:
>
>1. enterprises have an obtuse obsession for L2.  They'd pave the world
>with
>L2 and extend L2 from one end of the universe to the other if they could.
>Just look at the horror of vxlan (who are they kidding?  themselves?) as a
>perfect example of this insanity.  I don't know why this is but it's the
>way that lots of enterprise rolls, ranging from SME to largish networks.
>Outside truly large operations (i.e. 10s of thousands of users), I have
>never got the impression that enterprises got L3 routing.
>
>2. homenet: I don't understand the target audience for the entire homenet
>multiple network movement. Putting this another way: who is going to debug
>homenet multiple network stuff when it breaks, because as far as I can
>tell, that belongs in the realm of level 2 engineering escalation (i.e.
>$120/hr sort of thing).  It's a little far-fetched to expect gramps and
>grandma to set up and maintain and debug multiple networking segments.  A
>good chunk of the stuff going on in homenet is vastly more complicated
>than
>pretty much any home network is ever going to need.  Architecturally
>interesting, but srsly not realistic as a viable approach to home
>networking.
>
>3. service providers - the single operational group on the internet that
>actually understands L3 / network segmentation and why it's important -
>will attempt avoid multiple gateways per network like the plague because
>it
>makes their deployment scenarios more complicated and provides no extra
>value.  For server / host farms, service providers like FHRP with tight
>timers because it gives control of onward connectivity.
>
>All of which doesn't leave very many more user-market segments.
>
>Regarding RA for routing and DHCP for addressing, what people care about
>is
>connectivity.  What I need as an operator is a protocol (preferably a
>single protocol because that is simpler) which will enable my boxes to
>gain
>the connectivity they need.  Whether you call this routing or providing a
>default gateway, I don't much mind.
>
>Look, there's too much ideology going on here.  The IETF is being dazzled
>by the sight of multiple lan segments and multiple egress gateways without
>realising that these are the minority configuration.  All this effort is
>going into optimising ipv6 address / lan autoconfiguration for these
>unusual scenarios without heeding the sober reality that most people,
>service providers and enterprises are only ever going to want to have a
>single defgw per lan segment, and that by far the most common deployment
>scenario will be a single lan segment per organisation.
>
>I'm aware that this viewpoint will be regarded as retrograde, and that a
>bunch of people on this list will probably sit there, rolling their eyes
>and thinking: "yeah, and 640k was enough for everyone".
>
>Just bear in mind that added complexity is not necessarily a good thing.
>The support costs are high and the return on effort is dubious at best.
>IOW, the IETF is optimising a corner case.  This is not smart.
>
>Nick
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.