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

[Victor Kuarsingh <[e-mail]>]

Mark,

On 2013-10-24 3:44 PM, "Mark ZZZ Smith" <[e-mail]> wrote:

>
>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#sec
>tion-2
>

I am not arguing against these points, but have a few questions and
comments to this approach.  Based on the approach above, it appears that
in the model you describe, DHCPv6 would not provide layer 3 addresses to
end hosts (from the position of many operators, that's the first router or
host behind their access facility).

It this in fact what you are thinking, I believe there are a number of
issues that should be considered to that approach (if this is not what you
are describing, then ignore my next few statements).

Pushing addressing to the operators edge would effectively decentralize
addressing in large operator networks.   This may introduce significant
challenges for those operators (often managing millions of endpoints).
Also, pushing more work the the edge routers should be done with caution.
Edge routers are already becoming bogged down with code, and adding more
state and/or work for that device can exasperate this issue (sometimes it
takes months to over a year to get a code drop which can actually be put
into production).

Pushing the configuration to a centralized function like DHCP has definite
advantages in larger operators environments, providing the ability to
manage very large infrastructures.  It also provides them an ability to
standardize addressing across many different access types and/or platform
versions.  If we push this function to the edge, then we will need to
chase many vendors constantly, to keep up with the needs of this function.

Keeping the edge simple, and allowing the centralized functions to take on
the task of addressing and administering many of these configuration
functions makes the infrastructure much more manageable (and in my
experience, more stable which translates into a better user experience).

Of course, I am only talking about one (significant) use case, and any
changes and/or agreement on what to do with DHCPv6 and/or RAs needs to
take in to account all the use cases.


Regards,

Victor K

>