Subject: [dhcwg] Dual stack issues

From: Vijayabhaskar A K <[email-masked]>
Date: Thu, 12 Feb 2004 18:56:51 +0530

My quick comments about the draft....

I beleieve the main concern raised in the draft is, how to handle the 
service parameters obtained from DHCPv6 and DHCPv4.  I really see that 
this is a configuration issue rather than the protocol issue.. Every 
IPv4 service addresses can be sent as IPv4 mapped IPv6 addresses in the 
DHCPv6.. So, the client will always able to get the IPv4 configuration, 
What the admin needs to do is to make sure that these parameters are not 
configured in both DHCPv4 and DHCPv6. In this way, the dhcp clients 
doesn't need to merge/choose the lists. Remember the discussion about 
nisconfig in the wg list, kre rightly said that you could change the 
protocol for merging DHCPv4 and DHCPv6 information. But, it is not 
really possible if you are getting the parameters from someother source, 
eg:- SLP. In this way the problem exists still. So, I guess the best way 
to deal with the issue, rather than duplicating dhcpv4 options, its good 
to refer as IPv4 mapped IPv6 addresses. But still I am not convinced 
with sending IPv4 information in DHCPv6, even as IPv4 mapped IPv6 
addresses. DHCPv4 should give v4 parameters and dhcpv6 should give v6 
parameters. They should be disjoint list configured by an intelligent 
admin. Thats it.

Then regarding DHCPv6 server giving v4 addresses, its not really a good 
idea. Its just thrusting the DHCPv4 functionality in DHCPv6. Instead 
running dhcpv4 and dhcpv6 clients seperately, you are going to run an 
overloaded dhcpv6 client.I couldn't get a reason why there should be 
single dhcpclient. Am I missing something here?

~ Vijay

-- 
__________________________________________________________
Vijayabhaskar A K            Phone : +91-80-22053085
Hewlett Packard              Mobile: +91-9845241382
Bangalore, India             Email : [email-masked]

Intellectuals solve problems: geniuses prevent them.
-Albert Einstein, physicist, Nobel laureate (1879-1955)
__________________________________________________________

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

---

From: Christian Strauf <[email-masked]>
Date: Thu, 12 Feb 2004 15:01:19 +0100

Hi Vijay!

I agree with Stig in his mail (Stig: could you be so kind a post your
response to the list? tnx!) saying that we have fundamentally different
views. Having DHCPv4 only convey v4 information and DHCPv6 only v6
information is only one view. Another view is to regard DHCPv6 merely as
means of transport. If I remember correctly, there's no statement in RFC
3315 saying that you must only transport IPv6 information with DHCPv6.

Additionally, there are a number of paradigms in DHCPv6 that we miss in
DHCPv4 in our day to day operations, e.g. going away from using MACs for
per-host address assignment but instead use DUIDs/IAIDs etc.. I see a
real gain of administrative comfort in using DHCPv6 for transporting
IPv4 information.

> to refer as IPv4 mapped IPv6 addresses. But still I am not convinced 
There're cases where this is not desirable e.g. when using broadcast
address options for IPv4 which only make sense as suboptions of
OPTION_IAADDR_IPv4.

> parameters. They should be disjoint list configured by an intelligent 
Well, from an admin's point of view it's practical to only have to
administrate DUIDs and IAIDs for dual-stack hosts, not MAC addresses as
well.

> single dhcpclient. Am I missing something here?
The issues listed in draft-chown-dhc-dual-stack-00 can be solved by
having such a single client. Putting aside whether this is a pure DHCPv6
client that can request IPv4 information options or if it is a combined
DHCPv4/-v6 client, it is an elegant solution to the problems outlined
there.

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: Vijayabhaskar A K <[email-masked]>
Date: Thu, 12 Feb 2004 21:40:26 +0530

Christian

comments inline..

>3315 saying that you must only transport IPv6 information with DHCPv6.
It  doesn't matter whether it can be done or not. The real need is 
important.. I couldn't see an actual problem here.

>address options for IPv4 which only make sense as suboptions of
Though I am saying that the IPv4 service parameters can be given as IPv4 
mapped IPv6 addresses, I really dont like the idea of doing it. With a 
proper configuration of DHCPv4 and DHCPv6 server, you can acheive 
whatever the dual stack host need. Here, all the DHCPv4 address 
configuration (other than service parameters) should be done by DHCPv4

>administrate DUIDs and IAIDs for dual-stack hosts, not MAC addresses as
I guess some work is going on in this area. Rather than porting all the 
IPv4 configuration to  DHCPv6, backporting of just a single feature 
makes more sense.

>DHCPv4/-v6 client, it is an elegant solution to the problems outlined
Let me go through the list.. I have listed my comments along with the 
text from draft-chown-dhc-dual-stack-00

>3.1 Handling multiple responses
>
>   The general question is how to handle configuration information that
>   may be gathered from multiple sources.   Where those sources are DHCP
>   and DHCPv6 servers (which may be two physical nodes or two servers
>   running on the same node) the client node needs to know whether to
>   use the most recent data, or whether to perform some merger or union
>   of the responses by certain rules.  A node may choose to ask a DHCPv6
>   server and only use a DHCP server if no response is received.
>
Its a configuration issue....

Make DHCPv6 to send IPv6 params and DHCPv4 to send IPv4 params. Always 
the client needs to combine the list.

>Merging is possible, but is likely to be complex. 
>  
>
It is not at all complex when the lists are disjoint.

>A node configured manually to use an IPv6 DNS server via
>   such manual configuration may lose that configuration if it then uses
>   DHCP to obtain IPv4 settings if in a dual-stack environment; 
>
The problem exists even with your solution. Moreover, this is not 
protocol issue. The admin can define the order.

>3.2 Multiple interfaces
>
>Per interface settings can be complex because a client node needs to
>   know from which interface system settings like NTP server came from.
>   And it may not be apparent which setting should be used, if e.g. an
>   NTP server option is received on multiple interfaces, potentially
>   over different protocols.
>  
>
NTP server is not a per interface settings. It doesn't matter from which 
interface it came from. The router will take care where to forward if 
there is a NTP request for a particular server.

>3.3 DNS load balancing
>
>   In some cases it is preferable to list DNS server information in an
>   ordered way per node for load balancing, giving different responses
>   to different clients.   Responses from different DHCP and DHCPv6
>   servers may make such configuration problematic.
>
Here you need a mix up of ordering.. Use DHCPv6, since it can give IPv4 
addresses as IPv4 mapped IPv6 addresses.

>3.4 DNS search path issues

This falls in same category as the prev one. Do specify the search 
order, thats it.

>3.5 Administrative management
>
It could be termed as configuration issue.. Needed to be fixed this in 
administration rather than protocols.

>3.6 DHCP option variations
>
use DHCPv6, send IPv4 mapped IPv6 addresses.

I really couldn't see the difficulties in the configuration of dual 
stack nodes. Without the clear problem statement, I am not able to 
co-relate the solution you propose. May be, I am missing somethings. 
Comments are welcomed.

~ Vijay

---

From: Stig Venaas <[email-masked]>
Date: Thu, 12 Feb 2004 17:28:01 +0100

I think it boils down to two alternatives.

Dual-stack hosts using both DHCPv4 and DHCPv6

Dual-stack hosts getting necessary v4 info from DHCPv6

Or actually, there's sort of a middle solution of DHCPv6 being
able to specify v4 addresses in some options, but not leasing
out v4 addresses for the host configuration.

Perhaps should try to write down how things can be done in the
different cases, and then try to compare them?

Stig

---

From: Vijayabhaskar A K <[email-masked]>
Date: Thu, 12 Feb 2004 22:17:30 +0530

>different cases, and then try to compare them?
Yes. It is better to do. One of them will be a solution for the recent 
nisconfig and other configuration parameters options' problem in dual 
stack environment.

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Feb 2004 13:13:27 -0500

I think the first step is to identify those items that are going to be an
issue.

First, we need to look at the types of data:

a. Single values. When a single value for a configuration item exists,
obviously if the DHCPv4 and DHCPv6 supplied values differ, there is a major
problem. Worse, if the DHCPv4 and DHCPv6 clients don't in some way have a
consist policy for updating the client's configuration the value may
flip-flop depending on which client last received configuration information.

b. List of values. When a configuration item can be a list of values
(typically the first listed item is preferred), the significant issues are:
- Is merging the lists proper?
- When both DHCPv4/v6 configure values, how should the values be ordered
when merged?
- When there is a limit to the number of configured values that may be
allowed, what happens if the combined DHCPv4/v6 configured values exceed
this limit? If the values are simply concatenated, it is possible that one
transport's values may not be added (because the other fills the available
slots).

c. Incompatible configuration values. It may be that for some configuration
items, DHCPv6 supplies domain names (such the SMTP or POP servers) whereas
DHCPv4 provided only IPv4 addresses. But, I think this is any different from
(b) because if a host is truly dual stack, the applications should have been
updated appropriately to support either address or names.

d. Only one DHCPvX provides values. I presume that in this case the values
supplied are appropriate and the other DHCP client should NOT remove the
configuration values just because it did not receive that option.

Are there other cases? I've excluded multiple administrative domains since
supporting those requires special client considerations anyway.

My suggestions on handling these cases:

Case (a): This is truly an issue. But, is this significantly different from
the case where a user has configured a value and then the DHCPvX client
receives one that is different. Which should be used? So, in my mind this
becomes a policy issue and could be controlled on the host. A host might
have a <configuration-parameter>-policy that can be one of "use manually
configured", "prefer DHCPv4", "prefer DHCPv6".

If "use manually configured", neither DHCP client does anything with the
received value.
If "prefer DHCPv4", the DHCPv4 client will configure the value when one is
received. The DHCPv6 client can configure the value only if none is set.
If "prefer DHCPv6", the DHCPv6 client will configure the value when one is
received. The DHCPv4 client can configure the value only if none is set.

Case (b): I assume that merging the DHCPv4 and DHCPv6 lists is proper. A
true dual-stack host should have applications that support both transports.

Again, a configuration policy setting may be useful. This would be allowed
to have the following possible values: "prefer DHCPv4" (use only values
supplied via DHCPv4), "prefer DHCPv6" (use only values supplied via DHCPv6),
"DHCPv4 first" (place DHCPv4 values first), "DHCPv6 first" (place DHCPv6
values first), "alternate DHCPv4 first" (alternate values, starting with
DHCPv4 value), "alternate DHCPv6 first".

A DHCP client should maintain a list of the values it configured for the
parameter as well as the previously received option value.

Whenever the client receives new configuration information, it compares the
received information with the previously received. If there are no changes,
it is done with this parameter.

If there are changes, it obtains the current client's configuration and
removes the values it added (using the list of values it configured for the
parameter). What remains is either any empty list or a list of values
configured through other means. It then adds its values based on the
configuration policy as follows:

For DHCPv4 client:
If "prefer DHCPv4", use only the DHCPv4 received values.
If "prefer DHCPv6", if the remaining list is not empty, use it. If it is
empty, use the DHCPv4 supplied values.
If "DHCPv4 first", use the DHCPv4 received values and then append any
remaining values.
If "DHCPv6 first", use the remaining values and then append the DHCPv4
received values.
If "alternate DHCPv4 first", add values alternating between a DHCPv4 value
and a remaining value. (Once one set is exhausted, append the remaining
other set.)
If "alternate DHCPv6 first", add values alternating between a remaining
value and a DHCPv4 value. (Once one set is exhausted, append the remaining
other set.)

For the DHCPv6 client, make the appropriate changes in the above list of
actions.

If the number of values exceeds the allowed number (or length), truncate the
list to allowed number (or length).

The client must (internally) record the list of values it added to the
configuration parameter.

- Bernie

---

From: Christian Strauf <[email-masked]>
Date: Thu, 12 Feb 2004 20:39:30 +0100

Hi Bernie!

The way I see it, the "prefer DHCPvX" flags pose the real problem: how
does a host know when it's running which DHCP client? All
implementations I know have the same paradigm: you have an independent
DHCPvX client that receives information and puts it into the appropriate
places (e.g. configuration files like resolve.conf etc.). How does a
DHCPv4 client which read a "prefer DHCPv6" flag for a certain service
for instance know that

(a) a DHCPv6 client is actually running?
(b) the DHCPv6 server is receiving up-to-date information?
(c) the latest information is used for the service and there're no
"stale values" present?

There needs to be some form of coordination between the two DHCP clients
(v4/v6) so that values obtained by either protocol are in some way
honoured by the other protocol client. There needs to be a way for each
client to tell the other client about the internal states it saves for
its particular DHC protocol. There are three possible options:

(a) Have separate DHCP clients that have a "communications protocol" in
an abstract kind of way to exchange information about their state
machineries.

(b) Have a single client that is "bi-lingual" and speaks DHCPv4 & -v6.

(c) Only use a DHCPv6 client to obtain all information.

All three of the above options have advantages and disadvantages (the
following lists are not complete and just state some major points):

(a) Advantages:
- DHCP client implementations need minor changes.
- Protocol definitions are left untouched.
(a) Disadvantages:
- Potential problem of inconsistency of the states (how do you handle
concurrent changes etc.)
- Administrative overhead (MAC, DUIDs and IAIDs need to be handled --
and that is a considerable amount of work for sites with 20k+ hosts)

(b) Advantages:
- Protocol definitions are left untouched.
- You have only one client that knows both state machineries of DHCPv4 &
-v6 and therefore consistency is easier to achieve.
(b) Disadvantages:
- Completely new implementation, old DHCPv4 clients can't simply be
modified, a combined new client has to be written.
- Same administrative overhead as in (a)

(c) Advantages:
- DHCPv6 implementations only need slight modifications to include IPv4
options
- Consistency is easy because you only have one state machinery
(c) Disadvantages:
- Client doesn't speak native DHCPv4 anymore
- Options need to be "converted" to DHCPv6 options.

I think we can assume that (a), (b) and (c) would solve the issues you
identified equally well. The question is: which solution is more
feasible in practise? I personally doubt that a complete separation of
DHCPvX clients on dual-stack hosts will work in all cases, even if a
clever admin tries to keep both server configurations as clean as
possible.

When we wrote the I-Ds, we thought about various solutions which can be
kind of boiled down to the above three and (c) was our choice because we
think that from our practical experiences, this is the easiest solution
to implement which causes less administrative overhead than all others
(always keeping large sites in mind).

Cheers,
Christian

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Feb 2004 15:08:42 -0500

Hi:

>does a host know when it's running which DHCP client?

I don't see the major problem here. However, my initial process for how a
client updates the configuration was a bit incomplete and a similar
procedure to that used for the case (b) in my earlier email needs to be
used:

- The client maintains what value it set (if it did so in the past).
- When the client receives a value from the server, it obtains the current
configuration value.
- If the client is the preferred client, it sets the value and records that
it did so.
- If the client is not the preferred client, it only sets the value to the
new value if there is no value OR if it last set the value. It records what
it did. (This step can cause a problem in the off chance that the not
preferred client set the value initially, the preferred client then set the
same value, and now the non-preferred client receives a new value ... this
can be solved easily enough ...)

Ways to solve the communication problems and synchronization are fairly easy
... both the DHCP clients share a common file. This file is used to
synchronize changes and also allows the clients to record who changed what
value.

I also see no issue with having a single client that is bilingual. But, that
is not required.

Regarding the MAC, client identifier, and DUID, I fully support the work
Ted's been doing to adopt the DUID for DHCPv4 clients as the client
identifier.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Strauf
Sent: Thursday, February 12, 2004 2:40 PM
To: 'DHCPWG'
Subject: RE: [dhcwg] Dual stack issues

Hi Bernie!

(a) Advantages:

(b) Advantages:

(c) Advantages:

Cheers,
Christian