Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

[Andrew Yourtchenko <[e-mail]>]

On Sat, 7 Dec 2013, Owen DeLong wrote:

> 
> On Dec 7, 2013, at 22:25 , Andrew Yourtchenko <[e-mail]> wrote:
>
>       On Sat, 7 Dec 2013, Owen DeLong wrote:
>
>                         I don't think RAs are the single reason some people are resisting deploying IPv6 at all. I think some people
>                         are resisting deploying IPv6 because it needs to do one or both of two things for them - solve a foreseeable
>                         problem that will effect them, or provide a tangible benefit. If it won't do either of those things, then they
>                         don't currently see any value from the effort involved. What are foreseeable problems or tangible benefits is
>                         completely up to the perspective of the decision maker. Eventually they'll see value in it, and deploy it. In
>                         some cases, some people who could deploy IPv6 may never see any value in deploying it, so they never will.
> 
>
>                   It's not binary. You can represent as a number both the amount of pain that a given problem (or set of problems) causes,
>                   and the amount of pain that the big change in the network like adding a new protocol causes.
>
>                   As soon as the first number is smaller than the second one, nothing gets done.
>
>                   Judging by the feedback I get from talking with people, even the possibility of eventually eliminating RAs from their
>                   network might make the second number smaller for a nontrivial amount folks, whose situation dictates the DHCPv6.
> 
>
>             I find this very hard to believe. RAs are virtually automatic and free in 99% of cases. If you feel the need to tune them, then that's
>             pretty trivial if you know enough to tune them properly.
>
>             If you don't know what you are doing, then you can really mess yourself up with RA tweaking that you shouldn't be doing.
>
>             However, I do not advocate IETF breaking the internet just to prevent people from breaking their LANs out of ignorance.
> 
>
>       It's another protocol to run. It's not free.
> 
> 
> It seems free to me. I configure an address into my router and it starts announcing RAs.
>

That's the crux. It's free to you, so you make the leap "so it's free".

>       That the price varies for different parties is a different matter.
> 
> 
> Fair enough, but it's free or very nearly free for the vast majority of parties.

You need to take care:

1) that the RAs from the router reach the hosts.
2) that only the RAs from *your* router reach the hosts.

either of the two may be a non-issue for *you* but the induction that it's 
a non-issue for *everyone* is incorrect.

>
>                         There is no single answer to why people might resist deploying IPv6, no single solution, and things that
>                         motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works.
> 
> 
>
>                               I think in this discussion are again getting into the argument of "the best solution" instead of
>                               trying to collect the properties of the RA and DHCP.
>                               My position is that single best solution does not exist, because
> 
>
>                               everyone's problems are slightly different. So, rather than preaching for everyone to adopt the
>                               single solution which is the best in one scenario and suboptimal in the other, we should be
>                               engineering a way to be able to apply different solutions in different circumstances without the
>                               overhead of double work.
> 
>
>                         A single solution that solves most cases is better than two different,
> 
>
>                   That's the point. The single solution that solves most cases, does not exist. For a good part of the cases, you need to
>                   apply two solutions at once. Justifiably, the question is "why", given in legacy IP they did not need to do that.
> 
>
>             Actually, the problem is that people have conflated two different problems and like to pretend that they are one.
>
>             In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem.
>
>             RAs solve the problem of telling a host which routers are available on link.
>             RAs also sort of solve the problem of dynamic host configuration (address, RDNS servers, DNS Search list)
>
>             For better or worse, to keep RAs very light weight, they do not provide a complete or robust solution to host autoconfiguration.
>
>             For that, you need DHCPv6 which is a protocol designed to do host configuration.
> 
>
>       I think you nailed it here: With RA you *discover* the routers available on the link, with DHCP in legacy IP, you *configure* them.
> 
> 
> No, with DHCP, you discovered what some remote host rumored them to be.
>
>       In some case you don't want the hosts to "discover" anything - your network does not change, you know your router, and actually having a way to
>       *configure* it is more robust and secure than having to *discover* it. Why take away the tool from the toolbox ?
> 
> 
> Your host is always discovering things. IP doesn't work without discovery (at least not in any practical way for the vast majority of applications). In IPv4,
> ARP is used to discover the MAC address of adjacent hosts, for example. In IPv6, we use Neighbor Solicitation and Neighbor Advertisement to do roughly the same
> thing.
> 
> There are a number of advantages to finding out what routers are available to you FROM THE ROUTERS instead of getting rumors from some remote server which may
> or may not be accurate in general and certainly have a reasonable chance of being flat out wrong in the event of any failure condition.
> 
> A network that doesn't change is an amusing fallacy. I will agree that there are some networks which don't change until they do. However, I have yet to see a
> network that didn't change.

There are a number of advantages to NOT finding out from the routers that 
they are the routers in an unauthenticated manner.

The environments vary.

>
>       Thanks for this, I think this is a very valuable point, I'll add it to the text - https://github.com/ayourtch/ra-dhcpv6/issues/9
> 
> 
> If you do so, please do not misconstrue my remarks the way you have in this case.
>

Okay, I will not add you to the "acknowledgements", and will treat that 
idea as my own, FWIW.

> 
>
>             While I would like to see routing options added to DHCP for a variety of reasons (mostly political and organizational rather than
>             technical), I do not for one second believe that eliminating RAs is useful in any significant proportion of environments.
>             Even if we made the changes you are proposing, eliminating RAs would be unlikely in the vast majority of circumstances, at least for
>             many years to come.
> 
> 
>
>       First off, I am not proposing to eliminate the RAs, at least not just yet. :-)
> 
> 
> I didn't mean eliminating them in general. I meant that I am very hard pressed to imagine any scenario where a network would benefit from eliminating them
> other than certain environments that would probably be better suited to 6LOWPAN anyway.

Did you read the draft mentioned in the subject line ?

>
>       I am proposing to stop blindly repeating "thou shall not eliminate RAs" mantra and explore with an open mind, what are the drivers behind people
>       wanting to use DHCP-only, how hard would that be, and see on balance whether the juice is worth the squeeze.
> 
> 
> I've been through that exercise. I'm all for giving DHCP the ability to provide routing information. I've said as much on numerous occasions.
> 
> However, even on a network that is running "DHCP only" you gain nothing (at least in the vast majority of circumstances) and lose significant robustness if you
> turn off RAs.

Legacy IP runs fine with no RAs. Quite robustly.

>
>       Second, there are no IPv6-only enterprise networks today, so eliminating RA would be *trivial* in those environments that want to eliminate them,
>       as soon as 1-2 mainstream OSes were to support it.
> 
> 
> That isn't true. I doubt seriously that there are no IPv6-only enterprise networks, but I accept that there are very few.
> 
> However, eliminating RA in those environments that want to eliminate them would not be trivial. You'd have to upgrade every desktop OS and every other
> dynamically configured device because in the current running code, DHCP doesn't work without an RA to tell it "go ask the DHCP server".

My OS upgrades itself every other week. And installs apps, bugfixes, and 
such. Autoupdate exists and works. In a stricter environment you have an 
IT department building the golden setups. The image lifecycle there is 3-5
years.


>
>       How ? Much the same as with DHCPv6-only networks today. Don't support the network's policy ? Fine, you are welcome to use your legacy IP stack
>       until you do.
> 
> 
> There are no DHCPv6-only networks today.

I was using one just on Friday.

>
>       And in any case "taking many years to come" is not an argument for not doing things.
> 
> 
> It is an argument against putting significant risk into a deployed codebase for a minuscule gain for a very small number of beneficiaries.
>
>       Case in point: IPv6 itself.
> 
> 
> IPv6 itself didn't involve deploying incompatible updates that will potentially interfere with a deployed operational protocol.

IPv6 is completely incompatible with the deployed operational IPv4, and in 
the rfc3484 case a broken IPv6 completely screws up your perfectly working 
IPv4.

> The changes you are proposing
> (to make hosts do DHCP without bootstrapping it through the RA process) 
>are different. Those are not at all unlikely to be problematic in a 
>number of difficult
> to predict ways.

Again, all I am proposing is to decriminalize the thinking about proposing 
DHCPv6-only operation and its implications, and be able to write it up for 
further balanced analysis.

If you have an opinion that is a useless activity - absolutely fine.

I registered that. Let's move on and if you do not have any comments on 
the text itself, we can wrap this sub-thread up.

> 
> Personally, I would much rather see us focus on the following easily achievable goals that I think matter to a lot more people:
> 
> 1. Provide more consistent guidance on the interactions of M, O, and A flags in RAs and how RAs should be processed.

This is great - (though, if we were to use the argument you used 
previously - why bother ? it will anyway take forever to achieve the 
consistency). Documenting the existing behavior is a great start, anyway. 
draft-ietf-v6ops-dhcpv6-slaac-problem is awesome.

> 2. Provide more consistent guidance on the interactions of RAs that disagree. While this is arguably a "broken network"
> condition, it is a form of brokenness where having a defined and deterministic mode of failure is more desirable than
> the current "depends on the host OS, phase of the moon, and 2d20 roll of the operator" scenario.

This is indeed a broken network.

Use router priorities - it's an existing and deployed 
mechanism which trivially resolves the conflicts with no ambiguity and no 
code changes required. (Of course, assuming the host implements them and 
implements correctly).

> 3. Add routing information to DHCP for those that want to use it.

It will end up in the threads exactly like this one, just with different 
people.

--a