Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 29 Aug 2001 11:20:13 -0500

I am working through this document, but I had the same thought as I was reviewing it.

If the relay-address and source IP address of the relay are the same, there is no reason
to have both. Most relays should be able to do this, so it will hopefully be the exception
to the rule that this information is needed. This will require changes to section 12 and
likely other places.

Also, while I'm at it, 9.1 and 9.2 still have the "prefix-length" field defined by this
field no longer exists within the Relay-Forw and Relay-Repl messages.

In 13.4.2, it says "and copies the values of the transaction-ID field ...". All that is
now copied is the transaction-id so just say "value". Perhaps best to just say "copies
the transaction-id field".

In 13.4.2, as "The server MAY include other options", do these other options include
IA IDs (and related suboptions that are still being worked out) that the server might
know about for the client? In other words, might we allow a server to send back all
of the IA IDs (and addresses) it knows about a client in the Solicit. (Perhaps best to
wait to answer this based on what Mark, Ted, and I work out!)

I haven't finished the rest of the document so I may have more comments later.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 11:49 AM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from
the DHCPv6 header 

How about making relay-address an option?   I don't think it will be
useful in most cases, so it seems like a drag to have it part of the
fixed header.

			       _MelloN_

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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 29 Aug 2001 13:09:27 -0500

Please see my other message just sent a few moments ago before making this change.

To answer your specific question, correct. In many cases this probably won't be an issue (at least if you consider the IPv4 case as all we have there is giaddr). Sure, there are some cases where this would be a problem (relay has no global address or address of sufficient scope for the interface) and in those the relay uses the option to carry this information.

But, again, we need to look at the RETURN path and that's why I now think making this an option is a bad idea.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 1:23 PM
To: [email-masked]
Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from
the DHCPv6 header 

Before I make the change, let me make sure I understand your proposal.  If the relay agent does not include the relay-address, the relay agent has to cause the forwarded message to have a source address - an address with the widest scope possible; e.g., a link-local address isn't useful - that is assigned to the interface on which the message was received by the agent from the client.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 29 Aug 2001 19:45:29 -0400

Bernie,

Thanks for you careful review of the new text.  I made all
of the changes you suggested, except as noted below (RD>)

- Ralph

14.3.1. Creation and sending of Request messages 

   If a client has no valid IPv6 addresses of sufficient scope to 
   communicate with a DHCP server, it may send a Request message to 
BV> Why "communicate with a DHCP server"? And the client could well 
BV> have many addresses of sufficient scope - that's not the point 
BV> of the request. We really should just say that "If the client 
BV> is using stateful address configuration and either needs an 
BV> initial set of address or additional addresses, it MUST send a 
BV> Request message to obtain new addresses." (or something like that) 
   obtain new addresses.  The client includes one or more IAs in the 
   Request message, to which the server assigns new addresses.  The 
   server then returns IA(s) to the client in a Reply message. 

   The client generates a transaction ID and inserts this value in the 
   "transaction-ID" field. 

   The client places the address of the destination server in the 
   "server-address" field. 
BV> How about "The client copies the "server-address" field as received in 
BV> the selected Advertise message to the "server-address" field of the 
BV> Request." 

RD> Why the change?

   The client adds a DUID option to identify itself to the server.  The 
   client adds any other appropriate options, including one or more IA 
   options (if the client is requesting that the server assign it some 
   network addresses).  The list of addresses in each included IA MUST 
   be empty.  If the client is not requesting that the server assign it 
BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't 
BV> it that people wanted the addresses received in the Advertise to be 
BV> used here? 

RD> I leave this for the IA option and semantics design.

   any addresses, the client omits the IA option. 

   The client sends the Request message to the All DHCP Agents multicast 
   address through the interface for which the client is interested in 
   obtaining configuration information, with the destination port set 
   to 547.  The source port selection can be arbitrary, although it 
   SHOULD be possible using a client configuration facility to set a 
   specific source port value. 

   The server will respond to the Request message with a Reply 
   message.  If no Reply message is received within REP_MSG_TIMEOUT 
   milliseconds, the client retransmits the Request with the same 
   transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits 
   again.  The client continues this process until a Reply is received 
   or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at 
   which time the client MUST abort the configuration attempt.  The 
   client SHOULD report the abort status to the application layer. 

   Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS 
   are documented in section 7.5.

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 30 Aug 2001 08:17:02 -0500

Ralph:

RD> Why the change?

Just thought it was clearer where the server address comes from.

No problem.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 7:45 PM
To: Bernie Volz (EUD)
Cc: [email-masked]
Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from
th e DHCPv6 header

Bernie,

- Ralph

RD> Why the change?

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 30 Aug 2001 11:56:07 -0500

It does seem to me, based on the DHCPv4 RFC3046 description, that a circuit ID
option would work just fine.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, August 30, 2001 12:22 PM
To: Bernie Volz (EUD)
Cc: 'Ralph Droms'; [email-masked]
Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from
th e DHCPv6 header 

> For 2, the relay can either use 3 or provide some other means of
> identifying this information. It may not be an address - it could
> just be an interface id or some other opaque info. So, I suggest
> that for 2, we simply have an "Interface-ID" option which is
> whatever the relay wants it to be. The server should treat it as
> opaque and simply echo it back to the relay. If the relay doesn't
> need it (because the info in (3) is sufficient), it need not provide
> this option.

We've already got two options that handle this - the circuit ID and
the remote ID.   Do we need a third, or is the circuit ID already
serving this purpose?

			       _MelloN_