Subject: [dhcwg] DHCPv6 link-address field in Relay-Forward message.

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Oct 2010 14:30:11 -0700

I have recently been reminded of the link-address "convention" to use
zeroes in the Relay-Forward/Relay-Reply messages, and have had to
explain the current behavior and the rationale, and the use case as it
is not captured in RFC 3315.

Brief summary of the convention:

To my memory, Tomasz Mrugalski or Marek Senderski first started
sending IA_ADDR options from a DHCPv6 client with the address field
(all 128 bits) zeroed.  This was so that his client could advertise
preferred and valid lifetimes - the server could then negotiate final
values in reply.  Since the client had no notion of any address to
request, it requested the all-zeroes address as meaning 'none'.

This convention essentially has been extended in the link-address case
specifically where the relay agent has no globally route-able address
on the network the client is attached to (such as an L2 relay agent
that is passing the message along to an L3 agent or server).  My
memory is that Bernie was asked by such L2 implementors if they should
fill the link-address field with the relay's link-local address, or
some other special value, and he successfully negotiated a better
outcome in providing zeroes.

So a DHCPv6 server is expected to search from the "clientmost"
position in the packet out to the "outermost" Relay-Forward and find
either the first non-zero link-address field (possibly with the
sanity check to ensure it is not a link-local address), or in the case
all the link-address fields are zero to consider the client is 
attached on the interface it received the packet.

This is all working well, but the recent exercise of explaining the
current implementation and its reasons has reminded me that this so
far has not been written down as DHCPv6 protocol standard.

My memory is that Ralph wrote this down as RFC 3315-bis fodder, but
that doesn't seem to be happening, and so for the time being we have
a piece of distributed institutional knowledge.

Should we submit this as an RFC 3315 errata, or a small draft to
update 3315?

I have a suspicion that although the text to update 3315 (both for
the link-address and IAADDR) for conformance is quite small, and
suitable for errata, the text to explain the expected use case will be
quite hard to make plain.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/