Subject: Clarification sought for Oslo minutes regarding DHCPv6...

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Mon, 9 Aug 1999 17:59:43 -0400 (EDT)

Hi folks,

Could the person(s) who made the following suggestions please clarify what
you meant? (a paragraph would be nice). Please send your description
to me, copy <[email-masked]>

Current technical issues

	* How does a client request addresses from multiple prefixes?

DHCPv4 features to carry forward/misfeatures to avoid/missing features to add

	* "Echo option" - client retains and echoes option value from server

	* Explicit "change server" mechanism

DHCPv6 new features

	* Consistency across client implementations:
		- List of client-supported options
		- Client can explicitly reject options as unsupported/unrequested
		- Alternative actions: what to do if option unrecognized,
		  unrequested, ...
		- Requested values: client gives range of desired values.

Document structure
	
	* Additional discussion needed about why complicated actions  are mandated
	  and how there were arrived at. WG to send input to authors about parts
	  of the spec that require additional discussion. Could the WG please
	  do this?

Thanks much for your input,

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803

---

From: Francis Dupont <[email-masked]>
Date: Tue, 10 Aug 1999 12:38:23 -0400 (EDT)

In your previous mail you wrote:

   Current technical issues

=> a client boots on a link with more than one global prefix,
how the client gets an address per prefix? An example should be
enough (there are many ways to solve this issue but only one
should be correct).

Regards

[email-masked]

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Wed, 11 Aug 1999 19:23:48 -0400 (EDT)

Hi folks - awfully silent out there... can someone help me out and clarify the
following suggestions?

TIA.

---

From: Stig Venaas <[email-masked]>
Date: Sat, 14 Aug 1999 07:43:31 -0400 (EDT)

Hi all

> 		- Requested values: client gives range of desired values.

I'm trying to remember myself. I think my first suggestion was that the
client could in the solicit message indicate which extensions it knew of
(or options as I guess I said at the meeting). The format could be similar
to extensions in request messages. I think it should be optional for the
client to do this, and what the server does should be undefined as well.

I'm not sure how much use this is, it was just a spurious thought during
the meeting.

The second thought I had which I think might be more useful, is that the
client could send extensions with the solicit message to indicate minimum
requirements. If the client is looking for a spesific resource, or a
spesific amount or value of some extension it would be nice if this could
be done in the solicit, again similar to the options in request messages.
The servers should then reply with an advertisement only if it  can
satisfy these requirements at the moment (when the client later requests
them, it may be impossible to deliver).

I think this may be useful if you have a scenario with several DHCP
servers that can give out different resources. I'm not sure how useful
this is either. These are just ideas.

Another thing I've been thinking of that I did not bring up, is whether
non-DHCP servers should be able to send reconfigure messages. I can think
of at least one case where I think it's useful. Of course there would
have to be some flag indicating that it's not from a server, so that the
client instead of sending a request to the sender of the reconfigure 
message, issues a request to some DHCP server if it wants to. The server
is just telling a client that it would be a good idea if it got hold of
some resource, and it should then be up to the client if it asks some
DHCP server for it, get hold of the resource in some other way, or simply
ignores it. What do you think? This is perhaps outside the scope of DHCP,
a client and a server could figure this out in some other way.

> 	  of the spec that require additional discussion. Could the WG please

Personally I think the structure is okay. But I've been reading carefully
through draft-ietf-dhc-dhcpv6-14.txt again, and I've got some comments.

Agent is defined at the end of 2.2. Both the definition of message in 
2.1 and agent address in 2.2 should perhaps come after the definition
of agent.

Near the end of 3.3:

   A DHCP server or agent MUST transmit all messages to DHCP clients on
   UDP port 546.  A DHCP client MUST transmit all messages to a DHCP
   agent over UDP using port 547.  A DHCP server MUST transmit all
   messages to DHCP relays over UDP on port 546.  The source port for
   DHCP messages is arbitrary.

In the first sentence, it should be relay rather than agent I think.
In my opinion the following phrasing would be slightly better:

   A DHCP agent MUST transmit all messages to DHCP clients and relays
   over UDP using port 546.  A DHCP client MUST transmit all messages
   to a DHCP agent over UDP using port 547.  The source port for DHCP
   messages is arbitrary.

The last paragraph of 3.3:

   For the proper operation of the DHCP protocol to operate within a
   network where one or more firewallsare used, DHCP transactions sent
   to the IP addresses of DHCP servers at UDP destination ports 546 and
   547 will need to be permitted.

Why should one permit destination 546, if messages are only sent to port
547? To me it seems reasonable to permit messages sent to addresses of
servers with destination port 547 and messages sent from servers with
destination port 546.

In the last paragraph of 4.2 it says:

   The server MUST copy the client's link-local address into the
   advertisement which is sent in response to a DHCP Solicit.  Both
   server-address (if present) and agent-address of the DHCP Advertise
   message MUST have sufficient scope to be reachable by the client.
   Moreover, the agent-address of any DHCP Advertise message sent by a
   relay MUST NOT be a link-local address.  In situations where there

In the last line I think relay should be server, since the relay simply
passes on what it got from the server. What about replacing this with:

   If the relay-address is nonzero, the server MUST copy it into the
   agent-address field of the advertisement message.

Which is what it says in 6.2.

The last paragraph of 5.3 says suggests that the client may cache the
result of any advertisements, while in 5.4 it says:

   retransmit according to the rules in Section 8.  If (after following
   those rules) the client has not received a Reply message, it SHOULD
   start over again by multicasting a new DHCP Solicit message to find a
   different server.

   If the client receives an ICMP error message in response to such a
   DHCP Request, it likewise SHOULD start over again by multicasting a
   new DHCP Solicit message, to find a different server.

I think it should say something about using cached advertisements, or
do you think it's enough to state this in 5.3?

Apart from this it looks just fine to me,

Stig Venaas
UNINETT/NTNU