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

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

----- Original Message -----
> From: Nick Hilliard <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>; Ole Troan (otroan) <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>
> Sent: Thursday, 24 October 2013 3:15 PM
> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
> On 24/10/2013 03:20, Mark ZZZ Smith wrote:
>>  RAs are prehaps misnamed. They're not really router advertisements,
>>  they're advertisements (typically) sent from routers. View them as 
> layer
>>  3 configuration protocol packets, because they do far more than
>>  advertise a default router, and don't even need to advertise a default
>>  router to be useful.
> 
> I know what RAs are.  Both protocols provide info to network hosts
> necessary for functional ipv6 connectivity.  They have different
> approaches, but they are both lan configuration protocols.
> 
> If you feel that SLAAC+DHCPv6 or SLAAC only is the right thing for you,
> then that's great and I'm really happy for you.
> 
> There is a tiny amount of protocol glue missing which would allow dhcpv6 to
> act as a fully functional standalone protocol

No, there is lots of glue missing. You'd have to define DHCPv6 options for all of the functions I listed. You'd also have to define an option conflict resolution method or methods for those options, when they happen to be supplied by both RAs and DHCPv6. It may be argued that an network operator shouldn't be doing this, but it might happen accidentally, because your mother is not a network operator, and in the interests of robustness, and more importantly Internet user satisfaction (also your mother), the IETF must not ignore those consequences.

By leaving these RA options out of DHCPv6, the IETF is doing better - it is preventing this problem ever occurring, rather than having to then solve it after having then just creating it. I don't think this problem has been solved for DNS options in RAs (duplication in the other direction), so I won't be confident people would get around to solving it if RA options are put in DHCPv6.


>, and the various attempts to
> introduce this glue have been shot down repeatedly,
> mostly on the basis of

> arguments like "how do you expect your network to work when critical
> components of your network are broken?", "we don't like 
> duplication of
> functionality at the IETF (but we'll ignore all the other duplicated
> functionality in other ietf protocols)"

So you solve the problem of excess duplication by creating more? 

> or "polling sucks".

> 
> None of these points address the core issue which is that there are a lot
> of operators who have a strong preference to use a single lan configuration
> protocol instead of two protocols with strongly overlapping functionality

If you take address configuration out of DHCPv6, there is no overlapping functionality. Address configuration in DHCPv6 is the thing that is not correctly placed in my opinion, not the existence RAs. 


RAs should be limited to configuring layer 3 IPv6 parameters only, solving the network layer configuration problem, on a per link/subnet basis. Different links can have different layer 3 parameters, so the place to provide those parameters is on a per-link basis, using a link-local protocol.

DHCPv6 should be limited to providing primarily application parameters (and perhaps layer 4 parameters) to hosts, solving the end-to-end configuration problem. This problem exists regardless of the network layer parameters, and the parameters for applications are not restricted to being subnet specific, they're more likely to be global across the network, so a solution needs to be subnet/link-local protocol independent.

http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2



If you shove everything into DHCPv6, you now start having a circular dependency problem - DHCPv6 requires UDP to work, which requires IPv6 to work, which requires DHCPv6 to work, which requires UDP to work etc., etc.,

> and an ambiguous and poorly defined interaction model.
> 
> There is no reason for DHCP not to to be standalone-capable, so that
> operators can make up their own minds about what to use on their networks.
> 
> I completely understand that you want to use SLAAC on your networks: please
> stop insisting that I run it on mine.
> 

I'm not thinking of you, you're capable of running a network and fixing complicated problems with it. I'm thinking of my mother. How can she build a working IPv6 network without bothering me. Appletalk and IPX achieved this 20 years ago, it is time the Internet protocols met their standards of user friendliness. Avoiding duplication and function conflict visible to end-users is one of the best ways to achieve that.

> Incidentally a couple of minutes ago, Andrew Sullivan just spoke these
> words about the IETF at IGF2013 in Bali:
> 
> "We're not in the business of telling people how to run their 
> networks".
> 

That's true if you don't have to care about interoperability and ease of use.

Less is more. Complex equals more things that can break.


> 
> Nick
> 
>>  They can be use for:
>> 
>>  - changing host MTUs, instead of individual manual configuration on each 
> host
>>  - announce on-link presence of prefixes, exclusive of whether hosts have 
> addresses within the prefix, instead of individual manual configuration on each 
> host
>>  - adjust neighbor discovery parameters (e.g., timers), instead of 
> individual manual configuration on each host
>>  - announce prefix(es) to be used to generate SLAAC addresses, instead of 
> individual manual configuration on each host
>>  - indicate to hosts whether to use DHCPv6 or SLAAC or both (during a 
> transition between SLAAC/DHCPv6 or vice-versa), instead of individual manual 
> configuration on each host
>>  - advertise a default router, and an associated lifetime, instead of 
> individual manual configuration on each host
>> 
>> 
>> 
>> 
>>>  networks.
>>> 
>>>  Nick
>>> 
>> 
>