Subject: Latest DHCPv6 drafts

From: Thomas Narten <[email-masked]>
Date: Fri, 28 Jul 2000 11:49:13 -0400

Jim, Mike, Charlie:

I've finally managed to read both of the new DHCPv6 drafts, and must
say that they are (IMO) quite an improvement over the previous
drafts. They are much more concise than before and provide a clearer
basis for having followup discussions.  It's clear that a lot of
effort went into these documents, and it shows. Thanks for putting in
the time that it took to revise the documents.

Having said that, I'm concerned that we may still be quite a ways from
having a final document. With the IPv6 market pressures having shifted
quite noticeably over the last 9 months, there is a much greater
urgency for getting this spec done than there might have been even a
year ago.

Looking at the list of open issues listed in the document, I have to
ask if that list is intended to be complete, or whether there are
still other issues that the WG needs to consider. Specifically, I'm
thinking that there have been a number of threads in the past in which
issues were raised, but I'm not entirely certain that closure was
reached on all of them with the results of that closure documented in
the current ID.

In the following, I mention some examples of possible issues discussed
in the past that may still need further consideration (but are not
listed in the open issues section of the document). No claim is being
made that this list is complete, BTW.

Consider the message:

    From: Mike Carney - SNT Internet Engineering <[email-masked]>
    To: Multiple recipients of list <[email-masked]>
    Date: Wed, 10 Nov 1999 18:51:57 -0500 (EST)
    Subject: List of DHCPv6 Issues with Responses, Part 2 of 2

It seems like some of the resolutions listed in this message are not
fully reflected in the current draft. For example:

   - a versioning scheme for the protocol
   - rules for option encoding intented to ease introduction of new
     options without requiring client and server code changes
   - state transition diagram
   - how clients request addresses and what addresses the server
     returns
   
On the last point, it seems that the current spec still isn't entirely
clear on how addresses are requested by clients and returned by
servers. To be clear, I mean *exactly* what is a client supposed to do
to request addresses (in typical cases), and *exactly* what is a
server supposed to do when it gets such a request (in typical
cases). The document doesn't seem to be explicit about this, other
than giving packet formats and suggesting some general
possibilities. I worry that different implementors will make different
choices in what they put in packets, with resultant interoperability
issues. As background, I think it would be useful to review a couple
of threads on this topic to see if all of the cases discussed before
are adequately covered. Reference:

         To: <[email-masked]>
	 Date: Thu, 23 Dec 1999 11:14:48 -0500
	 Subject: DHCPv6 address allocation model
	 From: Thomas Narten <[email-masked]>

	 (and followups)

	 From: Mike Carney - SNT Internet Engineering <[email-masked]>
	 To: Multiple recipients of list <[email-masked]>
	 Date: Tue, 16 Nov 1999 14:54:13 -0500 (EST)
	 Subject: DC meeting: Discussion question #2, multiple IP addresses

	 (and followups)

Finally, I haven't yet seen an agenda for the dhcpv6 topics to be
discussed in Pittsburgh.  What are the plans?
	 	 
Thomas

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 29 Jul 2000 11:41:04 +0900

>the time that it took to revise the documents.

	Hello, thanks for the new documents (15 draft).

	One comment from implementors POV.  I think the following items
	must be clarificed.

itojun

	- padding requirement for variable length fields in extension.
	- similarly, string termination requirement for string fields.
	  are these field needs to be terminated by 0x00, or we must leave
	  them as is?

	  this question affects the following fields:
		DNS name field in IP address extension (extension document 4.1)
		IEEE timezone string in timezone extension (5.1)
		domain name suffix in domain name suffix extension (5.3)
		NIS domain name in NIS domain name extension (5.7)
		NIS+ domain name in NIS+ domain name extension (5.9)

	  for example, suppose we would like to transmit timezone string
	  "UTC" using extension type 8193.  which is the correct way to
	  send this?

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type = 8193           |             Length = 3        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    "U"        |   "T"         |   "C"         |   next extensin start here
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type = 8193           |             Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    "U"        |   "T"         |   "C"         |   0x00        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   next extension starts here

	  or, if we would like to send NIS domain name "KAME" using extension
	  type 8199, which is the correct one?

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Type = 8199          |             Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    "K"        |   "A"         |   "M"         |   "E"         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   next extension starts here

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Type = 8199          |             Length = 5        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    "K"        |   "A"         |   "M"         |   "E"         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   0x00        |   next extension starts here
   +-+-+-+-+-+-+-+-+

	- "subnet prefix octets" field in subnet prefix extension is
	  defined as variable length, however, I think we should make it
	  fixed length (16 bytes).  otherwise, implementers may do different
	  byte truncation and validation gets trickier.  also, padding
	  requirement is unclear if we do truncation.  i'd suggest wording
	  like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 8207         |             Length = 16       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Prefix Len (number of left-most bits) (1 octet)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Subnet Prefix Octets                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Subnet Prefix Octets                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Subnet Prefix Octets                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Subnet Prefix Octets                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   A subnet prefix is specified by the ``Subnet Prefix Octets'' field
   and the ``Prefix-Len'' field.  Any unused bits in the last octet of
   this field MUST be set to off (zero).

   The length of this extension is 16.

---

From: "Michael W. Carney" <[email-masked]>
Date: Sat, 29 Jul 2000 13:48:34 -0700 (PDT)

> the time that it took to revise the documents.

Thanks. We were hoping we'd have more comment on them than we got.

> reached on all of them with the results of that closure documented in

No, that list is not seen as a complete list, but rather one we'd figured
we'd add / subtract from as we had discussion on the list.

> discussed in Pittsburgh.  What are the plans?

I'm going to be presenting a list of issues/discussion points from the issues
list in the document, Carl Smith's input, and Francis' input.

I was hoping to get this list out to the working group last week, but
unfortunately due to an event out of my control, that didn't happen. I'll
submit the items to the list (one thread per item) for those folks not going
to pittsburg, as well as present the items at tuesday's meeting (for those
folks who are attending the meeting).

> Thomas

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
(650) 786-4171
Mailstop UMPK17-202
901 San Antonio Rd
Palo Alto, CA 94303