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

[Mark ZZZ Smith <[e-mail]>]

So what I really want to see is an actual and specific definition of the problem with RAs for conveying layer 3 protocol parameters, not the assertion that there are problems, and then time spent speculating on ways of achieving it.

It seems to me that the things people complain or might complain about RAs are :

(1) it is different to how it is done in IPv4, which is therefore asserting that IPv4 DHCP is the best way to solve the address configuration problem (which is different to the way the problem has been previously solved in every other protocol, including original IPv4, and needs to be considered in the context of when it was developed (IIRC, the primary thing DHCPv4 solved at the time, over bootp from which it is derived, was the ability to have more physical hosts than addresses, as long as the number of active hosts was less than or equal to the number of addresses. )

(2) it is database driven, so there are records of active addresses in use (which isn't actually the case, because DHCPv6 won't capture link-local addresses in use, or statically configured addresses)

(3) periodic unsolicited multicasts

So I think (2) is invalid, as it won't record link-local or static addresses in use. A better method would be to have the routers on the link monitor DADs, and them via some other method.

I think (3) is invalid, as by default RAs are announced once every 10 minutes, which means is RA multicasts are likely to be lesser of multicast traffic on the network. That timer can be changed to up to once very 30 minutes.

Which leaves (1). I don't think just because something is different is a reason to change it, when it has been shown to work.

The costs of providing two different methods for layer 3 network to host configuration would now be huge. It isn't just a matter of defining the methods in the IETF, which is cheap. For it to be useful and effective, it needs to be developed, debugged, deployed and supported/troubleshooted on hosts. Specifically, *all* possible hosts that might be exposed to the new method, which includes the billion+ IPv6 capable smartphones and tablets that are already deployed. Any IPv6 segment that a host might attach to might be using one or the other of these methods. To facilitate a smooth transition to DHCPv6 for everything, RAs will have to be enabled anyway ...


I don't think the argument that this decision is isolated to a network is valid. I'm guessing the example people are thinking of is the IS-IS vs OSPF vs other IGPs choice inside a network. However, that is nicely partitioned and isolated to a network using BGP (a single protocol between two different parties), and the only people who are impacted by the choice are the same people who choose, deploy and operate the devices in question, and their vendors (and the vendors won't provide that choice unless their are enough paying customers). A host to network interaction is very different when hosts are commonly owned, operated and developed by parties that are both exposed to the choice of the protocol between the host and the network but have no or very little say in it.

So provide evidence that RAs are inadequate, and that the huge time, effort and cost involved in moving to a dual RA and DHCPv6 method is worth while. Justify why creating more reasons not to deploy IPv6, by creating more choice and therefore more uncertainty, are worthwhile.

Create a problem statement before working on a solution to it.

Regards,
Mark.




>________________________________
> From: Lorenzo Colitti <[e-mail]>
>To: Gert Doering <[e-mail]> 
>Cc: "[e-mail]" <[e-mail]>; Ted Lemon <[e-mail]>; Ole Troan (otroan) <[e-mail]>; Dave Thaler <[e-mail]>; "[e-mail]" <[e-mail]> 
>Sent: Monday, 28 October 2013 1:58 AM
>Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft:    draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
>
>
>On Sun, Oct 27, 2013 at 11:52 PM, Gert Doering <[e-mail]> wrote:
>
>> > I do not think that I made an actual proposal here.
>>> I mean "Stateful RA could actually be piggybacked onto DHCP, so that the
>>> router just creates a DHCP message and forwards it upstream, or answers
>>> it locally, depending on the circumstances." xing
>>
>>This is called "DHCP relay or DHCP server on the router".  I can't see
>>what this has to do with RA ("periodically multicasted to everyone who
>>wants to receive it").
>>
>>This idea is... completely lacking the understanding of the difference
>>between solicited and unsolicited information, and also of the existing
>>possibilities of just having a DHCPv6 server (or relay) on the router
>>itself.
>>
>
>
>The way I read that was:
>
>
>1. Host sends RS.
>
>2. Router gets RS, encapsulates it in DHCPv6 option to DHCPv6 server.
>3. Server replies with RA parameters.
>4. Router sends unicast RA to host.
>
>
>The unicast RA would have more information than the multicast RA (e.g., more specific routes). The idea being that you if you do this you can send different clients different information (which is one of the things that DHCPv6 offers but RAs typically do not).
>
>
>So it's basically a RA-to-DHCPv6 translator in the router.
>
>
>If you want to do it this way, I don't see why you would use DHCPv6 and not something like radius, but I suppose you might want to do that if you need to keep state on the server (radius is stateless).
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>