Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01

From: Rémi Després <[email-masked]>
Date: Fri, 1 Jun 2012 09:59:29 +0200

2012-05-30 15:55, Ole Trøan:

> public 4over6 is exactly the same as MAP in hub and spoke mode with one mapping rule per subscriber.

Could you clarify how this relates to the MAP-rule definition saying "Each MAP node in the domain has the same set of rules".
(draft-mdt-softwire-mapping-address-and-port-03)

RD

> and if Reinaldo is correct, also the same as b4-translated-ds-lite.
> 
> we have 4 mechanisms doing almost the exact same thing (4rd, MAP, 4over6, B4-translated).
> 
> I would suggest that we do not progress this document now, but pass it through the same review process that 4rd/MAP is going through. unless we can reach consensus on pruning prior to that.
> 
> cheers,
> Ole
> 
>> This is a wg last call on draft-ietf-softwire-public-4over6-01.
>> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/
>> 
>> As usual, please send editorial comments to the authors and
>> substantive comments to the mailing list.
>> 
>> This wg last call will end on 2012 June 10 at 12pm EDT.
>> 
>> 
>> Yong & Alain
>> 
>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/softwires
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Ole Trøan <[email-masked]>
Date: Fri, 1 Jun 2012 10:45:30 +0200

> (draft-mdt-softwire-mapping-address-and-port-03)

you can look at it as if each subscriber has his own MAP domain.

cheers,
Ole

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Mon, 4 Jun 2012 01:52:47 +0000

Support for moving to the next step.

Cheers
Yu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yong Cui
Sent: Sunday, May 27, 2012 10:31 PM
To: [email-masked]
Cc: Yong Cui
Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01

Hi folks,

Yong & Alain

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 4 Jun 2012 14:34:23 +0000

Hi Ole,

AFAIK, this will couple the IPv4 address and IPv6 prefix. This isn't the
requirement for Public 4over6.

Thanks,
Yiu

On 6/1/12 4:45 AM, "Ole Trøan" <[email-masked]> wrote:

>> Could you clarify how this relates to the MAP-rule definition saying
>>"Each MAP node in the domain has the same set of rules".

---

From: Ole Trøan <[email-masked]>
Date: Mon, 4 Jun 2012 20:06:31 +0200

Yiu,

> requirement for Public 4over6.

with MAP you may embed parts of the IPv4 address into the IPv6 prefix and optionally a PSID.
the remaining bits are provisioned with DHCP (or something else). how many bits you embed and how many bits you provision are an operational choice.

if you move those levers to the end, with no embedded bits, with all bits provisioned, then you effectively have Public 4over6. no dependency between IPv4 and IPv6, as the IPV4 address is provisioned in the MAP DHCP option, independent of the IPv6 end user prefix. this implies one mapping rule or domain per tunnel (same amount of state as public 4over6 of course).

is that still MAP, given that you don't have address mapping anymore? well, who knows, but my point was that you can achieve Public 4over6 with MAP.

I didn't intend to put a spanner in the works of Public 4over6. it just occurred to me as I was looking at Public and Lightweight 4over6, as extensions to DS-lite. that we're basically talking about the exact same thing. the differences between the solutions, when we're talking about the hub and spoke 1:1 case (independence between IPv4 and IPv6 addresses), is how they are provisioned. MAP, DS-lite, Lightweight 4over6 and Public 4over6 are all equal when it comes to the amount of state on both sides as well as the bits on the wire.

do we want 3-4 'point' mechanisms specified separately or do we want one mechanisms with multiple 'modes'?

cheers,
Ole

---

From: Qiong <[email-masked]>
Date: Thu, 7 Jun 2012 16:17:57 +0800

Hi Ole,

>From the draft-ietf-softwire-stateless-4v6-motivation, the definition of
"Stateless 4/6 solution" is as follows:

Stateless 4/6 solution denotes a solution which does not require any
per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP
address sharing function in the Service Provider's network. This category
of solutions assumes a dependency between an IPv6 prefix and IPv4 address.

I think it clearly explained the motivation of MAP and 4rd, and this is
what we are seeking for in the design of any stateless solution.

If public 4over6 is one extreme case of MAP, in which one subscriber
represents one MAP domain, then should we also say that DS-Lite is another
extreme case of MAP, where one application (session) represents one MAP
domain ?

I think we should still keep the initial feature of these solutions.

Best wishes
Qiong

On Tue, Jun 5, 2012 at 2:06 AM, Ole Trøan <[email-masked]> wrote:

> the remaining bits are provisioned with DHCP (or something else). how many
> bits you embed and how many bits you provision are an operational choice.
>
> if you move those levers to the end, with no embedded bits, with all bits
> provisioned, then you effectively have Public 4over6. no dependency between
> IPv4 and IPv6, as the IPV4 address is provisioned in the MAP DHCP option,
> independent of the IPv6 end user prefix. this implies one mapping rule or
> domain per tunnel (same amount of state as public 4over6 of course).
>
> is that still MAP, given that you don't have address mapping anymore?
> well, who knows, but my point was that you can achieve Public 4over6 with
> MAP.
>
> I didn't intend to put a spanner in the works of Public 4over6. it just
> occurred to me as I was looking at Public and Lightweight 4over6, as
> extensions to DS-lite. that we're basically talking about the exact same
> thing. the differences between the solutions, when we're talking about the
> hub and spoke 1:1 case (independence between IPv4 and IPv6 addresses), is
> how they are provisioned. MAP, DS-lite, Lightweight 4over6 and Public
> 4over6 are all equal when it comes to the amount of state on both sides as
> well as the bits on the wire.
>

---

From: Ole Trøan <[email-masked]>
Date: Thu, 7 Jun 2012 10:48:59 +0200

Qiong,

> If public 4over6 is one extreme case of MAP, in which one subscriber represents one MAP domain, then should we also say that DS-Lite is another extreme case of MAP, where one application (session) represents one MAP domain ?  

a DS-lite AFTR could be represented by the combination of a MAP BR with per subscriber rules combined with a NAT44. there is a reason we started out calling MAP for "Stateless DS-lite".

> I think we should still keep the initial feature of these solutions.

all the proposed solutions, including DS-lite shares a large set of commonalities. where the differences are more operational considerations and deployment choices than technical differences. do we need a separate protocol specification for each deployment choice?

cheers,
Ole

---

From: Peng Wu <[email-masked]>
Date: Thu, 7 Jun 2012 22:04:40 +0800

Hi Ole and all,

Thank you all for the discussions on this topic, as well as sharing
your opinions during the offline discussions in the last couple of
days. Let me try to summarize.

I understand that we MAY adapt MAP to be 4over6-like, or even DS-lite
with more changes. It's actually a very interesting proposal. However,
in my understanding, the advantage of MAP is built on its
statelessness, with of cost of v4-v6 address coupling. If we mandate
MAP to further include the features of 4over6/DS-lite, we lose its
original generality: it's no longer stateless, the motivation document
won't work; GMA algorithm is no longer needed, no rule provisioning
anymore; we enforce a big bindng table on MAP BR. These are somehow
signifcant changes in implmentaton and deployement.

Now there are actually 3 directions for IPv4-over-IPv6 mechanisms,
they have respective application scenarios, pros and cons.
1)stateless,  4rd, MAP
2)per-flow stateful: DS-Lite
3)per-user stateful: public 4over6, lightweight 4over6
As Ole said, the problem is that, do we want serveral simple
mechanisms, or one super-compatible mechanism with different modes.

Now Given that a) the WG has accomplished DS-lite; b)MAP follows the
stateless motivation all along the way; c)The signifcant changes to
make MAP super-compatible, I vote for we define the third type,
per-user stateful mechanisms independently.

Cheers,
Peng

---

From: Qiong <[email-masked]>
Date: Thu, 7 Jun 2012 22:23:40 +0800

Hi Ole,

On Thu, Jun 7, 2012 at 4:48 PM, Ole Trøan <[email-masked]> wrote:

> all the proposed solutions, including DS-lite shares a large set of
> commonalities. where the differences are more operational considerations
> and deployment choices than technical differences. do we need a separate
> protocol specification for each deployment choice?
>

I vote for describing the protocol specifications for different
scenarios seperately.
Although they have some commonalities, there are still quite a lot of
differences from techincal details for their own features. As we currently
have three categories of solutions,  I think it will be easier and clearer
for readers to understand each solution in seperated document.

Best wishes
Qiong

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Jun 2012 19:33:41 +0200

Qiong, all,

Le 2012-06-07 à 16:23, Qiong a écrit :

> I vote for describing the protocol specifications for different scenarios seperately.

+1
Also considering that:
- Draft-ietf-softwire-public-4over6-01 has already reached a WG document status, and needs AFAIK no technical change to become an RFC
- It has no dependency on 4rd or MAP 
- There is even one more solution with different scope but commonality, namely 464XLAT currently discussed in v6ops

Regards,
RD

> Although they have some commonalities, there are still quite a lot of differences from techincal details for their own features. As we currently have three categories of solutions,  I think it will be easier and clearer for readers to understand each solution in seperated document.
> 
> Best wishes
> Qiong
>     
> 
> cheers,
> Ole
> 
> 
> 
>

---

From: Ole Trøan <[email-masked]>
Date: Fri, 8 Jun 2012 09:43:23 +0200

Peng,

> per-user stateful mechanisms independently.

actually there are no significant changes to the MAP specification, the per-user stateful mechanism is just intrinsically supported by MAP. it is a corner case, and it would be more work in the specification to "ban" this operational mode, than to support it.

btw, one thing that appears most complicated is provisioning; currently it looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to get provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, then a DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchange to get the IPv4 address, and then a new DHCPv4 option to get the port set. that seems to me to be quite a few moving parts, and quiet a few corner cases to be specified when one or more of the above fails. in MAP you do all of that with one single DHCPv6 option...

cheers,
Ole

---

From: Peng Wu <[email-masked]>
Date: Fri, 8 Jun 2012 17:35:35 +0800

Ole,

> btw, one thing that appears most complicated is provisioning; currently it looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to get provisioned. firstly a RFC6334 exchange to get…

Let me make it more precise.

In lw 4over6, It's one DHCPv6 exchange and one DHCPv4 exchange.
DHCPv6 exchange to get the concentrator address and DHCPv4 server
address, two options at the same time. And of course the DHCPv4 server
could be collocated with the concentrator.
DHCPv4 exchange to retrieve the address and port-set at the same time.

Now compared with MAP:
1) Concentrator address is also needed in provisioning.
2) DHCPv4 server address. This is only used when we want to separate
DHCPv4 server from the concentrator (For HA, redundancy...). With MAP
you cannot do this separation.
3) DHCPv4 is used to provision the address and port-set to the
intiator. Now with MAP you provide this as a rule in DHCPv6. That's
the most significant difference

So, I don't see lw4over6 provisioning more complicated than MAP...

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 8 Jun 2012 13:44:16 +0200

Peng,

On 8 June 2012 11:35, Peng Wu <[email-masked]> wrote:

> Ole,
>
>
> > btw, one thing that appears most complicated is provisioning; currently
> it looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to
> get provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up,
> then a DHCPv6 option for the DHCPv4 server address, and then a DHCPv4
> exchange to get the IPv4 address, and then a new DHCPv4 option to get the
> port set. that seems to me to be quite a few moving parts, and quiet a few
> corner cases to be specified when one or more of the above fails. in MAP
> you do all of that with one single DHCPv6 option...
>

Yes, because MAP doesn't require one to use another component like DHCPv4
which is in itself subject to failure. That said, MAP can also use DHCPv4,
but quite honestly what's the point of running DHCPv4 when all the useful
info is available via DHCPv6?

> So, I don't see lw4over6 provisioning more complicated than MAP...

Current MAP = operating DHCPv6
l24over6 =  operating DHCPv4 and DHCPv6 +  mechanisms to get to the DHCPv4
server over IPv6
There appears to be some evident complication there, for no clear benefit.

-Woj.

---

From: Rémi Després <[email-masked]>
Date: Fri, 8 Jun 2012 14:36:13 +0200

Peng,

> they have respective application scenarios, pros and cons.

Thank you for having not forgotten that 4rd and MAP are on equal footing in Softwire, something that seems to be forgotten more than needed on this discussion thread. 

Incidentally, while the WG draft on 4rd has been available since May 16, the MAP specification, which was claimed in Paris to be well stabilized, already tested, and urgent to be published, is still not available as a WG draft. I therefore believe that discussing relationship between MAP and/or 4rd and 4over6 would be more useful when an up-to-date MAP specification is available.

In any case, I renew my support for Public 4over6 to progress autonomously.

Regards,
RD

---

From: Peng Wu <[email-masked]>
Date: Fri, 8 Jun 2012 22:01:59 +0800

Woj,

On Fri, Jun 8, 2012 at 7:44 PM, Wojciech Dec <[email-masked]> wrote:
>> > corner cases to be specified when one or more of the above fails. in MAP you
>> > do all of that with one single DHCPv6 option...
>>
[Peng] PLEASE NOTE that I'm talking about concentrator/BR HA rather
than DHCPv4 server HA. It applies to both lw 4over6 and MAP, as long
as you want to implement per-user stateful mode by MAP

> info is available via DHCPv6?
[Peng] You can use DHCPv6 in lw 4over6, too. We list it in the draft
as a provisioning possibility. We explicitly use a DHCPv6 port-set
option, while you use a MAP rule. But that's not the point.

> There appears to be some evident complication there, for no clear benefit.
[Peng] Well, the information amount are the same, with the MAP form a
little difficult to understand from today's view, honestly.
DHCPv4 is chosen because evidently we are provision IPv4 information,
and we keep IPv4 and IPv6 addressing separated.
In my understanding, the story in original MAP/4rd is because of the
algorithmic mapping, you provision IPv4 address/port along with IPv6
address. Now you are talking about provison IPv4 as a rule. That's not
exactly the same.
Another question is that, how do you configure the rules in DHCPv6
now that it's per-user specific, and you do not have address mapping?
Relay all DHCPv6 messages to BR and generate the rules dynamically
there? I guess that's not a feature in original MAP.

I want to say that, please develop your understanding on this problem
from the fundamental per-user stateful feature, rather than directly
from MAP, a solution initially not designed for this case. That's not
fair.

---

From: Ole Trøan <[email-masked]>
Date: Fri, 8 Jun 2012 18:31:39 +0200

Remi,

> Incidentally, while the WG draft on 4rd has been available since May 16, the MAP specification, which was claimed in Paris to be well stabilized, already tested, and urgent to be published, is stil…

since you specifically bring it up.
the MAP draft was posted on June 1, and we are awaiting the softwire chairs to approve it as a -00 softwire document.

I expect they are busy as everyone else, but Alain promised to get to it today.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 8 Jun 2012 18:52:50 +0200

> I expect they are busy as everyone else, but Alain promised to get to it today.

Thanks.
RD

---

From: Qi Sun <[email-masked]>
Date: Sat, 9 Jun 2012 11:35:31 +0800

Hi Ole,

In your previous Email you wrote,
> in MAP you do all of that with one single DHCPv6
option...

IMHO, that's because the one DHCPv6 option contains so many KINDS of
information (e.g. PSID, BR's prefix or address, see draft of
map-dhcp-option ).

And with separate provisoning processes , it's easier to detect
problems if the whole process fails.

Best Regards!

Qi Sun

On 6/8/12, Ole Trøan <[email-masked]> wrote:
> actually there are no significant changes to the MAP specification, the
> per-user stateful mechanism is just intrinsically supported by MAP. it is a
> corner case, and it would be more work in the specification to "ban" this
> operational mode, than to support it.
>
> btw, one thing that appears most complicated is provisioning; currently it
> looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to get
> provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, then a
> DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchange to
> get the IPv4 address, and then a new DHCPv4 option to get the port set. that
> seems to me to be quite a few moving parts, and quiet a few corner cases to
> be specified when one or more of the above fails. in MAP you do all of that
> with one single DHCPv6 option...
>
> cheers,
> Ole

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 11 Jun 2012 10:56:43 +0200

> problems if the whole process fails.

Disagree: Figuring out what went wrong in DHCPv6 acquisition followed by
DNS resolution to get the DHCPv4 server address, followed by DHCPv4
relaying, followed by DHCPv4 acquisition, has multiple levels of not easy
to detect failuires.

-Woj.

> it

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 11 Jun 2012 11:10:24 +0200

There is basic question regarding this draft, one that has also been raised
at previous WG meetings: "why is it needed?".
I do not think this draft should progress before a thorough review of this
space. We do not need another form of a classic dual stack "transition"
architecture!
Also, at best this draft is an informational one as opposed to standards
track.

There is a deeper issue here: This draft seems to give the impression that
running such a regular public addressed DHCPv4 based overlay on IPv6 is a
simple idea, as opposed to native dual stack. It is anything but, given
that a) it it requires changes to DHCPv4 processing b) it introduces non
trivial dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires
changes to CPE d) makes life really a mess if we consider a real dual stack
CPE.

-Woj.

---

From: Peng Wu <[email-masked]>
Date: Tue, 12 Jun 2012 02:38:38 +0800

Woj,

> at previous WG meetings: "why is it needed?".
It's actually written in section 4 of the draft.

> simple idea, as opposed to native dual stack. It is anything but, given that
Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar
to scenario of DS-Lite and MAP/4rd.
I thought the assumption of IPv4-over-IPv6 is that you cannot/do not
want to provision native dual-stack?

> a) it it requires changes to DHCPv4 processing b) it introduces non trivial
> dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires changes to
> CPE d) makes life really a mess if we consider a real dual stack CPE.
a) Simply make DHCPv4 work with IPv6 as underlying transport. No
essential changes to protocol processing.
b) What really matters here is provisioning the IPv4 address through
DHCPv4. Just like in MAP/4rd, you provision the address through
DHCPv6.
In pb4over6 DHCPv6 is only an *option* to provide the concentrator
address. You have similar logic too in MAP.
So I don't think it's "non trivial dependancy". They are similar
functions for all IPv4-over-IPv6 mechanisms that need provisioning,
only different technical paths.
c) Any IPv4-over-IPv6 mechanism requires change to CPE

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 12 Jun 2012 11:52:46 +0200

Peng,

On 11 June 2012 20:38, Peng Wu <[email-masked]> wrote:

> that

To put it simply: This draft describes a scenario where public v4 addresses
are available. The "classic" v6 migration scenario is in this case "dual
stack" and is what I believe has been advised for years by the IETF, and
continues to be the recommended approach. Why would one want to run in this
case dual-stack over a tunnel infra is the question? Is this intended as an
academic draft (as in "we can do it, but don't know why")?

> essential changes to protocol processing.

Woj> That's not what the draft DHCPv4overv6 indicates, unless one assumes a
very specific and limiting deployment scenario. In any case it's quite
clear that it is not possible to use regular DHCPv4 clients for this, or a
regular DHCPv4 server (there is no mention of how the broadcast flags
should be handled, mapped to IPv6, etc).

> only different technical paths.

There are several components/parts that all need to play together in this
solution, many more than apparently required, and the failure of one is not
obvious to anyone looking at another. As in any such multi-part system
design, the overall complexity is higher.

> c) Any IPv4-over-IPv6 mechanism requires change to CPE

Yes, but in the case of this draft, the changes that are proposed do not
lead to anything over and above what plain dual stack accomplishes, except
extra complexity.

---

From: Peng Wu <[email-masked]>
Date: Wed, 13 Jun 2012 12:36:53 +0800

Woj,

> academic draft (as in "we can do it, but don't know why")?
[Peng] That's not always the case. Now to be more precise, with pb 4over6
1.Concentrator can be in a high position, and we don't have to IPv4 every where
2.Provision IPv4 in a flexible, on-demand way
3.It can be deployed along with DS-lite to provide a value-added service
These points are already written in the draft

> very specific and limiting deployment scenario. In any case it's quite clear
> that it is not possible to use regular DHCPv4 clients for this, or a regular
> DHCPv4 server (there is no mention of how the broadcast flags should be
> handled, mapped to IPv6, etc).
[Peng]Actually we can use regular DHCPv4 client, with the help of a
CRA function planted on the same host, that's a very fundamental point
of the DHCPv4over6v6 draft.
Server side need modification, yes. But only on the step of
sending/receiving DHCP messages (sockets). That's what I wanted to
express in last mail.
FYI, it only uses IPv6 unicast, with the aid of CRA.

> design, the overall complexity is higher.
Sorry but I simply don't buy that it's *significant* more complexity.
As to failure, it's more like a sequencial rather than " the failure
of one is not obvious to anyone looking at another". If I cannot get
the concentrator or the DHCPv4 server address, I stop the rest steps.

> lead to anything over and above what plain dual stack accomplishes, except
See above

Cheers~

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 14 Jun 2012 15:07:08 +0200

Peng,

your answers do not address the key concerns:
- Why is this needed, besides that it can be done, as opposed to classic
dual stack?
- It requires changes to the client/relay, thus it cannot be simply used
with regular DHCPv4 implementations (note: it doesn't matter that you're
putting a CRA element, that's an implementation detail). It is thus
invesement in legacy IPv4 technology, not migration to IPv6.
- It is more complicated to get through failures, to anyone who looks at it
all objectively (Basic example: A dhcpv4 user will have no idea that the
failure to get an ipv4 address is because in the
CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is returning a wrong
AAAA for some host name that happens to be a dhcpv4 server, or because
dhcpv6 is not providing the right option or name).
- DHCPv4 servers need to be modified to take into account IPv6.

-Woj.

On 13 June 2012 06:36, Peng Wu <[email-masked]> wrote:

> >> > running such a regular public addressed DHCPv4 based overlay on IPv6
> is
> >> > a
> clear

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 15 Jun 2012 02:51:26 +0000

Hi Woj,

Let me try to answer some of your questions:

From:  Wojciech Dec <[email-masked]>
Date:  Thursday, June 14, 2012 9:07 AM
To:  Peng Wu <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, Yong Cui
<[email-masked]>
Subject:  Re: [Softwires] WG last call on
draft-ietf-softwire-public-4over6-01

Peng,

[YL]  The scenario is addressing IPv6-only access network. If the access
network is DS, yes, you don't need this technology.

[YL] AFAIK, the client won't change but will require CRA. This technology is
to support legacy v4 service while migrating to IPv6. The client will have
both v4 and v6 addresses. This is given. So I fail to see why this is only
an investment in legacy IPv4 technology.

[YL] I am sorry, I can't follow this. Can you explain more please?

[YL] Yes or we need to deploy TRA.

Thanks,
Yiu

-Woj.

is
>>>> >> > a
>>>> >> > simple idea, as opposed to native dual stack. It is anything but, >>>>
given

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 15 Jun 2012 12:42:37 +0200

Lee,

On 15 June 2012 04:51, Lee, Yiu <[email-masked]> wrote:

> Cc: "[email-masked]" <[email-masked]>, Yong Cui <
> [email-masked]>
>

Woj> This draft proposes using public IPv4 addressing to deliver a dual
stack service to the end-user. Even on a future IPv6-only network, in the
selective cases where such a dual stack service is to be offered, using
existing IPv4 functionality, one that all operators use today, that is
mature, and requires NO client or server or relay changes, is way simpler
than investing in new intricate functionality.
I see this scheme directly leading into changing this scenario to one of
IPv4 address sharing, which brings this work into direct overlap with other
work in softwires.
As such I can only re-iterate what I said before; IMO we need a thorough
review of this solution space, including this draft, before progressing.

> [YL] AFAIK, the client won't change but will require CRA. This technology
> is to support legacy v4 service while migrating to IPv6. The client will
> have both v4 and v6 addresses. This is given. So I fail to see why this is
> only an investment in legacy IPv4 technology.
>

Woj> The fact that there is a CRA means a client change, or a CPE change.
The fact that you call it CRA, and not DHCP-client change, even though this
function is specific to DHCPv4, does not change that fact.

>
> - It is more complicated to get through failures, to anyone who looks at
> it all objectively (Basic example: A dhcpv4 user will have no idea that the

Woj> The sequence of events leading to a client acquiring a v4 address is
complex and not intuitive to anyone who deals with DHCPv4. There are
numerous points at which the whole thing could fail even before dhcpv4.

-Woj.

---

From: Qi Sun <[email-masked]>
Date: Sat, 16 Jun 2012 15:17:29 +0800

Hi Woj,

     Please see inline.

> than investing in new intricate functionality.

[Qi]Because it is difficult for the operators to deploy native dual stack
in such a short period when the IPv4 address resource is running out, here
comes stateful mechanisms DS-lite and pb4over6 to solve the transition
problems, with/without CGN on the AFTR/concentrator. IMHO, they do not
compete with native dual stack for the reason above.

> IPv4 address sharing, which brings this work into direct overlap with other

[Qi] Pb4over6 is a stateful mechanism without CGN. It's different from
other work.

> [Qi] IMO we should progress the draft, instead of blocking the IPv4/IPv6
transition progress.

>> [Qi] CRA is short for Client Relay Agent. AFAIK, we don't take DHCP relay
agent as a change to DHCP server, but a separate part. So I'm not sure if
it's proper to call CRA a client change.

> numerous points at which the whole thing could fail even before dhcpv4.

[Qi]  I think you ignored a fact that the DHCPv4 server is likely to be
collocated with the concentrator, as Peng stated before.  IMHO , in MAP,
you put many kinds of information in one DHCPv6 option. The client and CPE
need to be modified to pick out what they need. And there are some other
process to make the mechanism work. I think it is not simpler than pb4over6.

>>> >> > There is a deeper issue here: This draft seems to give the
>>> impression
>>> >> > that
>>> >> > running such a regular public addressed DHCPv4 based overlay on
>>> IPv6 is
>>> >> > a

---

From: Wojciech Dec <[email-masked]>
Date: Sat, 16 Jun 2012 11:25:19 +0200

Qi,

> compete with native dual stack for the reason above.

This statement confirms all the concerns regarding this draft; it mentiones
IPv4 address run-out in the context of a draft whose sole purpose is to
hand out public IPv4 addresses,; it also mentions the difficulty of
deploying dual stack, yet, this draft requires IPv6 to be deployed
(presumably in existing networks) along with an IPv4 overlay too.

>> [Qi] IMO we should progress the draft, instead of blocking the IPv4/IPv6

Woj> The last thing we need is another transition mechanism, and this draft
appears to claim being one and nobody's blocking here deployment of IPv6.
As stated earlier, we need a review of the whole solution space in
softwires, rather than spin up more drafts that are of questionable use.

-Woj.

>>> [YL] AFAIK, the client won't change but will require CRA. This
>>> technology is to support legacy v4 service while migrating to IPv6. The
>>> client will have both v4 and v6 addresses. This is given. So I fail to see
>>> why this is only an investment in legacy IPv4 technology.
>>>
>>
>>> [Qi] CRA is short for Client Relay Agent. AFAIK, we don't take DHCP
> relay agent as a change to DHCP server, but a separate part. So I'm not
> sure if it's proper to call CRA a client change.
>
>
>>>> >> > There is basic question regarding this draft, one that has also
>>>> been
>>>> >> > raised

---

From: Qi Sun <[email-masked]>
Date: Sat, 16 Jun 2012 22:02:37 +0800

Hi Woj,

In your previous mail you wrote :
> This statement confirms all the concerns
regarding this draft; it mentiones IPv4 address
run-out in the context of a draft whose sole
purpose is to hand out public IPv4 addresses,; it
also mentions the difficulty of deploying dual
stack, yet, this draft requires IPv6 to be
deployed (presumably in existing networks) along
with an IPv4 overlay too.

[Qi] Operators still have IPv4 address space to assign. that's why
IPv4 Internet is still growing. And if we don't hand out IPv4 address
, how can we achieve IPv4-over-IPv6(such as DS-Lite and MAP)? And
handing out public IPv4 address can achieve e2e transparency.

In the mechanism, there are dual stack nodes, which contribute to
achieve IPv4-over-IPv6. This is different from the so called 'native'
dual stack in which every node is dual stack.

> Woj> The last thing we need is another
transition mechanism, and this draft appears to
claim being one and nobody's blocking here
deployment of IPv6.
As stated earlier, we need a review of the whole
solution space in softwires, rather than spin up
more drafts that are of questionable use.

[Qi] This mechanism has its senario which has been stated in the draft
andof previous mails. what's more, this draft is now a WG  draft , NOT
a new draft.  So I don't think it is of 'questionable' use.

Best Regards!

Qi

On 6/16/12, Wojciech Dec <[email-masked]> wrote:
>>>>> > case dual-stack over a tunnel infra is the question? Is this
>>>>> > intended
>>>>> as an
>>>>> >> > a) it it requires changes to DHCPv4 processing b) it introduces
>>>>> >> > non
>>>>> >> > trivial

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 18 Jun 2012 20:19:54 +0200

Qi,

> handing out public IPv4 address can achieve e2e transparency.

Woj> As was previously indicated there are numerous solutions in this area,
and a review of this space is needed.

> a new draft.  So I don't think it is of 'questionable' use.

Woj> The fact that this is WG draft does not mean anything except that at
some point there was interest in working on a solution to a problem.
Currently it appears that there are multiple solutions to this problem,
some perhaps more flexible and practical than others. We won't know that
until we take stock of the whole space, rather than publishing RFCs that
(in this case) IMO bring little value.

-Woj.

> >>>> it all objectively (Basic example: A dhcpv4 user will have no idea
> that
> >>>> the
> >>>>> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec <
> [email-masked]>
> >>>>> wrote:
> >>>>> >> > simple idea, as opposed to native dual stack. It is anything
> but,
> >>>>> given
> >>>>> >> > that
> >>>>> > stack" and is what I believe has been advised for years by the
> IETF,
> >>>>> and
> >>>>> >> > dependencies between DHCPv6 and DHCPv4 and tunnelling c)
> requires
> >>>>> >> > changes to
> >>>>> > that it is not possible to use regular DHCPv4 clients for this, or
> a
> >>>>> regular
> >>>>> > DHCPv4 server (there is no mention of how the broadcast flags
> should
> >>>>> be
> >>>>> > There are several components/parts that all need to play together
> in
> >>>>> this
> >>>>> > solution, many more than apparently required, and the failure of
> one
> >>>>> is not
> >>>>> > Yes, but in the case of this draft, the changes that are proposed
> do
> >>>>> not