hey,
If you have RA from more than one source on the cable you are much more
likely to identify that after none too long debugging if all your
IP configuration is by RA.
You'll just have bignum users calling the helpdesk to complain that
The Internet Is Broken (tm) or that they can't work.
>
It's different in that you can do a change in one protocol expecting it
to be picked up, and a fraction of well-configured hosts may not because
they prefer the other information source.
Deterministic faults are MUCH easier to debug and fix than Heisenbugs.
I don't agree at all that multiple RAs are easier to debug than RA+DHCP.
Normal enduser will not be able to debug it and when you start looking
with packet sniffer you will find the problem in both cases pretty quickly.
Ok, so? How long do you suppose vendors would continue to support RA if
all their enterprise customers ran setups where RA was expressly switched
off? How well would the code that supports RA be tested? are you familiar
with the term bitrot?
Sure I am. Why do you think RA will be switched off? Me and Nick have
totally different use-cases. I'm interested in supporting default gw
together with IA_PD (don't really care for IA_NA at all) for HGW
provisioning. This is in the operator network between HGWs and PEs. As I
already said, it's totally natural to run RA behind the HGW in the LAN
or in the enterprise network, even more as RDNSS is now there.
Let's imagine someone proposes to add IA_PD equivalent into RA, will you
then say it must not be done because DHCPv6 is already there? Or must
DHCPv6 deprecated alltogether because RA can then do everything DHCPv6
can (not really true but you get my point)?
It's not exactly someone elses problem as someone else don't need to
do work if default gw is added to DHCPv6.
You misread me. If default gw is added and DHCP clients start adding it
to routing table, kernel developers, for example, don't have to add
code. If we would have protocol preference then API between RA
implementation and DHCP implementation has to be added.
--
tarko
