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