Subject: [dhcwg] DHCPv6 IA matching

From: Timothy Winters <[email-masked]>
Date: Wed, 17 Sep 2008 13:25:02 -0400

Hello,
	Is a DHCP server allowed to send a Reply to a Confirm message that  
does not contain the same Address option in it's IA?  These does not  
appear to anything in RFC 3315 specifying that the IAs have to match,  
but if they don't, then it is unclear which address the Client should  
bind upon reception of the Reply.
Here is what I have discovered.
	Section 18.1.8 "The client SHOULD perform duplicate address detection  
[17] on each address in any IAs it receives in the Reply message  
before using the address for traffic"
	
	Indicates that it should bind the address in the Reply, but this  
Section of the RFC says
	
	Section 18.1.2 "In any situation when a client may have moved to a  
new link, the client MUST initiate a Confirm/Reply message exchange.   
The client includes any IAs assigned to the interface that may have  
moved to a new link, along with the addresses associated with those  
IAs, in its Confirm message.  Any responding servers will indicate  
whether those addresses are appropriate for the link to which the  
client is attached with the status in the Reply message it returns to  
the client."
	Indicates that a Client would keep the addresses it has already based  
on a success Reply from the server.

	If a server did not want the Client to keep its currently configured  
address it doesn't seem to make sense to change the configuration  
during a Confirm/Reply message exchange.  Any clarification you can  
give in this matter would be appreciated.

I've included one comment I've already received on this issue:
  I think the WG anticipated that the server could, but usually would  
not, send a different set of addresses in the Reply.  I think the  
expectation also is that there would be some intersection between the  
set of addresses in the Confirm and the set in the Reply; that is, the  
server might remove some addresses (imagine some prefixes had expired  
from the link) and add some addresses (...and imagine some prefixes  
had been added to the link).

For example, some sort of renumbering event might take place between  
the time the client disconnects and the time the client sends the  
Confirm.  In that case, the set of prefixes on the link would change  
and the addresses sent to the client would change.

Arguably, the server could send an error status, indicating the  
addresses are no longer valid, causing the client to restart the  
Solicit-Advertise-Request-Reply message exchange.  That alternative  
would be cleaner and required if there is some chance the client  
should establish its address assignment relationship with a different  
server.

Can anyone else shed light on this issue?

Regards,
Tim

Timothy Winters
UNH-IOL

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 17 Sep 2008 12:47:03 -0700

> bind upon reception of the Reply.

I think that Ted Lemon just supplied an extremely detailed analysis
which answers these questions.

In summation, a client should never inspect a Confirm-Reply for an
IA, nor an IAADDR.

Servers probably should not send IA's nor their contents, as they will
be ignored.  Just three options are sent in the reply:  Server's DUID,
client's DUID, status code (3315 section 18.2.2).

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg