Subject: DHCPv6 extension comments

From: Richard Draves <[email-masked]>
Date: Fri, 21 Jan 2000 03:02:11 -0800

Comments on draft-ietf-dhc-v6exts-11.txt.

Overall, I thought the split between the two documents was rather confusing,
the main DHCPv6 spec does not stand on its own because it doesn't say
anything about how the extensions are formatted.

   Future applications will make extensive use of an ever-increasing
   number and variety of network services.  It is expected that client
   needs for creating connections with these future network services
   will be satisfied by the Service Location Protocol [27], and not
   DHCPv6.  DHCP is expected to be used for the kinds of configuration
   that enable clients to become fully functional as self-contained
   network entities, but not the kinds of configuration that might be
   required by applications running above the network or transport layer
   protocol levels.

This draft defines a bunch of extensions (NTP, DNS, NIS, ...) that would
seem to violate this applicability statement.

   of extension type 64 (see section 7.1), DHCP entities MUST assume
   that that the maximum DHCP message size including extensions is 1280
   octets.

Does this size include any headers (like IP, UDP) before DHCP?

   3. IP Address Extension

How would one handle IPv4 addresses using DHCPv6? Use v4-mapped address
format with the IP Address Extension, or define a new extension?

      prefix-size
               If the client address is present (the 'C' bit is set), a
               nonzero prefix-size is the number of leftmost bits of the
               client's IPv6 address which make up the routing prefix.
               Otherwise, if the 'C' bit is not set, prefix-size MUST be
               zero.

Why is there a prefix-size field in the IP Address extension? What do you
expect the client to do with this information??

      Q        If the 'Q' bit is set, the fields included by the client
               are required, and must be made available by the server or
               else the extension must be rejected.

Can the server set the Q bit? What should happen if it does?

I assume the DNS name is present if either the A or P bits are set? Can the
client send a non-FQDN and get back a FQDN? Will the server ever send a
non-FQDN? In general the A & P bits and their use are unclear.

Do you expect the client to know its name and tell the server, or the server
to know the client's name and tell the client, or are you allowing for both?
What if they disagree?

   The DNS name can be a host name, which does not contain the '.'
   ASCII character as a separator between DNS hierarchy components.  Any
   name containing the '.'  is treated as a Fully Qualified Domain Name
   (FQDN). The length of the DNS name may be determined by subtracting,
   from the Length, the length of those fixed length fields which are
   present.

Why not use the same DNS name representation (label sequence) that DNS uses?

   By default, the client SHOULD update the AAAA record, and the server
   SHOULD update the PTR record.  The IP Address extension permit

What about A6? How can the server "SHOULD update the PTR" by default?
Doesn't it need a DNS name in the address extension, meaning the client sets
the P bit, meaning the client requested this action so it wasn't performed
by default?

   clients and servers to use a different behavior than the default, and
   they MAY set the 'Q' and 'A' bits to suit their needs.

Should this be 'P' and 'A' bits?

   3.2.1. Use with the DHCP Advertise message

I'm unclear on the use of address extensions in Advertise messages. Can an
address extension in an Advertise give a client an address? Can you provide
some scenarios?

   4.3. Domain Name Server Extension

Shouldn't the two DNS extensions be in the "Application and Services"
section?

   4.4. Domain Name
   This extension specifies the default domain name that client should
   use when resolving hostnames via the Domain Name System.

Shouldn't this be called the Domain Name Suffix extension?

If there are multiple Domain Name extensions, does the last one apply, the
first one, or do they form a search list?

(More generally, what happens when the same extension shows up more than
once?)

   5.3. Network Information Service (NIS and NIS+) extensions

   This subsection describes DHCPv6 extensions useful for NIS and NIS+
   clients.

Are NIS and NIS+ IETF standards? If so update the reference. If not, why are
these extensions being defined here - if it's relevant to something
proprietry, put it in a separate document.

   7.2. DHCP Retransmission and Configuration Parameter Extension

Are clients expected (or discouraged) to update/store these parameters
(particularly the ones that apply to Solicits) in stable storage?

   7.3. Platform Specific Information

What's the point of encapsulating the platform-specific extensions? Why
can't they be given directly to the client without encapsulation?

   The Encapsulated platform-specific extensions field MUST be
   encoded as a sequence of type/length/value fields of identical
   syntax to the form defined for DHCPv6 extensions.  Extension
   65535 (END), if present, signifies the end of the encapsulated
   platform extensions, not the end of the platform extensions field.
   If no extension 65535 is present, then the end of the enclosing
   platform-specific information field is taken as the end of the
   encapsulated platform-specific extensions field.

What's the point of the 65535/END extension? The end of the outer,
encapsulating extension signifies the end of the platform-specific
extensions.

   7.4. Platform Class Identifier
   This extension is used by a DHCP client to identify the hardware type
   and operating system platform it is hosted on.  The extension value
   itself is an opaque value to a DHCP server, and is only used by the
   DHCP server to "lookup" Platform Specific Extensions associated with
   clients of a certain platform class.

Since the platform is a combination of hardware & operating-system, why
isn't this split out into two identifiers?

   7.5. Class Identifier

How is a client supposed to know it's class identifier?

   7.7. Renumber DHCPv6 Server Address

What about renumbering the relay address?

   The Length of the DHCP Relay ICMP Message extension is the length of
   the ICMP error message received by the relay [9].

What about truncating the error message to make it fit?

Thanks,
Rich

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Jan 2000 13:35:01 -0800

Hello Richard,

Thanks for your note.  I'll try to answer some of your points,
and I reckon we'll all three have something more to say next
week after our next meeting.

> anything about how the extensions are formatted.

I do not understand why the main specification should say how the
extensions are formatted.  The main specification handles the
protocol control flow.  The extensions carry the data.  This makes
for a very clear division in the specification.  Of course, no one
wants to have a control sequence without any data, and no one wants to
send data without any understanding of how it is to be used.
Nevertheless, I think that looking at the specifications this way
leads to a very clear document structure.

> seem to violate this applicability statement.

What is the violation?  Are you suggesting that DNS should be found by
using SLP?  We don't intend to invalidate current practices for such
well-known operations.

> format with the IP Address Extension, or define a new extension?

Are you suggesting that we need a way for a DHCP client to specifically
ask for an IPv4 address?  If so, then that is a new feature not
requested
by anyone else up until now.  Maybe it would be better to defer this new
featue until after we have finally stabilized the current documents.
Most people seem to be very anxious to get finished with the current
specification without adding new features.  We don't deal specifically
with allocating anycast addresses either, for example.

> expect the client to do with this information??

We don't tell the clients what to do with the information, nor what to
do with their IP addresses or any other information.  Do you believe
that clients should not have this information?

> Can the server set the Q bit? What should happen if it does?

The server should not set the Q bit.  I reckon doing so should
be prohibited.

> non-FQDN? In general the A & P bits and their use are unclear.

We'll probably discuss this more on Monday, but I think that the
server would never send back a non-FQDN.  Did you know that FQDN does
not seem to appear in any RFC? (useless bit of trivia)

> to know the client's name and tell the client, or are you allowing for both?

We do not place any such expectation, but we did want to handle the
various
cases correctly.  There are many places for various network agents to
disagree, even in the case of Router Advertisements without DHCP.  Can
you make a suggestion about how we should handle disagreements in this
case?

> the P bit, meaning the client requested this action so it wasn't performed

According to your discussion, I think we need to clarify the
specification
to eliminate future confusion.  We didn't take the A6 record update
into account, which just goes to show how long it's been since this
document was originated.

> address extension in an Advertise give a client an address? Can you provide

The newly revised document is supposed to contain some examples, but
roughly speaking the idea is for a client to find a server that can
supply an IP address that matches what the client wants somehow.
I don't have the time just now to build a suitable example to make
this clear, but I hope that small bit of intuition will be helpful.

> Shouldn't the two DNS extensions be in the "Application and Services"

Is DNS an application, or is it a core network requirement?
How can I tell the difference?

> Shouldn't this be called the Domain Name Suffix extension?

It's O.K. with me!

> (More generally, what happens when the same extension shows up more than

What happens today?  Can you suggest a reasonable specification
for this?

> proprietry, put it in a separate document.

It's in DHCPv4, and more than one person asked for it.  Are you
suggesting
that we should create some admission criteria for new extensions?
If it's in DHCPv4, and people want it, do we still try to find
reasons not to include it for DHCPv6?

> (particularly the ones that apply to Solicits) in stable storage?

We didn't make any inducement, nor prohibition.  We only included
this feature because previous commentators asked for it.  If a client
asked for a configuration parameter, I guess it ought to remember
that it asked.  I don't know why someone would go to all the trouble
of getting a new parameter just to forget about it.  Do you mean to
ask about behavior for such parameters over reboots and system crashes?
Do you have a preference for what needs to be specified?

> encapsulating extension signifies the end of the platform-specific

I think we just tried to do it like DHCPv4 does it.

> isn't this split out into two identifiers?

I don't think this split is universally needed, and I do think that
for cases when it is needed, you can use the existing extension to
provide it.  On the other hand, if people generally want to have
two extensions, that's totally fine with me.

> How is a client supposed to know it's class identifier?

I don't think we have to specify this.

> What about renumbering the relay address?

The relay's address is more important to the server than it
is to the client.  This is something that probably matters
whenever a IPv6 server-server protocol gets built.

Thanks again for your comments.  The parts I left out are
the parts I need to think more about, and will have more to
say on them next week.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 23 Jan 2000 16:50:23 +0100

In your previous mail you wrote:

      3. IP Address Extension

=> DSTM needs this function then Jim should have the answer (:-)!

   What about A6?

=> next I-D of course!

=> the domain name is the name of the domain where is the client but
a way to get a search list is a useful idea.

Regards

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Sun, 23 Jan 2000 21:15:51 -0500

Hi Francis,

Charlie is responding to Rich's comments and we will discuss as a team
tomorrow (Monday).

But...........

>DSTM needs this function then Jim should have the answer (:-)! 

I don't want to throw this into the extensions spec at this point and
add a new extension and all the discussion it will take.  Also I would
l like to use the DSTM req as a means to put forth a new extension for
DHCPv6 after we reach PS status.  

But this is on the agenda for the authors regular meeting tomorrow.
As my coauthors of DSTM would like it to be part of the present exts
draft too.

Do you feel one way or the other?

[p.s. You know where I am coming from on this.  We will deploy DSTM in
the market with or without the IETF, but still working with the IETF at
this point and having forward progress but DHCPv6 is more immediate as
one of the ngtrans chair (Alain Durand) stated to the DHCv6 WG at Wash
D.C., ergo I don't want to do anything that will prevent an expedited
DHCPv6 PS status, but maybe it would not to add the DSTM requirement]...

thanks
/jim

---

From: Ralph Droms <[email-masked]>
Date: Sun, 23 Jan 2000 22:39:28 -0500

>=> DSTM needs this function then Jim should have the answer (:-)!

DSTM?  Can someone expand that FLA for me?

- Ralph

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Jan 2000 12:21:01 +0100

=> I think the *important* thing is to get the new & final I-D
for DHCPv6 asap. DSTM details can go into DSTM I-D(s).

Thanks

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Mon, 24 Jan 2000 07:59:57 -0500

Hi Ralph,

>DSTM?  Can someone expand that FLA for me?

See draft-ietf-ngtrans-dstm-01.txt its an ngtrans WG piece of work.

Bottom line is this.

Customer deploys IPv6 department at their site or in multiple sites.
All nodes will be using IPv6 as the core prototocol.  IPv4 is only
needed when the node temporarily needs to use IPv4 via a Tunnel to speak
with say an IPv4 Web Server.  The DSTM mechanism has 3 parts.
  
 - Interation with DNS to find IPv6 Nodes in this environment
 - Dynamic Tunneling Interfaces on an implementation
 - Use of DHCPv6 by an IPv6 node to obtain a temporary IPv4 address
   via an IPv6 IPv4-Mapped Address or for a co-located DHCPv6/DNS server 
   to dynamically assign an IPv6 node an IPv6 IPv4-Mapped Address.
   IPv6.

This will require a new extension for DHCPv6 to provide an IPv6
IPv4-Mapped address.

/jim

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Jan 2000 14:08:44 +0100

=> DSTM is a IPv4->IPv6 transition tool (ie. in the ngtrans WG scope)
using DHCPv6 reconfigure message for IPv4 temporary address
assignment. It is a merge between AIIH (by Jim Bound) and
DTI (by Laurent Toutain, a colleague) with IPv4 over IPv6 tunnels
in place of header & address translation.
 The current position of the ngtrans WG is to not slow down DHCPv6
on its way on the standard path (:-) because of DSTM.
Last I-D is draft-ietf-ngtrans-dstm-00.txt .

Regards

[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Jan 2000 11:21:43 -0500

>See draft-ietf-ngtrans-dstm-01.txt its an ngtrans WG piece of work.

Thanks for the clarification, Jim...

- Ralph