[dhcwg] RFC3315 DECLINE definition

[perl-list]

> From: "Simon Hobson" <dhcp1 at thehobsons.co.uk>
> To: dhcp-users at lists.isc.org
> Sent: Tuesday, February 14, 2017 3:00:10 AM
> Subject: Re: [dhcwg] RFC3315 DECLINE definition

> 김우태(Network Innovation Projec) <utae.kim at kt.com> wrote:

> > I think IPv6 is co-existed with IPv4 for a while.
> > Devices have dual stack with IPv4 and IPv6 address.
>> And there are cases that traces the problem with IPv4 & IPv6 address
> > information.
> > But, now there have no common key between them.
>> So, I think IPv6 information is included with device mac address for tracing
> > IPv4.

> If I understand you correctly, you are describing a completely separate issue -
> that of identifying the MAC-IP pairing for IPv6 because your IPv4 workflow is
> based on that.
> That too has been done to death in the DHC WG list - to the extent that (IIRC)
> there is now a MAC address option defined that clients may send, or was it that
> relay agents could add ? I think it might have been the latter since it's
> easier to upgrade a few relay agents rather than every client.
It is RFC 6939, specifically option 79 (OPTION_CLIENT_LINKLAYER_ADDR). It will contain client link layer address if the relay agent supports such relay option stuffing. So far, I hear that Cisco and Brocade support such. Juniper does not yet support. Not sure if they ever will at this point. 

See: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml and https://tools.ietf.org/html/rfc6939 for details if interested. 

> For devices not using a relay agent, the MAC address is in the packet.
> Also, there's been quite firm statements that the wording of the RFCs that
> prohibits "looking inside" the client identifier does not in fact prohibit
> that, although since on a multi-homed device that may not be based on the same
> interface, it's not necessarily all that useful anyway.
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170214/8333909a/attachment.html>