<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 21/mag/2013, at 15:25, Tim Chown <<a href="mailto:tjc@ecs.soton.ac.uk">tjc@ecs.soton.ac.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 21 May 2013, at 13:26, Nick Hilliard <<a href="mailto:nick@foobar.org">nick@foobar.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On 21/05/2013 13:00, Liviu Pislaru wrote:<br><blockquote type="cite">With DHCPv6 i didn't find a way to do that (identify what IPv6 is allocated<br>to which customer) without asking any additional information from the<br>customer (like DUID).<br></blockquote><br>apparently this is a feature, not a bug.<br></blockquote></div><br><div>There is this, which allows a relay to insert the client hardware address:</div><div><a href="http://tools.ietf.org/html/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01">http://tools.ietf.org/html/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01</a></div><div><br></div><div>Seems to have expired though :/</div><div><br></div><div>Tim</div></div></blockquote></div><br><div>This one is still valid, though:</div><div><a href="http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/" style="font-family: monospace; ">http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/</a><br style="font-family: monospace; "></div><div><br></div><div>The difference is that in the new draft the link-layer address is not an option for clients, but just for relays. The idea is that servers located on the same link as the client may find the link-layer address in the L2 header.</div><div><br></div><div>Marco</div></body></html>