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

"Weil, Jason" <> Wed, 30 October 2013 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DBB011E8252 for <>; Wed, 30 Oct 2013 07:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.363
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j6iPh7Meo7yv for <>; Wed, 30 Oct 2013 07:28:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B994D21F9FE9 for <>; Wed, 30 Oct 2013 07:27:58 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.93,601,1378872000"; d="scan'208";a="46080522"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 30 Oct 2013 10:27:38 -0400
Received: from ([]) by ([]) with mapi; Wed, 30 Oct 2013 10:27:57 -0400
From: "Weil, Jason" <>
To: Nick Hilliard <>, "" <>
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: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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


On 10/29/13 5:50 PM, "Nick Hilliard" <> 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
>that it will break the multiple-routers-per-lan-segment scenario.  The
>above 3 paragraphs also strongly hint at this as being the target
>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
>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
>pretty much any home network is ever going to need.  Architecturally
>interesting, but srsly not realistic as a viable approach to home
>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
>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
>connectivity.  What I need as an operator is a protocol (preferably a
>single protocol because that is simpler) which will enable my boxes to
>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.
>v6ops mailing list

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.