Subject: [dhcwg] [Fwd: Re: Dual stack issues]

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

I thought it will be good to include the list also in this discussions. 

~ Vijay

Subject: Re: Dual stack issues
From: Vijayabhaskar A K <[email-masked]>
To: Stig Venaas <[email-masked]>
Cc: [email-masked], [email-masked], Ralph <[email-masked]>, [email-masked]
Date: Thu, 12 Feb 2004 18:55:20 +0530

Stig Venaas wrote:

>On Thu, Feb 12, 2004 at 05:41:58PM +0530, Vijayabhaskar A K wrote:
>[...]
>  
>
>>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?
>>    
>>
>
>I think we have some fundamentally different views.
>
>I know it can get complicated etc. but in general without looking at
>the technical details, I would say that which DHCP protocol is used
>(whether it's over v4 or v6) shouldn't affect what kind of addresses
>you can get configured with it. Although none of us would propose
>getting v6 with DHCPv4 I'm sure (:
>  
>
There is nothing wrong in it.. But, the real requirement is important

>As another example, what if I'm running say Apple Talk, and I wanted
>to learn the AT address for a service, or some configuration parameter,
>wouldn't that be something DHCP could do as well?
>
>The fundamental problem for me anyway, is dual-stack hosts, which we
>will have for at least next 10 years if you ask me, probably longer.
>We want to start migrating to IPv6 services, but some will remain in
>IPv4 for some years. Should I then be forced to run both DHCPv4 AND
>DHCPv6, and also have dual-stack hosts do BOTH DHCPv4 and DHCPv6?
>  
>
Please remember that, DHCPv4 is not just another application which *just 
uses* IPv4 addresses... They *provide* IPv4 addresses. They are 
indispensable unit in IPv4.. You need IPv4 router and IPv4 stack till 
there is a last node supporing IPv4 exists.. DHCPv4 is also very similar 
to this. Let both versions of DHCPv4 and DHCPv6 exist together

>To me that sounds pretty broken. There's a lot of extra managment
>and failure possibilities.
>  
>
As I said earlier, intelligent configuration of network will solve the 
problems stated, there is no need of protocol changes.. Moreover, extra 
management and failure possibilities will be more, only in the case,if 
we merge it together.. Some of the issues has been already sent by Bernie..

>Doing also IPv4 with DHCPv6 is a relatively simple addition I think.
>You need a new option for the address delegation, and one for doing
>encapsulation. Isn't that all? There might be complications I'm not
>aware of.
>  
>
client needs to do an ARP, some servers also do ARP check. Similar needs 
will arise and it really make dhcpv6 heavier and will lead to lot more 
implementation issues..

>Then, I would say that hosts that have IPv6 support should try
>DHCPv6 query, if it works fine. If not, fall back to do DHCPv4.
>  
>
Well, you can do it as different entity rather than a single dhcpclient 
application..

>Of course it should also be possible for administrator or user
>to choose witch one to use, and whether to fall back.
>
>Shouldn't we have this discussion on the list?
>  
>
I want to make sure whether my understanding is correct or not.. I 
didn't want to create a mess in WG with my wrong assumption and there is 
a chance of the discussion drifting away from the topic.. Anyhow, I will 
post it in WG list...

~ Vijay

>Stig

-- 
__________________________________________________________
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)
__________________________________________________________

---

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

[...]
> to this. Let both versions of DHCPv4 and DHCPv6 exist together

I'm of course not saying that DHCPv4 should stop to exist. But in a
dual-stack environment, I think it's cleaner to get the v4 addresses
from the DHCPv6 server, and not be forced to manage both.

[...]
> we merge it together.. Some of the issues has been already sent by Bernie..

If you need both servers to configure interfaces with addresses, and
get other configuration, then you rely on two separate protocols to
work (servers and relays etc) in order for the host to behave correctly.

> will arise and it really make dhcpv6 heavier and will lead to lot more 

Of course it could be up to the vendor whether they also want to
support delegation of v4 addresses. And the administrator can
perhaps choose whether to use it, and maybe choose between different
versions.

Stig

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

---

From: Vijayabhaskar A K <[email-masked]>
Date: Thu, 12 Feb 2004 20:33:00 +0530

>from the DHCPv6 server, and not be forced to manage both.
Stateless address autoconf doesn't advertise IPv4 prefixes.. Why should 
DHCPv6 support IPv4 configuration?

>work (servers and relays etc) in order for the host to behave correctly.
Well, you need IPv4 router, IPv4 stack, applications understanding IPv4 
and lot more for IPv4 to work.. Its just a configuration.. Already all 
the DHCPv4 components exist and you need to  just configure.. In your 
case also admin has to configure both...

>perhaps choose whether to use it, and maybe choose between different
The question is whether to give that flexibility or not. IPv4 is going 
to die one day. Whatever you are trying to define will give an uglier or 
complicated look to dhcpv6 on that day. The key fact is you *can* 
configure IPv4 stack *without* requiring DHCPv6. The gains you get by 
duplicating all these functionalities in DHCPv6 is much lesser. Even it 
is not worth time investing in duplicating IPv4 configuration in DHCPv6.

~ Vijay

---

From: Cristian Cadar <[email-masked]>
Date: Thu, 12 Feb 2004 17:04:56 +0100

Hi Vijay!

> is not worth time investing in duplicating IPv4 configuration in DHCPv6.

We are trying to draw a line between the configuration of clients with only v4 
stack and clients with dual stack ,  the first to  be configured by the 
dhcpv4 and the latter only by the dhcpv6  avoiding the dual stack clients to 
be configured by both dhcpv4 and dhcpv6 which could create some problems 
latter(in this way there is less overhead for the admin to mantain the v4 and 
v6 networks at the same time).  As it was outlined in the draft these 
modifications have only a small inpact on the dhcpv6 stack , on the day  when 
IPv4 will die the options for carring ipv4 opt will be declared obsolete .

Cheers
Cristian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Feb 2004 16:10:29 -0500

I think we're going down a rathole here.   You may think it's easier to 
have one DHCPv6 server and no DHCPv4 server in a dual-stack 
environment, and that may even be true, but we are discussing making 
substantial and painful changes to the protocol to accomodate your 
preference.

It seems to me that it would be easier to just have a DHCP server that 
supports both DHCPv4 and DHCPv6 from the same configuration.   I can 
easily imagine how to implement such a thing, and I think the 
difficulty of administering it would be about the same as the 
difficulty of administering a DHCPv4-only server.   This requires no 
new protocol nastiness, and provides a nice new product space in which 
the several DHCP server vendors on this mailing list can compete.   :')

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Feb 2004 21:46:41 -0500

Ted - I was talking about the same idea with some of my colleagues here at
Cisco earlier today.  Seems like it would be relatively straightforward to
write a configuration manager that would accept a single configuration
specification from the service manager and parcel out the right config
pieces to the DHCPv4 and DHCPv6 servers.  In this case, maintaining
coordinated configurations in two servers is an interface issue, not a
protocol issue.

- Ralph

At 04:10 PM 2/12/2004 -0500, Ted Lemon wrote:
>have one DHCPv6 server and no DHCPv4 server in a dual-stack environment, 
>and that may even be true, but we are discussing making substantial and 
>painful changes to the protocol to accomodate your preference.
>
>easily imagine how to implement such a thing, and I think the difficulty 
>of administering it would be about the same as the difficulty of 
>administering a DHCPv4-only server.   This requires no new protocol 
>nastiness, and provides a nice new product space in which the several DHCP 
>server vendors on this mailing list can compete.   :')
>
>

---

From: Robert Elz <[email-masked]>
Date: Fri, 13 Feb 2004 15:19:23 +0700

Date:        Thu, 12 Feb 2004 21:46:41 -0500
    From:        Ralph Droms <[email-masked]>
    Message-ID:  <[email-masked]>

  | Ted - I was talking about the same idea with some of my colleagues here at
  | Cisco earlier today.  Seems like it would be relatively straightforward to
  | write a configuration manager that would accept a single configuration
  | specification from the service manager and parcel out the right config
  | pieces to the DHCPv4 and DHCPv6 servers.

Damn, Ted got his message in first - I was going to say just the same
thing.

Whether there is a DHCPv4 server, and a DHCPv6 server, with separate
configurations, a single configuration split by a tool (of some kind)
and fed to separate servers, or one server, that implements both the
DHCPv4 and DHCPv6 protocols, and takes a single configuration, sending
whatever information is appropriate in each offer (just as a single
protocol server does) is really all irrelevant to the protocol
specifications.

People worried about having to manage two different servers just need
to acquire a single server (or a single management interface).   There's
nothing difficult about this.   Others who want to manage their v4
and v6 stacks entirely separately can use independent servers and
configurations.

On the other hand, is the DHCPv6 protocol were altered (or simply
specified) to supply v4 configuration information (by sending around
v4 compatible v6 addresses), then consider what happens when your
typical client first does its normal v4 configuration, and talks to the
v4 server, and gets v4 information that way, and then the v6 stack talks
to its v6 dhcp server, gets its v6 configuration information (fine) but
also gets a bunch of v4 configuration info, and proceeds to alter the
configuration that was already made for the v4 stack.    That possibility
isn't even worth contemplating.

Keep v4 addresses completely out of the DHCPv6 protocol.

The other info, that can be delivered by both servers (names, etc)
which is IP version neutral just gets delivered by both - in exactly the
same way as it gets delivered to each of N interfaces.   It is a server
management issue to make all of that remain consistent so the client
doesn't need to try and guess which interface's (or which stack's)
value is the correct one to use.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 13 Feb 2004 08:54:07 -0500

>server vendors on this mailing list can compete.   :')

And how would the client put it back together?

I really feel like we are having a classic failure to communicate...
So, let me try an example.

Let's suppose that I have a set of servers that provide a single
service that is accessible via IPv4 of IPv6 transports.  How do I
configure all of the nodes in a network (that might include IPv4-only,
dual-stack or, perhaps in the future, IPv6-only nodes) to reach that
service?

To be more specific:

Let's say that I have 4 DNS Servers in my site.  Let's say that I am
only starting to roll out IPv6, so 2 of my DNS servers are dual-stack
(providing service over IPv4 and IPv6 transports) and two of them are
only available via the IPv4 transport.  My servers could have the
following IP addresses:

Server1:  IPv6-Addr1
           IPv4-Addr1

Server2:  IPv4-Addr2

Server3:  IPv6-Addr3
           IPv4-Addr3

Server4:  IPv4-Addr4

Let's also assume that I have two nodes somewhere on my network,
Node1 and Node2.  Node1 is an IPv4-only node, and Node2 is a dual-
stack (IPv4 and IPv6 node).  Both nodes are configured to get their
IPv4 addresses using DHCPv4, and Node2 uses IPv6 autoconfiguration
to generate IPv6 addresses.

Let's also assume that the DNS search list for each of these nodes
should be in the order I have listed the servers above (Server1,
Server2, Server3, Server4), and that I want the dual-stack node
to use the IPv6 addresses for Server1 and Server3.  So this
is what I want to configure in each node's DNS server list:

Node1:  IPv4-Addr1, IPv4-Addr2, IPv4-Addr3, IPv4-Addr4

Node2:  IPv6-Addr1, IPv4-Addr2, IPv6-Addr3, IPv4-Addr4

So, how do I do that?

Well, I have to configure my DHCPv4 server to return all four
of the IPv4 addresses, right?

And, I guess you'd have me configure my DHCPv6 server to return
only the two IPv6 addresses?

So, Node1 will be configured correctly, but Node 2 will get
_two_ lists of DNS server addresses (the IPv4 ones and the IPv6
ones).  Which ones will it try first?  There doesn't seem to be
any priority or meta-information associated with any DHCP options
that would allow Node2 to decide how to order the six entries
it receives.  There also doesn't seem to be a way for Node2
to know that two of the entries in the IPv4 table point to the
same DNS servers as the two IPv6 entries.

There seems to be some desire to sweep these decisions under
the rug of "client implementation", but I can't see that our
DHCPv6 options, as currently defined, are providing enough
information for the client to make a reasonable choice.

Margaret

---

From: Ralph Droms <[email-masked]>
Date: Fri, 13 Feb 2004 09:56:46 -0500

I think we're just talking about different sides of the problem - the 
server side and the client side.  And we have to solve both sides of the 
problem.

Ted, kre and I are commenting on the server side - from the network admin's 
point of view, a requirement for both DHCPv4 and DHCPv6 messages on the 
wire does not add complexity to the admin's job.  An appropriate single 
administration interface, for either a single server sending both DHCPv4 
and DHCPv6 or two separate servers, can coordinate the DHCPv4 and DHCPv6 
services.

 From the client side, we have to define how the client puts things back 
together.  But this problem may be simplified if we assume that the DHCPv4 
and DHCPv6 services, presumably run in the same administrative domain, can 
be managed to avoid conflicting configuration information.

- Ralph

At 08:54 AM 2/13/2004 -0500, Margaret Wasserman wrote:

>>nastiness, and provides a nice new product space in which the several 
>>DHCP server vendors on this mailing list can compete.   :')
>

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 13 Feb 2004 10:08:06 -0500

Regarding this configuration example:

1) See my email from yesterday on how this would work at the client. The
dual-stack client would, in this case, have the "alternate, DHCPv6 first"
setting and it would produce something fairly close:

Node2:  IPv6-Addr1, IPv4-Addr1, IPv6-Addr3, IPv4-Addr2, IPv4-Addr3,
IPv4-Addr4

For DHCPv6 clients, that's likely what I would assume would be the default.

While this may not be optimum (since Server1 is listed twice and if down it
will take a bit longer to resolve names), it will still produce decent
results.

BTW, you're right that if there was some way for the node to know that
IPv6-Addr1 and IPv4-Addr1 where the same host, it could perhaps remove one
of the addresses from the list (in which case you'd be left with your
configuration). But, I think that's an optimization that isn't worth the
effort. That may also be point of discussion - as to how "good" a solution
we need. I don't think we need one that is prefect under all conditions.

2) With DNS, does it really matter that much exactly what the order is. The
DNS protocol is transport agnostic, so it really shouldn't matter as the DNS
servers should all be pointing to the same DNS name space (which I presume
they'd better be!). Except for perhaps load balancing issues (such as
round-robining the list for different clients), it really doesn't matter.
(There could also be connectivity issues I guess?)

3) I think better examples are things like dns search lists since these are
very order dependent (though some might argue that is bad since a temporary
DNS failure might return unexpected results - such as connecting to the
wrong host).

4) I'm willing to allow IPv4-mapped addresses into DHCPv6 based options
(such as the DNS servers). But I'm not convinced that this full solves the
problem. You still need some policy on a client for it to install the proper
set of options depending on what is available or not.

5) BTW, I presume node2 is using DHCPv6 to obtain the DNS information
(Information-Request/Reply)? You don't mention this ("and Node2 uses IPv6
autoconfiguration to generate IPv6 addresses").

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Margaret Wasserman
Sent: Friday, February 13, 2004 8:54 AM
To: Ted Lemon
Cc: Stig Venaas; Vijayabhaskar A K; DHCPWG; Harald Tveit Alvestrand
Subject: Re: [dhcwg] [Fwd: Re: Dual stack issues]

To be more specific:

Server1:  IPv6-Addr1
           IPv4-Addr1

Server2:  IPv4-Addr2

Server3:  IPv6-Addr3
           IPv4-Addr3

Server4:  IPv4-Addr4

So, how do I do that?

Margaret

---

From: Stig Venaas <[email-masked]>
Date: Fri, 13 Feb 2004 16:27:46 +0100

> will take a bit longer to resolve names), it will still produce decent

Yes, I think something like this could work.

I got one idea/question. How easy would it be to have the dual-stack
client, tell DHCPv4/DHCPv6 servers that it's only interested in some
of the information? You could imagine that dual-stack client gets
"IP neutral" data from v6 server, and then tell the v4 server that it
only wants the v4 dependent data.

Well, do you get the idea? I suppose the client could just ignore some
of the info it gets anyway though, but how could you do something like
this? You could perhaps even imagine that you give different answers to
dual-stack and single-stack hosts in other cases. E.g. if you only use
DHCPv4, you might want to give v4-only clients "example.com" as search
path, while give dual-stack clients "ipv6.example.com example.com".

Stig

---

From: Robert Elz <[email-masked]>
Date: Fri, 13 Feb 2004 22:28:53 +0700

Date:        Fri, 13 Feb 2004 08:54:07 -0500
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | So, how do I do that?

You most probably don't, though other than as a strawman example to
try and imagine non-existent differences, nor do you really want to.

Ralph is totally correct, in real life, with any kind of sane management,
these issues just don't arise (if the management is insane, that's a better
thing to fix).

If you're configuring the DNS, as in your example, what you want for
each node is that its first back end resolver (not really DNS server,
which is a different beast) give it correct answers, quickly.

That's all that matters really - extra resolvers beyond that (and most clients
only take 3 anyway, they ignore numbers 4, 5, 6. .... if you configure them)
are used almost never (just if the first resolver goes down), and in that
circumstance, you almost never really care which one gets used (the delay
to determine that the first one is not responding is bothering the users
enough) as long as something does - anything that the client can reach
which is working is good enough (if you have to fall back as far as the 3rd
in the list, most people have already gone out for lunch, and simply don't
care).

This is why I asked Harald for a *real* example where it makes a real
difference - in practice, such things are very hard to find.

And once more, this is *not* a v4 vs v6 issue.   Exactly the same thing
happens entirely within DHCPv4.

A much more likely scenario is that I have 2 multi homed hosts, X and Y.
Those are each connected to networks A and B.    On each of A and B I have
a DNS back end resolver (DA and DB).

To even out the load, I want X to use DA, and Y to use DB.   That is,
provided that X's A interface is up and configured and working, and
the same for Y's B interface (if not, then I want X to use DB, and Y
to use DA respectively).

That is, I configure the DHCP responses so that when X or Y asks for its
address on net A, it gets told to use DA, when they ask for their address
on net B, they get told to use DB (in each case I might list the other
resolved as a second choice, or I might not - each has some advantages and
some disadvantages).

How exactly do I arrange for X and Y to end up with different orders
when they both configure both interfaces?

This problem is inherent in the way DHCP was "designed" since it
bootstrapped itself out of BOOTP.

If you want something that allows some kind of different configuration
method, go and design some entirely new protocol, because DHCP just
isn't what you are looking for.    Whatever is designed should fix the
"conflicting information from different servers on multiple interfaces"
problem - once you've a method for that, the v4 vs v6 thing is just more
of the same (one can treat v4 and v6 on the same hardware as being different
logical interfaces).   For the same protocol, and different interfaces,
there are no "cute tricks" like using v4 compatible v6 addresses that
will pretend to make everything nice, but really just cause problems.

Good luck.

kre