RE: [dhcwg] Rev of DHCPv6 spec

["Thirumalesh Bhat" <[e-mail]>]

Some comments on the latest draft below:

a) Section 10.1 - DUIDs
	Do we have an upper limit on the DUID length? I thought we had a
prior thread regarding DUIDs where it was agreed that the upper limit on
DUID length will help the server implementation. 

b) Section 15.1.2 Creation of Solicit messages:
   Can the client send a solicit message without an IA. An example would
be for a client to check the servers that can provide the options it
needs.	
c) Section 15.1.3 Transmission of Solicit Messages:
The draft says "The client sends the Solicit message to the
All_Dhcp_Agents" multicast address". How would this work if the DHCP
Server is on the same segment as the client? Probably the DHCP server
should bind to "ALL_Dhcp_Agents" as well as "All_DHCP_Servers" address.

d) Section 15.1.4: Receipt of Advertise Messages:
Is there a recommendation on how long a client should wait to collect
response from all the responding servers or is this implementation
specific?

e) Section 15.2.2 - Creation and transmission of Advertise messages:
third paragraph:
What happens if the client doesn't send an IA - does the server ignore
the packet?

f) Section 16.1.5 
When a client receives AddrUnavail status should it create a new IA? I
would think that the client should create a new IA if it receives
NoPrefixMatch status back.

Not sure the reason for the use of "ConfNoMatch" status - I think the
other error codes can pretty much tell the client what to do. Same goes
for the error codes "RenwNoMatch", "RebdNoMatch".

g) Section 16.2.2 Receipt of confirm messages:

"If the server cannot determine if the info in the confirm message is
valid or invalid, the server MUST NOT send a reply to the client". 

This statement is a bit confusing. A server might be able to figure out
that the client request is not valid as far as it is confirmed but it
cant verify if it is invalid to other servers. 

May be the server should send its error message anyway and the client
should wait for a certain period of time ( as it does for advertise
messages ) to check if there is a server that can serve its needs.

h) Section 17.1.1 - Creation and transmission of reconfigure-init
messages.

Has the possibility of sending reconfigure-init to a relay been removed
so that the relay can unicast to the clients that it is aware of?

i) Section 20.1 - Format of DHCP Options.
We should be explicit in saying that the option code and option length
are in network byte order.

j) I feel that we should also add "Vendor class" and "User class"
options to the draft. I can prepare the text for these two options if
desired.


thx

-----Original Message-----
From: Ralph Droms [mailto:[e-mail]] 
Sent: Wednesday, October 10, 2001 7:02 PM
To: [e-mail]
Subject: [dhcwg] Rev of DHCPv6 spec

I've finished another rev of the DHCPv6 spec (-20d), which is available
at 
http://www.dhcp.org/dhcpv6.tty  I plan to submit this draft of the spec
to 
the IETF for publication on 10/12.  The list of issues addressed by this

draft is included below; these issues were discussed at the DHC WG
meeting 
in London (8/2001).  The -20d draft does not include any changes related
to 
IAs.  The changes related to IAs will appear in the next published rev
of 
the draft.

- Ralph

=====
Issues from London addressed in this draft.

* Should addresses in an Advertise message be "real" addresses or
   "informational"; e.g., just prefixes?

   WG consensus: addresses in Advertise are the addresses the server
   will return in a subsequent Reply; client supplies those addresses
   to server in IA in Request message

* Servers will only assign complete addresses and not prefixes (e.g.,
   to be used by the client for stateless autoconfiguration)

   WG consensus: yes; prefix advertisement is handled through ND

* How and when does the client use DAD on addresses in Advertise and
   Reply messages?

   WG consensus: Client does DAD on addresses in Reply message and
   responds with Decline if addresses unacceptable (e.g., already in
   use)

* Advertise message SHOULD include options for all OROs that were
   included in the Solicit if the server is willing/capable of offering
   a value for that option

   WG consensus: yes

* Add "NAK" function:

    If the server finds that the prefix on one or more IP addresses in
    any IA in the {Request, Confirm, Rebind} message is not a valid
    prefix for the link to which the client is connected, the server
    MUST send an NoPrefixMatch status in the IA status field for that
    IA in the DHCP Reply message.

   WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch"
                 error code.  Add text allowing client to ignore
                 "NoPrefixMatch" from other servers if ACK received from
                 at least one server.

* Define DUID to be one of:
   - Link-layer address plus time
   - Vendor-assigned unique ID
   - Link-layer address
   - IMSI
   - IMEI

   WG consensus: yes; based on text submitted by Lemon with extensions
                 from subsequent WG discussion

   MODIFICATION: drop IMSI, IMEI

* Use IPsec for secure agent/server communication

   WG consensus: yes; add text to draft

* Add an "error code" option, to indicate errors not connected with a
   specific option

   WG consensus: yes; should allow inclusion of text message

* Tighten up language for unicasting Reconfigure-Init; in particular,
   the server may not have an appropriate address to use to send the
   message to the client.

   WG consensus: yes

* Reply to a Confirm should be a simple ACK/NAK without changing any
   values in options

   WG consensus: Discussion to be taken to mailing list
   Note: check to make sure there is text in the draft describing
   behavior if no response is heard to a Confirm

   FOLLOWUP:  Issue was not posted to mailing list.  Draft now defines
   Confirm to be simple ACK/NAK.

* Reply to Decline or Release should carry no options

   WG consensus: yes

* Restrict options in Decline or Release to IA with text to allow
   other options in the future

   WG consensus: no; this is an overspecification

* Server does not respond to Solicit when client wants addresses and
   server has no addresses

   WG consensus: Server should be allowed to respond

* Include only options specifically mentioned in the text in the
   DHCPv6 spec; move others to second doc or separate appendix

   WG consensus: anything we have consensus on stays; anything else
   gets punted to a separate draft.

* Add 'secs' field to fixed header

   WG consensus: if client retransmits, MUST send option called
   "milliseconds"

* Make the preference field an option

   WG consensus: yes

* Describe message transmission and retransmission in a separate
   section of the spec and reference that text throughout the remainder
   of the spec

   WG consensus: yes

* Discard the client unicast or recheck the entire spec for
   consistency in reference to message transmission

   WG consensus: yes, authors to fix spec

* Remove client link-local address from client message header.  Agent
   can then determine link-local from source (IP header) in client
   message and insert into agent->server message.  Server responds to
   source from IP header (whether agent or client).

   WG consensus: Yes



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

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