Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th

From: <[email-masked]>
Date: Mon, 6 May 2013 14:28:19 +0200

Nearly missed that. I'm in favor to adopt this I-D as a WG item.

If I remember right, there has been a large discussion at last IETF about different approaches to provide IPv4 parameters over IPv6-only capable access networks and my feeling was that
- this topic has been of huge interest for the DHCP community and is targeted to real world scenarios
- this I-D provides a good evaluation of the existing mechanisms for DHCP provisioning of IPv4 parameters in IPv6 only networks
- there is still some work to do regarding the conclusions and recommendations.
What else is needed to become a WG item?

Regards	
	Olaf

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Tomek Mrugalski
Gesendet: Mittwoch, 24. April 2013 18:37
An: [email-masked]
Betreff: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th

Hi all,

This draft is an attempt to summarize the alternatives regarding IPv4 hosts configuration in IPv6-only network. If adopted, it will eventually document DHC recommendation for the stated problem. Currently there is no conclusion stated in the text. The plan is to first see if the WG wants to work on this issue. If the answer is yes, then we will try to reach a consensus on what should the recommendation be. That will be done only after this draft is adopted.

As requested by the authors, we are announcing adoption call on draft-rajtar-dhc-v4configuration-02. 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 favour of the adoption by replying to this mail. If you are not in favour, please also state your objections in your response. This adoption call will conclude after 2013-05-08.

This adoption call is about whether we as a working group want to work on this problem and ultimately make a recommendation. It is not about picking specific technology for IPv4 hosts configuration in IPv6 networks at that time.

Background info:

This issue was extensively discussed during Orlando meeting. Couple useful things came out of it: DHCPv4-over-DHCPv6 draft that documents what looked like a consensus in the meeting room (adopted couple days ago), a new draft that documents relay behaviour when receiving unknown messages (also adopted recently), and draft-rajtar-dhc-v4configuration received an update to reflect the latest developments.

This draft went through an adoption call couple months ago, but it then had a conclusion that pointed out toward a solution that was undefined at that time. The (somewhat premature) conclusion was promptly removed, but it was too late to stop a heated discussion.

Regards,
Bernie & Tomek
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 06 May 2013 15:36:03 +0200

> What else is needed to become a WG item?
Support from members of the WG as a response to the adoption call. So
far we have only a single support voice - yours (+ mine, see below).

Please keep in mind that while you may have raised your support for this
work before (during previous discussions on perhaps in WG meeting), you
need to explicitly state in adoption call.

I'm supporting adoption of this I-D as a WG item.

Ok, so there are 2 in favor now. That's still not enough.

Tomek

p.s.
This adoption call was announced on April 24th and was planned to last 2
weeks (until May 8th). This time has already passed. Olaf (and myself)
are the only support voices so far. That is not nearly enough to have
this work adopted. If you want this work to be adopted, please say so! A
simple "I favor adoption" is sufficient. If you don't support adoption,
please also say so and explain your objections.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 May 2013 13:51:31 +0000

> Ok, so there are 2 in favor now. That's still not enough.

AD hat off, I support this document.

---

From: <[email-masked]>
Date: Mon, 6 May 2013 16:01:22 +0200

+1 support.

Ian

On 06/05/2013 14:28, "Bonneß, Olaf" <[email-masked]> wrote:

>If I remember right, there has been a large discussion at last IETF about
>different approaches to provide IPv4 parameters over IPv6-only capable
>access networks and my feeling was that
>- this I-D provides a good evaluation of the existing mechanisms for DHCP
>provisioning of IPv4 parameters in IPv6 only networks
>This draft is an attempt to summarize the alternatives regarding IPv4
>hosts configuration in IPv6-only network. If adopted, it will eventually
>document DHC recommendation for the stated problem. Currently there is no
>conclusion stated in the text. The plan is to first see if the WG wants
>to work on this issue. If the answer is yes, then we will try to reach a
>consensus on what should the recommendation be. That will be done only
>after this draft is adopted.
>
>As requested by the authors, we are announcing adoption call on
>draft-rajtar-dhc-v4configuration-02. 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 favour of the adoption by replying
>to this mail. If you are not in favour, please also state your objections
>in your response. This adoption call will conclude after 2013-05-08.
>
>This adoption call is about whether we as a working group want to work on
>this problem and ultimately make a recommendation. It is not about
>picking specific technology for IPv4 hosts configuration in IPv6 networks
>at that time.
>
>Background info:
>
>This issue was extensively discussed during Orlando meeting. Couple
>useful things came out of it: DHCPv4-over-DHCPv6 draft that documents
>what looked like a consensus in the meeting room (adopted couple days
>ago), a new draft that documents relay behaviour when receiving unknown
>messages (also adopted recently), and draft-rajtar-dhc-v4configuration
>received an update to reflect the latest developments.
>
>This draft went through an adoption call couple months ago, but it then
>had a conclusion that pointed out toward a solution that was undefined at
>that time. The (somewhat premature) conclusion was promptly removed, but
>it was too late to stop a heated discussion.
>
>Regards,
>Bernie & Tomek

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 6 May 2013 22:04:09 +0800

I also support this adoption.

Qiong

Sent from my iPad

---

From: Qi Sun <[email-masked]>
Date: Mon, 6 May 2013 22:02:33 +0800

Dear all,

I support the adoption of the document.

Best Regards,
Qi

On 2013-4-25, at 上午12:36, Tomek Mrugalski wrote:

> document DHC recommendation for the stated problem. Currently there is
> no conclusion stated in the text. The plan is to first see if the WG
> wants to work on this issue. If the answer is yes, then we will try to
> reach a consensus on what should the recommendation be. That will be
> done only after this draft is adopted.
> 
> confirm whether there is WG consensus to adopt this work as DHC WG
> draft. Please state whether or not you're in favour of the adoption by
> replying to this mail. If you are not in favour, please also state your
> objections in your response. This adoption call will conclude after
> 2013-05-08.
> 
> This adoption call is about whether we as a working group want to work
> on this problem and ultimately make a recommendation. It is not about
> picking specific technology for IPv4 hosts configuration in IPv6
> networks at that time.
> 
> Background info:
> 
> had a conclusion that pointed out toward a solution that was undefined
> at that time. The (somewhat premature) conclusion was promptly removed,
> but it was too late to stop a heated discussion.
> 
> Regards,
> Bernie & Tomek
> 
> On 23.04.2013 23:23, [email-masked] wrote:
>> Just in case you missed it, a new version of
>> draft-rajtar-dhc-v4configuration (02) was recently posted.
>> 
>> As this version incorporates the new DCHPv4 over DHCPv6 model described
>> in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and other changes
>> based on the discussions in Orlando, the authors would like request that
>> the WG chairs make a call for adoption based.
>> 
>> Cheers,
>> Ian
>> 
>> 
>> 
>> 
>>

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 6 May 2013 10:19:13 -0400

I am in favor of adopting this draft as a work item.

Regards -- Kim

---

From: Branimir Rajtar <[email-masked]>
Date: Mon, 6 May 2013 14:21:26 +0000

I also support the document.

Branimir

<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: Vízdal Aleš <[email-masked]>
Date: Mon, 6 May 2013 22:59:51 +0200

+1 to support adoption of this document.

Cheers,
Ales

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek
> Mrugalski
> Sent: Wednesday, April 24, 2013 6:37 PM
> To: [email-masked]
> Subject: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by
> May 8th
> 
> Hi all,
> 
> This draft is an attempt to summarize the alternatives regarding IPv4 hosts
> configuration in IPv6-only network. If adopted, it will eventually document DHC
> recommendation for the stated problem. Currently there is no conclusion stated in the
> text. The plan is to first see if the WG wants to work on this issue. If the answer is
> yes, then we will try to reach a consensus on what should the recommendation be.
> That will be done only after this draft is adopted.
> 
> As requested by the authors, we are announcing adoption call on draft-rajtar-dhc-
> v4configuration-02. 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
> favour of the adoption by replying to this mail. If you are not in favour, please also
> state your objections in your response. This adoption call will conclude after 2013-05-
> 08.
> 
> This adoption call is about whether we as a working group want to work on this
> problem and ultimately make a recommendation. It is not about picking specific
> technology for IPv4 hosts configuration in IPv6 networks at that time.
> 
> Background info:
> 
> This issue was extensively discussed during Orlando meeting. Couple useful things came
> out of it: DHCPv4-over-DHCPv6 draft that documents what looked like a consensus in
> the meeting room (adopted couple days ago), a new draft that documents relay
> behaviour when receiving unknown messages (also adopted recently), and draft-rajtar-
> dhc-v4configuration received an update to reflect the latest developments.
> 
> This draft went through an adoption call couple months ago, but it then had a
> conclusion that pointed out toward a solution that was undefined at that time. The
> (somewhat premature) conclusion was promptly removed, but it was too late to stop a
> heated discussion.
> 
> Regards,
> Bernie & Tomek
> 
> > As this version incorporates the new DCHPv4 over DHCPv6 model
> > described in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and
> > other changes based on the discussions in Orlando, the authors would
> > like request that the WG chairs make a call for adoption based.
> >
> > Cheers,
> > Ian
> >
> >
> >
> >
> >

---

From: Tina TSOU <[email-masked]>
Date: Tue, 7 May 2013 06:12:59 +0000

Dear all,
I support the adoption.

Thank you,
Tina

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 07 May 2013 14:46:01 +0200

I support adoption of this document.

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 May 2013 13:51:55 +0000

Hi:

1. (WG co-chair hat off:) I support adopting this document as a working group work item.

2. (WG co-chair hat on): If you have not expressed support or opposition for adopting this work, the call expires today!

- Bernie

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 09 May 2013 12:10:48 +0200

> 2. (WG co-chair hat on): If you have not expressed support or opposition for adopting this work, the call expires today!
Hi,

Although this adoption call looked a bit grim for the first 10 days,
large support voiced in the last couple days saved the day. We have
around a dozen support voices, which means that this I-D was adopted.

Authors, please upload it as draft-ietf-dhc-v4configuration-00. Once
that is done, I encourage authors to start a discussion about
recommendation that the WG wants to offer.

It is a pleasure to see such a strong consensus. Let's hope that the
discussion about writing Conclusion section will have equally strong
consensus.

Bernie & Tomek

---

From: Branimir Rajtar <[email-masked]>
Date: Wed, 15 May 2013 09:26:13 +0000

Hi all, 

Following on Tomek's e-mail and the upload of draft-ietf-dhc-v4configuration-00, the authors would like to start the discussion on it's conclusion. Following the talk on the mailing list, our proposal is as follows:

"Whilst all of the approaches described here will require some development work in order to realize, it is clear from the above analysis that the most sustainable approach capitalizes on existing DHCPv4 implementations and include them as new DHCPv6 message types.  The main rationale for this is that it enables all of DHCPv4's existing options to be migrated for use over IPv6 in a single step.

Porting of all necessary DHCPv4 options to DHCPv6 would require ongoing development work, re-implementing existing DHCPv4 functionality in DHCPv6.  This will result in having legacy DHCPv4 options in DHCPv6, which will no longer be useful once IPv4 is completely abandoned.
 
Therefore, the DHCPv6 approach is not suitable for delivering IPv4 configuration parameters in an efficient, ongoing manner.
 
The dynamical leasing of IPv4 addresses is fundamental to the efficient use of remaining IPv4 resources. This will become increasingly important in the future, so a mechanism which supports this is necessary. DHCPv4oSW does not provide this function and so is not recommended.

The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6 functionality) for all deployment scenarios, even when DHCPv4 specific functionality is not required by the operator.

Therefore, this memo recommends DHCPv4oDHCPv6 <I-D.ietf-dhc-dhcpv4-over-dhcpv6> as the best underlying approach for provisioning IPv4 parameters over an IPv6 only network."

Also, we propose two changes to the document itself which we find should better reflect the overview of all proposals:
1. Section 3, requirement no. 6 - should be "No" for DHCPv4o6 
1. Section 3, requirement no. 1 - should be "No" for DHCPv4oSW

BR,
Branimir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Thursday, May 09, 2013 12:11 PM
To: [email-masked]
Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - adopted!

Hi,

Bernie & Tomek

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 May 2013 12:27:53 +0000

<ad hat off>I think this text is good.</-hat>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 May 2013 13:04:57 +0000

Yes, I concur (with dhc co-chair hat off).

I think section 3.3.2 has mistakes ... It misses changing relays to relay the new messages (but perhaps it assumes that the unknown messages draft has already been implemented). And it is really the dhcpv4 client that needs to change to send / receive the new messages (#2 says dhcpv6 clients).

One issue which is more for the actual draft on this method is how does dhcpv4 client determine to do this (send over v6) rather than attempt normal dhcpv4 - or perhaps client tries both methods at same time? But that's likely an issue for all if the techiques.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 May 2013 13:13:55 +0000

> One issue which is more for the actual draft on this method is how does dhcpv4 client determine to do this (send over v6) rather than attempt normal dhcpv4 - or perhaps client tries both methods at…

This is worth documenting, if it's not clear in the draft: the DHCPv4 client knows to do this because it's not a DHCPv4 client—it's a DHCPv4-over-DHCPv6 client.   So it just assumes that DHCPv4-over-DHCPv6 is available and tries to use it; if it succeeds, it is available, and if it fails, it's not.   It might additionally be worth talking about when it decides to try: when it notices a device on the homenet trying to use IPv4 to access an off-network service, or does it do it as soon as it comes up?

I guess we really haven't talked about how this works—with DHCPv4-over-IPv6, we'd intended to add a DHCPv6 option with the IP address of the DHCPv4-over-IPv6 server, but with DHCPv4-over-DHCPv6 that's not necessary.

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 15 May 2013 16:42:44 +0100

> <ad hat off>I think this text is good.</-hat>
+1 (with my chair hat off)

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 15 May 2013 16:51:05 +0100

On 13-05-15 14:13, Ted Lemon wrote:
> I guess we really haven't talked about how this works—with
> DHCPv4-over-IPv6, we'd intended to add a DHCPv6 option with the IP
> address of the DHCPv4-over-IPv6 server,
There was a draft about providing IPv6 address of the DHCPv4-over-IPv6
server that I wrote together with Peng Wu. Since the DHCPv4-over-IPv6 is
no longer the recommended solution, I let it expire. There is currently
no plan to revive that work.

> but with DHCPv4-over-DHCPv6 that's not necessary.
That's another advantage of DHCPv4-over-DHCPv6 compared to DHCPv4-over-IPv6.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 May 2013 17:54:50 +0000

Maybe this relates to the sunset4 discussion ... A dhcpv6 option could say use dhcpv4-over-dhcpv6.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 May 2013 18:09:45 +0000

> Maybe this relates to the sunset4 discussion ... A dhcpv6 option could say use dhcpv4-over-dhcpv6.

Yup, or a DHCPv4 option could say "DHCPv4 not supported."

---

From: <[email-masked]>
Date: Thu, 16 May 2013 08:54:22 +0200

Hi,

Having thought about this a bit over the last few days, specifically in
relation to softwire, this is where I'Ve got to.

There are 3 possible options for a softwire client's IPv4 configuration:

1) Static IPv4 address & ports obtained from DHCPv6 (OPTION_MAP etc)
2) Dynamic IPv4 & ports (+ optional addition DHCPv4 conf.) obtained from
DHCPv4overDHCPv6

3) Static IPv4 address & ports obtained from DHCPv6 (OPTION_MAP etc) +
additional DHCPv4 config. obtained from DHCPv4overDHCP6

Therefore, if we used a separate DHCPv6 option to convey that
DHCPv4overDHCPv6 configuration should be attempted, the client logic can
work out what it's meant to be doing by whether it receives its IPv4
config from an OPTION_MAP sub-option only (1), gets the DHCPv4overDHCPv6
config option only (2) or gets both (3).

This also means that a non-softwire DHCPv4overDHCPv6 client (should one
appear in the future) can just use the DCHPv4overDHCPv6 without needing
any OPTION_MAP logic.

As for the what such a DHCPv4overDHCPv6 option could contain, I think that
there could be some advantages in being able to (optionally) provision the
client with a /128 address for the DHCPv4overDHCPv6 server (as the old
Tomek/Peng draft described). This could work as follows:

* If the /128 field for the DHCPv4over6 server is empty, then the client
uses multicast configuration is used as normal
* If the prefix is present, then the client uses this address as unicast

The reason for this is around the separation of DHCPv4 and DHCPv6
configuration. At the moment the DHCPv4 over DHCPv6 draft uses an update
to DHCPv6 relays so messages can be relayed to a different DHCP server. As
the client needs to be updated to implement the function anyway (and the
relay is not adding anything useful in the configuration process), having
the possibility of letting the client make the decision (and a way of
provisioning the client with what to do) seems like it could be a good
idea. It also means that DHCPv6 relays don't need to be updated, which
seems cleaner.

Cheers,
Ian

On 15/05/2013 19:54, "Bernie Volz (volz)" <[email-masked]> wrote:

>>> One issue which is more for the actual draft on this method is how
>>>does dhcpv4 client determine to do this (send over v6) rather than
>>>attempt normal dhcpv4 - or perhaps client tries both methods at same
>>>time? But that's likely an issue for all if the techiques.
>> 
>> This is worth documenting, if it's not clear in the draft: the DHCPv4
>>client knows to do this because it's not a DHCPv4 client‹it's a
>>DHCPv4-over-DHCPv6 client.   So it just assumes that DHCPv4-over-DHCPv6
>>is available and tries to use it; if it succeeds, it is available, and
>>if it fails, it's not.   It might additionally be worth talking about
>>when it decides to try: when it notices a device on the homenet trying
>>to use IPv4 to access an off-network service, or does it do it as soon
>>as it comes up?
>> 
>> I guess we really haven't talked about how this works‹with
>>address of the DHCPv4-over-IPv6 server, but with DHCPv4-over-DHCPv6
>>that's not necessary.
>>

---

From: Branimir Rajtar <[email-masked]>
Date: Thu, 16 May 2013 07:27:17 +0000

>It also means that DHCPv6 relays don't need to be updated, which
seems cleaner.

This would also resolve Bernie's comment about the need to include a "con" for DHCPv4-over-DHCPv6 saying that relays have to be updated as well.

Also, I think his comment that DHCPv6 clients are not the ones that should change, but DHCPv4 clients, is valid and I propose to change it the next version of the draft.

Branimir

On 15/05/2013 19:54, "Bernie Volz (volz)" <[email-masked]> wrote:

>>client knows to do this because it's not a DHCPv4 client<it's a
>> I guess we really haven't talked about how this works<with

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 May 2013 12:51:05 +0000

> This would also resolve Bernie's comment about the need to include a "con" for DHCPv4-over-DHCPv6 saying that relays have to be updated as well.

I think that would have to be restricted to "broken relays may need to be fixed," because relays _really_ shouldn't be dropping unknown message types, even though 3315 never _required_ them not to.

---

From: Qi Sun <[email-masked]>
Date: Sun, 19 May 2013 11:15:34 +0800

I also think the text seems good.

Best Regards,
Qi Sun

---

From: Qi Sun <[email-masked]>
Date: Sun, 19 May 2013 11:31:17 +0800

I notice in DHCPv6 based provisioning, it doesn't mention the DHCPv6 server is required to manage IPv4 address while a DHCPv6 client is responsible to configure IPv4 stack. These changes would live with DHCPv6 if one used this set of mechanisms. DHCPv4oSW also has the same issue (IPv4 address & port set are provisioning in DHCPv6 option), while DHCPv4oDHCPv6 doesn't for it's the DHCPv4 client that takes the job.

Is it necessary to consider this?

Best Regards,
Qi

---

From: Qi Sun <[email-masked]>
Date: Mon, 20 May 2013 00:15:56 +0800

Dear Ted,

> This is worth documenting, if it's not clear in the draft: the DHCPv4 client knows to do this because it's not a DHCPv4 client—it's a DHCPv4-over-DHCPv6 client.   So it just assumes that DHCPv4-over-DHCPv6 is available and tries to use it; if it succeeds, it is available, and if it fails, it's not. 

Yes, we should make it specific on how the client knows to use DHCPv4-over-DHCPv6.

> It might additionally be worth talking about when it decides to try: when it notices a device on the homenet trying to use IPv4 to access an off-network service, or does it do it as soon as it comes up?

IMHO, this is necessary to document. As for the two proposals, I think the second one would be more appropriate. The clients won't conflict: DHCPv6 client will get an IPv6 address/a prefix from the Unified server, DHCPv4-over-DHCPv6 client will get an IPv4 address from the Unified server, and DHCPv4 client won't work (for there is no IPv4 transmission network uplink). 
The first one requires the client to be aware of requests behind the homegateway. Would that complex the client's logic/function?

Best Regards,
Qi Sun

---

From: Qi Sun <[email-masked]>
Date: Mon, 20 May 2013 00:17:19 +0800

Dear all,

> I think that would have to be restricted to "broken relays may need to be fixed," because relays _really_ shouldn't be dropping unknown message types, even though 3315 never _required_ them not to.

Yes. I think this is what the unknown message draft (draft-ietf-dhc-dhcpv6-unknown-msg-00) documents, which intends to update RFC3315. 

BTW, should we include draft-ietf-dhc-dhcpv6-unknown-msg-00 as a reference in the DHCPv4-over-DHCPv6 draft?

Best Regards,
Qi

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 May 2013 16:31:10 +0000

> The first one requires the client to be aware of requests behind the homegateway. Would that complex the client's logic/function?

The problem with the first way is that it means that every DHCPv4-over-DHCPv6 gateway will always try to acquire an IPv4 configuration, even if the CPE network has no IPv4-only devices on it, and accesses no IPv4-only services.   So there will be no way to shut off IPv4 service for CPE networks that don't require it.

On the other hand, as you say, to make the client acquire IPv4 connectivity only when a CPE device tries to use it is more complicated, and may even be impossible to do correctly.

I do not have an easy answer to this question.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 May 2013 16:31:27 +0000

> BTW, should we include draft-ietf-dhc-dhcpv6-unknown-msg-00 as a reference in the DHCPv4-over-DHCPv6 draft?

I think that would make sense, yes.

---

From: Cong Liu <[email-masked]>
Date: Mon, 20 May 2013 17:54:48 +0800

Hi Branimir,

In section 1.5 and 3.3.2, should "separation of DHCPv4 and DHCPv4
provisioning" be "separation of DHCPv4 and DHCPv6 provisioning"?

I'm confused with requirement no. 4. Does it mean separated DHCPv4/DHCPv6
server devices, or separated IPv4/IPv6 address provisioning process, or
separated IPv4 address/other options provisioning process?

Best Regards,
Cong

==============================================
Cong Liu
Tsinghua University

2013/5/15 Branimir Rajtar <[email-masked]>

> Hi all,
>
> Following on Tomek's e-mail and the upload of
> draft-ietf-dhc-v4configuration-00, the authors would like to start the
> discussion on it's conclusion. Following the talk on the mailing list, our
> proposal is as follows:
>
> "Whilst all of the approaches described here will require some development
> work in order to realize, it is clear from the above analysis that the most
> sustainable approach capitalizes on existing DHCPv4 implementations and
> include them as new DHCPv6 message types.  The main rationale for this is
> that it enables all of DHCPv4's existing options to be migrated for use
> over IPv6 in a single step.
>
> Porting of all necessary DHCPv4 options to DHCPv6 would require ongoing
> development work, re-implementing existing DHCPv4 functionality in DHCPv6.
>  This will result in having legacy DHCPv4 options in DHCPv6, which will no
> longer be useful once IPv4 is completely abandoned.
>
> Therefore, the DHCPv6 approach is not suitable for delivering IPv4
> configuration parameters in an efficient, ongoing manner.
>
> The dynamical leasing of IPv4 addresses is fundamental to the efficient
> use of remaining IPv4 resources. This will become increasingly important in
> the future, so a mechanism which supports this is necessary. DHCPv4oSW does
> not provide this function and so is not recommended.
>
> The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6
> functionality) for all deployment scenarios, even when DHCPv4 specific
> functionality is not required by the operator.
>
> Therefore, this memo recommends DHCPv4oDHCPv6
> <I-D.ietf-dhc-dhcpv4-over-dhcpv6> as the best underlying approach for
> provisioning IPv4 parameters over an IPv6 only network."
>
> Also, we propose two changes to the document itself which we find should
> better reflect the overview of all proposals:
> > 2. (WG co-chair hat on): If you have not expressed support or opposition
> for adopting this work, the call expires today!
> Hi,
>
> 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.
>
>  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: Branimir Rajtar <[email-masked]>
Date: Wed, 22 May 2013 08:45:33 +0000

Hi,

I think this is actually already covered - the draft says about keeping IPv4 and IPv6 domains separate and I would say that a lot of significance is put on that. However, looking at the your comment and other comments from the working group, I think I should expand on it and put some more explanations in the next version.

BR,
Branimir

-----Original Message-----
From: Qi Sun [mailto:[email-masked]] 
Sent: Sunday, May 19, 2013 5:31 AM
To: Branimir Rajtar
Cc: Ted Lemon; [email-masked] WG; Bernie Volz (volz)
Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00

Best Regards,
Qi

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

---

From: Branimir Rajtar <[email-masked]>
Date: Wed, 22 May 2013 08:50:54 +0000

Hi,

My comments are inline...

Branimir

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cong Liu
Sent: Monday, May 20, 2013 11:55 AM
To: Branimir Rajtar
Cc: [email-masked]
Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00

Hi Branimir,

In section 1.5 and 3.3.2, should "separation of DHCPv4 and DHCPv4 provisioning" be "separation of DHCPv4 and DHCPv6 provisioning"?

[BR] You're right, it's a typo - I'll fix it for the next version.

I'm confused with requirement no. 4. Does it mean separated DHCPv4/DHCPv6 server devices, or separated IPv4/IPv6 address provisioning process, or separated IPv4 address/other options provisioning process?

[BR] It actually means all of them :) We wanted the solution to be as flexible as possible for the operator so it can be deployed in whatever scenario the operator wishes. I will expand this requirement in the next version of the draft.

Best Regards,
Cong

2013/5/15 Branimir Rajtar <[email-masked]<mailto:[email-masked]>>
Hi all,

BR,
Branimir

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Thursday, May 09, 2013 12:11 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - adopted!

Hi,

Bernie & Tomek

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

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

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