Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01

[Sheng Jiang <[e-mail]>]

>-----Original Message-----
>From: Ted Lemon [mailto:[e-mail]]
>Sent: Friday, November 16, 2012 9:41 PM
>To: Mark Smith
>Cc: Sheng Jiang; joel jaeggli; [e-mail]; IPv6 Ops WG;
>[e-mail]
>Subject: Re: [v6ops] some feedback on
>http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01
>
>On Nov 16, 2012, at 1:31 AM, Mark Smith <[e-mail]>
>wrote:
>> I agree with Joel, I think observation by most likely a router is a better
>method, as it will capture address information regardless of whether it was
>configured via static, SLAAC or DHCPv6 (or any future methods).
>
>It's certainly true that a router can capture all the IPv4 and IPv6 addresses
>that a device with a particular MAC address uses.   However, what a router
>_can't_ do, and what this option allows to be done, is for a device that has
>autoconfigured to then provide the network administrator with a hint as to
>what its FQDN should be.   This information isn't available to the router.
>
>It seems to me that although it is true that it is worthwhile to define a
>mechanism for getting common address information from a router, this is
>orthogonal to the question of whether a client-based mechanism for address
>registration is useful.   It seems to me that there are three broad
>classifications of use cases here:
>
>1. In an environment where address registration is mandatory, and hosts are
>tightly controlled, this protocol may suffice.
>2. In an environment where address registration is optional/advisory, this
>protocol may suffice, since presumably the reason you register addresses is to
>track client-sourced information like hostname that relates to the address.
>3. In an environment where address registration is mandatory and hosts are
>not tightly controlled, you need support for address registration on the router.
>However, you can _still_ benefit in this case from the DHCP-based address
>registration protocol; devices that support it can still provide hints about the
>FQDN they want.
>
>I point this out because the reason I support this draft is the FQDN use case.
>This is a use case that has seen substantial use in enterprise environments in
>IPv4.   We do not currently have a solution to the problem for IPv6, because
>in IPv6 we don't require DHCP for host configuration.   This DHCP extension
>allows us to leverage a DHCP infrastructure without _requiring_ that hosts
>autoconfigure using DHCP, and without even _requiring_ that hosts register
>their addresses at all.
>
>I think Sheng has a different use case in mind, and from what I can tell his use
>case falls into the first category, where mine falls into the second.   I know
>of other enterprise users who have use cases that fall into category 3; for
>them, this protocol will not be sufficient, and they will need the router-based
>protocol either instead, or as well.

Hi, Ted,

Thanks for your email. Yes, my original use case falls into the first category. However, since we are trying to define a generic addr registration mechanism, we could include more applicable use cases. I guess what we should do now is to add a "Applicability" section into the draft. Are you interested and have time to contribute some text?

For me, router-based addr registration may need another dedicated draft. Although current IA can work out, a new DHCP option that support bulk addr registration may be more efficient than one addr per time. What's your opinion?

Best regards,

Sheng