Subject: Re: [dhcwg] Volunteer to work on configuring IPv4 over IPv6 network

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Mar 2013 19:32:49 +0000

On Mar 19, 2013, at 1:17 PM, Tomek Mrugalski <[email-masked]> wrote:
> But still method 2 requires client update, which is a major pain. It is
> easier to update relays and server. Operators control their server and
> their relays, but they typically do not control the hosts. Operators
> can't force their customers to upgrade their software or hardware.

I think client update is a non-issue here, and in fact both options should require that the client be updated.   The reason is that an unmodified client isn't going to do the right thing with the answer anyway.   So although in principle you are right that the client is the hardest thing to modify, in this case we _have_ to modify it, so we might as well modify it completely, and not only halfway.

The only solution that makes sense to me is the one where the client sends a DHCPv4 packet wrapped in a special client header to the All_Relays_And_Servers multicast address on the DHCPv6 server port.   This uses the exact same infrastructure as DHCPv6, and requires no special DHCPv4-specific modifications other than on the server.

We have also talked about two other variations.   The first is the variation where the first relay agent knows the difference between a DHCPv6 message and a DHCPv4 message, and can send DHCPv6 messages to a different IPv6 address than DHCPv4 messages.

The other variation we talked about is the one where at the end of the relay chain, either the DHCP server or a DHCP relay agent that is connected to both the IPv6 network and an IPv4 network recognizes DHCPv4 packets being relayed to it and relays them over IPv4 to a DHCPv4 server.

These variations are just optional enhancements.   We don't need them, but someone might like them.   So they are probably worth clearly documenting, but the main thing that needs to be documented is how the client works, and this should be the same in all three cases: the main case and the two variations.

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 19 Mar 2013 21:03:16 +0100

> I think client update is a non-issue here, and in fact both options should require that the client be updated.   The reason is that an unmodified client isn't going to do the right thing with the a…

Ted,

I am not questioning that you're right but I don't understand why
"client isn't going to do the right thing with the answer". Can you
please elaborate?

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Mar 2013 20:14:03 +0000

> "client isn't going to do the right thing with the answer". Can you

A client sends a DHCPDISCOVER over IPv4 to configure the interface from which it sends the DHCPDISCOVER.   Whatever response it gets, it will use to configure that interface.

Here, we are using the DHCPDISCOVER to configure the tunnel endpoint, not the broadcast interface.   So an unmodified client has no hope of doing the right thing with the configuration it gets from the server.   It will try to use the response it gets on its broadcast interface, and every IPv4 packet it sends will be dropped, because there's no router to carry it.

This brings up the point that the draft probably ought to give some guidance as to *which* broadcast interface to use to send the DHCPDISCOVER, since a typical HG has multiple interfaces, and at least the current use case targets HGs.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 19 Mar 2013 20:54:14 +0000

I believe ... One important thing to keep in mind is that the DHCP client here is on the CPE device (router) and not a Windows, iOS, Linux, Android, ... device. So, changing the client isn't really that significant a concern. (The CPE device will also have NAT and a DHCP server just as they do today to use that one IPv4 address.) I think the diagram and document needs to be clear on this as the term "client" is often confusing (at least to me). CPE, gateway, residential router, "the network box", ... are probably better terms to use?

There were a few times where I had my model confused and was thinking host or 'end client' (Windows, IOS, Linux, ... device) instead of CPE. And, that wrong model seems to be reflected in the artwork Marcin's draft currently has which shows V4/V6 going to the "Unified Relay". And while we could have such a model, I don't think it is correct and realistic. The DHCPv4 Client and DHCPv6 Client are in one box. The uplink side of that box communications IPv6 only to the SP. The v4/v6 side of the box communicates to "hosts" which are running standard operating systems. The "hosts" will do DHCPv4 and DHCPv6/SLAC to get addresses from the "box". The "box" will do NAT for v4 and tunnel v4 over v6 to the some tunnel endpoint.

I do think we need to make sure we're all on the same page as to the model:

    Home Network with v4/v6 ----> CPE ----- v6-only link (DSL, Cable, ...) ----> SP network [with relays] -----> DHCPv6/v4 server

The CPE has NAT for v4 and also supports tunneling v4 over v6. The CPE has v6 only uplink. SP network is mostly v6 (has limited v4 for tunnel endpoints and perhaps some limited v4 services -- v4 is mostly for connectivity to Internet). The devices in the home use v4 pretty much as they would today behind a CPE that provides native v4 service (via NAT). They can use 'native' v6 (either via SLAC or DHCPv6).

Ted wrote:
"The only solution that makes sense to me is the one where the client sends a DHCPv4 packet wrapped in a special client header to the All_Relays_And_Servers multicast address on the DHCPv6 server port.   This uses the exact same infrastructure as DHCPv6, and requires no special DHCPv4-specific modifications other than on the server."

I agree. The uplink is only capable of IPv6 and so this packet must go over IPv6. And, as we assume that the CPE was given a PD (and perhaps v6 address) via DHCPv6, DHCPv6 support (relay or server) must be at the other end of this link.

I think it best to focus on the "base" solution without the optional enhancements? Once we get the "base" solution worked out, we can add the optional enhancements (either in the base document or as a separate one).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Tuesday, March 19, 2013 3:33 PM
To: Tomek Mrugalski
Cc: Qi Sun; Marcin Siodelski; Suresh Krishnan; Bernie Volz (volz); [email-masked]; [email-masked]; [email-masked]; Cong Liu; Yuchi Chen; [email-masked]
Subject: Re: Volunteer to work on configuring IPv4 over IPv6 network

On Mar 19, 2013, at 1:17 PM, Tomek Mrugalski <[email-masked]> wrote:
> But still method 2 requires client update, which is a major pain. It 
> is easier to update relays and server. Operators control their server 
> and their relays, but they typically do not control the hosts. 
> Operators can't force their customers to upgrade their software or hardware.

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 19 Mar 2013 22:16:31 +0100

> I believe ... One important thing to keep in mind is that the DHCP client here is on the CPE device (router) and not a Windows, iOS, Linux, Android, ... device. So, changing the client isn't really…

Yes. I agree that this is confusing and thus I suggest that we stop
using term "DHCP client".

> There were a few times where I had my model confused and was thinking host or 'end client' (Windows, IOS, Linux, ... device) instead of CPE. And, that wrong model seems to be reflected in the artwo…

What I think then is that we make a document that Qi Sun has sent a base
document for further work because it definitely better reflects the
goal. I removed the document that I have created to avoid confusion for
somebody looking into the repo and will eventually merge some parts of
it to the base document later on.

> I agree. The uplink is only capable of IPv6 and so this packet must go over IPv6. And, as we assume that the CPE was given a PD (and perhaps v6 address) via DHCPv6, DHCPv6 support (relay or server)…
In this case we should probably remove the "Method 2 from the document
provided by Qi Sun" as we should move towards only one solution. 

> I think it best to focus on the "base" solution without the optional enhancements? Once we get the "base" solution worked out, we can add the optional enhancements (either in the base document or a…

Yes, but maybe we could list the ideas for enhancements (as they already
exist) in a temporary section so as people reading this draft have big
picture of what work is planned that may affect the way the protocol is
working.

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Mar 2013 22:17:44 +0000

>    Home Network with v4/v6 ----> CPE ----- v6-only link (DSL, Cable, ...) ----> SP network [with relays] -----> DHCPv6/v4 server

It's possible that some other use model will surface in the future, so I don't think we should insist that the client has to be a CPE device.   But that should definitely be the model that's used to explain the protocol; we should just include a disclaimer in the applicability statement that says that while the currently identified use case is a CPE device with a tunnel, this should not be read as excluding other use cases that are identified in the future.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Mar 2013 11:48:40 +0000

On Mar 20, 2013, at 12:53 AM, Suresh Krishnan <[email-masked]> wrote:
> where the unmodified clients send out DHCPv4 messages that are
> encapsulated by a relay (which I call an IFRA) into a DHCPv6
> Relay-forward message? Or do people think this case is not important?

In a real dual-stack network, can't you just do DHCPv4 directly?