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

It is useful for ISPs where some of their network types don't have the circuit ID available, or there is no circuit ID (wireless) or the Circuit ID is dynamic. In these cases, they tend to use the Link Layer address for customer identification. 
----- Original Message -----

> From: "Marc Perea" <marccp@srttel.com>
> To: "Andre Kostur" <akostur@incognito.com>, "Ted Lemon"
> <Ted.Lemon@nominum.com>
> Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>
> Sent: Thursday, July 12, 2012 5:24:11 PM
> Subject: Re: [dhcwg] I-D
> Action:draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

> 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 <Ted.Lemon@nominum.com> 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.

> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg