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

["Bernie Volz" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Tim
Chown
Sent: Tuesday, February 10, 2004 5:30 PM
To: [e-mail]
Subject: [dhcwg] DHCP-DHCPv6 Issues and IPv4 options drafts

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg




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