Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

["Marc Perea" <[e-mail]>]

Indeed. Although I work for an ISP, and our intent on v6 is to use option 82 to identify endpoints, including for the purposes of PD where we won't care what LL address is presented from the WAN of the device, this work is useful when I wear the corporate hat, or the educational lab services hat, or the captive portal for wifi hat. I'm not necessarily interested in restricting the use of the mechanism we're attempting to push forward here - I'm trying to understand what real world scenario could exist that justifies expanding the scope of the draft. I feel that the work and scope are currently justified and real - I'm not against expanding both, but I'd like to know it's being done to solve a real problem. Can you elaborate?

>>> Ted Lemon <[e-mail]> 7/12/2012 2:49 PM >>>
On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote:


Ok, if we're restricting to ISP environments, why not mandate in such
environments that they should be using the Remote ID (RFC 4649) to
specify the downstream "client".  Note that in DOCSIS environments,
this is already happening.  (Just not in RFC 4649 form... but in an
enterprise-specific option 17).

It's my understanding that the main motivator for this draft is use in corporate IT departments that inventory machines by MAC address.   I guess it would also be useful for ISPs, but that's certainly not the use case that I've heard mentioned most.