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

[Ray Hunter <[e-mail]>]

inline

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 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.

I think you do Enterprise engineers a serious dis-service. Many
consciously choose for L2 interfaces (with HSRP/ VRRP) isolation LANs
between service providers precisely because L3 is more complex to debug
and engineer across an administrative boundary. Even agreeing on an IGP
can be tricky, never mind worrying about route flapping or
redistribution loops. Experience has shown that HSRP/VRRP + static
routes in a simple active/standby construction can deliver extremely
robust SLA KPI's.

Secondly, practical deployment of L3 routing protocols on end hosts was
a no-go in IPv4.

> 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.

I think Homenet WG well-understands the challenges with deployment and
little-conf..


> 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.

I disagree entirely, and would characterise this as a rather
network-operator-centric view, rather than a host-centric view.

> 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.


Erm. Have you missed the move to wireless?

My smartphone already has two radios and a physical interface, connected
to multiple providers.

How exactly do you then configure a "single defgw per lan segment"
(without draft-troan-homenet-sadr-01)

> 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
>
>

-- 
Regards,
RayH