Subject: [dhcwg] DHCP-DHCPv6 Issues and IPv4 options drafts

From: Tim Chown <[email-masked]>
Date: Tue, 10 Feb 2004 22:30:07 +0000

Hi,

These two drafts have now been published.   As they may not be copied to
the dhc list due to their personal status, their summaries are below.

The purpose of the drafts is to form a framework for discussion in Seoul,
where Stig Venaas will present the issues draft.   Both drafts have a short
slot on the agenda. 

The main options appear to be keeping the functionality separate, or adding
IPv4 information options to allow only DHCPv6 to be required for dual-stack
nodes.   In additional, some "administrative" considerations could/should be
made, e.g. whether or not to use a split name space (*.ipv6.foo.com) for 
early IPv6 deployment.

        Title           : IPv4 and IPv6 Dual-Stack Issues for DHCPv6
        Author(s)       : T. Chown
        Filename        : draft-chown-dhc-dual-stack-00.txt
        Pages           : 10
        Date            : 2004-2-10

   A node may have support for communications using IPv4 and/or IPv6
   protocols.  Such a node may wish to obtain IPv4 and/or IPv6
   configuration settings via the Dynamic Host Configuration Protocol
   (DHCP).   The original version of DHCP [1] designed for IPv4 has now
   been complemented by a new DHCPv6 [4] for IPv6. This document
   describes issues identified with dual IP version DHCP interactions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chown-dhc-dual-stack-00.txt

        Title           : DHCPv6 IPv4 Information Options
        Author(s)       : C. Cadar
        Filename        : draft-cadar-dhc-dhcpv6-v4options-00.txt
        Pages           : 21
        Date            : 2004-2-10

   To ease the management of a site, the Dynamic Host Configuration
   Protocol (DHCP) is often used. DHCP exists both for the Internet
   Protocol Version 4 (DHCPv4 for IPv4) and Version 6 (DHCPv6 for IPv6).
   To avoid possible pitfalls that occur if both DHCP versions are used
   and to avoid redundancy, IPv4 Information Options may be transmitted
   using DHCPv6 as described in this document. In dual-stack IPv4/IPv6
   scenarios that employ DHCPv6, DHCPv4 can be completely replaced by
   using the DHCPv6 IPv4 Information Options.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cadar-dhc-dhcpv6-v4options-00.txt

Tim

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

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 11 Feb 2004 18:23:24 -0500

Hi:

I've read draft-chown-dhc-dual-stack-00.txt and skimmed
draft-cadar-dhc-dhcpv6-v4options-00.txt and have the following comments.

First, I personally severely dislike the idea of using DHCPv6 to also
configure IPv4.

For one, this really doesn't solve anything as there are still IPv4 only
hosts you have to configure, and they can not use DHCPv6. So, in ANY
reasonable world where you have IPv4-only hosts and dual-stack hosts you
MUST run both DHCPv4 and DHCPv6. You have no choice.

You must consider:
1. What advantage is there for configuring IPv4 information into DHCPv6
servers when the DHCPv4 servers need to be configured anyway to support
IPv4-only hosts. You're still duplicating information.
2. What happens if there are DHCPv6 servers that don't return IPv4
information? Does this mean the client can't run IPv4 (since it won't do
DHCPv4).
3. What happens if the IPv6 interface (transport) is started AFTER DHCPv4
was used to configure the client? Does the client simply discard the current
IPv4 information? What happens if the IPv6 interface (transport) is switched
off? Should the client start DHCPv4 then?
4. Unless the DHCPv4 and DHCPv6 servers are able to communicate in some way
(perhaps they are running in the same image or the DHCPv6 uses DHCPv4 to get
leases for clients that need IPv4 addresses), this may result in further
fragmenting the available IPv4 address space (since now some needs to be
allocated to the DHCPv6 server to dole out to dual hosts clients). In many
networks, this is probably no big deal; but if addresses are constrained ...
I guess we'd all be happy since we'd just say switch to IPv6-only?

The bottom line is that DHCPv4 must continue to exist as long as you have
IPv4-only or dual stack hosts.

Some specific issues with the draft-cadar-dhc-dhcpv6-v4options-00.txt
(remember that I'm NOT for this approach):
- Why go through the work of defining DHCPv6 options for every DHCPv4 option
that someone may want? If we go down this road of using DHCPv6 to configure
IPv4, we should just have a single DHCPv6 option that can be used to
encapsulate DHCPv4 options. Note that this encapsulation option may be used
many times within a single message if needed (depending on scope).
Note: I do believe we should document what DHCPv4 options MUST NOT be
allowed to be encapsulated; for example addresses may be communicated with
IAADDR_IPv4 options.
- The IAADDR_IPV4 option is adding new semantics for IPv4 addresses (the
lifetimes). This is not a concept IPv4 has had and I'm not sure why we would
want to introduce this concept (though I could see having a valid lifetime
since that is fairly straight forward for a DHCP server to enforce).
- I believe if you're going to do this properly, you really need an
"Identity Association for IPv4 Addresses" option and NOT simply piggyback
IADDR_IPv4 options within an IA_NA or IA_TA. The reason is that then a
client has the ability to request that it wants an IPv4 address - if the
IA_NA or IA_TA is used, this is not easily done. It also allows the IPv4
addresses to have different T1/T2 times. It also allows a client to request
ONLY IPv4 addresses over DHCPv6 (such as if it is a dual-stack host and the
RA "O" bit is set, so the client would not use DHCPv6 for IPv6 addresses).
In this case, the client simply sends a SOLICIT with only an IA_IPv4 (no
IA_TA or IA_NA).

I would much prefer we define a methodology for clients to use to configure
information collected from DHCPv4 and DHCPv6. Since all clients that will
use DHCPv6 (and be dual-stacked) will need software updates, asking them to
make some modifications to DHCPv4 should not be completely out of line.

In my view, there are two major conditions:
a) DHCPv4 and DHCPv6 provide the same value for a particular parameter (such
as domain name search list). In this case, there is no conflict and all is
fine.
b) DHCPv4 and DHCPv6 provide different values for a particular parameter.
- In some cases, such as domain name server addresses, this isn't a major
problem. Sure, the ORDER that the information might be used won't be clear
(use IPv4 first, then IPv6, or vice versa, or one, then the other), but in
most cases I can't see this as a major problem. The host should install both
(merged) and use them.
- In other cases (such as the domain name), this is a problem. But, the host
might have a means for dealing with it. For example the DHCP servers
certainly will if updating DNS with the host's name/address information
(DHCPv4 will use the domain name received via it; DHCPv6 will use its).
However, the "default domain name" or "dns search list" for the system would
be an issue. In this case, either the user or software must choose. Perhaps
a solution would be to add a DHCPv6 option as to whether the DHCPv6
configuration information should OVERRIDE DHCPv4 information where conflicts
are not otherwise easily resolved?

It is extremely interesting to look at the options that were chosen to be
included in draft-cadar-dhc-dhcpv6-v4options-00.txt ... only TWO cover
anything that DHCPv4 and DHCPv6 MIGHT both configure - the "DNS Server" and
"Search Domains". And, the DNS Server list is minor since it is very easy to
simple concatenate the DHCPv4 and DHCPv6 list (sure there could be extremely
rare cases where this might not be optimum). The search order is a bit
trickier since order could be critical here but this will just be one option
DHCP administrators will need to configure carefully.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Chown
Sent: Tuesday, February 10, 2004 5:30 PM
To: [email-masked]
Subject: [dhcwg] DHCP-DHCPv6 Issues and IPv4 options drafts

Hi,

Tim

---

From: Christian Strauf <[email-masked]>
Date: Thu, 12 Feb 2004 10:09:43 +0100

Hi Bernie,

please find my comments inline.

> IPv4-only hosts. You're still duplicating information.
This is true for environments that contain IPv4-only hosts. But for pure
dual-stack environments (which are not uncommon and which are likely to
be quite common in the near future), you wouldn't need to configure
DHCPv4. Please note that the scenarios the IPv4 option draft applies to
are not mainly environments that contain IPv4-only hosts if you don't
use per-host address assignment. Maybe we should've stressed that some
more in the scenarios section.

> information? Does this mean the client can't run IPv4 (since it won't do
This is a configuration issue not an implementation issue in my eyes.

> off? Should the client start DHCPv4 then?
A client that uses IPv4 information options in DHCPv6 wouldn't use
DHCPv4 at all. Additionally, I don't see why an IPv6 interface would be
randomly switched off. If your point is that IPv6 transport is a point
of failure when obtaining IPv4 information, then you're right. But I
guess DHCP is always a possible point of failure (either if the DHCP
server itself or if the connectivity to the server dies) and it makes no
significant difference if either the use of DHCPv4 or the use of DHCPv6
is the point of failure.

> networks, this is probably no big deal; but if addresses are constrained ...
We were aware of the fragmentation issue when writing the I-D, and I
really agree with you that one shouldn't transport IPv4 options with
DHCPv6 at the cost of clean IPv4 addressing. But as you said yourself,
in many networks, this is not a problem. Especially if you have a fixed
IPv4 address assignment on a per-host basis. In this case, you don't
have a problem at all. And there's certainly a great number of sites
that practise per-host address assignment. In scenarios where you don't
have such a fixed assignment, one should refrain from using IPv4 options
in DHCPv6 if IPv4-only hosts are expected to be part of the subnet.

> I guess we'd all be happy since we'd just say switch to IPv6-only?
I take it you're kidding because that's obviously not the intention of
the I-D. :-)

> IPv4-only or dual stack hosts.
It must continue to exist as long as there are IPv4-only hosts, I agree.
But using IPv4 options in DHCPv6 for dual-stack hosts reduces the
configuration tasks to configuring only one DHCP server.

> encapsulate DHCPv4 options. Note that this encapsulation option may be used
We decided not to use this approach to allow an easier implementation of
IPv4 information options in existing DHCPv6 implementations. And I
personally don't like the idea of encapsulating DHCPv4 options.

> since that is fairly straight forward for a DHCP server to enforce).
To be honest, we were not sure whether or not we should stick to the
lifetime concept for IPv4 addresses when we submitted the I-D. As you
said, it's not so much a problem of implementing it but more a
conceptual question. So your input is very welcome because we weren't
sure what would be the best approach.

> In this case, the client simply sends a SOLICIT with only an IA_IPv4 (no
Interesting point. I need to think it over a little and discuss it with
Cristian.

> make some modifications to DHCPv4 should not be completely out of line.
Though you're right when you say that it's not too much to ask to make
updates to DHCPv4, I still don't agree. I personally think that one
should keep the DHCPv4 and DHCPv6 implementations separate. If you look
at DHCP implementations for Unix flavours, for example, I don't see how
you can easily make clients decide which information to use from which
service. The DHCP implementations are disjoint and making them
communicate with each other would be quite tricky in my eyes (please
correct me if this was not what you were aiming at).

> as domain name search list). In this case, there is no conflict and all is
I disagree. As long as one service has no information about the other
service, this is exactly the scenario where you get into trouble. Let's
take search domain lists as an example. If you get the same search
domain list from both DHCPv4 and DHCPv6 and either one service does a
reconfigure, it may remove this particular search list, thought the
other service still "thinks" that the search list is valid and present.
The service does not have the knowledge that the search list information
also belongs to the other service. This is one of the reasons why having
only one service that transports both IPv4 and IPv6 information is an
advantage.

> most cases I can't see this as a major problem. The host should install both
You're right, this is not a critical case.

> are not otherwise easily resolved?
This is an interesting point. But then again, if there is a way to
transport all information using a single transport protocol (e.g.
DHCPv6), that is a much better solution because this will avoid pitfalls
when configuring both DHCPv4 and DHCPv6. Accidental overrides wouldn't
be possible. And you wouldn't have the administrative overhead of
configuring both services for dual-stack hosts (e.g. when doing per-host
address assignment).

Thank you for your interesting comments. Though you don't like IPv4
information options in DHCPv6, I guess we agree that the issues
identified in Tim's draft exist and pose a problem in dual-stack
environment and they need to be solved. I still think that IPv4
information options are a possible solution that is not difficult to
implement.

Cheers,
Christian
-- 
JOIN - IP Version 6 in the WiN  Christian Strauf
A DFN project                   Westfälische Wilhelms-Universität Münster
http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung
Team: [email-masked]      Röntgenstrasse 9-13
Priv: [email-masked]    D-48149 Münster / Germany
GPG-/PGP-Key-ID: 1DFAAA9A       Fon: +49 251 83 31639, Fax: +49 251 83 31653

---

From: Stig Venaas <[email-masked]>
Date: Thu, 12 Feb 2004 11:38:31 +0100

> more in the scenarios section.

I agree very much with this. I know several places where there are
pure dual-stack environments now, having to run both DHCPv4 and
DHCPv6 is not that nice for managment.

Based on situation here at UNINETT, where we have very few IPv4-only
and rest dual-stack, here is my take from the managment point of view.

Currently DHCPv4 is used, and dual-stack hosts get configuration info
from that, except for stateless autoconfiguration for v6 addresses.

Being dual stack with more and more services being available also via
IPv6, we would like to continue the transition, which means we also
need to tell those dual-stack hosts about services with v6 addresses.

To do that, we could run both DHCPv4 and DHCPv6, but I don't think
the sysadmins would be too happy about that. We could manage without
DHCP on the very few dual-stack hosts we have, so running DHCPv6 only
would be good, provided that we could learn not only about v6 services,
but also services on v4. For some services like say NTP, there could be
a mix of v4 and v6 servers.

> > off? Should the client start DHCPv4 then?

This is a theoretic possibility, but not common I think. I'm not sure
what best behaviour would be though.

[...]

> personally don't like the idea of encapsulating DHCPv4 options.

I'm not sure of all the implications in the protocol, but to me
encapsulation sounds reasonable. Else you'll have either only a few
v4 options available, or you would need to put out new specifications
for many of them.

I don't know if it's an issue, but on both server and client, there
might be a possible to have some common code, image or process for
doing both DHCPv4 and DHCPv6, especially in the client, it could be
nice to have a minimal client supporting both I think. The question
I have then, is whether it's easier to reuse client code if the
options are simply embedded. Could this make the client footprint
smaller?

Stig