Subject: RE: DHCPNAK for DHCPv6?

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 15 Jul 2001 22:36:41 -0500

Ted:

I agree that we likely need to tighten up the specification. I think the assumption is that an IA (IAID) is bound to a specific interface and that IA (IAID) should only be used on that interface as long as it is in use (has a prefix that hasn't become invalid).

Now, this might have some impact if I change my NIC card because I may now loose all of my old addresses. But, I think that's a small price to pay (it also has some attractions since if I plug in different cards at home and at work, I can retain my home addresses while I'm at work since the IAIDs for the home interface continue to exist and will be valid again when I plug in at home).

>Then, there's no guidance in the draft about how the server chooses IP
>addresses. 

I've always thought we needed text around this subject. I agree that we're kind of assuming a lot - the obvious is for the server to assign addresses with the correct prefixes. But, we should also have recommendations with regards to servers generating addresses. For example, simply incrementing addresses by 1 or some fixed number might be bad (predictive and leaks information). Also, perhaps there should be recommendations against using addresses that could be generated by stateless (with the 'u' bit set) since there could be issues if one switches between stateful/stateless?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, July 13, 2001 12:23 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6? 

> I believe this is covered in the status field in the IA
> option. Section 7.4 has various error codes that can be returned in
> IA status or addr status (the text isn't as clear as to which status
> codes are where as it could be).

No, that's not the problem.  I agree that the DHCP Reply status code
"InvalidSource" solves the problem of sending a DHCPNAK - the problem
is that the draft doesn't say when one would be generated, or how, or
what the client should do when one is received.

Here's the problem: the draft never says *what* IAs you can configure
in a message.  So as an implementor, how do I program my client to
handle the case where there is more than one interface?  It looks from
the protocol specification like I can just send a DHCP Solicit on any
one interface listing IAs for each interface to be configured.  Or
maybe I should send the Solicit on *all* interfaces?  Of course, we
are DHCP geeks, and we know that we should send one Solicit out each
interface containing one IA that is specific to the interface being
configured.   But the draft doesn't say this.

Then, there's no guidance in the draft about how the server chooses IP
addresses.  Presumably, if the client message is received encapsulated
in a Relay-forward message, the server should assign an IP address
that will work on the subnet on which the relay agent reported that
the message was received, and if the message was not received in a
Relay-forward message, the server assigns an IP address on the network
segment to which the network interface on which the packet was
received is connected.   But again, this is never mentioned in the
draft.

Further, once you *have* an address configured, it would be very
tempting to clump all the IAs into one unicast message for renewals.
This would probably work fine in a Renew message, but what about in a
Confirm message?   Obviously this won't work, but the draft offers no
guidance.

I think that the language for the Confirm message does a reasonable
job of solving this problem *if* we add language to the other messages
offering guidance about what IAs can be mentioned.  We could attach
language to the Solicit, Request and Confirm messages saying that only
IAs for addresses for the interface on which the message is being sent
may be included in these messages, and that if the client is trying to
configure more than one interface, it should send one of these
messages on each interface.   I *think* that would solve the problem,
but the language that talks about how to handle responses in that case
still doesn't seem right.   Shouldn't it be possible for *any* server
listening on the link on which the client is trying to Confirm to send
a message saying "you're on the wrong link?"   The present language
implies that only the server that issued the original IA will respond,
and doesn't mention any sort of response that says "you're on the
wrong network."   Here's the language for servers:

   When the server receives a Confirm and an IA option is included the
   client is requesting confirmation that the addresses in the IA are
   valid.  The server SHOULD locate the clients binding and verify the
   information in the IA from the client matches the information stored
   for that client.

   If the server cannot find a client entry for this IA the server
   SHOULD return an empty IA with status set to NoBinding.

   If the server finds that the information for the client does not
   match what is in the server's records for that client the server
   should send back an empty IA with status set to Conf_NoMatch.

   If the server finds a match to the Confirm then the server should
   send back the IA to the client with status set to success.

There's nothing in here about validating the address as to whether or
not it is correct for the link to which the client is attached.
There is an InvalidSource error message, but its use isn't documented.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Mon, 16 Jul 2001 21:52:00 -0400 (EDT)

stateless can generate addresses with the u bit set.

we should say no more about how addresses are generated by a dhcpv6 server
than a router does for stateless.

also your iaid may not last for inifinity and it should not.  

/jim