Subject: [dhcwg] Requesting adoption of draft-scskf-dhc-dhcpv4-over-dhcpv6

From: Marcin Siodelski <[email-masked]>
Date: Wed, 03 Apr 2013 19:20:42 +0200

In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I am asking
for adoption of this document by DHC WG.

The latest version (-01) is available here:

http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6-01.txt
http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01

This document describes a mechanism whereby IPv4 client obtains its
configuration from the DHCPv4 server separated from the client by IPv6-
only network having DHCPv6 service. This mechanism is frequently
referred as "DHCPv4-over-DHCPv6".

The DHCPv4 client's request is carried in the newly defined DHCPv6
messages/option to/from the server and can be sent either through a
relay or directly.

Cheers,
Marcin

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 03 Apr 2013 19:40:52 +0200

Hi all,

This draft is a result of the discussion we had during last meeting in
Orlando. We have very productive discussion about IPv4 hosts
configuration in IPv6-only network. After we reached what looked like a
consensus in the meeting room, couple folks volunteered to write down
the draft that summarizes that perceived consensus. This draft is a
product of this effort.

As requested by authors, we are announcing adotion call on
draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated to
confirm whether there is WG consensus to adopt this work as DHC WG
draft. Please state whether or not you're in favor of the adoption by
replying to this mail. If you are not in favor, please also state your
objections in your response. This adoption call will complete on 2013-04-17.

Regards,
Bernie & Tomek

On 03.04.2013 19:20, Marcin Siodelski wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Apr 2013 12:42:51 +0200

> objections in your response. This adoption call will complete on 2013-04-17.

This looks very good. I would favour adoption, but I would really like 
to see some discussion before.

Some feedback:

- In section "6. Client Behavior", it's not clear on which IPv6 
interface the request for IPv4 parameters is to be sent. That knowledge 
would depend on the protocol that uses DHCPv4-over-IPv6. For example, if 
you are provisioning an IPv4-over-IPv6 tunnel interface, you would send 
the BOOTREQUEST6 message on the tunnel's underlying IPv6 interface.
Suggestion: This document should say that future documents that define 
uses of DHCPv4-over-IPv6 MUST specify which IPv6 interface is to be used 
by the client.

- In section "8. Server Behavior", it is said that the request is 
"passed to the DHCPv4 server engine". Is this an implementation detail 
(in which case it could be removed), or does it actually mean that the 
IPv4 message could be passed over the network to an unmodified DHCPv4 
server (in which case it could be more explicit)?

- Section "9. Security Considerations" says: "DHCPv6 is made a 
'transport protocol' for DHCPv4 messages over an IPv6 network". This is 
not true unless you can use this with a pure DHCPv4 client on one side 
and a pure DHCPv4 server on the other. It doesn't seem to be the case 
according to the rest of the draft and figure 1 in particular. So, is it 
or is it not a transport protocol for DHCPv4?

Nit:

- Section 8: "This message is passed to the DHCPv4 server engine, which 
generates a response *to the* as specified in [RFC2131]."
(remove "to the")

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 4 Apr 2013 11:34:19 +0000

> - In section "8. Server Behavior", it is said that the request is "passed to the DHCPv4 server 

This is possible but would likely require relaying the packet and that means adding (and later removing) the option 82 information. Things like subnet selection might be critical to indicate to the server where the client is located. 

I also support adopting this work.

- Bernie

On Apr 4, 2013, at 6:43 AM, "Simon Perreault" <[email-masked]> wrote:

> This looks very good. I would favour adoption, but I would really like to see some discussion before.
> 
> Some feedback:
> 
> - In section "6. Client Behavior", it's not clear on which IPv6 interface the request for IPv4 parameters is to be sent. That knowledge would depend on the protocol that uses DHCPv4-over-IPv6. For example, if you are provisioning an IPv4-over-IPv6 tunnel interface, you would send the BOOTREQUEST6 message on the tunnel's underlying IPv6 interface.
> Suggestion: This document should say that future documents that define uses of DHCPv4-over-IPv6 MUST specify which IPv6 interface is to be used by the client.
> 
> - In section "8. Server Behavior", it is said that the request is "passed to the DHCPv4 server engine". Is this an implementation detail (in which case it could be removed), or does it actually mean that the IPv4 message could be passed over the network to an unmodified DHCPv4 server (in which case it could be more explicit)?
> 
> - Section "9. Security Considerations" says: "DHCPv6 is made a 'transport protocol' for DHCPv4 messages over an IPv6 network". This is not true unless you can use this with a pure DHCPv4 client on one side and a pure DHCPv4 server on the other. It doesn't seem to be the case according to the rest of the draft and figure 1 in particular. So, is it or is it not a transport protocol for DHCPv4?
> 
> 
> Nit:
> 
> - Section 8: "This message is passed to the DHCPv4 server engine, which generates a response *to the* as specified in [RFC2131]."
> (remove "to the")
> 
> 
> Simon
> --

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Apr 2013 15:06:43 +0000

> This looks very good. I would favour adoption, but I would really like to see some discussion before.

I see people say this a lot.   If the working group is going to work on a document, it has to adopt it.   Any discussion prior to that should be about whether the problem ought to be worked on, and whether the document is a good place to start.   And that's precisely the discussion that a call for adoption is supposed to trigger.   I find it quite weird when working groups get a document all the way to the finished state before adopting it, so essentially there is nothing that needs to happen between adoption and last call.   That just doesn't make sense.

Anyway, thanks for your comments—I think they're insightful, and need to be addressed in the document.

---

From: <[email-masked]>
Date: Fri, 12 Apr 2013 13:47:35 +0200

Dear all,

(I cc sofwtire as this work is also relevant for the working group.)

I do not support this work as it induces more complexity compared to just defining adequate option in dhcpv6. Defining one container or few DHCPv6 options is much more simpler that the proposed approach. 

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Tomek Mrugalski
>Envoyé : mercredi 3 avril 2013 19:41
>À : [email-masked]
>Objet : [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6
>
>Hi all,
>

---

From: Qi Sun <[email-masked]>
Date: Mon, 15 Apr 2013 13:48:35 +0800

Dear Med, 

Thanks for your response. Here is my understanding.

IMHO, defining options in DHCPv6 seems to introduce less complexity in protocol. However, we do not know for now which options are needed in the future. If we have to port DHCPv4 options into DHCPv6, how many times should we do the work? Like one new option per 2 years, or redefining all DHCPv4 options into DHCPv6 at one time? The proposed solution tries to avoid polluting the DHCPv6 option space, which is necessary for transition in DHCP.

Another point is that, defining option(s) / container would require the DHCPv6 engine to handle DHCPv4 options, which would introduce more complexity to the logic and implementation of end points. The proposed solution leverages the DHCPv4 engine for DHCPv4 messages / options and DHCPv6 engine for DHCPv6 messages / options. The end points would compatible to both DHCPv4 process and DHCPv6 process. This is more suitable for the transition.

A third consideration is, in the case of IPv6 transition, the DHCP client (on the tunnel endpoint) is bound to be modified. We think it better to modify the client completely for the transition purpose.

Last but not the least, the proposed solution is based on the DHCPv6 infrastructure, which has been deployed in operators' networks. 

The DHCPv4 over DHCPv6 mechanism is an architectural development for DHCP protocol to meet the requirements for configuring IPv4 parameters across the IPv6 network. We think it is important for the DHC WG to work on it.

Best Regards,
Qi Sun

---

From: Qi Sun <[email-masked]>
Date: Mon, 15 Apr 2013 13:56:14 +0800

Dear Med, 

Best Regards,
Qi Sun
(Sorry for resending, try to synchronize with softwire ML...)

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 09:40:12 +0200

Re-,

Except "IPv4 addressing"-related configuration, what additional configuration parameters can be provisioned with DHCPv4 and not with DHCPv6? 
Why in the future, an IPv6-enabled node will require to retrieve configuration using DHCPv4-over-DHCPv6 and not directly using DHCPv6?

Cheers,
Med

>De : Qi Sun [mailto:[email-masked]]
>Envoyé : lundi 15 avril 2013 07:56
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Tomek Mrugalski; [email-masked]; Softwires ([email-masked])
>Objet : Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6
>
>
>Dear Med,
>
>IMHO, defining options in DHCPv6 seems to introduce less complexity in
>protocol. However, we do not know for now which options are needed in the
>future. If we have to port DHCPv4 options into DHCPv6, how many times
>should we do the work? Like one new option per 2 years, or redefining all
>DHCPv4 options into DHCPv6 at one time? The proposed solution tries to
>avoid polluting the DHCPv6 option space, which is necessary for transition
>in DHCP.
>
>Another point is that, defining option(s) / container would require the
>DHCPv6 engine to handle DHCPv4 options, which would introduce more
>complexity to the logic and implementation of end points. The proposed
>solution leverages the DHCPv4 engine for DHCPv4 messages / options and
>DHCPv6 engine for DHCPv6 messages / options. The end points would
>compatible to both DHCPv4 process and DHCPv6 process. This is more suitable
>for the transition.
>
>A third consideration is, in the case of IPv6 transition, the DHCP client
>(on the tunnel endpoint) is bound to be modified. We think it better to
>modify the client completely for the transition purpose.
>
>Last but not the least, the proposed solution is based on the DHCPv6
>infrastructure, which has been deployed in operators' networks.
>
>The DHCPv4 over DHCPv6 mechanism is an architectural development for DHCP
>protocol to meet the requirements for configuring IPv4 parameters across
>the IPv6 network. We think it is important for the DHC WG to work on it.
>
>Best Regards,
>Qi Sun
>> I do not support this work as it induces more complexity compared to just
>defining adequate option in dhcpv6. Defining one container or few DHCPv6
>options is much more simpler that the proposed approach.
>>
>> Cheers,
>> Med
>>
>>> objections in your response. This adoption call will complete on 2013-
>04-
>>> 17.
>>>
>>> Regards,
>>> Bernie & Tomek
>>>

---

From: Qi Sun <[email-masked]>
Date: Mon, 15 Apr 2013 16:59:47 +0800

Dear Med,

Please see inline.

Except "IPv4 addressing"-related configuration, what additional
> configuration parameters can be provisioned with DHCPv4 and not with DHCPv6?
>

[Qi] There are over 200 DHCPv4 options that may be required to provide IPv4
services. In the period of transition, some service providers and services
may remain in IPv4 for some time, while end users may demand these IPv4
services to be delivered over IPv6. The required info may be more than IPv4
addresses (port set). As for examples, IMHO, SIP server option and NTP
server option are potential customers for this usage. There may be more,
because demands are arising with time going on.

> Why in the future, an IPv6-enabled node will require to retrieve
> configuration using DHCPv4-over-DHCPv6 and not directly using DHCPv6?
>
> [Qi] We are talking about IPv6-enabled node in IPv4/IPv6 transition
period, when IPv4 and IPv6 services are coexisted. Using DHCPv4-over-DHCPv6
can guarantee all DHCP-based services to be configured correctly.

Of course, in IPv6 only Internet where there is no demand for IPv4
services, we should use DHCPv6. But DHCPv4-over-DHCPv6 can also work in
this case.

Best Regards,
Qi

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 11:35:27 +0200

Re-,

Please see inline.

Cheers,
Med

De : Qi Sun [mailto:[email-masked]]
Envoyé : lundi 15 avril 2013 11:00
À : BOUCADAIR Mohamed OLNC/OLN
Cc : [email-masked]; Softwires ([email-masked])
Objet : Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6

Dear Med,

Please see inline.

[Qi] There are over 200 DHCPv4 options that may be required to provide IPv4 services. In the period of transition,
[Med] The question is not how many dhcpv4 exist, but which ones are really needed when the host is IPv6-enabled.

some service providers and services may remain in IPv4 for some time, while end users may demand these IPv4 services to be delivered over IPv6. The required info may be more than IPv4 addresses (port set). As for examples, IMHO, SIP server option and
[Med] This is doable using option 21. The name can be resolved to an IPv6 or an IPv4 address. Nothing prevent from doing so.

NTP server option are potential customers for this usage.
[Med] This is doable using dhcpv6. Why the use dhpv4-over-dhcpv6 is a must?

There may be more, because demands are arising with time going on.
[Med] I’m still not seeing any particular demand which cannot be honored using dhcpv6.

[Qi] We are talking about IPv6-enabled node in IPv4/IPv6 transition period, when IPv4 and IPv6 services are coexisted. Using DHCPv4-over-DHCPv6 can guarantee all DHCP-based services to be configured correctly.

[Med] What are those services? Why those services cannot be configured using DHCPv6? Before designing a solution, we need understand the requirements and the needs first.

Of course, in IPv6 only Internet where there is no demand for IPv4 services, we should use DHCPv6. But DHCPv4-over-DHCPv6 can also work in this case.

[Med] … except that dhcpv4-over-dhcpv6 introduces more complexity for not obvious reasons.

Best Regards,
Qi

Cheers,
Med

>De : Qi Sun [mailto:[email-masked]<mailto:[email-masked]>]
>Cc : Tomek Mrugalski; [email-masked]<mailto:[email-masked]>; Softwires ([email-masked]<mailto:[email-masked]>)
>On 2013-4-12, at 下午7:47, <[email-masked]<mailto:[email-masked]>>
><[email-masked]<mailto:[email-masked]>> wrote:
>
>> Dear all,
>>
>>> De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part
>de
>>> Tomek Mrugalski
>>> À : [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 15 Apr 2013 09:50:41 +0000

>This looks very good. I would favour adoption, 

+1.

Sheng

>but I would really like

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 15 Apr 2013 10:02:57 +0000

I agree with Med. In reality, it is highly unlikely that each and every Dhcpv4 option would be needed for an ipv6 only host.

And the ones that are really needed,  would better move to dhcvpv6 sooner than later. It would be prudent for us to do find the delta instead of carrying over the legacy and getting the relevant ones fixed. Or has that work been done already?

Cheers,
Rajiv

Sent from my Phone

On Apr 15, 2013, at 5:36 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Re-,

Please see inline.

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>; Softwires ([email-masked]<mailto:[email-masked]>)

Dear Med,

Please see inline.

Best Regards,
Qi

Cheers,
Med

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Simon Perreault <[email-masked]>
Date: Mon, 15 Apr 2013 14:18:43 +0200

Le 2013-04-15 12:02, Rajiv Asati (rajiva) a écrit :
> I agree with Med. In reality, it is highly unlikely that each and every
> Dhcpv4 option would be needed for an ipv6 only host.

Sure we can expect that today with the information we have at our 
disposal. But what will we do if in the future the situation changes, 
for whatever unanticipated reason, and we need more IPv4 options? 
Assuming we won't need more makes it very easy to paint ourselves into a 
corner.

Simon

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 14:57:36 +0200

Hi Simon,

(cced softwire ML as this topic is of the interest of the wg too. This draft cannot be discussed without having the problem space to solve in mind)

With all due respect, complexifying the design because of a speculated need of IPv4-centric options in the future is not a valid argument IMHO.

RFC6333 is a typical example of a solution which shows we don't need at all DHCPv4 to offer IPv4 service continuity.

As discussed in http://datatracker.ietf.org/doc/draft-ietf-softwire-unified-cpe/, very few parameters in addition to DS-Lite ones are needed to be configured to support MAP and LW4over6. Those few parameters can be packaged in one single DHCPv6 option and we are done.

Cheers,
Med

>Simon Perreault
>Envoyé : lundi 15 avril 2013 14:19
>À : [email-masked]
>Objet : Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-
>over-dhcpv6
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 15 Apr 2013 12:58:19 +0000

We must also consider all of the other infrastructure that already exists for DHCPv4 that the proposed approach is able to leverage - failover, dns updates, leasequery, etc. All of this would require significant rework if these things were part of DHCPv6. By using the existing v4 server engine (except for injecting and sending packets), all that infrastructure comes for free.

You also get similar benefits on the client side since the DHCPv4 client code is being used pretty much intact.

- Bernie

On Apr 15, 2013, at 6:03 AM, "Rajiv Asati (rajiva)" <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Rajiv

Sent from my Phone

Re-,

Please see inline.

Cheers,
Med

Dear Med,

Please see inline.

Best Regards,
Qi

Cheers,
Med

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Apr 2013 13:35:03 +0000

> Why in the future, an IPv6-enabled node will require to retrieve configuration using DHCPv4-over-DHCPv6 and not directly using DHCPv6?

That's exactly the point, Med.   We are attempting to separate out legacy solutions that continue to require native IPv4 from those that can survive entirely on IPv6, which we expect in the long run to be the vast majority.   The point is simply to say that if you want to configure your IPv4 stack with DHCP, you should, in general, continue to use DHCPv4.

There is general agreement that it's pretty harmless, and also quite efficient, to provision MAP-E-based solutions using DHCPv6, as long as all they need from the DHCP server is their MAP prefix/port set configuration.   But we are trying to keep the camel's nose from coming any further under the tent by explicitly saying how you do any additional provisioning of the IPv4 stack, should you need to do so.

This document also addresses the problem of doing _stateful_, as opposed to _stateless_ IPv4 address configuration for dual-stack nodes on an IPv6-only network with IPv4 tunneling to AFTRs.   In that case, again, the required extensions to DHCPv6 would be large, and it's actually pretty convenient to just leverage the DHCPv6 infrastructure to carry protocol messages to a DHCPv4 server, which already knows how to do dynamic IPv4 address allocation.

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 15:49:31 +0200

Hi Ted,

I'm afraid there is no camel at all...and only a mirage in a desert.

Cheers,
Med

>De : Ted Lemon [mailto:[email-masked]]
>Envoyé : lundi 15 avril 2013 15:35
>Cc : Qi Sun; [email-masked]; Softwires ([email-masked])
>That's exactly the point, Med.   We are attempting to separate out legacy
>solutions that continue to require native IPv4 from those that can survive
>entirely on IPv6, which we expect in the long run to be the vast majority.
>The point is simply to say that if you want to configure your IPv4 stack
>with DHCP, you should, in general, continue to use DHCPv4.
>
>There is general agreement that it's pretty harmless, and also quite
>efficient, to provision MAP-E-based solutions using DHCPv6, as long as all
>they need from the DHCP server is their MAP prefix/port set configuration.
>But we are trying to keep the camel's nose from coming any further under
>the tent by explicitly saying how you do any additional provisioning of the
>IPv4 stack, should you need to do so.
>
>This document also addresses the problem of doing _stateful_, as opposed to
>_stateless_ IPv4 address configuration for dual-stack nodes on an IPv6-only
>network with IPv4 tunneling to AFTRs.   In that case, again, the required
>extensions to DHCPv6 would be large, and it's actually pretty convenient to
>just leverage the DHCPv6 infrastructure to carry protocol messages to a
>DHCPv4 server, which already knows how to do dynamic IPv4 address
>allocation.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Apr 2013 13:53:50 +0000

On Apr 15, 2013, at 5:35 AM, <[email-masked]<mailto:[email-masked]>> wrote:
some service providers and services may remain in IPv4 for some time, while end users may demand these IPv4 services to be delivered over IPv6. The required info may be more than IPv4 addresses (port set). As for examples, IMHO, SIP server option and
[Med] This is doable using option 21. The name can be resolved to an IPv6 or an IPv4 address. Nothing prevent from doing so.

Exactly right.   DHCPv4-over-DHCPv6 is _not_ a must if you have a working IPv6 service infrastructure and are using stateless prefix mapping for IPv4 transport.   Your home gateway can even answer DNS queries it receives on the local network over IPv4 by doing the lookups directly to the DNS server over IPv6—there is no reason at all why a configuration like this requires any DHCPv4 configuration options at all, even though it's supporting IPv4 in the home.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Apr 2013 13:55:18 +0000

On Apr 15, 2013, at 6:02 AM, "Rajiv Asati (rajiva)" <[email-masked]<mailto:[email-masked]>> wrote:
And the ones that are really needed,  would better move to dhcvpv6 sooner than later. It would be prudent for us to do find the delta instead of carrying over the legacy and getting the relevant ones fixed. Or has that work been done already?

Why would _any_ be needed?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Apr 2013 14:09:11 +0000

> I'm afraid there is no camel at all...and only a mirage in a desert.

This is not a technical argument.

In any case, if there is a mirage, it does no harm, because you aren't required to use it if you are just doing straightforward MAP-E, right?

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 16:27:39 +0200

Ted, 

Are you saying MAP is not a concerned with this draft and dhcpv6 can be used for MAP?

Cheers,
Med

>Envoyé : lundi 15 avril 2013 16:09
>In any case, if there is a mirage, it does no harm, because you aren't
>required to use it if you are just doing straightforward MAP-E, right?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Apr 2013 14:38:54 +0000

> Are you saying MAP is not a concerned with this draft and dhcpv6 can be used for MAP?

For configuring the MAP-E prefix and port set, yes.   That was the discussion we had in Softwires in Orlando: cover the easy stuff with DHCPv6 (this is the existing DHCPv6 MAP option), and then if someone needs legacy IPv4 services or stateful address allocation, do it with DHCPv4-over-DHCPv6.

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 16:47:55 +0200

Re-,

Thanks for clarifying Ted. I must admit this is not what I understood when I read draft-scskf-*.

Does the same conclusion applies also for lw-4over6? (I'm naively assuming, given the approach defined in draft-ietf-softwire-unified-cpe, the same dhcpv6 to configure MAP will also be used lw-4over6)

Cheers,
Med

>Envoyé : lundi 15 avril 2013 16:39
>For configuring the MAP-E prefix and port set, yes.   That was the
>discussion we had in Softwires in Orlando: cover the easy stuff with DHCPv6
>(this is the existing DHCPv6 MAP option), and then if someone needs legacy
>IPv4 services or stateful address allocation, do it with DHCPv4-over-
>DHCPv6.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Apr 2013 14:51:43 +0000

> Does the same conclusion applies also for lw-4over6? (I'm naively assuming, given the approach defined in draft-ietf-softwire-unified-cpe, the same dhcpv6 to configure MAP will also be used lw-4ove…

I think if you're using a purely deterministic mapping, you can do lw4over6 with just the DHCPv6 option.   For deployments where dynamic allocation is desired, then you need DHCPv4-over-DHCPv6.

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 16:55:38 +0200

Hi Med,

It would still work for lw-4o6 and the unified CPE. All of the basic
params for configuring lw4o6/MAP1:1 can be provisioned through the
OPTION_MAP_BIND that is proposed in the unified CPE draft over DHCPv6.
Additional DHCPv4 only options would be done via the DHCPv4oDHCPv6 method
for both lw4o6 and MAP-E.

We still need to agree on which option will be used for provisioning the
address of the lwAFTR/MAP BR, however. There was some discussion on this
on the SW ML last week, but no conclusion reached.

Cheers,
Ian

On 15/04/2013 16:47, "[email-masked]"
<[email-masked]> wrote:

>Does the same conclusion applies also for lw-4over6? (I'm naively
>assuming, given the approach defined in draft-ietf-softwire-unified-cpe,
>the same dhcpv6 to configure MAP will also be used lw-4over6)
>
>Cheers,
>Med
>
>[email-masked]

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 17:01:42 +0200

Re-,

As the situation is now much more clearer for the static/deterministic mapping, let us focus on the dynamic allocation case.

What would prevent a dhcpv6 server to manipulate IPv4 addresses + port range as IPv4-mapped IPv6 prefixes for instance?

Cheers,
Med

>Envoyé : lundi 15 avril 2013 16:52
>I think if you're using a purely deterministic mapping, you can do lw4over6
>with just the DHCPv6 option.   For deployments where dynamic allocation is
>desired, then you need DHCPv4-over-DHCPv6.

---

From: Qi Sun <[email-masked]>
Date: Mon, 15 Apr 2013 22:16:14 +0800

Dear Rajiv,

If all the required information / parameters are moved to DHCPv6 & IPv6, that means the customers and providers of those services have migrated to IPv6. However, that is not the situation. Customers and service providers would remain in IPv4 for some time (transition period). What's more, it is not quite clear for now which ones are really needed. So it's hard to decide which options to be / not to be moved to DHCPv6. 

In this case, original DHCPv4 engine will handle all the DHCPv4-related parameters. So that I think DHCPv4-over-DHCPv6 is needed.

Best Regards,
Qi Sun

On 2013-4-15, at 下午6:02, Rajiv Asati (rajiva) wrote:

> On Apr 15, 2013, at 5:36 AM, "[email-masked]" <[email-masked]> wrote:
> 
>> Re-,
>>  
>> Please see inline.
>>  
>> Cheers,
>> Med
>>

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 17:13:57 +0200

Hi Ian,

Thanks for the clarification.
I understood from your answer: dhcpv6 will be used for both MAP and lw4over6 and both don't require draft-scskf-* for IP address + port provisioning.

Given currently no additional dhcpv4 only options is required for any of the solutions we are discussing in softwire, I do still think it is not justified to take on a solution for a problem which may not exist.

draft-scskf-* proposal can be revived when there is a real need to support dhcpv4-only options. No?

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]]
>Envoyé : lundi 15 avril 2013 16:56
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]
>Cc : [email-masked]; [email-masked]; [email-masked]
>Objet : Re: [Softwires] [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-
>over-dhcpv6
>
>Hi Med,
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Apr 2013 15:16:03 +0000

> What would prevent a dhcpv6 server to manipulate IPv4 addresses + port range as IPv4-mapped IPv6 prefixes for instance?

This would be sort of easy to do as a hack on the client, I guess.   Unless you mean to have the server stuff this information into the MAP option, of course.   But that would be really weird—the MAP option isn't stateful.   So essentially you're talking about a new stateful extension to DHCPv6, on the lines of RFC3633.   That's a really heavyweight solution to this problem.

---

From: <[email-masked]>
Date: Mon, 15 Apr 2013 17:52:37 +0200

Re-,

Thanks for the explanations.

I suggest the document to be updated to reflect the clarifications you provided and also the ones provided by Ian and Ted for MAP and Lw4over6 cases. These are important inputs.

I withdraw my objection to his document.

Thank you all for your patient explanations.

Cheers,
Med

>Envoyé : lundi 15 avril 2013 17:47
>Cc : [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>In MAP-E pure stateless mode, IPv4 address (prefix) and port set are
>provisioned in MAP Rules as designed. But in MAP-E 1:1 mode and lw4over6
>which are (kind of) stateful, it has to take into considerations about the
>lease time etc. issues. In this case, IMHO, DHCPv4 over DHCPv6 is more
>suitable for IPv4 related configurations.
>
>What's more, DHCPv4-over-DHCPv6 is not only designed to deal with the
>option issues, but also to handle other architectural problems in
>transition (as Bernie mentioned in previous mail). So I think DHCPv4-over-
>DHCPv6 is helpful for the evolvement in DHCP architecture.
>
>
>Best Regards,
>Qi Sun
>
>
>On 2013-4-15, at 下午11:13, <[email-masked]>
>> I understood from your answer: dhcpv6 will be used for both MAP and
>lw4over6 and both don't require draft-scskf-* for IP address + port
>provisioning.
>>
>> Given currently no additional dhcpv4 only options is required for any of
>the solutions we are discussing in softwire, I do still think it is not
>justified to take on a solution for a problem which may not exist.
>>
>>>>>> Are you saying MAP is not a concerned with this draft and dhcpv6 can
>be
>>>>> used for MAP?
>>>>>

---

From: Qi Sun <[email-masked]>
Date: Mon, 15 Apr 2013 23:46:31 +0800

Dear Med,

In MAP-E pure stateless mode, IPv4 address (prefix) and port set are provisioned in MAP Rules as designed. But in MAP-E 1:1 mode and lw4over6 which are (kind of) stateful, it has to take into considerations about the lease time etc. issues. In this case, IMHO, DHCPv4 over DHCPv6 is more suitable for IPv4 related configurations. 

What's more, DHCPv4-over-DHCPv6 is not only designed to deal with the option issues, but also to handle other architectural problems in transition (as Bernie mentioned in previous mail). So I think DHCPv4-over-DHCPv6 is helpful for the evolvement in DHCP architecture. 

Best Regards,
Qi Sun

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 15 Apr 2013 19:27:09 +0000

Med,

I agree we can talk more motivations in the draft. However,
draft-scskf-dhc-dhcpv4-over-dhcpv6 discusses a generic specification of
DHCPv4 over DHCPv6. I am not sure what we want to mention specific to MAP
or lw4over6 in this draft.

Thanks,
Yiu

On 4/15/13 11:52 AM, "[email-masked]"
<[email-masked]> wrote:

>I suggest the document to be updated to reflect the clarifications you
>provided and also the ones provided by Ian and Ted for MAP and Lw4over6
>cases. These are important inputs.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 15 Apr 2013 22:11:12 +0000

This might be where draft-rajtar-dhc-v4configuration comes in? We still need to determine what to do about that draft at some point - I think the plan was to update it sometime after adopting this work to include it and also documenting the "consensus".

We'll need to take a look at the full set of documents we might need.

I think we need to be clear that DHCPv6 is NEVER supposed to assign and manage specific IPv4 addresses. We want that to be done via DHCPv4.

MAP is different in that the DHCPv6 server is not explicitly assigning / managing any IPv4 addresses (or port space). The client derives its IPv4 address using the information in the MAP option (which is the same set of bits for many clients) and its IPv6 address. This is a significant difference. And, it does restrict what other 'services' (such as DNS registration) the DHCPv6 needs to do (and the client can be provided) in terms of IPv4. In the MAP case this also makes sense as there isn't one client behind the address (as the port space is shared).

And, also why other cases are likely to be different and need more of DHCPv4 - as DNS and more may be needed to provide the complete IPv4 support over IPv6.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lee, Yiu
Sent: Monday, April 15, 2013 3:27 PM
To: [email-masked]; Qi Sun
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6

Med,

I agree we can talk more motivations in the draft. However,
draft-scskf-dhc-dhcpv4-over-dhcpv6 discusses a generic specification of
DHCPv4 over DHCPv6. I am not sure what we want to mention specific to MAP or lw4over6 in this draft.

Thanks,
Yiu

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Apr 2013 22:34:00 +0000

> This might be where draft-rajtar-dhc-v4configuration comes in? We still need to determine what to do about that draft at some point - I think the plan was to update it sometime after adopting this…

The thought was that we would publish it as Informational, since it's certainly not intended to be deployed by anyone in the future, but has seen some deployment already because some sites needed something to use for early deployment, and this was a pretty easy thing to implement.   The document would have a big "informational only—do not deploy" pasted on it so that nobody gets the wrong idea.

Of course, the working group could also just decide to drop it—I' replying here to tell you what I recall from discussions we had in Orlando, not to tell you what to do.

---

From: <[email-masked]>
Date: Tue, 16 Apr 2013 07:39:31 +0200

Hi Yiu,

Ted and Ian provided an important clarification on the applicability scope of draft-scskf-*. IMHO, this should be recorded in the draft not only in mailing list archives.

Having an applicability scope section in that draft would be useful.

Cheers,
Med

>De : Lee, Yiu [mailto:[email-masked]]
>Envoyé : lundi 15 avril 2013 21:27
>À : BOUCADAIR Mohamed OLNC/OLN; Qi Sun
>Cc : [email-masked]; [email-masked]

---

From: Branimir Rajtar <[email-masked]>
Date: Tue, 16 Apr 2013 07:41:27 +0000

Hi,

Just a short info on the the draft-rajtar work. Ian and I have been watching closely the discussions here (with Ian taking the more active role) and we're updating the draft accordingly. We hope to be able the publish the new draft which will include dhcp4-over-dhcp6 and some other changes later this week and make a call for adoption. We feel that Ted's approach of "informational-only" is the way to go.

BR,
Branimir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, April 16, 2013 12:34 AM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]; Qi Sun; Lee, Yiu
Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6

> This might be where draft-rajtar-dhc-v4configuration comes in? We still need to determine what to do about that draft at some point - I think the plan was to update it sometime after adopting this…

The thought was that we would publish it as Informational, since it's certainly not intended to be deployed by anyone in the future, but has seen some deployment already because some sites needed something to use for early deployment, and this was a pretty easy thing to implement.   The document would have a big "informational only-do not deploy" pasted on it so that nobody gets the wrong idea.

Of course, the working group could also just decide to drop it-I' replying here to tell you what I recall from discussions we had in Orlando, not to tell you what to do.

<HTML><P><FONT face=Arial color=#999999 size=1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadržaj ove poruke i eventualno priloženih datoteka je povjerljiv i namijenjen je samo osobama ili subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku greškom, molimo Vas, obavijestite pošiljatelja, a poruku i sve njene privitke odmah, bez čitanja, trajno uklonite s računala. Bilo kakvo prenošenje, kopiranje ili distribucija informacija sadržanih u poruci trećim osobama je zabranjeno i može biti zakonski kažnjivo. Sadržaj, stavovi i mišljenja izneseni u poruci su autorovi i ne predstavljaju nužno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaća nikakvu odgovornost za eventualnu štetu nastalu primitkom ove poruke i priloga sadržanih u poruci.

</FONT></P><P><FONT face=Arial color=#999999 size=1>

 DISCLAIMER:The contents of this email as well as any files attached to it are confidential and intended solely for individuals or entities which they are addressed to. If you have received this email message in error, please notify the sender and permanently remove the message and all attached files from the computer. Any disclosure, copying or distribution of all or a part of information contained herein to or by third parties is prohibited and may be unlawful. Please note that any views or opinions presented in this message are solely those of the author and do not necessarily represent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts no liability for any potential damage caused by this message and files attached to it.

</FONT></P></HTML>

---

From: "Yuchi Chen" <[email-masked]>
Date: Tue, 16 Apr 2013 16:41:10 +0800

Hi Med and Yiu,

I agree with you, and also I think it's better if not any specific solution is mentioned in draft-scskf-*, as this draft is meant to be a general solution. Maybe the clarification on applicability scope could be like this: "this solution is most recommended for dynamic IPv4 allocation and IPv4 param provisioning". We can add a section to say that, or just say that in the Introduction section as the supplement of the motivation statement (i.e. "In addition to providing IPv4 addresses for clients of this service, other IPv4 configuration parameters may also need to be provided ...").

Best regards!

Yuchi Chen 

From: [email-masked]
Date: 2013-04-16 13:39
To: Lee, Yiu; Qi Sun
CC: [email-masked]; [email-masked]
Subject: Re: [Softwires] [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6
Hi Yiu,

Cheers,
Med

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Apr 2013 14:41:05 +0000

> Just a short info on the the draft-rajtar work. Ian and I have been watching closely the discussions here (with Ian taking the more active role) and we're updating the draft accordingly. We hope to…

<ad hat off>
The new draft looks good.   I did not have time to review all the pros and cons, but I like the new table with evaluation criteria.   BTW, I think this draft should be BCP—I was referring to the DHCPv4-over-IPv6 draft regarding informational status.   Sorry for the confusion.

---

From: Qiong <[email-masked]>
Date: Wed, 17 Apr 2013 16:50:17 +0800

+1 support. I think this work is quite useful.

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Branimir Rajtar <[email-masked]>
Date: Wed, 17 Apr 2013 09:07:37 +0000

+1 as well

BR,
Branimir

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qiong
Sent: Wednesday, April 17, 2013 10:50 AM
To: Tomek Mrugalski
Cc: [email-masked]
Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6

Best wishes
Qiong
On Thu, Apr 4, 2013 at 1:40 AM, Tomek Mrugalski <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Regards,
Bernie & Tomek

Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
===============================================

</FONT></P></HTML>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Apr 2013 13:02:26 +0000

<ad hat off>I also support adoption.</>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 17 Apr 2013 14:10:50 +0000

Dear all,
I support the adoption.

Thank you,
Tina

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 18 Apr 2013 07:59:10 -0700

> <ad hat off>I also support adoption.</>
<chair hat off>I also support adoption.</>

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 18 Apr 2013 23:03:24 -0700

> objections in your response. This adoption call will complete on
This adoption call deadline has passed. I'm very happy that we had a
healthy discussion with many useful comments posted. Most comments were
supporting adoption. There were two objections (one was later
withdrawn). This means that the WG has reached a strong consensus to
adopt this work.

Authors, please upload this work as draft-ietf-dhc-dhcpv4-over-dhcpv6-00
once you address all received comments.

Bernie & Tomek

---

From: Marcin Siodelski <[email-masked]>
Date: Fri, 26 Apr 2013 17:18:02 +0200

> once you address all received comments.

Thanks to everybody who have taken time to review this document and
shared comments. We tried to address comments from the adoption call
period and the uploaded -00 version includes relevant changes. In
particular:

1) Rename the document draft-ietf-dhc-dhcpv4-over-dhcpv6-00
2) Add some text in Introduction section about the motivation and scope
3) Add a paragraph in Section 6 about the use of IPv6 interface
4) Add some text in Section 8 to clarify what a 'DHCPv4 server engine'
is, and specify the related discussions are out of scope.
5) Rewrite Section 9 (Security Considerations)
6) Move RFC2119 to the list of Normative References

All further comments regarding the latest version of this document are
appreciated.

Links:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-00

Cheers,
Marcin