<html><body><div style="font-family: Andale Mono; font-size: 10pt; color: #000000"><div><br></div><div style="font-family: Andale Mono; font-size: 10pt; color: #000000"><br><br><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Simon Hobson" <dhcp1@thehobsons.co.uk><br><b>To: </b>dhcp-users@lists.isc.org<br><b>Sent: </b>Tuesday, February 14, 2017 3:00:10 AM<br><b>Subject: </b>Re: [dhcwg] RFC3315 DECLINE definition<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">김우태(Network Innovation Projec) <utae.kim@kt.com> wrote:<br><br>> I think IPv6 is co-existed with IPv4 for a while.<br>> Devices have dual stack with IPv4 and IPv6 address.<br>> And there are cases that traces the problem with IPv4 & IPv6 address information.<br>> But, now there have no common key between them.<br>> So, I think IPv6 information is included with device mac address for tracing IPv4.<br><br>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.<br>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.</blockquote><div><br></div><div>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.</div><div><br data-mce-bogus="1"></div><div>See: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml  and https://tools.ietf.org/html/rfc6939 for details if interested.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>For devices not using a relay agent, the MAC address is in the packet.<br>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.<br>_______________________________________________<br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users</blockquote></div></div><div><br></div></div></body></html>