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

[Victor Kuarsingh <[e-mail]>]

On 2013-10-24 12:15 AM, "Nick Hilliard" <[e-mail]> wrote:

>
>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 seems to be folks talking about very different environments, and in
some cases attempting to make arguments which don't address the comments
of the other side.

I understand Nick's point.  Coming freshly off a long sting at an ISP, I
see the value (if it can be done in a sound technical manner), of having
the * option * of a clean deployment for addressing and supplying IP
related configuration information to the end host/router.

This is not saying that it applies everywhere.  It's quite obvious that in
environments like sensor nets, home nets and other places, SLACC/RAs
supply significant value.  In other areas, like an operator access network
(edge element addressing), it's a different case.  Operators, such as the
one I worked or, would never (rarely?) let an element auto-configure
itself onto the network.

I think there may be valid uses cases where, if feasible, there is
perceived value is operating in DHCPv6 only mode.  Of course, in many
environments, DHCPv6 alone is not a good idea (example, my IPv6 light bulb)

In the case of client functionality, in those highly controlled access
network attachment areas, it is expected that the client (router or host)
has a certain level of functionality (and often times this can be
enforced).  So it's reasonable to expect DHCPv6 client functionality in
some use cases. 

>
>There is a tiny amount of protocol glue missing which would allow dhcpv6
>to
>act as a fully functional standalone protocol, and the various attempts to

If this can be done, without harm to other environments, and achieve it's
goals for those who want it (I.e operators who see a need and can
articulate the benefits it will supply in network management and
operation), I don't see why we are unwilling to discuss it's technical
merits.


>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
>and an ambiguous and poorly defined interaction model.

I do wonder how many operators will ask for this?  My concern is that if
there are not too many raising their hands now, it may be that they either
don't care, or if they are way behind in IPv6 deployment, they may not
know that they care yet.


Regards,

Victor K



>