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

["Weil, Jason" <[e-mail]>]

Silly Nick!

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

Jason

On 10/29/13 5:50 PM, "Nick Hilliard" <[e-mail]> 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
>[e-mail]
>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.