Subject: Re: [Softwires] Path to move forward with 4rd…

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sun, 01 Apr 2012 09:38:58 +0200

On 3/31/12 4:56 PM, Rémi Després wrote:
> Alain,
>
> You had initially announced that either one specification would be
> chosen for standard track (among T, E, and U), or specifications
> would all become WG drafts on the experimental track ((*) below). In
> Paris: (a)The MAP proposal became presented as an inseparable T+E
> package. (b) The WG couldn't make a consensus choice between T+E or
> U.
>
> Now publishing both MAP-T+E and 4rd-U as WG documents on the
> experimental track, is therefore consistent with what was announced
> (and was also asked for by several at the end of the meeting). As you
> explained, this won't prevent from selecting one for standard track
> later on, based on better market experience.

Not sure that was the outcome - as I understood Alain, we'll make a 
decision here on mailinglist in a very short period of time.

Cheers, Jan

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 2 Apr 2012 03:02:03 +0900

After the meeting, I've figured out that 4rd-u define new type of transport, since it adds several new semantics in its packet format with V-octet as a helper of packet format distinguisher. That kind of work is of course out of scope of Softwire working group. I therefore suggest to the 4rd-u authors that a new BOF or a working group which named like 'unified packet format for tunneling'.

Best regards,
--satoru

On 2012/04/01, at 16:38, Jan Zorz @ go6.si wrote:

> Not sure that was the outcome - as I understood Alain, we'll make a decision here on mailinglist in a very short period of time.
> 
> Cheers, Jan
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 2 Apr 2012 03:11:57 +0900

> After the meeting, I've figured out that 4rd-u define new type of transport, since it adds several new semantics in its packet format with V-octet as a helper of packet format distinguisher. That k…

In addition, April Fool is ended at JST.

cheers,
--satoru

---

From: Maoke <[email-masked]>
Date: Mon, 2 Apr 2012 06:08:03 +0000

2012/4/1 Satoru Matsushima <[email-masked]>

> After the meeting, I've figured out that 4rd-u define new type of
> transport, since it adds several new semantics in its packet format with
> V-octet as a helper of packet format distinguisher. That kind of work is of
> course out of scope of Softwire working group. I therefore suggest to the
> 4rd-u authors that a new BOF or a working group which named like 'unified
> packet format for tunneling'.
>

+1. this is also a good way to achieve the community
understanding/acceptance of the architectural building block that 4rd-u
offers. - maoke

---

From: Wentao Shang <[email-masked]>
Date: Mon, 2 Apr 2012 14:22:37 +0800

Totally agree with Maoke.

As one of the developers for the MAP design team, I think it's unfair
to put both MAP and 4rd-u as experimental. It's good to see the
attempt to implement 4rd-u. However, any discussion about
standardization should be postponed until it is coded, deployed and
fully tested.

Regards,
Wentao

2012/4/1 Maoke <[email-masked]>:
> hi all,
>
> i listented to the softwire wg live on March 30 online and recorded my
> comments in the jabber room. as the person who was mentioned by the
> presenter not less than twice, i have to point out that it is unfair that
> the presenter mentioned me with only acknowledgment to my effort but my
> point of views. my summerized comment on 4rd-u is: it is flawed in both
> architecture and technical aspects, and now still uncertain in several
> details.
>
> it would become as a ridiculous and weird record in the  ietf history, had
> the wg made a decision of putting two as experimental, one is
> well-understood, well-coded and well-practised while the other is misleading
> the understanding on the Internet architecture, not yet coded, not yet
> tested by any operators.
>
> our company, as an ISP and as a provider doing also application services,
> including those over mobile platforms, is waiting for the MAP standard
> desirably. we have no interest in introducing the 4rd-u elements into our
> platforms.
>
> personally i won't code a stuff with obvious architectural flaws but, if i
> were believing in the 4rd-u, i would do the code and operational test with
> serious self-checking as MAP-T and MAP-E teams already have done, before
> talking on any doc-track issue with the community. this is the way of being
> responsible.
>
> thanks,
> maoke
>

-- 
Wentao Shang

Master Candidate and Research Assistant at CERNET Center & NGN Lab, EE
Department, Tsinghua University

---

From: Rémi Després <[email-masked]>
Date: Mon, 2 Apr 2012 11:04:15 +0200

Le 2012-04-01 à 00:15, Maoke a écrit :

> hi all, 
> 
> i listented to the softwire wg live on March 30 online and recorded my comments in the jabber room. as the person who was mentioned by the presenter not less than twice, i have to point out that it is unfair that the presenter mentioned me with only acknowledgment to my effort but my point of views.

I acknowledged that some of the recent progress to complete 4rd-U was due to the technical quality of our dialogue on the ML (... even if sometimes more aggressive than really needed).
I thought it was fair to say it.
Sorry if the words I used seemed unfair to you. 
Please be sure the intention was the opposite.

> my summerized comment on 4rd-u is:

> it is flawed in both architecture and technical aspects,

Which ones?

> and now still uncertain in several details.

Which ones?

I confirm that, in my understanding, all points that were argued with technical substance, had been dealt with in 4rd-u-06.
This is not to negate that you wrote in your last answer, as anyone can verify: "with your newly proposed solution, yes, IPv4 TTL is fine. but on the other hand, the IPv6 also needs TTL(HopLimit)=255 to protect something. we have to concern if 4rd-u possibly introduces some new measures for the attackers breaking such kind of protection mechanism, as putting the first bit of IPv4 TTL into IPv6 HopLimit CHANGES the semantics of IPv6's HopLimit!"

Frankly, I don't understand the new objection: "concern if 4rd-u possibly introduces..." is IMHO an incitation to FUD, but not a technically justified issue.
If you can detail what you mean, with a point an experiment might reveal, dialogue will continue.
Without that, I don't understand what you mean.

> it would become as a ridiculous and weird record in the  ietf history, had the wg made a decision of putting two as experimental,

That was Alain's plan in case no consensus on a single standard would emerge.
It was expressed on the ML well before the meeting.
You didn't object to it then, did you?

> one is well-understood,

This "one" obviously being, in your opinion, MAP-T+E, but:  

a) The need for disjoint packet IDs form shared address CEs is still uncovered in MAP-T.

b) The MAP-E specification is claimed to work in hub-and-apoke topology, but when a BR receives an IPv6 packer, "If the CE IPv6 address is equal to the IPv6 source address in the received IPv6 packet, BR decapsulates the IPv4 packet and then forward it via the IPv4 interface."

c) It has been said during the meeting that, in the tested double-translation implementation, BRs compute UDP checksums of IPv4 datagrams when not computed by sources (Null checksums). Nothing is specified AFAIK specified in the MAP-T document. Is it a MUST, a SHOULD, a MAY?

d) The hub-and-spoke domain parameter, which is needed as Ole acknowledged on the ML, is still not documented in MAP. (Very easy to fix, of course, but a sign that there is still work to be done to have a clear specification.)

e) The Port Parameter option of MAP-DHCP specifies 3-bits "offset" AND a 16-bit "excluded-ports". Which combinations of these values have been actually tested? Why to have "excluded-ports" if there is an offset parameter? 

If these remarks can help E+T proponents to improve their approach, good, but my interest here is ONLY to make WG members understand that MAP-E+T isn't the well specified design it is sometimes claimed to be.

> well-coded and well-practised

A list of once practiced mapping rules for each representative configuration (for T AND for E, and for mesh AND hub-and-spoke) is still missing to support this assertion.

> while the other is misleading the understanding on the Internet architecture,

If it is  a reference to the V octet of 4rd-U, none of the experts I talked to others than MAP-T+E strong proponents has found any architectural problem. (It is new, yes, but is also backward compatible with existing RFCs. No misleading.)

If it is a reference to something else, please explain.

> not yet coded, not yet tested by any operators.

Fair enough, but when Free decided to deploy 6rd, there was not even a document describing it! Yet, it has been the most effective step toward IPv6 availability on a large scale. Understanding the specification was found sufficient. 
Conclusion: clear theory is sometimes more convincing than "I ran a successful experiment". 

> our company, as an ISP and as a provider doing also application services, including those over mobile platforms, is waiting for the MAP standard desirably.

> we have no interest in introducing the 4rd-u elements into our platforms.

Fair enough, but standardization is a collective effort.

Regards,
RD

> personally i won't code a stuff with obvious architectural flaws but, if i were believing in the 4rd-u, i would do the code and operational test with serious self-checking as MAP-T and MAP-E teams already have done, before talking on any doc-track issue with the community. this is the way of being responsible.
> 
> thanks,
> maoke

---

From: Maoke <[email-masked]>
Date: Mon, 2 Apr 2012 09:13:20 +0000

2012/4/2 Rémi Després <[email-masked]>

>
>   Frankly, I don't understand the new objection: "concern if 4rd-u
> possibly introduces..." is IMHO an incitation to FUD, but not a technically
> justified issue.

well, IMHO i have expressed the question and it is concrete. i gently used
the wording "possibly" because the verification could only be done after
you have the 4rd-u system built out.

>
>
> > it would become as a ridiculous and weird record in the  ietf history,
> had the wg made a decision of putting two as experimental,
>

yes, i did objected (in this very thread) the chair's questions, esp. Q2,
with "I don't think it is correct now to insert 4rd-u into a sort of
exclusive decision of choice".

regards,
maoke

---

From: Maoke <[email-masked]>
Date: Mon, 2 Apr 2012 09:16:22 +0000

2012/4/2 Rémi Després <[email-masked]>

>   > it is flawed in both architecture and technical aspects,

please refer to discussion mails and also my real-time comments on 4rd-u
presentation in the jabber room as a brief summary focusing on major
points. - maoke

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 02 Apr 2012 11:28:19 +0200

> standardization should be postponed until it is coded, deployed and

Hi,

Do you think we have time for this? Meantime, CGNs have free way into 
networks without any alternative...

Cheers, Jan

---

From: Rémi Després <[email-masked]>
Date: Mon, 2 Apr 2012 11:30:59 +0200

Le 2012-04-02 à 11:16, Maoke a écrit :

> please refer to discussion mails

I carefully read all emails addressed to me, plus most others, but don't understand that any flaw really exists in 4rd-u-06.

Sorry if I am not as shrewd as I should be in your opinion.

> and also my real-time comments on 4rd-u presentation in the jabber room as a brief summary focusing on major points. - maoke 

Do you know where I could get access to these comments?

Thanks,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 2 Apr 2012 11:33:56 +0200

> In addition, April Fool is ended at JST.

Thanks for understanding yourself that it could have ben taken as a fools' day joke ;-).

Kind regards,
RD

---

From: Maoke <[email-masked]>
Date: Mon, 2 Apr 2012 09:45:22 +0000

> I carefully read all emails addressed to me, plus most others, but don't
> understand that any flaw really exists in 4rd-u-06.
>

i am still in review on the version -06, but i have found something not
qualified (inconsistent semantics). on the other hand, this message is more
about progress rather than the technical details. if we have the BoF or new
working group for the unified header mapping, i'd love to keep discussion
there, with contributing my list of semantics/architecture/technical-detail
questions that i found during the review.

> and also my real-time comments on 4rd-u presentation in the jabber room as
> a brief summary focusing on major points. - maoke
>
>

i guess we have the jabber log. but it is less informative. if the unified
header mapping wg or BoF is started, i will contribute a comprehensive, and
well-studied list of questions.

best,
maoke

---

From: Rémi Després <[email-masked]>
Date: Mon, 2 Apr 2012 12:10:21 +0200

2012-04-02  11:45, Maoke:
...
> i am still in review on the version -06, but i have found something not qualified (inconsistent semantics).

Asserting there are flaws implies ability to describe them.
What you have already "found" will be looked at fairly when described. (Just saying "inconsistent semantics" is unsuffcient).

> on the other hand, this message is more about progress rather than the technical details.

> if we have the BoF or new working group for the unified header mapping, i'd love to keep discussion there, with contributing my list of semantics/architecture/technical-detail questions that i found during the review.

If Satoru-san and yourself want to set up a BOF on this, that remains up to you.
AFAIK, it won't prevent those who want to test 4rd-U-06 to do it.

> i guess we have the jabber log.

Not seen where.
And there isn't AFAIK an audio record either.

> but it is less informative.

Less informative than what?

> if the unified header mapping wg or BoF is started, i will contribute a comprehensive, and well-studied list of questions. 

A WG now without a previous BOF is of course completely unrealistic.

If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections.
Fair enough?

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Mon, 2 Apr 2012 10:30:11 +0000

> Less informative than what?

well i found that, through the ietf agenda page:
http://www.ietf.org/jabber/logs/softwire/2012-03-30.html, FYI.
less informative than my email discussions.

>
> if the unified header mapping wg or BoF is started, i will contribute a
> comprehensive, and well-studied list of questions.
>
>
> If this is to say that until a BOF is started, you will keep your
> objection(s) unknown, I continue to take it as a lack of identified
> objections.
> Fair enough?
>

i din't say what if the BoF is not started but only said about what if the
BoF would started. ;-)

best,
maoke

---

From: Ole Trøan <[email-masked]>
Date: Mon, 2 Apr 2012 12:33:38 +0200

> If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections.

the objections I'm aware of are:
 - people are uncomfortable with only a double translation solution
   * injection of IPv4 routes into IPv6
   * transparency
   * hard to identify IPv4 traffic in the "core"
   * higher risk of leakage. i.e single translation / packets outside the domain
   (all these apply equally to MAP-T btw)
 - redefining the modified EUI-64 format (V-octet) and the consequences standardization wise of that
 - overloading information in the fragment header

(please don't respond to these, FYI only. I'm on Easter holiday.)

if it wasn't for my general "uncomfortableness" with double-translation I'd could be convinced that a single solution was possible.

the status quo; with no path forward just means that we'll effectively kill A+P.
I would certainly not recommend my product managers to implement either of this given the risk.
is there consensus to abandon these efforts (which is basically what we do by publishing them as experimental anyway)?

the alternatives we have are perfectly fine:
 - Shared IPv4 address over IPv4 transport -> NAT444 / CGN
 - Shared IPv4 address over IPv6 transport -> 464XLAT / DS-lite
 - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 address

problem solved. ;-)

cheers,
Ole

---

From: Maoke <[email-masked]>
Date: Mon, 2 Apr 2012 10:37:31 +0000

> qualified (inconsistent semantics).
>
>
> What you have already "found" will be looked at fairly when described.
> (Just saying "inconsistent semantics" is unsuffcient).
>

because i don't think we didn't cover that topic before.

> if we have the BoF or new working group for the unified header mapping,
> i'd love to keep discussion there, with contributing my list of
> semantics/architecture/technical-detail questions that i found during the
> review.
>
>
i don't believe 4rd-u but we respect your belief and therefore we suggest
you do. but what we can make is only suggestion. surely it is welcome if
anyone would like to test 4rd-u. but the test is not the scope of softwire,
and AFAIK, the test of 4rd-u won't prevent those who want to deploy MAP in
real.

regards,
maoke

---

From: Maoke <[email-masked]>
Date: Mon, 2 Apr 2012 10:41:31 +0000

2012/4/2 Maoke <[email-masked]>

> because i don't think we didn't cover that topic before.

sorry here my wording is impolite. i mean we covered that and therefore
please let me later include that into my summary instead of putting it
separetely for easy read.

regards,
maoke

---

From: Wentao Shang <[email-masked]>
Date: Mon, 2 Apr 2012 18:42:49 +0800

Well, IMHO operational test is definitely necessary, as is already
done by the MAP design. It is unresponsible and even dangerous to
publish an untested design, not to mention standardizing it.

regards,
Wentao

-- 
Wentao Shang

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 02 Apr 2012 12:44:25 +0200

On 4/2/12 12:33 PM, Ole Trøan wrote:
> the status quo; with no path forward just means that we'll
> effectively kill A+P. I would certainly not recommend my product
> managers to implement either of this given the risk. is there
> consensus to abandon these efforts (which is basically what we do by
> publishing them as experimental anyway)?
>
> the alternatives we have are perfectly fine: - Shared IPv4 address
> over IPv4 transport ->  NAT444 / CGN - Shared IPv4 address over IPv6
> transport ->  464XLAT / DS-lite - Full IPv4 address over IPv6
> transport ->  DS-lite with Public IPv4 address
>
> problem solved. ;-)

So, if we deprecate RFC6346 and with that the whole A+P idea - is that 
solving anything? Really?

I'm also really tempted to do that if this community can't decide what 
to do in a quick time manner, showing the industry the path forward.

Cheers, Jan Zorz (speaking for myself only)

---

From: Ole Trøan <[email-masked]>
Date: Mon, 2 Apr 2012 13:13:36 +0200

On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si wrote:

> So, if we deprecate RFC6346 and with that the whole A+P idea - is that solving anything? Really?

- less IPv4 exit mechanisms to implement and choose among. that must be good, no?
  (currently there are at least 4 mechanisms proposed in the A+P H&S and mesh space)
- large stateful boxes in the SP network; we know how to build them,
  and we can charge more for them. that's a good thing too, no? ;-)

> I'm also really tempted to do that if this community can't decide what to do in a quick time manner, showing the industry the path forward.

yes, if there was a path forward I would also be a lot less despondent with regards to A+P.

cheers,
Ole

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 2 Apr 2012 20:43:35 +0900

So, I choose MAP.

> - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 address

Otherwise, I'm tempted to do the above, if the wg decide to choose 4rd-u.
As an operator, the 4rd-u scares us too much since no experience of 4rd-u's new unified tunneling in our circumstance at this time. Sorry, Remi-san. I really respect you, but I can't decide to do 4rd-u in our real production network.

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Mon, 2 Apr 2012 15:46:12 +0200

> - people are uncomfortable with only a double translation solution

Are you furtively suggesting that 4rd-U has all limitations of a real double translation solution like MAP-T? 
That mays sound tactically smart, but isn't justified by facts.

>   * injection of IPv4 routes into IPv6

No need for this with 4rd-U (and BTW not even needed with MAP-T, AFAIK)

>   * transparency

4rd-U is fully transparent.
It has been precisely designed for this  (and to simultaneously keep compatibility with IPv6-only O&M).

>   * hard to identify IPv4 traffic in the "core"

The V octet is precisely what facilitates IPv4-traffic identification in the core.

>   (all these apply equally to MAP-T btw)

???
If you have a reference explaining which new risk you see, I will look at it.

> - redefining the modified EUI-64 format (V-octet)

As said in the draft, the u=g=1 combinations of the V octet 'differs from "u" = 0, reserved for local-scope Interface IDs, and also differs from "u" = 1 and "g"= 0, reserved for unicast Interface IDs using the EUI-64 format.'
There is therefore no "redefinition" of the modified EUI-64 format.

> and the consequences standardization wise of that

Using, between CEs and BRs, unused bits of packet IDs doesn't interfere with any existing RFC, independently from its being considered overloading or not. 

> (please don't respond to these, FYI only. I'm on Easter holiday.)

Asking that a list of objections shouldn't be answered is to me very unusual!
(You need not to look at my response before you return from holiday!)

> the status quo; with no path forward just means that we'll effectively kill A+P.

Validating 4rd-U with running code, clearly isn't status quo;
It is a path forward which, in case of success, will also be success of the generic A+P approach. 

> I would certainly not recommend my product managers to implement either of this given the risk.

Either of this???

> is there consensus to abandon these efforts (which is basically what we do by publishing them as experimental anyway)?

Suggesting that validating 4rd-U would be abandoning the A+P effort is very daring. 
It is precisely a way to try and have a clean and unique standard for shared addresses:
- working on mesh topologies
- without per-customer state in ISP nodes

> - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 address

Your suggesting that these three might be sufficient is really strange: 
- none of these supports mesh topologies
- In order to support shared addresses, all these need per-customer or per session states in network devices.

> problem solved. ;-)

Enjoy you vacation.
RD

---

From: Xing Li <[email-masked]>
Date: Mon, 02 Apr 2012 21:50:12 +0800

> yes, if there was a path forward I would also be a lot less despondent with regards to A+P.

I choose MAP and fully believe in A+P, based on the operation 
experiences of the large IPv6-only network - CERNET2.

Regards,

xing

---

From: Ole Trøan <[email-masked]>
Date: Mon, 2 Apr 2012 16:05:08 +0200

Remi,

> Asking that a list of objections shouldn't be answered is to me very unusual!

it was to remind you of the problems with 4rd-U. we have been many rounds on these exact arguments, and I don't see the point of rehashing the discussion. we're going to continue to have different views on the new use of u/g, the overloading of fragmentation, and that double translation can replace tunneling. I'd rather see arguments from non-authors.

(this reminds me of cockfighting; somewhat entertaining for the spectators (if that's your kind of thing), one is declared a winner, but both combatants die...

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 2 Apr 2012 16:34:41 +0200

Le 2012-04-02 à 16:05, Ole Trøan a écrit :

> it was to remind you of the problems with 4rd-U.

> we have been many rounds on these exact arguments, and I don't see the point of rehashing the discussion. 

Then, don't do it yourself.

> we're going to continue to have different views on the new use of u/g, the overloading of fragmentation, and that double translation can replace tunneling.

> I'd rather see arguments from non-authors.

Then, arguments from others than MAP-team members and 4rd-U authors would be the most valuable.
Sheng Jiang of Huawei writing "we are going to implement 4rd-u and do operational tests" is therefore a very important one (like it or not).

> (this reminds me of cockfighting; somewhat entertaining for the spectators (if that's your kind of thing), one is declared a winner, but both combatants die...

You may fear that MAP T+E would be about to die (your judgement) but, in particular in view of the quotation above, I think 4rd-U as in a good position to remain alive.

Your recent comment suggesting that hub&spoke and per-customer stateful solutions might after all be sufficient seems to me a sheer lack of confidence in the solution you propose. (It looks like you become tired to work on the double-standard approach, knowing that arguments for it are too weak for success.)

This doesn't justify, however, your trying to also kill the single standard solution, the most credible A+P approach we have on the table.

RD

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 2 Apr 2012 08:08:50 -0700

>  and we can charge more for them. that's a good thing too, no? ;-)

Do you have data? Or are you perpetuating the myth that stateless is
cheaper?

Last I checked stateless requires some heavy duty provisioning systems and
less efficient static allocation of expensive ipv4 addresses

I ietf has seldom shown the path forward. In this particular context
....especially so.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 2 Apr 2012 08:08:50 -0700

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 2 Apr 2012 17:17:31 +0200

> That mays sound tactically smart, but isn't justified by facts.

Woj> Well, in terms of facts we have
1. 4rd-U does not supporting single translation mode, or if it does then is
requires NAT64/BIH/Something else. (How anybody thinks that deploying 4rd-u
+ "something" else is manageable is a mystery)
2. 4rd-u is incompatible with NAT64 use or deployment
2. MAP solution (call it MAP, divi, or other variants) has proven deployment
3. Any operator who runs NAT64 today is a proof point that 4rd-U solves
problems that are non-issues to operators.
4. 4rd-u changes the basic structure/use of the v6 header, which is a
change to IPv6 that needs to be vetted by 6man, etc. Creating such "novel"
(bogus?) IPv6 packets, that no regular IPv6 host today will recognize and
use, effectively creates a new IPv6 protocol sub-class.

Indeed 4rd-u deserves an "experimental" status track, more than anything.

-Wojciech.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 2 Apr 2012 08:36:50 -0700

> 1. 4rd-U does not supporting single translation mode, or if it does then
is requires NAT64/BIH/Something else. (How anybody thinks that deploying
4rd-u + "something" else is manageable is a mystery)
> 2. MAP solution (call it MAP, divi, or other variants) has proven
deployment

Just for my own clarification, do these proven deployments use static ipv4
address+port sharing with coordinated dhcp assignment? These are the key
feature and method of map-t, and it would be good to know if and how these
key features have been proven.

Cb

---

From: Ole Trøan <[email-masked]>
Date: Mon, 2 Apr 2012 18:59:40 +0200

Cameron,

> Do you have data? Or are you perpetuating the myth that stateless is cheaper?

where did you get the "myth idea" from?
cost obviously depends on platform. scaling a solution based on per flow state, versus per subscriber state versus no state at all. it obviously costs money to keep this state around, increased complexity to maintain it and so on. in addition you need solutions for redundancy that typically involves hot-standbys. while a purely stateless solution can easily do load balancing between multiple active systems.

of course, if we end up with all platforms have to support all mechanisms, including stateful translation, then these may end up on special service cards anyway...

> Last I checked stateless requires some heavy duty provisioning systems and less efficient static allocation of expensive ipv4 addresses

I don't think a DHCP server was considered a "heavy duty provisioning" system.

> I ietf has seldom shown the path forward. In this particular context ....especially so.
> 

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Mon, 2 Apr 2012 19:04:00 +0200

Remi,

> Your recent comment suggesting that hub&spoke and per-customer stateful solutions might after all be sufficient seems to me a sheer lack of confidence in the solution you propose. (It looks like yo…

can we just cite irreconcilable differences and stop discussing this?

> This doesn't justify, however, your trying to also kill the single standard solution, the most credible A+P approach we have on the table.

I believe that a consequence of us not being able to agree on a A+P solution will have the effect of killing A+P.
the "problem" with MAP isn't that it has two modes of encapsulation. the problem with MAP is 4rd-U. the unification of churches rarely work. I would have been happy to concede and go with 4rd-U, but only if I thought it worked. and would have an easy way through standardization. unfortunately, the esoteric features with the V-octet and fragment header will make that not so.

this is my last mail to you on this subject.

Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 2 Apr 2012 19:10:36 +0200

Hi, all,

Following some points made on the ML, please find below some clarifications on 4rd-U.

...
> > 1. 4rd-U does not supporting single translation mode,
> 
Not claimed to.
> or if it does then is requires NAT64/BIH/Something else.
> 
The 4rd-u-06 draft says:
"This specification only concerns IPv4 communication between IPv4-capable endpoints.  For communication between IPv4-only endpoints and IPv6 only remote endpoints, the BIH specification of [RFC6535] can be used.  It can coexist in a node with the CE function, including if the IPv4-only function is a NAT44 [RFC1631]"

The reference here to NAT64 and "something else" is clearly inappropriate.

> (How anybody thinks that deploying 4rd-u + "something" else is manageable is a mystery)
> 
In RFC6535, BIH lets the IPv4 stack to be used if only an AAAA record is received (which characterizes an an IPv6-only host). If 4rd-U is activated in the same node, IPv4 packets of the IPv4 stack are simply tunneled across IPv6, according to the 4rd-U specification. No mystery.

> > 2. 4rd-u is incompatible with NAT64 use or deployment
Not claimed to, and no need to.

464XLAT, for example, doesn't need MAP-T (and even less MAP-E) to work with NAT64. 
In this respect, 464XLAT and BIH work identically.
The sentence of RFC6535 that doesn' "recommend" using BIH for double translation, isn't a formal objection to using it if it is the only way to satisfy a need. (In this instance, the exact need that the 464XLAT draft identifies)

I added a copy to Teemu Savolainen, a better specialist of BIH than I am. 
> Just for my own clarification, do these proven deployments use static ipv4 address+port sharing with coordinated dhcp assignment? These are the key feature and method of map-t, and it would be good to know if and how these key features have been proven.
> 
+1 
(To renew, once more, my request to know which set of MAP-T mapping rules have actually been validated.) 
> Cb
> 
> > 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves problems that are non-issues to operators.
> 
According to this statement, co-authors of 4rd-U coming from network operators don't understand their problems as well as Wojciech does. 
I find this doubtful.

> > 4. 4rd-u changes the basic structure/use of the v6 header, which is a change to IPv6 that needs to be vetted by 6man, etc. Creating such "novel" (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and use, effectively creates a new IPv6 protocol sub-class. 
> 
In discussions in Paris with Dave Thaler, Dan Wing, Stuart Cheshire, Lorenzo Colitti, I didn't get any indication that using the unused u-g combination, if useful, would be a big issue.
Making a backward-compatible extension of RFC2373 shouldn't in my understanding be too difficult (if confirmed to be useful for 4rd-U).
> > Indeed 4rd-u deserves an "experimental" status track, more than anything.
Well, with no WG consensus achieved on any 4via6 solution working on mesh topologies, that's probably the best that can be done so far.
Still, it is a step forward. 

Regards,
RD

---

From: Tom Taylor <[email-masked]>
Date: Mon, 02 Apr 2012 13:47:19 -0400

People on the list might get the impression that Rene is single-handedly 
holding up WG progress. I have not been involved in this work, but did 
observe at the meeting a show of hands for 4rd-U at least as numerous as 
that for MAP. For whatever reason, the WG at large does not seem 
prepared to commit to a single solution.

On 02/04/2012 11:17 AM, Wojciech Dec wrote:
> On 2 April 2012 15:46, Rémi Després<[email-masked]>  wrote:
>
>>

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 2 Apr 2012 20:18:59 +0200

> > 1. 4rd-U does not supporting single translation mode,

It's good to get clarity now that previous 4rd-U claims of supporting
services such as web-caching, log-on-portals, etc. are now false, and no
longer claimed. MAP(-T) continues to allow these.

>
> The 4rd-u-06 draft says:
> "This specification only concerns IPv4 communication between IPv4-capable
> endpoints.  For communication between IPv4-only endpoints and IPv6 only
> remote endpoints, the BIH specification of [RFC6535] can be used.  It can
> coexist in a node with the CE function, including if the IPv4-only function
> is a NAT44 [RFC1631]"
>

There already is a decent solution for IPv4-IPv4 only, without loss of info
= IPinIP tunnel. Now, let "something else" be BIH (or whatever), this is an
admission that 4rd-U is not any kind of unified solution, but rather a
different collation a novel "pseudo-tunneling" solution with an addon in
the form of BIH.
Ironically since BIH is NAT64 based, all the problems 4rd-U tries to solve,
remain still applicable in that BIH dimension. It is thus no complete
solution.

> In RFC6535, BIH lets the IPv4 stack to be used if only an AAAA record is
> received (which characterizes an an IPv6-only host). If 4rd-U is activated
> in the same node, IPv4 packets of the IPv4 stack are simply tunneled across
> IPv6, according to the 4rd-U specification. No mystery.
>

The managing of a MAP deployment looks far much simpler, and less
mysterious too, including the use of less moving parts.

> Not claimed to, and no need to.

That's your call, but its neither  the starting point of most customers who
deploy and use NAT64 today, or the direction which sees NAT64 usage. With
4rd-u, such NAT64's need to be replaced or extra operational complexity
brought in by running in parallel with 4rd-u (possibly serving the same end
points).

> The sentence of RFC6535 that doesn' "recommend" using BIH for double
> translation, isn't a formal objection to using it if it is the only way to
> satisfy a need. (In this instance, the exact need that the 464XLAT draft
> identifies)
>

This is not about BIH, but rather that 4rd-U needs "something else" to
cover the MAP space. It thus is no unifying solution at all as it claims to
be

> have actually been validated.)

One work in progress...
http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02.
More data was presented at the softwire IETF interim (lost the link for now)

> According to this statement, co-authors of 4rd-U coming from network
> operators don't understand their problems as well as Wojciech does.
> I find this doubtful.
>

Rather, according to this statement co-authors of MAP, including numerous
operators, don't care about the problems 4rd-U solves.

> In discussions in Paris with Dave Thaler, Dan Wing, Stuart Cheshire,
> Lorenzo Colitti, I didn't get any indication that using the unused u-g
> combination, if useful, would be a big issue.
> Making a backward-compatible extension of RFC2373 shouldn't in my
> understanding be too difficult (if confirmed to be useful for 4rd-U).
>

Not sure how the above constitute the v6man WG, or what the personal
opinions of these individuals have to do with the fact that ultimately
you're changing core IPv6 semantics, incl those of the fragmentation
header, which is not within softwire charter.

> Well, with no WG consensus achieved on any 4via6 solution working on mesh
> topologies, that's probably the best that can be done so far.

For 4rd-U experimental would indeed be a fitting track, given that it has a
lot of experimentation and proving yet to do, less so for MAP.

-Woj.

---

From: Tetsuya Murakami <[email-masked]>
Date: Mon, 2 Apr 2012 18:27:27 +0000

+1.

4rd-u is tweaking IPv6 header such as fragment header, hop limit, V-octet, etc to create a unified transport instead of the encapsulation (MAP-E) and the translation (MAP-T). MAP-E and MAP-T do not intend to create a new transport. In fact, MAP-E utilizes rfc2473 and MAP-T utilizes rfc6145. We implemented the mapping rule with the standard transport. So, from my point of view, since 4rd-u focus on defining a new transport, the discussion point of 4rd is a little bit different from MAP-E/MAP-T. Also, the following idea is a good way to get the consensus widely to define the new transport instead of the existing tunneling/translation.

Thanks,
Tetsuya Murakami

On 2012/04/01, at 11:02, Satoru Matsushima wrote:

Best regards,
--satoru

Cheers, Jan

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

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

---

From: Tetsuya Murakami <[email-masked]>
Date: Mon, 2 Apr 2012 18:27:53 +0000

Hi Remi,

As you pointed out, the text related to Hub & Spoke model in MAP-E draft could is not correct. I will correct it soon in the next version.

But, we have already implemented hub&spoke model in our MAP-E/MAP-T implementation. Our implementation is having the following option for map tunnel.

ip -6 tunnel change map1 fmr disable

Also, we have already tested hub&spoke model in MAP-E/MAP-T. Of course, mesh model has been already implemented/tested in our MAP-T/MAP-E implementation.

Thanks,
Tetsuya Murakami

On 2012/04/02, at 2:04, Rémi Després wrote:

hi all,

Which ones?

Which ones?

one is well-understood,

Regards,
RD

thanks,
maoke

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 3 Apr 2012 10:53:06 +0900

FYI, choosing MAP doesn't mean that committing to a 'single'. But choosing 4rd-u means that committing to a 'single'.

There're just transport variants, which are encapsulation, translation and new one we've never seen before. Proponents of the new one claim to unify transport only to the new one, which means that eliminating both encapsulation and translation variants of MAP because they say two choice of transport type would make confusion for operators. The new one is transparent than translation, but less than encapsulation. I couldn't decide transport type to be unified with the new one. No evidence, no expertise, no experience for that. Do we need them to be sure in spite of we already have existing mature transport variants?

cheers,
--satoru

On 2012/04/03, at 2:47, Tom Taylor wrote:

> People on the list might get the impression that Rene is single-handedly holding up WG progress. I have not been involved in this work, but did observe at the meeting a show of hands for 4rd-U at least as numerous as that for MAP. For whatever reason, the WG at large does not seem prepared to commit to a single solution.
>

---

From: Wentao Shang <[email-masked]>
Date: Tue, 3 Apr 2012 11:17:52 +0800

> There're just transport variants, which are encapsulation, translation and new one we've never seen before. Proponents of the new one claim to unify transport only to the new one, which means that…

+1. With all due respect, I cannot image making a standard that has
neither rough consensus nor running code.

Regards,
Wentao

-- 
Wentao Shang

---

From: 韩国梁 <[email-masked]>
Date: Tue, 3 Apr 2012 11:26:02 +0800

+1.

As a follower of MAP team, I participated much in developing and deploying
double-translation in CERNET. As far as I am concerned, in the translation
scenario,
4rd-U only solved some corner cases but missed some other cases
simultaneously.

As an example, I suppose one fragmentation case as following:

(IPv4 customer network)--CE---(IPv6 access network)--BR(Core
Translator)--(IPv4 network)---IPv4 host

The minumum MTU of IPv6 access network is 1400, and the minimum MTU of IPv4
network on the right side is 800. Now an IPv4 host on the left side sends a
packet
with length set to 1200 and MTU set to 1, to the IPv4 host in the right
side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4
network.
In this case, BR(Core Translator) must set DF to 0 when translating from
IPv6 back to IPv4,
instead of preserving the original IPv4 DF bit.

In fact, according to RFC6145, if BR(Core Translator) receives an ICMP
Packet Too Big packet
whose indicating MTU is less than 1280 bytes, it will change it to 1280. So
if the BR preserve
the DF bit, the sender will always believe the path MTU is 1280, which will
certainly lead to
a black hole.

This is only one deployment problem, and we don't know how many issues will
be encountered
in the future. So my point is that 4rd-U still needs examination in the
actual deployment, and
it's a bit early to propose it as an Informational/Standards Track Document.

The mail sent yesterday seemed to encounter some problems. So if you see
this mail twice, sorry for that.

regards,
Guoliang

2012/3/26 Maoke <[email-masked]>

> hi Remi,
>
> let me remove those you have marked as "end". they are fine to me too.
> only one point: no implementation nor operation trouble != it is safe to
> say it an architectural building block of tunnel. if we both say 4rd-u is
> an alternative for translation, it would be much clear. (i don't think it
> is a tunnel variant at all, due to not providing virtual links; while you
> insist it not a translation at all).
>
> 2012/3/25 Rémi Després <[email-masked]>
>
>>
>>
>>        c) MAP-A+P says "Each MAP node in the domain has the same set of
>>>> rules" while MAP-T says "if a CE knows only a subset of the mapping rules
>>>> ..."
>>>>
>>>>
>>>
>>> first of all, they are not conflicting logically.
>>>
>>>
>>> ???
>>>
>>>  second, if you mean one doc is superior than multiple with better
>>> consistency in writing, i could agree.
>>>
>>>
>>> This is not the point.
>>> Separate documents can be consistent, but they aren't on this point.
>>>
>>> One of the two assertions must be changed.
>>> Remaining question: which one?
>>>
>>>
>>
>>  well. this is why i said they are not conflict in logic. as a
>> definition of the MAP rule, right, each MAP node in the domain SHOULD have
>> the same set of rules. however, in practice of operation, it is possible
>> that this MAY not strictly achieved due to some information losses (which
>> is often happens in the Internet environment), MAP-T defines the CE working
>> as it were in hub&spokes mode for an unknown destination CE.
>>
>>
>> I am not aware that a CE might receive some of the MAP DHCPv6 parameters
>> but not all due to lost packets.
>>  Clarification on this will be welcome.
>>
>
> my understanding is: DHCPv6 is not running on a reliable protocol, while
> MAP DHCPv6 does not yet determine if all FMR would be carried in a single
> or multiple DHCPv6 messages provided they are many. (if the MAP-dhcp has
> done with this, please teach me, thanks!)
>
> if you assume Internet is always reliable for everything, we must change
> our discussion on a lot of issues.
>
>
>>
>>  if you mean the single mapping rule in IVI case, the answer is NONE,
>> surely. IVI uses RFC6052 address format rather than the MAP, without the
>> business of MAP.
>>
>>
>>  OK
>> (In this respect at least, IVI significantly differs from a running
>> version of MAP-T).
>>
>
> well, here i don't know how "significantly" you mean. IVI/dIVI/MAP-T(or
> dIVI-pd) are same in header processing but different in address mapping and
> operation. the context of "IVI" above mentioned the original IVI/dIVI that
> applies RFC6052 mapping, while MAP-T (dIVI-pd) applies MAP mapping rules.
>
>
>>
>>
>> if you mean using the MAP for the single translation as we did in IVI
>> (though actually we have IVI working for both single and double
>> translations simultaneously), MAP-T Sec 8.3 has answered your question.
>>
>>
>> Saying that there is no mapping rule in IVI is sufficient an answer.
>>
>
> then there is no more "not reaching collective understanding" for this
> point. End of this topic for me.
>
>
>>
>>    None?
>>> If one, is it a DMR or a BMR?
>>> If two, what are they?
>>>  ...
>>>  OK, could have been clearer.
>>> Yet, I think you understand that with U, one has SIMULTANEOUSLY,
>>> transparency to DF=MF=1 and applicability of IPv6-only middle boxes that
>>> look at TCP ports.
>>>
>>>
>>
>>  ok. then may i conclude, for the major part of U, that 1) U, as a
>> stated enhancement for double translation, gain the transparency for
>> DF=MF=1 (the 10^-6 minor cases, commonly thought abnormal);
>>
>>
>>  1) A statistic at a given time, and in a given place, isn't a proof
>> that the same ratio will be found later and somewhere else.
>> 2) Those that happen to be in the sacrificed minority, be it small, may
>> not like their situation. Solving the problem, be it only for them, is
>> progress.
>>
>
> 1) not only one statistics. i did it at Tsinghua University. prof. Bao and
> others did it at CERNET. other guys did it in Europe and published in
> IMC'07. and if you carefully read that paper, you may found that case was
> very abnormal.
> 2) well, it is good if we can take care of the minority without putting
> the majority into potential trouble and uncertainty.
>
>
>>
>>   2) with introducing #1. weird definition of the fragment header of
>> IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages?
>>
>>
>> AFAIK, not weird to those who are open to accept that it is very simple.
>>
>
> AFAIK, you'd better to have #1 accepted by the IPv6 protocol and have #2
> well discussed with the ICMP designers before concluding they are "not
> weird"! i am not so open. to those who are open to accept this, i think
> they should be also open to the following propositions (that are wrong to
> me):
>
> *1. IPv6 option header, as long as there are reverved or not-yet-used or
> padding bits, could be redefined as we like.
> *2. it is a useless design that ICMP(v4 or v6) error message body contains
> part of the original IP(v4 or v6) packet, where the source address is
> identical to the destination of the IP(v4 or v6) header carrying the
> ICMP(v4 or v6) message.
> *3. it is a useless design that ICMPv6 header checksum contains
> pseudo-header of the IPv6 header carrying it.
> *4. IPv4 header checksum is actually useless.
>
> if the community would accept these *1 ~ *4 as true statements, i would be
> also open to accept the above 2). but don't conclude before we get the
> feedback from the community!
>
>    ...
>>  well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are
>> major flaws (as we discussed so much, i was not convinced at all). i don't
>> think others who read the specification don't see them and other issues.
>>
>>
>>  ICMPv4 payloads in IPv6 packets appear only during domain traversal,
>> where they don't hurt anyone.
>>
>
> see above.
>
>
>>
>> If a host is IPv6 only, it isn't a 4rd-U host.
>> For communication between IPv4-only applications of DS hosts and
>> IPv6-only hosts, there are already workable RFCs.
>>
>
> common understanding, including RFC6052/RFC6145/RFC6146 but surely not
> limited to these.
>
>
>>  BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient.
>> A new solution for this isn't needed.
>>
>
> BIH serves DS hosts connected to DS networks. the use case does not cover
> the all cases of IPv4-IPv6 mutual communciations.
>
>
>>
>>  an operator definitely needs the encapsulation as a fully featured
>> virtual link (underlay infrastructure) in real O&A for IPv4 communications
>> over IPv6 infrastructure. U cannot replace E at all.
>>
>>
>> Different understanding.
>> An detailed E use case that cannot be supported by U (if it exists) would
>> give substance to this claim.
>>  Open to look at it.
>>
>
> in my personal experience i could give you at least three quick examples
> of the use case for the building block of "virtual link":
>
> first example, if the IPv4 customer network plays BGP over IPv4 with the
> provider, through the BGP session between CE and BR, a virtual link is
> desired.
>
>     (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4
> world)
>
> second example, there are dynamic routing protocols like RIP running in
> the following (multihoming) topology for IPv4 routing. the operator may
> want to treat the CE-BR as a single hop in order the virtual link is
> considered the distance vector calculation.
>
>      (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR
> ----(IPv4 world)
>                \                                                        /
>                 \                                                      /
>                  +------------ CE ----(Another, IPv4 domain)----------+
>
> third example, same topology as above but OSPF are applied, and OSPF
> TTL-security check are enabled to ensure hop-passings less than a specified
> threshold. if the operator would like to treat CE---(IPv6-only domain)---BR
> as one hop because it is considered as virtual link, 4rd-u's rudiness in
> decreasing TTL will hurt.
>
> MAP-E (and other E) surely has no limitation in supporting any features of
> existing routing protocols. with at least the above three examples, i
> conclude "U cannot replace E at all"! (btw, surely the translation has the
> same limitation not to support the above features but, e.g., as you also
> said, it opens transport-layer stuff to the middle boxes). therefore i said
> operators may use either encapsulation or translation according to what
> they attach importance to.)
>
>
>>
>>  but U needs still discussion
>>
>>
>>  T too.
>> See, for example, (*) above.
>>
>
> you have ended that subject. fine to me. people have known the difference
> between the "needs discussions" for the both.
>
>
>>
>>  and running code approval. it cannot replace T at least this moment.
>>
>>
>> Understanding how U's header mapping works doesn't need great expertise.
>> Co-autors readily understood it, with origins as varied as
>> router-and-host vendor, software vendor, broadband operator, mobile
>> operator.
>>
>
> well, it works just like another translator, surely it doesn't need great
> expertise.
>
>
>>
>> Running code as soon couldn't be done yet, but isn't a big deal at all
>> (see (**) below)
>>
>> ...
>>
>>  MAP can work even without the V-octet and CNP, at least in significant
>> cases.
>>
>>
>> Not a valid reason to stop progress, especially if easy to understand.
>> At least Med suggested to look at V octet even in the context of MAP (if
>> chosen for standard track).
>>
>
> no problem if you keep debate in/with the MAP design team. just our
> current understanding is: it is not necessary.
>
>
>>
>>   if we have the standard of MAP, we can immediately deploy it into
>> practice through applying MAP rules into the already well understood, well
>> approved, well standardized encapsulation and translation modules,
>>  without waiting for the approval of the new features in the address
>> format, and the approval of the reversible header mapping tightly coupled
>> with the address format.
>>
>>
>> (**)
>> When we discussed in Taipei, you first said you might code 4rd-U so that
>> it could be tested for real. You didn't do it for reasons that I perfectly
>> respect.
>>
>
> yes but i also mentioned the prerequisite: "when i fully understand it and
> see it qualified". i also talked with some others that i was interested in
> that and, if possible and necessary, i would try to code it out and test
> it, but again the prerequisite was attached. i have no reason to do a code
> for a stuff even suspected by myself. you should remember that, after a
> large amount of discussion, i told you i wouldn't code it when we reached
> the problem of IPv6 carrying ICMPv4. this made me re-think the issue in the
> aspect of architectural building block. sure the company's resource
> allocation was a reason but this reason was tightly correlated to my own
> academic judgement on the necessity.
>
> thanks,
> - maoke
>
>
>>  Yet, modifying T code to support header mapping remains quite simple
>> (you even call it a translation variant). Starting from E code, it's simple
>> too.
>> When this is done, all verifications can be easily done that what
>> analysis says is right is also right with running code.
>>
>>
>> Regards,
>> RD
>>
>
>

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 03 Apr 2012 09:41:03 +0200

On 4/3/12 3:53 AM, Satoru Matsushima wrote:
> FYI, choosing MAP doesn't mean that committing to a 'single'. But
> choosing 4rd-u means that committing to a 'single'.
>
> There're just transport variants, which are encapsulation,
> translation and new one we've never seen before. Proponents of the
> new one claim to unify transport only to the new one, which means
> that eliminating both encapsulation and translation variants of MAP
> because they say two choice of transport type would make confusion
> for operators. The new one is transparent than translation, but less
> than encapsulation. I couldn't decide transport type to be unified
> with the new one. No evidence, no expertise, no experience for that.
> Do we need them to be sure in spite of we already have existing
> mature transport variants?
>
> cheers, --satoru

+1

Given the situation with IPv4 exhaustion we have to hurry and go with 
what we know and what is proven to work today with no funky new features.

I agree that 4RD-U brings some good new features, but as it changes the 
IPv6 current usage I suggest to redirect 4RD-U to BoF and to go through 
revision of also other working groups that needs to say their 
understanding of changed IPv6 transport behavior. I also believe that 
when 4RD-U goes through the whole proper procedure it might be widely 
adopted later as MAP replacement.

Meantime - let's fix the problem with what we know and understand.

Speaking as A+P (RFC6346) co-author, we got many questions about A+P 
progress from operators and we learned that the time-frame for decision 
between CGN and something else is already nearly expired. If we want 
anything-A+P to still reach the operators, then the time for decision is 
now. We already missed the majority of that train, but last seats in 
last wagon are still reachable.

We need to act and not just to push the endless discussion (that is not 
that uncommon for any IETF WG :) ).

Cheers, Jan Zorz

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Apr 2012 10:31:57 +0200

Hi, Guoliang,

Interesting enough, the example you give illustrates that MAP-T needs to remain experimental, more than any other solution.

1.
RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=1280. It specifies two behaviors, one that does this, and one that doesn't. Which one to choose isn't AFAIK specified in the MAP-T draft.

2.
With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination unchanged. This is exactly what is necessary for PMTU discovery to work.

3.
Now, you suggest to replace DF=1 by DF=0 in BRs. This differs AFAIK from RFC6145, and therefore from MAP-T.

When we have a detailed report on which parts of MAP-T have been validated, with which options of RFC6145, it will be easier to analyze scenarios like the one you propose.

In any case, thanks for providing one more evidence that the MAP-T specification isn't as clear as claimed to all those who support it, and in particular to some also criticize 4rd-U with invalid arguments.

Regards,
RD

Le 2012-04-03 à 05:26, 韩国梁 a écrit :

> double-translation in CERNET. As far as I am concerned, in the translation scenario,
> 4rd-U only solved some corner cases but missed some other cases simultaneously.
>  
> (IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translator)--(IPv4 network)---IPv4 host
>  
> network on the right side is 800. Now an IPv4 host on the left side sends a packet 
> with length set to 1200 and MTU set to 1, to the IPv4 host in the right side. The packet 
> could traverse the IPv6 access network, but will be blocked in the IPv4 network. 
> In this case, BR(Core Translator) must set DF to 0 when translating from IPv6 back to IPv4,
> In fact, according to RFC6145, if BR(Core Translator) receives an ICMP Packet Too Big packet 
> whose indicating MTU is less than 1280 bytes, it will change it to 1280. So if the BR preserve
> the DF bit, the sender will always believe the path MTU is 1280, which will certainly lead to 
> a black hole.
>  
> This is only one deployment problem, and we don't know how many issues will be encountered
> in the future. So my point is that 4rd-U still needs examination in the actual deployment, and 
> The mail sent yesterday seemed to encounter some problems. So if you see this mail twice, sorry for that. 
>  
> regards, 
> Guoliang
> 
>  
> let me remove those you have marked as "end". they are fine to me too. only one point: no implementation nor operation trouble != it is safe to say it an architectural building block of tunnel. if we both say 4rd-u is an alternative for translation, it would be much clear. (i don't think it is a tunnel variant at all, due to not providing virtual links; while you insist it not a translation at all). 
> 
>>> c) MAP-A+P says "Each MAP node in the domain has the same set of rules" while MAP-T says "if a CE knows only a subset of the mapping rules ..."  
>>>  
>>>  
>>> second, if you mean one doc is superior than multiple with better consistency in writing, i could agree.
>> 
>> This is not the point.
>> well. this is why i said they are not conflict in logic. as a definition of the MAP rule, right, each MAP node in the domain SHOULD have the same set of rules. however, in practice of operation, it is possible that this MAY not strictly achieved due to some information losses (which is often happens in the Internet environment), MAP-T defines the CE working as it were in hub&spokes mode for an unknown destination CE.
> 
> I am not aware that a CE might receive some of the MAP DHCPv6 parameters but not all due to lost packets.
> my understanding is: DHCPv6 is not running on a reliable protocol, while MAP DHCPv6 does not yet determine if all FMR would be carried in a single or multiple DHCPv6 messages provided they are many. (if the MAP-dhcp has done with this, please teach me, thanks!)
> 
> if you assume Internet is always reliable for everything, we must change our discussion on a lot of issues. 
>  
> 
>> if you mean the single mapping rule in IVI case, the answer is NONE, surely. IVI uses RFC6052 address format rather than the MAP, without the business of MAP.
> 
> OK
> (In this respect at least, IVI significantly differs from a running version of MAP-T).
> 
> well, here i don't know how "significantly" you mean. IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different in address mapping and operation. the context of "IVI" above mentioned the original IVI/dIVI that applies RFC6052 mapping, while MAP-T (dIVI-pd) applies MAP mapping rules. 
>  
> 
>>  
>> if you mean using the MAP for the single translation as we did in IVI (though actually we have IVI working for both single and double translations simultaneously), MAP-T Sec 8.3 has answered your question.
> 
> then there is no more "not reaching collective understanding" for this point. End of this topic for me. 
>  
> 
>> None? 
>> Yet, I think you understand that with U, one has SIMULTANEOUSLY, transparency to DF=MF=1 and applicability of IPv6-only middle boxes that look at TCP ports.
>>  
>>  
>> ok. then may i conclude, for the major part of U, that 1) U, as a stated enhancement for double translation, gain the transparency for DF=MF=1 (the 10^-6 minor cases, commonly thought abnormal);
> 
> 1) A statistic at a given time, and in a given place, isn't a proof that the same ratio will be found later and somewhere else.
> 2) Those that happen to be in the sacrificed minority, be it small, may not like their situation. Solving the problem, be it only for them, is progress.
> 
> 1) not only one statistics. i did it at Tsinghua University. prof. Bao and others did it at CERNET. other guys did it in Europe and published in IMC'07. and if you carefully read that paper, you may found that case was very abnormal. 
> 2) well, it is good if we can take care of the minority without putting the majority into potential trouble and uncertainty. 
>  
> 
>> 2) with introducing #1. weird definition of the fragment header of IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages?
> 
> AFAIK, you'd better to have #1 accepted by the IPv6 protocol and have #2 well discussed with the ICMP designers before concluding they are "not weird"! i am not so open. to those who are open to accept this, i think they should be also open to the following propositions (that are wrong to me):
> 
> *1. IPv6 option header, as long as there are reverved or not-yet-used or padding bits, could be redefined as we like.
> *2. it is a useless design that ICMP(v4 or v6) error message body contains part of the original IP(v4 or v6) packet, where the source address is identical to the destination of the IP(v4 or v6) header carrying the ICMP(v4 or v6) message. 
> *3. it is a useless design that ICMPv6 header checksum contains pseudo-header of the IPv6 header carrying it. 
> if the community would accept these *1 ~ *4 as true statements, i would be also open to accept the above 2). but don't conclude before we get the feedback from the community!
> 
>> ... 
>> well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are major flaws (as we discussed so much, i was not convinced at all). i don't think others who read the specification don't see them and other issues.
> 
> ICMPv4 payloads in IPv6 packets appear only during domain traversal, where they don't hurt anyone.
> 
> see above. 
>  
> 
> For communication between IPv4-only applications of DS hosts and IPv6-only hosts, there are already workable RFCs. 
> 
> common understanding, including RFC6052/RFC6145/RFC6146 but surely not limited to these. 
>  
> BIH serves DS hosts connected to DS networks. the use case does not cover the all cases of IPv4-IPv6 mutual communciations. 
>  
> 
>> an operator definitely needs the encapsulation as a fully featured virtual link (underlay infrastructure) in real O&A for IPv4 communications over IPv6 infrastructure. U cannot replace E at all.
> 
> Different understanding.
> An detailed E use case that cannot be supported by U (if it exists) would give substance to this claim.
> Open to look at it.  
> 
> in my personal experience i could give you at least three quick examples of the use case for the building block of "virtual link": 
> 
> first example, if the IPv4 customer network plays BGP over IPv4 with the provider, through the BGP session between CE and BR, a virtual link is desired. 
> 
>     (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 world) 
>                                      
> second example, there are dynamic routing protocols like RIP running in the following (multihoming) topology for IPv4 routing. the operator may want to treat the CE-BR as a single hop in order the virtual link is considered the distance vector calculation.
> 
>     (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 world) 
>                \                                                        /
>                 \                                                      /
> third example, same topology as above but OSPF are applied, and OSPF TTL-security check are enabled to ensure hop-passings less than a specified threshold. if the operator would like to treat CE---(IPv6-only domain)---BR as one hop because it is considered as virtual link, 4rd-u's rudiness in decreasing TTL will hurt. 
> 
> MAP-E (and other E) surely has no limitation in supporting any features of existing routing protocols. with at least the above three examples, i conclude "U cannot replace E at all"! (btw, surely the translation has the same limitation not to support the above features but, e.g., as you also said, it opens transport-layer stuff to the middle boxes). therefore i said operators may use either encapsulation or translation according to what they attach importance to.) 
> 
> 
> 
> you have ended that subject. fine to me. people have known the difference between the "needs discussions" for the both. 
>  
> 
> Co-autors readily understood it, with origins as varied as router-and-host vendor, software vendor, broadband operator, mobile operator.
> 
> well, it works just like another translator, surely it doesn't need great expertise. 
>  
> 
> Running code as soon couldn't be done yet, but isn't a big deal at all (see (**) below)
> 
> ... 
> 
>> MAP can work even without the V-octet and CNP, at least in significant cases.
> 
> At least Med suggested to look at V octet even in the context of MAP (if chosen for standard track).
> 
> no problem if you keep debate in/with the MAP design team. just our current understanding is: it is not necessary. 
>  
> 
>>  if we have the standard of MAP, we can immediately deploy it into practice through applying MAP rules into the already well understood, well approved, well standardized encapsulation and translation modules,  without waiting for the approval of the new features in the address format, and the approval of the reversible header mapping tightly coupled with the address format.
> 
> (**)
> When we discussed in Taipei, you first said you might code 4rd-U so that it could be tested for real. You didn't do it for reasons that I perfectly respect.
> 
> yes but i also mentioned the prerequisite: "when i fully understand it and see it qualified". i also talked with some others that i was interested in that and, if possible and necessary, i would try to code it out and test it, but again the prerequisite was attached. i have no reason to do a code for a stuff even suspected by myself. you should remember that, after a large amount of discussion, i told you i wouldn't code it when we reached the problem of IPv6 carrying ICMPv4. this made me re-think the issue in the aspect of architectural building block. sure the company's resource allocation was a reason but this reason was tightly correlated to my own academic judgement on the necessity. 
> 
> thanks,
> - maoke
>  
> Yet, modifying T code to support header mapping remains quite simple (you even call it a translation variant). Starting from E code, it's simple too.
> When this is done, all verifications can be easily done that what analysis says is right is also right with running code.
> 
> 
> Regards,
> RD
> 
>

---

From: Maoke <[email-masked]>
Date: Tue, 3 Apr 2012 09:07:00 +0000

2012/4/3 Jan Zorz @ go6.si <[email-masked]>

> Given the situation with IPv4 exhaustion we have to hurry and go with what
> we know and what is proven to work today with no funky new features.
>
> revision of also other working groups that needs to say their understanding
> of changed IPv6 transport behavior. I also believe that when 4RD-U goes
> through the whole proper procedure it might be widely adopted later as MAP
> replacement.
>

agree and have the same feeling. i'd love to keep study what 4rd-u brings
to the transition architecture and more practices are not excluded along
with the 4rd-u getting well-understood. and if 4rd-u is
approved/improved/verified superior to both -T and -E through the whole
procedure, i don't think it will be a problem that MAP would be obsoleted
in the future. but that's of not our current situation, fixing the problem
with well-understood building blocks is what we must do as soon as
possible.

- maoke

> now. We already missed the majority of that train, but last seats in last
> wagon are still reachable.
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Apr 2012 11:07:33 +0200

Le 2012-04-03 à 03:53, Satoru Matsushima a écrit :

> There're just transport variants, which are encapsulation, translation and new one we've never seen before. Proponents of the new one claim to unify transport only to the new one, which means that eliminating both encapsulation and translation variants of MAP because they say two choice of transport type would make confusion for operators.

> The new one is transparent than translation, but less than encapsulation.

If you would have a detailed scenario where ANY transparency difference could be noticeable e2e between a MAP-E tunnel and a 4rd-U tunnel, this sentence would be fair.
However, you haven't shown such a scenario, and AFAIK you can't have one because it doesn't exist.
The above assertion, being wrong, is therefore misleading.

> I couldn't decide transport type to be unified with the new one.

> No evidence, no expertise, no experience for that.

But many of those who have no motivation to look for flaws that don't exist, do understand that the design is safe.

> Do we need them to be sure in spite of we already have existing mature transport variants?

MAP-E+T isn't as mature as repeatedly claimed.
MAP-T may be more imprecise than MAP-E in this respect, but both have known bugs to be fixed (at least packet IDs of shared-addres CEs of MAP-T, and BR hairpinning in MAP-E).

Besides, the exact list of MAP DHCPv6 parameters has yet to be finalized.

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Tue, 3 Apr 2012 09:21:46 +0000

dear Remi,

1. for this issue, you are in misunderstanding.

i checked the RFC6145 logic and behavior, very carefully, with the PTB <
1280 issue. there is no two behaviors but only one behavior supporting
independent working of the IPv4-to-IPv6 and the IPv6-to-IPv4 translators.
there is no question on which one to choose in the MAP-T draft. (i think
you may accept that a "if...else..." logic does not mean option).

2. it is necessary to verify, in practice, if the feature that IPv6 is
carrying ICMPv4 message is secure. it is new to the IP/ICMP architecture.

3. please refer to RFC6145 Sec 6 for the details (but maybe other sections
are also needed to read).

i think your objection to RFC6145 and MAP-T here is invalid.

regards,
maoke

2012/4/3 Rémi Després <[email-masked]>

> Hi, Guoliang,
>
> Interesting enough, the example you give illustrates that MAP-T needs to
> remain experimental, more than any other solution.
>
> 1.
> RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=1280. It
> specifies two behaviors, one that does this, and one that doesn't. Which
> one to choose isn't AFAIK specified in the MAP-T draft.
>
> 2.
> With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination unchanged.
> This is exactly what is necessary for PMTU discovery to work.
>
> 3.
> When we have a detailed report on which parts of MAP-T have been
> validated, with which options of RFC6145, it will be easier to analyze
> scenarios like the one you propose.
>
>
> In any case, thanks for providing one more evidence that the MAP-T
> specification isn't as clear as claimed to all those who support it, and in
> particular to some also criticize 4rd-U with invalid arguments.
>
> Regards,
> RD
>
>

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 03 Apr 2012 02:22:45 -0700

Hello,

I was not part of the design team and maybe my question was already answered
in some design team ML.

Is there a document describing where MAP-T was tested,  which products,
operators, test timespan,  test plan,  was it production network,  etc?

And btw, I'm not talking about IVI or the part of MAP-T that is compatible
with IVI. Sorry, but If I will back MAP-T I would like to see MAP-T data,
not a look alike.  I guess this brings another question whether there is a
plan to write a document to for those that have deployed IVI and want to
transition to MAP-T.

Thanks,

Reinaldo

From:  Maoke <[email-masked]>
Date:  Tue, 3 Apr 2012 09:07:00 +0000
To:  "Jan Zorz @ go6.si" <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rdŠ

2012/4/3 Jan Zorz @ go6.si <http://go6.si>  <[email-masked]>
> Given the situation with IPv4 exhaustion we have to hurry and go with what we
> know and what is proven to work today with no funky new features.
> 
> I agree that 4RD-U brings some good new features, but as it changes the IPv6
> current usage I suggest to redirect 4RD-U to BoF and to go through revision of
> also other working groups that needs to say their understanding of changed
> IPv6 transport behavior. I also believe that when 4RD-U goes through the whole
> proper procedure it might be widely adopted later as MAP replacement.
> 

agree and have the same feeling. i'd love to keep study what 4rd-u brings to
the transition architecture and more practices are not excluded along with
the 4rd-u getting well-understood. and if 4rd-u is
approved/improved/verified superior to both -T and -E through the whole
procedure, i don't think it will be a problem that MAP would be obsoleted in
the future. but that's of not our current situation, fixing the problem with
well-understood building blocks is what we must do as soon as possible.

- maoke
 
> 
> Speaking as A+P (RFC6346) co-author, we got many questions about A+P progress
> from operators and we learned that the time-frame for decision between CGN and
> something else is already nearly expired. If we want anything-A+P to still
> reach the operators, then the time for decision is now. We already missed the
> majority of that train, but last seats in last wagon are still reachable.
> 
> We need to act and not just to push the endless discussion (that is not that
> uncommon for any IETF WG :) ).
> 
> Cheers, Jan Zorz
> 

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

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 3 Apr 2012 18:31:22 +0900

> The above assertion, being wrong, is therefore misleading.

I already noticed rfc5082 as a detail.

> But many of those who have no motivation to look for flaws that don't exist, do understand that the design is safe.

I can't understand what you mean. Let us study it in your BOF.

> MAP-T may be more imprecise than MAP-E in this respect, but both have known bugs to be fixed (at least packet IDs of shared-addres CEs of MAP-T, and BR hairpinning in MAP-E).

thanks, the authors of map suite are working to improve the documents. Don't worry about encapsulation and translation.

> Besides, the exact list of MAP DHCPv6 parameters has yet to be finalized.

Besides, 4rd-u is on the stage of pre-BOF discussion.

cheers,
--satoru

---

From: Ole Trøan <[email-masked]>
Date: Tue, 3 Apr 2012 11:40:37 +0200

> The above assertion, being wrong, is therefore misleading.

there is more to this than comparing the IPv4 packet put into to the 4rd-U cloud against the packet exiting the 4rd-U cloud. (from that perspective MAP-T and 4rd-U are for most practical solutions equal (IMHO)).

1) MAP-E supports independence of IPv4 and IPv6 addressing. by using hub and spoke mode with a separate
   mapping rule per subscriber. in this mode e.g only ports could be embedded in the address. this is not
   possible in a translation solution like 4rd-U.

2) a node inside the network will treat translated packets different from encapsulated ones.
   e.g. for the purposes of counting or for applying features. for an encapsulated packet both the complete
   IPv4 datagram and the IPv6 header is available, and different features can be applied to both.

Ole

---

From: Maoke <[email-masked]>
Date: Tue, 3 Apr 2012 11:23:46 +0000

hi Reinaldo,

well, you pointed me as the first receiver. AFAIK, everyone participating
Beijing interim has viewed the prototype (if you rejected to call that as a
product) of MAP-T which is running over a production network. it was surely
not IVI, and some important test data has been presented in IETF meetings.
others may add information in response to your request but i don't think
they are obliged to do so here, in this thread, considering 4rd-u hasn't
have no even prototype yet.

regarding your second question, MHO, IVI that supported by RFC6052 address
mapping has different address plan with the MAP domain (you may be also
interested in reading draft-mdt-softwire-map-deployment and RFC6219). they
have different use cases in deployment. there is no question about
transition from IVI to MAP-T, to my understanding. i may agree if you mean
the existing RFCs related to IVI are still not enough to provide an
informational guideline for people who would like to deploy it.

thanks,
maoke

2012/4/3 Reinaldo Penno <[email-masked]>

> Hello,
>
> I was not part of the design team and maybe my question was already
> answered in some design team ML.
>

---

From: Maoke <[email-masked]>
Date: Tue, 3 Apr 2012 11:34:26 +0000

>> remain experimental, more than any other solution.
concluding above of my points, here your assert "MAP-T needs to remain
experimental" is invalid. - maoke

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Apr 2012 14:00:59 +0200

> I already noticed rfc5082 as a detail.

AFAIK, rfc5082 compatibility is ensured with TTL preservation that is in 4rd-u-06.
Anything more?

> I can't understand what you mean. Let us study it in your BOF.

There is no such thing as "my BOF"!

> thanks, the authors of map suite are working to improve the documents.

> Don't worry about encapsulation and translation.

Just being tired to hear that the spec if clean and complete, and to have to find out myself what is missing.

>> Besides, the exact list of MAP DHCPv6 parameters has yet to be finalized.

Thanks for having implicitly acknowledged this fact (contrary to the claim that MAP is completely specified).

> Besides, 4rd-u is on the stage of pre-BOF discussion.

Sorry to read this kind of argument from you.
No other comment.

RD

---

From: Simon Perreault <[email-masked]>
Date: Tue, 03 Apr 2012 08:16:04 -0400

>     possible in a translation solution like 4rd-U.

This mode of operation was suggested last week during the SD-NAT 
presentation. There seemed to be consensus among operators that it was 
not practically feasible.

>     IPv4 datagram and the IPv6 header is available, and different features can be applied to both.

In practice, the contents of encapsulated packets are rarely inspected 
by firewalls and other such devices.

IMHO at this point we should let the market decide. Publish both as 
experimental. Let's work on something else now.

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: Guoliang <[email-masked]>
Date: Tue, 3 Apr 2012 20:53:32 +0800

Hi, Remi:

I don't think my case illustrates MAP-T needs to remain experimental, my
comments are below:

> one to choose isn't AFAIK specified in the MAP-T draft.

RFC6145 says in Section 6: "It SHOULD be possible to configure a translator
for either of the two approaches", the first approach is that "IPv6 hosts,
IPv6-host-based firewalls, and IPv6 network firewalls can be administered
in compliance with Section 4.3.1 of [RFC4890]", the second approach is to
change PTB MTU value to 1280 in case PTB<1280 and set DF bit to 0 in case
the packet is less than or equal to 1280 bytes, if the requirements of the
first approach can't be met. It doesn't mean the administrator can refuse
to take the second approach according to his will.

> This is exactly what is necessary for PMTU discovery to work.

Actually, what I worry about is whether IPv6 packets of 4rd-U embedding
ICMPv4 packets could  traverse current IPv6 firewalls successfully.

> RFC6145, and therefore from MAP-T.

Please see Section 6 of RFC6145.

> particular to some also criticize 4rd-U with invalid arguments.

In fact, MAP-T is clear enough to be deployed without any problems, if you
read RFC6145 carefully.

Regards,
Guoliang

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Apr 2012 14:57:08 +0200

Maoke,

Please see in line.

Le 2012-04-03 à 11:21, Maoke a écrit :

> i checked the RFC6145 logic and behavior, very carefully, with the PTB < 1280 issue. there is no two behaviors but only one behavior supporting independent working of the IPv4-to-IPv6 and the IPv6-to-IPv4 translators. there is no question on which one to choose in the MAP-T draft.

Although I tried, I cannot share your interpretation:
- sec 6 introduces a problem due to some Host/FWs that don't support IPv6 PTB<1280 (although they should)
- Two approaches are proposed.
- The second one looses the IPv4 MTU information if < 1280 (creating a problem for PMTU discovery in IPv4)
- The first one isn't described, but consists in avoiding the problem, apparently by ensuring that all host/FWs support PTB<1280. Implicitly, this can be understood as no replacement of <1280 by = 1280.

Anything missed?

> (i think you may accept that a "if...else..." logic does not mean option). 
> 
> 2. it is necessary to verify, in practice, if the feature that IPv6 is carrying ICMPv4 message is secure. it is new to the IP/ICMP architecture. 

If you have something in mind, please detail.
AFAIK, it isn't difficult in a ISP domain to make sure IPv6 packets are transparently transmitted between BRs and CEs, even if their next header is 1 (that of ICMPv4).

> 
> 3. please refer to RFC6145 Sec 6 for the details (but maybe other sections are also needed to read). 

See 1. above.

> i think your objection to RFC6145 and MAP-T here is invalid. 

Not convinced by your comment.

Besides, even if it would be the case, the mail to which I was answering below was proposing to always change DF=1 into DF=0, instead of just in the fragmented-pcket case.
To me, this illustrates that MAP-t specification isn't so easy to understand where it deals with details of ICMP v4/v6 translations.
Criticisms addressed to 4rd-U should be more carefully studied before being made.

Regards,
RD

>> could traverse the IPv6 access network, but will be blocked in the IPv4 network.

(*)

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Apr 2012 14:57:57 +0200

Le 2012-04-03 à 11:40, Ole Trøan a écrit :

> there is more to this than comparing the IPv4 packet put into to the 4rd-U cloud against the packet exiting the 4rd-U cloud.

What else?

> (from that perspective MAP-T and 4rd-U are for most practical solutions equal (IMHO)).

Nothing new here, but this is only an opinion, not a technical consideration.

>  mapping rule per subscriber. in this mode e.g only ports could be embedded in the address.

New requirement?
New feature?
Your draft says "Each MAP node in the domain has the same set of rules."
It's getting very confusing.

BTW, is this something you claim to have been tested?

If you want to pursue this point, a use-case example with its mapping rules could help to understand what you have in mind.

> this is not

Yes, but so what?

>  IPv4 datagram and the IPv6 header is available, and different features can be applied to both.

I don't see what would be missing with 4rd-U: 
- the IPv4 payload is available
- IPv4 source and destination addresses are available in a fixed position of IPV6 addresses
- IPv6 packets that are header-mapped IPv4 packets are recognizable wit the V octet of the CE address

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Apr 2012 15:17:55 +0200

2012-04-03  14:43, guoliang han :

> Hi, Remi:
>  
> I don't think my case illustrates MAP-T needs to remain experimental, my comments are below:
>  
>  
> RFC6145 says in Section 6: "It SHOULD be possible to configure a translator for either of the two approaches", the first approach is that "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can be administered in compliance with Section 4.3.1 of [RFC4890]", the second approach is to change PTB MTU value to 1280 in case PTB<1280 and set DF bit to 0 in case the packet is less than or equal to 1280 bytes, if the requirements of the first approach can't be met. It doesn't mean the administrator can refuse to take the second approach according to his will. 
>  
> 
> 2.
> Actually, what I worry about is whether IPv6 packets of 4rd-U embedding ICMPv4 packets could  traverse current IPv6 firewalls successfully.

Typical use cases of 4rd-U have no firewall between BRs and CEs.
If some would exist, they should be configured to let ICMPv4 payloads go through (Protocol = 1)
This is like configuring them to accept IPv4 headers in IPv6 payloads (Protocol = 4)

> See Section 6 of RFC6145.

This isn't in RFC6145, simply a reference to (*) below.
If I misunderstood, please explain what.

> In fact, MAP-T is clear enough to be deployed without any problems, if you read RFC6145 carefully.

Replacing IPv4 PTB<1280 by IPv4 PTB=1280 should AFAIK be avoided for IPv4 PMTU discovery to work.
Still waiting for a clarification on this issue.

Regards,
RD

(retransmitted after deletion of unnecessary old text, message too big for the ML!) 

(*)

---

From: Guoliang <[email-masked]>
Date: Tue, 3 Apr 2012 21:46:04 +0800

Hi, Remi:

Pls read my comments below.
2012/4/3 Rémi Després <[email-masked]>

>  RFC6145 says in Section 6: "It SHOULD be possible to configure a
> translator for either of the two approaches", the first approach is that
> "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can be
> administered in compliance with Section 4.3.1 of [RFC4890]", the second
> approach is to change PTB MTU value to 1280 in case PTB<1280 and set DF bit
> to 0 in case the packet is less than or equal to 1280 bytes, if the
> requirements of the first approach can't be met. It doesn't mean the
> administrator can refuse to take the second approach according to his will.
>
>
>>
>>  2.

Hope so. Still anticipating experimental results proving that yet.

>  If I misunderstood, please explain what.

You surely misunderstood that. I mentioned "in that case", instead of
replacing DF=1 by DF=0 in all cases. Replacing DF bit only occurs in the
case that incoming packet size is less that 1280 bytes, which is exactly
the requirement of RFC6145.

> Still waiting for a clarification on this issue.

If the translator set DF bit to 0 in case the packet is less than or equal
to 1280 bytes, and replace PTB<1280 by PTB=1280, there are no problems on
the data path, whether in single/double translation.

Regards,
Guoliang

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Apr 2012 16:52:46 +0200

Le 2012-04-03 à 15:41, Guoliang a écrit :

> Le 2012-04-03 à 14:43, guoliang han a écrit :
> 
>> Hi, Remi:
>>  
> You surely misunderstood that. I mentioned "in that case", instead of replacing DF=1 by DF=0 in all cases. Replacing DF bit only occurs in the case that incoming packet size is less that 1280 bytes, which is exactly the requirement of RFC6145.

The so called "corner case" where RFC6145 looses the DF=1 is when a packet with DF=1 is already fragmented by its source. 
In this case, because there are several fragments, translates back to IPv4 with DF=0.

In the example you give, RFC6145 doesn't add a fragment header, in the IPv4 to IPv6 translation because the packet has DF=1 and isn't fragmented (sec 4).
The inverse translation, seeing no fragment header, the DF bit is normally set to 1 (sec 5.1). (A configuration option is mentioned so that the node MAY set it to 0 in some conditions, but MAP-T makes clear this must not be the case: "the IPv4 packets with DF=1 will be translated to IPv6 packets without fragmentation header and will be translated back to IPv4 packets with DF=1".)

> If the translator set DF bit to 0 in case the packet is less than or equal to 1280 bytes, and replace PTB<1280 by PTB=1280, there are no problems on the data path, whether in single/double translation. 

In any case, not a MAP-T feature.

RD

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 03 Apr 2012 17:14:25 +0200

Dear Softwires WG chairs.

For how long will you leave this useless cockfight go on instead of 
steering the working group into a direction, that may enable us to 
decide on something and chose the direction?

We are running in circles here and just amplificating the noise, coming 
from certain usual suspects.

Cheers, Jan

P.S: I too enjoy observing the roosters fight, but I don't think we have 
time for this now. :)

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 03 Apr 2012 08:14:39 -0700

From:  Maoke <[email-masked]>
Date:  Tue, 3 Apr 2012 11:23:46 +0000
To:  Cisco Employee <[email-masked]>
Cc:  "Jan Zorz @ go6.si" <[email-masked]>, <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rdŠ

hi Reinaldo,

well, you pointed me as the first receiver. AFAIK, everyone
participating Beijing interim has viewed the prototype (if you rejected to
call that as a product) of MAP-T which is running over a production network.
it was surely not IVI, and some important test data has been presented in
IETF meetings.

[Reinaldo]  I was not at the Interim meeting Can you point to the test data
so we can put this issue to rest?

[Reinaldo] humm....So, basically you are saying that since 4rd-U has no
prototype, others are not obliged to show their goods either.  I thought it
would be the other way around, I.e.,  go for the finish line: Let's push for
rough consensus and running code,  put the issue to rest and get MAP
adopted.  

[Reinaldo] Certainly.

thanks, 
maoke

> with IVI. Sorry, but If I will back MAP-T I would like to see MAP-T data, not
> a look alike.  I guess this brings another question whether there is a plan to
> write a document to for those that have deployed IVI and want to transition to
> MAP-T. 
> 
> Thanks,
> 
> Reinaldo

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 3 Apr 2012 16:31:21 +0000

Hi Remi,

> MAP-T may be more imprecise than MAP-E in this respect, but both have known bugs to be fixed (at least packet IDs of shared-addres CEs of MAP-T, and BR hairpinning in MAP-E).

If you pointed out bugs in the text of MAP-E/MAP-T drafts, we will correct it soon. But what you pointed out in the above has been already tested with our implementation of MAP-T/MAP-E. So, our MAP-E/MAP-T implementation has already supported BR hairpinning (hub&spoke model).

Thanks,
Tetsuya Murakami

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 3 Apr 2012 12:32:30 -0400

I don't see a way out of this thread. 

my suggestion:
- published both as experimental
- let the market decide
- come back later to move one or the other standard track.

Above all, I think having a stable specification (i.e. RFC) that implementers can code against  and providers to require is what is needed first. 

Marc.

Le 2012-04-03 à 11:14, Jan Zorz @ go6.si a écrit :

> For how long will you leave this useless cockfight go on instead of steering the working group into a direction, that may enable us to decide on something and chose the direction?
> 
> We are running in circles here and just amplificating the noise, coming from certain usual suspects.
> 
> Cheers, Jan
> 
> P.S: I too enjoy observing the roosters fight, but I don't think we have time for this now. :)

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 3 Apr 2012 20:56:45 +0200

The irony is that this is an apples and oranges comparison, and throwing
away ripe apples into some box with raw oranges looks rather unfair.

Some of the of the indicators are:
- MAP is not only the result of a consensus of a broad WG design team, but
also that of numerous authors of the merged drafts whihc have been
discussed for 1 year+. The 4rd-u technical proposals were evaluated by the
design team, and have not gained support there.
- MAP running code exist
- 4rd-U covers a technical corner case that is "self created" (if not self
invented/motivated)
- 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 sign-up
portal, etc)
- 4rd-U is not by any means "universal". As admitted it requires the
coupling with BIH, which features the same technical corner case that 4rd-u
claims to solve (doh).

The other aspect is that some different measure appears to be being applied
in this selection *for WG adoption* vs the selection of the other drafts in
softwire, which have gained WG draft status without even a shred of running
code.

-Woj.

On 3 April 2012 18:32, Marc Blanchet <[email-masked]> wrote:

> Above all, I think having a stable specification (i.e. RFC) that
> implementers can code against  and providers to require is what is needed
> first.
>
> Marc.
>
> steering the working group into a direction, that may enable us to decide
> on something and chose the direction?
> >

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 3 Apr 2012 16:07:08 -0400

well, let's see the other way around: what is the problem of publishing the two documents now?So that they are stable and have a RFC number. Then any implementer can implement based on the RFC. Providers can request their manufacturers to have a product which conforms to the RFC.

Marc.

Le 2012-04-03 à 14:56, Wojciech Dec a écrit :

> The irony is that this is an apples and oranges comparison, and throwing away ripe apples into some box with raw oranges looks rather unfair.
> 
> - MAP is not only the result of a consensus of a broad WG design team, but also that of numerous authors of the merged drafts whihc have been discussed for 1 year+. The 4rd-u technical proposals were evaluated by the design team, and have not gained support there.
> - MAP running code exist
> - 4rd-U covers a technical corner case that is "self created" (if not self invented/motivated)
> - 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 sign-up portal, etc)
> - 4rd-U is not by any means "universal". As admitted it requires the coupling with BIH, which features the same technical corner case that 4rd-u claims to solve (doh).
> 
> The other aspect is that some different measure appears to be being applied in this selection *for WG adoption* vs the selection of the other drafts in softwire, which have gained WG draft status without even a shred of running code.
> 
> -Woj.
>

---

From: Maoke <[email-masked]>
Date: Wed, 4 Apr 2012 02:25:14 +0000

well, i cannot help but send out this late Apr-1 joke: let's see what is
the problem publishing the two document plus an informational doc analysing
what problems 4rd-u introduces to architecture and real operation, with
them all stable and having an RFC number for each? if this is fine, we all
could be happy and the peace comes. lol

a serious point not of the Apr-1 joke: as an IETF WG, we are obliged to
provide surely high-quality document to the market. even we believe market
choice, at least we have to publish what we ourselves have well understood,
carefully coded and well tested. otherwise, the market would see IETF more
of a group of doc-makers rather than technology-explorers.

- maoke

----
- we reject kings, presidents, and voting...
- Rex redivit. vive le Roi.

2012/4/3 Marc Blanchet <[email-masked]>

> well, let's see the other way around: what is the problem of publishing
> the two documents now?So that they are stable and have a RFC number. Then
> any implementer can implement based on the RFC. Providers can request their
> manufacturers to have a product which conforms to the RFC.
>
> Marc.
>
> The other aspect is that some different measure appears to be being
> applied in this selection *for WG adoption* vs the selection of the other
> drafts in softwire, which have gained WG draft status without even a shred
> of running code.
>
> -Woj.
>

---

From: Congxiao Bao <[email-masked]>
Date: Wed, 4 Apr 2012 12:04:06 +0800

Fully agree with Maoke!

This is not just the issue of publishing two documents.......To accormodate
with 4rd-U, many existing RFCs should be updated, like RFC
4291,RFC6052,etc. There is no evidence to show that we need to do that
because 4rd-U havn't been shown that it is workable in today's Internet.

Congxiao

2012/4/4 Maoke <[email-masked]>

>> - MAP is not only the result of a consensus of a broad WG design team,
>> but also that of numerous authors of the merged drafts whihc have been

---

From: GangChen <[email-masked]>
Date: Wed, 4 Apr 2012 15:25:12 +0800

> longer claimed. MAP(-T) continues to allow these.

I don't see the difference between 4rd-U and MAP-T on this pionts.
BTW, woj, do you really see the value of supporting single
translation. I guess that is not targeting scenario for Softwires wg.
IMHO, this single translation is not sufficient in the wild. It's only
applicable for a subset of IPv6 address (i.e. IPv4-converted addresses
communicating with IPv4-translatable addresses)

BRs

Gang

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 4 Apr 2012 08:59:57 -0400

Le 2012-04-03 à 22:25, Maoke a écrit :
> 
> a serious point not of the Apr-1 joke: as an IETF WG, we are obliged to provide surely high-quality document to the market. even we believe market choice, at least we have to publish what we ourselves have well understood, carefully coded and well tested. 
> otherwise, the market would see IETF more of a group of doc-makers rather than technology-explorers.

agreed. then what do we do in the absence of consensus? I proposed one solution.

Marc.

---

From: Rémi Després <[email-masked]>
Date: Wed, 4 Apr 2012 18:24:47 +0200

+1

RD

---

From: Maoke <[email-masked]>
Date: Thu, 5 Apr 2012 00:52:57 +0000

2012/4/4 Marc Blanchet <[email-masked]>

> choice, at least we have to publish what we ourselves have well
> understood, carefully coded and well tested.
>

i propose another, maybe closer to the chairs' opinion: let's do the vote
and decide with the game rule of "majority wins", stopping the endless
vote. ;-) - maoke

---

From: Ralph Droms <[email-masked]>
Date: Wed, 4 Apr 2012 22:12:40 -0400

Here's the situation.  There was no clear consensus in the WG meeting in Paris.  But the IETF conducts its business on the mailing list, so - as we always do - the chairs asked for feedback on the two questions asked in Paris.  We'll use the responses to assess if there is consensus for the choices in each of those questions.

- Ralph

On Apr 4, 2012, at 8:52 PM 4/4/12, Maoke wrote:

> i propose another, maybe closer to the chairs' opinion: let's do the vote and decide with the game rule of "majority wins", stopping the endless vote. ;-) - maoke
>  
> 
> Marc.
> 
> 
>

---

From: Rémi Després <[email-masked]>
Date: Sun, 25 Mar 2012 15:38:03 +0200

Le 2012-03-25 à 14:08, Maoke a écrit :

> Le 2012-03-25 à 05:34, Maoke a écrit :
> 
>> dear Remi,
>> 2012/3/24 Rémi Després <[email-masked]>
>> 
>> Le 2012-03-22 à 15:40, Maoke a écrit :
>> 
>>> dear Alain, Yong, Ralph and all,
>>> 
>>> in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions  a little confused me: if we need to go back to the stage before the works of the MAP design team?  
>>> 
>>> The MAP series have reached running codes
>> 
>>> and the collective understanding of the community.
>> 
>> Here are some issues among those remaining before reaching "collective understanding":
>>  
>>  
>> some issues remaining not yet reaching collective undertanding is not a reason of making things over. the collective understanding has been reached for the major part of the
>> 1) MAP address format and the corresponding algorithms
>> 2) encapsulation and translation modes being supported by MAP format and the existing header processing standards 
>> 3) DHCP extensions as a way of distributing rules.
>>  
>> the above big picture are what i call "collective understanding". the correct way is: making these already gained approaches as bases, continuing discussion or even dabate on the details. i don't think it is a correct way of action to disrespect a team's work. 4rd-u's problem is even its big picture is still fuzzy.
> 
> Not more fuzzy than MAP (actually less fuzzy IMHO).
> Debate on details is possible for U as wall as for T+E.
>  
>  
> you may argue that MAP is much more fuzzy. but as i said, nobody knows exactly what the "4rd-u tunnel" is.

> you said it is just a reversible header mapping that is not tunnel

I rather say that reversible header mapping implements a "tunnel" variant.
 
> nor translation path section.

> then what does the "reversible header mapping" provides to the architecture of transition? you never clearly state this. 

The draft is AFAIK not ambiguous.
I tried to answer all your questions on this point I barely understand (neither an implementation nor an operation issue)

End of this point for me, if there is nothing significantly new.

>> a) T operation in hub&spoke (hasn't been so far answered in an understandable way).
>>  
>> i doubt i understand what you mean. may you please specify the question in details?
> 
> Is a DHCPv6 parameter needed, yes or no?
>  
>  
> i am not sure i know about the details of what you mean.

Today, there is no DHCPv6 parameter to require H&S, right?
My question is then: "is it sufficient to have none, or is it needed to add a new parameter".
Looking at more details would be premature for me until you have answered this question.

> do you mean the feature of R-2.C? if so, i happen to have following questions:
> 1) why hub&spoke topology should be announced to the CE? (IMHO, if a  CE is informed with the FMR involving other CEs, it works as mesh; if only BMR and DMR is informed, surely it is hub&spoke. i think this has been clarified in MAP Section 5.)
> 2) to this parameter issue, what is the difference between T and E?

None AFAIK.

> look forward to your further clarification/discussions! if you mean not the hub&spoke mode indicator, please specify your question further.
>  
>  
>> b) IDs from shared-address CEs.  T currently has so far no solution while both U and E include one. 
>>  
>>  
>> what do you mean with the IDs? or do you mean interface IDs? i don't see "IDs from shared-address CEs" in U too. please teach!
> 
> Sec 4.5.3. is "Packet Identifications from Shared-Address CEs".
> Did you read the complete draft?
>  
>  
> execuse me. it is my fault. i read it but i didn't realize you mean the datagram identification here. it is a good point, and not only this but also the issue of how BR deals with fragments of the same datagram where only the first fragment has the port number. for this point, i think MAP-T also needs to consider this problem described in the MAP-E Section 7, last 2 paragraphs. thanks a lot!

(*)
End of this subject.

> the text of Sec 8.2 of MAP-T and that of Sec 8.2 of MAP-E are clear enough to me. no one among MAP/MAP-T/MAP-E here needs to be changed. (i may partly agree with you that one could be further clarified).
>  
> 
>  
>> but it doesn't mean one doc is definitely reflecting "collective understanding" better than multiple.
>>  
>>  
>> d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp.
>>  
>>  
>> single mapping rule for a domain != single mapping rule for the IPv4 world.
> 
> ???
> 
>> the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and BMR being exclusive is a problem.
> 
> How many MAP mapping rules do you see for the equivalent of the IVI use case in a MAP domain? 
>  
>  

OK

>> The fact that no-one involved in the MAP design raised any of these issues is AFAIK sign that MAP has NOT reached "collective understanding of the community".
>> (Note that, concerning stateless v4/v6 solutions, I think I should be considered part of this community. Right? ).
>>  
>>  
>> well, "collective understanding" was mentioned by Sally Floyd to the community of Internet researchers, and i borrowed her term. but i understand: no matter it is research or engineering, collective understanding is the understanding on the problems and the architecture rather than the detailed technical solutions. the MAP architecture has been reflected in the works of the draft suite. on the other hand, the community is not the softwires wg but the whole Internet engineering circle.
>>  
>>  
>> 
>> Maoke, clarifications on these points will be welcome.
>> 
>> 
>>> From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. 
>>> 
>>> in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment.
>> 
>> Note: This excludes ISPs that would like to offer full IPv4 transparency with some IPv6-only middles boxes.
>> Right?
>>  
>>  
>> i cannot follow your "full IPv4 transparency" with "some" IPv6-only middle boxes. what does the "transparency" mean for the middle boxes? i understand, when we talk about the Internet transparency, we refer to the "end-to-end transparency". please specify your question concretely.
> 

>>> The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community. 
>>> 
>>> second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing the tunneling and translation, if accepted as standard, may trap the operators into a harsh situation of being unable to define what building block it really is.
>> 
>> Such an operator would know it uses 4rd-U. 
>>  
>>  
>> well, this is what i mean the uncertainty of 4rd-U in the architecture to the common understanding. as a analogy, one of Mr. E and Mr. T said, "i give you a horse", while the other said "i give you a donkey". then people well understand when they need a horse when they need a donkey. now Mr. U said "wow, i give you a fantastic donkorse!". there would be 2 possible results, not certain right now:
>> A. donkorse is just another sort of donkey, somehow good but somehow flawed.
>> B. donkorse is just donkorse, and people, taking a long time to understand it, and finally find it either a flawed or a quite good hybrid, like mule, useful in some cases.
>>  
>> no matter if the future result is A or B, now Mr. O understand what he needs for his business is either a horse and a donkey, with their well-known characteristics. Mr. MAP provides a wheeled car as the common instrument, while Mr. O needs a standard suite for the wheeled-car, the horse-driving and donkey-driving methods and the way of feeding the horse and donkey. this is the task of our wg, right now.  
>>  
>> Mr. U said you must have another type of wheel and drive it with my donkorse --- and when Mr. O asked him, what your donkorse is, he answered: you will know it is donkorse, having both the advantages of the horse and the advantages of the donkey. however, Mr. O doubts donkorse hasn't also the disadvantages of horse and the disadvantages of donkey and some flaws not yet documented. why not?
>>  
>>  
>> This doesn't seem to justify any FUD from co-authors from broadband and mobile operators (or from product vendors).
>> 
>>> It is stated as tunneling but actually behaves like tunnel in some aspects while like translation in some other aspects.
>> 
>> Yes indeed, thus achieving the best of both worlds without making it more complex. Actually making it clearly less complex than supporting both T and E.
>>  
>>  
>> i don't think those who made out mule expected the mule could replace horse and donkey and achieving a better world without horse and donkey but only mule. surely mule-only world is simpler.
> 
> Comparison is not reason (French proverb).
>  
>  
> i just try to understand what the 4rd-u reversible header mapping really is, in the term of architecture. this analogy is written as problem understanding rather than a reason of anything.  
>  
>  
> 
>>  
>>> (I have pointed out in the 4rd-u discussion thread).
>> 
>>> We see it only a yet-another-translation that try to solve some corner problems but introduces new, possibly major flaws (also pointed out in the technical threads on 4rd.)
>> 
>> "Possibly major flaws" isn't an identified point on which U would do less than what it has been designed to do (unified replacement of T + E).
>>  
>>  
>> i believe they are major flaws but i was gently argued with the "possibly" because i respected that maybe others didn't think so critically like me.
> 
> I have still to understand where you see "major flaws".
> Just asserting they exist, without explanation although others who read the specification don't see them isn't enough.
>  
>  

> Saying that E+T is better because its current inconsistencies are "details" isn't enough either (IMHO).
>  
>  
> different problems. E + T is actually not only the MAP-E and MAP-T, but the utilization of existing, already mature E and T with the new MAP format.  
>> IMPORTANT:  
>> - The essential characterization of U (vs T and E) is its Reversible header mapping (as replacement of both Double RFC6145 translation and Encapsulation).
>>  
>>  
>> yet-another-translation, with some issues still in debates.
>  
> You can call it as you wish, but the point remains that, with U, one doesn't need both E and T.
>  
>  
> no. U has changed the layered model of Internet protocol stack.

Different understanding.

> on the other hand, an operator needs the translation to encourage transition and mutual communications between IPv4 and IPv6 and double translation is included in such an environment. T has specifications for this working

BIH does the job with single translation.
Where U applies, both ends are IPv4, T has AFAIK no operational superiority while U is more transparent.

T too.

>> - Other features of U that differ from MAP (V-octet, CNP), or are complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this respect. Each of these features could be abandoned in U, or, if the WG appreciates what they offer, added to MAP.
>>  
>>  
>> MAP team has concluded V-octet and CNP are not necessary. do we need to debate again? i doubt people have unlimited time.
> 
> I made the point many times that the right to analyze problems didn't stop after a majority decision obtained during an improvised meeting.
> Many MAP contributors were absents, and no time was given to correct invalid objections that had been made just before during a WG meeting.
> 
>  
> the reason is simple,

(**)

Regards,
RD

>  
> - maoke
>  
> Note that several co-authors of the U proposal have been MAP contributors.  
>  
>  
> 
> 
>> - For this, community acceptance to listen to explanations, would be the normal process. I will be available this week for this.
>>  
>>  
>> i think we are all open to listen to and to discuss on any explorations but it doesn't mean we should stop standardization of our wheeled-car/horse-driving/donkey-driving/feeding suite with an expectation of a "better world" with only donkorse and the donkorse-specific wheeled car.
> 
> Your stand is clear, but comparison isn't reason.
> 
> RD
> 
> 
> 
> 
>> regards,
>> maoke
>>  
>>  
>> 
>> Cheers,
>> RD
>> 
>> 
>>> In either the term of architectural philosophy or technical details, introducing 4rd-u into standards would be harmful. 
>>> 
>>> personally, i respect the exploration of the author(s), and the discussion between me and the author encouraged me to comprehensively review E and T, and the result is: i bacame much more confident of the correctness of the MAP track. We should move forward. 
>>> 
>>> regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be put into standard track. Question is not about T, E or U. 
>>> 
>>> best regards,
>>> Maoke
>>> 
>>> 在 2012年3月20日星期二，Alain Durand 写道：
>>> Dear wg,
>>> 
>>> After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd.
>>> 
>>> 1) There  is an observation that all the solutions on the table E, T & U actually solve the stateless  problem we started with.
>>>    There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation
>>>    proposals, U is an hybrid unifying solution.
>>> 
>>> 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those
>>>    documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track.
>>> 
>>> We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T & U).
>>> Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation.
>>> 
>>> Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask
>>> and their sequence.
>>> 
>>> Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to?
>>> 
>>> If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market.
>>> If the answer is YES, we move to the next question.
>>> 
>>> 
>>> Q2: Do you believe that the WG should publish U as the one Standards Track document?
>>> 
>>> If the answer is YES, the process stop, we put U on the Standard Track and publish E & T as Informational.
>>> If the answer is NO, we are left with E & T (U then might be abandoned or published as Historical/Informational)
>>> 
>>> 
>>> Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)?
>>> 
>>> If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational.
>>> If there is no clear consensus on this question, we will publish both E & T as Experimental.
>>> 
>>> In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other.
>>> 
>>>  Alain & Yong, wg co-chairs.

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Apr 2012 15:13:11 +0200

Regards,
RD

(*)

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Apr 2012 16:48:59 +0200

RD

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 6 Apr 2012 10:00:44 +0000

+1

I've read the endless discussion, and found that is seems the MAP also has not fully convinced the ISP operation guys.
Since there's explicit controversy, why not just publish them both as experimental. why we must chose one as a "standard track"? Being a standard track can eliminate operators' misgiving?

If the technology is really appropriate, I don't think the "experimental" status would be a issue for the operators to adopt. Just let the operator decide by themselves. 

I remembered in the meeting venue, Joel Halpern who chairs Karp and lisp WG, suggested we publish both of them as experimental, and that was exactly how they handle the similar situation in their WG. I think his suggestion is reasonable to be considered. (To Joel: Pardon me if I improperly quoted your comment, or I just misunderstood your suggestion ). 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Tuesday, April 03, 2012 8:16 PM
> To: [email-masked]
> Subject: Re: [Softwires] Path to move forward with 4rd… 4rd-U as transparent
> as MAP-E
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 6 Apr 2012 14:48:33 +0000

I also followed the discussion. I appreciate both teams bought up the
technical details for both designs. To be honest, I fail to see which one
is better than other (yet). I like the fact that 4rd-u can do what MAP-T
does w/o introducing any encap overhead. But I understand the concerns
others brought up in the ML such as V-octet. For MAP-T, I like it not
introducing any new requirement to the IPv6 header, but I need more
published data to determine whether the double-translation would cause any
transparent issue or not. For example: I would very appreciate if somebody
who trial MAP can publish data such as what applications they have tested,
what pass and what fail.

This piece of work is very important because once we select it, this
technology will stay for long time. I do not want to rush to make a
decision and come back to regret in future.

On 4/6/12 6:00 AM, "Liubing (Leo)" <[email-masked]> wrote:

>+1
>
>I've read the endless discussion, and found that is seems the MAP also
>has not fully convinced the ISP operation guys.
>Since there's explicit controversy, why not just publish them both as
>experimental. why we must chose one as a "standard track"? Being a
>standard track can eliminate operators' misgiving?
>
>If the technology is really appropriate, I don't think the "experimental"
>status would be a issue for the operators to adopt. Just let the operator
>decide by themselves.
>
>I remembered in the meeting venue, Joel Halpern who chairs Karp and lisp
>WG, suggested we publish both of them as experimental, and that was
>exactly how they handle the similar situation in their WG. I think his
>suggestion is reasonable to be considered. (To Joel: Pardon me if I
>improperly quoted your comment, or I just misunderstood your suggestion
>). 
>
>> Subject: Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as
>>transparent
>> as MAP-E
>> 
>> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using
>>hub
>> and spoke mode with a separate
>> > 2) a node inside the network will treat translated packets different
>>from
>> encapsulated ones.
>> >     IPv4 datagram and the IPv6 header is available, and different
>>features
>> can be applied to both.
>>

---

From: Congxiao Bao <[email-masked]>
Date: Mon, 9 Apr 2012 13:41:06 +0800

Hi,

MAP-T has been tested in CERNET2 and we have tested applications such as
http, telnet, ssh，ftp, icmp echo request/reply, qq, skype, msn,  video (for
example: youku.com, xunlei.com, etc)  without any problem.

Congxiao

2012/4/6 Lee, Yiu <[email-masked]>

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 9 Apr 2012 06:17:42 +0000

> technical details for both designs. To be honest, I fail to see which
> one is better than other (yet). I like the fact that 4rd-u can do what
> MAP-T does w/o introducing any encap overhead. But I understand the
> concerns others brought up in the ML such as V-octet. For MAP-T, I like
> it not introducing any new requirement to the IPv6 header, but I need
> more published data to determine whether the double-translation would
> cause any transparent issue or not. For example: I would very
> appreciate if somebody who trial MAP can publish data such as what
> applications they have tested, what pass and what fail.
> 

We would like to see both solution published. So that, operators can choose according to their own networks and preference. There are enormous number of operators, who do not come to IETF meeting or do not participate in ML either. They also need to choose IPv6 transition mechanisms. They should be provided enough technical supports. That's the response of IETF, in our understanding.
 
> >status would be a issue for the operators to adopt. Just let the
> >operator decide by themselves.
> >
> >I remembered in the meeting venue, Joel Halpern who chairs Karp and
> >lisp WG, suggested we publish both of them as experimental, and that
> >was exactly how they handle the similar situation in their WG. I think
> >his suggestion is reasonable to be considered. (To Joel: Pardon me if
> I
> >> From: [email-masked] [mailto:[email-masked]]
> >>On  Behalf Of Simon Perreault
> >>transparent  as MAP-E
> >> >     mapping rule per subscriber. in this mode e.g only ports could
> >> > be
> >> embedded in the address. this is not
> >> presentation. There seemed to be consensus among operators that it
> >> was not practically feasible.
> >>
> >> >     e.g. for the purposes of counting or for applying features.
> for
> >> > an
> >> encapsulated packet both the complete
> >> In practice, the contents of encapsulated packets are rarely
> >> inspected by firewalls and other such devices.
> >>
> >>

---

From: Maoke <[email-masked]>
Date: Mon, 9 Apr 2012 07:24:30 +0000

hi Yiu and others,

1. "both published" does surely conflict with the design goal of 4rd-U
itself:
   unification of multiple standards. politically speaking, the 4rd-u
authors'
   positition is now quite confusing.

2. operators surely need to choose IPv6 transition mechanisms but such a
choice
   is based on their demand and understanding to the existing and
well-tested,
   well-practiced building blocks. i don't think any operators are waiting
for
   an option of choice they never see and never understand. and the "enough
   technical supports" is now still "a check without signature". i do
suggest
   the 4rd-u authors and supporters say that after making something real.

   on the other hand, 4rd-u makes a tight coupling between the address
format
   and its own header mapping mechanism. this makes an operator unable to
have
   different choices of transition mechanism as long as it chooses 4rd-u.
if
   you concern the choice of IPv6 transition mechanism, i do recommend MAP,
as
   either encapsulation or translation is operatable with MAP address/port
   mapping without difficulty.

3. surely MAP still has room of improvement but i don't think there are
   architectural uncertainty as 4rd-U has. request on more testing data is
   surely appreciated but please think it over again if it is a correct way
   to require further data of a counterpart in order to defense a solution
   without any data.

4. even there were no MAP at all, current level of 4rd-U is far premature
to be
   talked about any working group acception.

the authors and supporters will be appreciated if they talk about the
acception
after their coding and testing and refinement on the document according to
their
practical experiences, and understanding the problem again and again.

thanks,
maoke

2012/4/9 Sheng Jiang <[email-masked]>

> We would like to see both solution published. So that, operators can
> choose according to their own networks and preference. There are enormous
> number of operators, who do not come to IETF meeting or do not participate
> in ML either. They also need to choose IPv6 transition mechanisms. They
> should be provided enough technical supports. That's the response of IETF,
> in our understanding.
>

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 09 Apr 2012 09:50:12 +0200

On 4/9/12 8:17 AM, Sheng Jiang wrote:
> choose according to their own networks and preference.

Disagree. This would hypothetically be nice for operators to have a 
choice, but vendors (looks like) will not implement two slightly 
different solutions in same hardware.

On the other hand, who will make operators understand, what the 
difference really is and what are the dangers deploying one or another?

Cheers, Jan

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 09 Apr 2012 09:52:14 +0200

On 4/9/12 9:24 AM, Maoke wrote:
>     well-practiced building blocks. i don't think any operators are
> waiting for
>     and its own header mapping mechanism. this makes an operator unable
> to have
>     different choices of transition mechanism as long as it chooses
> 4rd-u. if
>     you concern the choice of IPv6 transition mechanism, i do recommend
> MAP, as

+1

Agree.

Cheers, Jan

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 9 Apr 2012 07:56:00 +0000

Please allow me to clarify myself: I support both MAP and 4rd-u.

MAP has been a good effort with many experts together in IPv4/IPv6 transition area and has been proved by running code. It also need to improve itself before being published as a RFC later. This process will take several months.

Personally, I think 4rd-u is a little bit behind MAP in maturity aspect for now. But, it is only matter of time. The authors have agreed to remove the architectural conflict, if there was any. We have offered to help on the improvement by implementation.

Giving time, both solution can be mature enough for operations. IETF does not have to choose one by now. And, these two solutions are not necessary to be a same pace.

Best regards,

Sheng

From: Maoke [mailto:[email-masked]]
Sent: Monday, April 09, 2012 3:24 PM
To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; [email-masked]
Subject: Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as transparent as MAP-E

hi Yiu and others,

1. "both published" does surely conflict with the design goal of 4rd-U itself:
   unification of multiple standards. politically speaking, the 4rd-u authors'
   positition is now quite confusing.

2. operators surely need to choose IPv6 transition mechanisms but such a choice
   is based on their demand and understanding to the existing and well-tested,
   well-practiced building blocks. i don't think any operators are waiting for
   an option of choice they never see and never understand. and the "enough
   technical supports" is now still "a check without signature". i do suggest
   the 4rd-u authors and supporters say that after making something real.

   on the other hand, 4rd-u makes a tight coupling between the address format
   and its own header mapping mechanism. this makes an operator unable to have
   different choices of transition mechanism as long as it chooses 4rd-u. if
   you concern the choice of IPv6 transition mechanism, i do recommend MAP, as
   either encapsulation or translation is operatable with MAP address/port
   mapping without difficulty.

4. even there were no MAP at all, current level of 4rd-U is far premature to be
   talked about any working group acception.

the authors and supporters will be appreciated if they talk about the acception
after their coding and testing and refinement on the document according to their
practical experiences, and understanding the problem again and again.

thanks,
maoke

2012/4/9 Sheng Jiang <[email-masked]<mailto:[email-masked]>>

> On 4/6/12 6:00 AM, "Liubing (Leo)" <[email-masked]<mailto:[email-masked]>> wrote:
>
> >+1
> >
> >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> >> To: [email-masked]<mailto:[email-masked]>

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 9 Apr 2012 08:04:20 +0000

> difference really is and what are the dangers deploying one or another?

Operators have their own brains. They may listen to vendors, but they do think by themselves and make decisions by themselves. Vendors would implement whatever the operators order. 

There are a large number of operators. There are very slim chance they will all stick on a same transition mechanism. We all know there have no one-suit-all solution for IPv4/IPv6 transition. IETF have produced many transition mechanisms. Obviously, they are not "enough". That's why we are still here to discuss more.

Sheng

---

From: Rémi Després <[email-masked]>
Date: Mon, 9 Apr 2012 10:13:22 +0200

Le 2012-04-09 à 09:56, Sheng Jiang a écrit :
> ...
> Giving time, both solution can be mature enough for operations. IETF does not have to choose one by now.

+1

Besides, in view of the clear lack of WG consensus in Paris, that is the only fair approach at this stage.

Regards,
RD

> And, these two solutions are not necessary to be a same pace.
>  
> Best regards,
>  
> Sheng
>

---

From: Maoke <[email-masked]>
Date: Mon, 9 Apr 2012 09:38:36 +0000

> MAP has been a good effort with many experts together in IPv4/IPv6
> transition area and has been proved by running code. It also need to
> improve itself before being published as a RFC later. This process will
> take several months.
>
>
>
> Personally, I think 4rd-u is a little bit behind MAP in maturity aspect
> for now. But, it is only matter of time. The authors have agreed to remove
> the architectural conflict, if there was any. We have offered to help on
> the improvement by implementation.
>
>
>
> Giving time, both solution can be mature enough for operations. IETF does
> not have to choose one by now. And, these two solutions are not necessary
> to be a same pace.
>

what if, giving time, people can be mature enough to identify 4rd-U is
really a flawed donkorse? ;-) if the 4rd-u designers are so confident, why
not do the real coding work first and then propose it as a replacement of
MAP suite? i don't see any unfairness here. - maoke

>
>
> Best regards,
>
>
>
> Sheng
>
>
>
> *From:* Maoke [mailto:[email-masked]]
> *Sent:* Monday, April 09, 2012 3:24 PM
> *To:* Sheng Jiang
> *Cc:* Lee, Yiu; Liubing (Leo); Simon Perreault; [email-masked]
>
> *Subject:* Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as
> transparent as MAP-E
>
>
>
> hi Yiu and others,
>
>
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 9 Apr 2012 09:37:52 +0000

...
> Operators have their own brains. They may listen to vendors, but they do think
> by themselves and make decisions by themselves. Vendors would implement
> whatever the operators order.
...

+1
I believe most of the time operators understand their own networks much better than other engineers. 
Operators come to IETF with some requirements, if there're multiple solutions offered, finally they should make the choice by themselves.

"rough consensus and running code" maybe is not sufficient for operators to have a decision of long-term deployment model, especially the "consensus" seems not so strong so far.

---

From: Maoke <[email-masked]>
Date: Mon, 9 Apr 2012 09:52:12 +0000

>  Without any objection to MAP, we just start to coding 4rd-u and help to
> improve it.
>

fine. we'd love to see it out with good amount of data and good amount of
feedback from testing operators. if you invite me to test, i'd love to
provide challenging scenarios. ;-) but it doesn't mean we should postpone
current process of standardization of MAP, because the result of 4rd-u is
still unsure. - maoke

>
>
> Multiple transition mechanisms would co-exist in the world. Neither MAP
> nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all solution.
>

> *Sent:* Monday, April 09, 2012 5:39 PM
>
> *To:* Sheng Jiang

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 9 Apr 2012 10:01:32 +0000

Without any objection to MAP, we just start to coding 4rd-u and help to improve it.

Multiple transition mechanisms would co-exist in the world. Neither MAP nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all solution.

From: Maoke [mailto:[email-masked]]
Sent: Monday, April 09, 2012 5:39 PM
To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; [email-masked]
Subject: Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as transparent as MAP-E

what if, giving time, people can be mature enough to identify 4rd-U is really a flawed donkorse? ;-) if the 4rd-u designers are so confident, why not do the real coding work first and then propose it as a replacement of MAP suite? i don't see any unfairness here. - maoke

---

From: Maoke <[email-masked]>
Date: Mon, 9 Apr 2012 10:16:32 +0000

2012/4/9 Liubing (Leo) <[email-masked]>

>  >fine. we'd love to see it out with good amount of data and good amount
> of feedback from testing operators.
>
> >if you invite me to test, i'd love to provide challenging scenarios. ;-)
>
> >but it doesn't mean we should postpone current process of standardization
> of MAP, because the result of 4rd-u is still unsure. - maoke
>
>
>
> I’d love to see operators find proper mechanisms respectively according to
> their own situations, rather than some mechanisms **out**.
>

joke. operators haven't know what the 4rd-u is. operators never make
selection on things not belonging to its knowledge. come on, believe me, as
an engineer in an operator company, the real operators are more
conservative than me. ;-)

>
>
> The transition mechanisms are developed for the operators, but in my
> observation, the MAP hasn’t  proved sufficiently for operators’ long-term
> selection. So why we have to rush to a **stand track**?
>

it is only your observation and it is a different question. you may argue
that the MAP is not mature enough for the wg acceptance but the wg is doing
a consensus decision.

on the other hand, as i pointed out, even there is no MAP at all, i don't
think 4rd-u now is at the time of talking about wg acceptance.

may i suggest, as you have promised that you will code the stuff, to start
the coding work as soon as possible. i don't like to make out a testing
list but finally see nothing to test. thanks!

- maoke

> *Sent:* Monday, April 09, 2012 5:52 PM
>
> *To:* Sheng Jiang

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 09 Apr 2012 12:36:42 +0200

On 4/9/12 11:37 AM, Liubing (Leo) wrote:
>> Operators have their own brains. They may listen to vendors, but
>> they do think by themselves and make decisions by themselves.
>> Vendors would implement whatever the operators order.
> ...
>
> +1 I believe most of the time operators understand their own networks
> much better than other engineers. Operators come to IETF with some
> requirements, if there're multiple solutions offered, finally they
> should make the choice by themselves.
>
> "rough consensus and running code" maybe is not sufficient for
> operators to have a decision of long-term deployment model,
> especially the "consensus" seems not so strong so far.

This probably means the vendors fight for customers, each deploying 
different not compatible solutions and CPE vendors will have to deploy 
all of them in order to be able to sell to different operators.

Vendors did it in the past and it looks like we did not learn.

I understand that VendorX would like to lock his customers to his 
solution, but that's a trap. A walled garden. I buy solutionX from 
VendorX and can't change it in the future, because my CPE base is locked 
to solutionX.

Can we please do it properly this time?

Cheers, Jan

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 09 Apr 2012 12:39:04 +0200

> nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all solution.

MAP or 4RD cannot replace 6RD, because the goal is different. But they 
were specifically done to replace DS-Lite and all CGN derivatives (and I 
hope we are not too late for that).

Cheers, Jan

---

From: "Antonio M. Moreiras" <[email-masked]>
Date: Mon, 09 Apr 2012 08:00:01 -0300

Em 09/04/12 04:56, Sheng Jiang escreveu:

> Giving time, both solution can be mature enough for operations. IETF
> does not have to choose one by now. And, these two solutions are not
> necessary to be a same pace.

IMHO the problem is that we don't have time.

We have to consider that some ISPs are already committing themselves
with NAT444, or other CGNs, for the transition. A transition based on
A+P could be a better choice, but we have to have a real option to do
that in a very short time.

I think that it is the time to focus on one solution. If the decision is
further delayed, it could be useless, because operators will have
followed other paths, without even considering A+P. It seems to me that
there is no more time to decide upon the ideal solution. We have to go
with a choice already tested, with running code, proven to be good
enough and workable, and it happens to be MAP. The perfect is the enemy
of the good.

Moreiras.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 9 Apr 2012 12:36:30 +0000

> From: Jan Zorz @ go6.si [mailto:[email-masked]]
> Sent: Monday, April 09, 2012 6:37 PM
> To: Liubing (Leo)
> Cc: Sheng Jiang; [email-masked]

[Bing] If operators' networks have different requirements, I guess we'll have to implement different CPEs. I think the networks' requirements should be the higher priority.
I'm not a CPE expert, but as I learned, customized CPE is normal in current networks, is it a big problem?

> VendorX and can't change it in the future, because my CPE base is locked
[Bing] That's true, but it's not the situation of what we are discussing. In fact, if we hurry to make a choice right now, it is just like to be locked in one solution. We should open the choices to the operators, let them decide.

---

From: Alain Durand <[email-masked]>
Date: Mon, 9 Apr 2012 07:45:31 -0700

Makoe,

The usage of disparaging language does not benefit the clarity of the discussion.
I understand that english may or may not be your primary language, nor is it for the majority of the wg members.

I encourage everybody to remain civil in this discourse.

As about implementation, they are a required element in the IETF standard process when we move from Proposed Standard to Draft Standard.
I know that the routing area has experimented with requiring implementation for Proposed Standard, but I'm not aware of any such requirement
in the Internet Area.

Alain.

On Apr 9, 2012, at 5:38 AM, Maoke wrote:

---

From: Maoke <[email-masked]>
Date: Tue, 10 Apr 2012 01:07:17 +0900

dear Alain,

thanks a lot for the message. i apologize for the language disparaging that
i used in the above discussion. please Sheng and Bing accept my apology.

what i am meaning is unchanged: i'm willing to contribute testing scenarios
if people think they are useful for problem understanding and/or protocol
improvement.

sincerely,
maoke

2012/4/9 Alain Durand <[email-masked]>

> As about implementation, they are a required element in the IETF standard
> process when we move from Proposed Standard to Draft Standard.
> I know that the routing area has experimented with requiring
> implementation for Proposed Standard, but I'm not aware of any such
> requirement
> in the Internet Area.
>
> Alain.
>
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 9 Apr 2012 19:39:17 +0200

Le 2012-04-09 à 12:16, Maoke a écrit :

> >fine. we'd love to see it out with good amount of data and good amount of feedback from testing operators.
> 
> >but it doesn't mean we should postpone current process of standardization of MAP, because the result of 4rd-u is still unsure. - maoke 
> 
>  
> I’d love to see operators find proper mechanisms respectively according to their own situations, rather than some mechanisms *out*.
> 
> 
> joke. operators haven't know what the 4rd-u is.

This is disparaging for operator engineers who took the time to read the specification (not to speak about those who co-autrhored the specification!).

> operators never make selection on things not belonging to its knowledge. come on, believe me, as an engineer in an operator company, the real operators are more conservative than me. ;-) 
>  
>  
> The transition mechanisms are developed for the operators, but in my observation, the MAP hasn’t  proved sufficiently for operators’ long-term selection. So why we have to rush to a *stand track*?
> 
> 
> it is only your observation and it is a different question.

> you may argue that the MAP is not mature enough for the wg acceptance but the wg is doing a consensus decision.

Precisely, and people who attended MAP and 4rd presentations couldn't reach consensus.

> on the other hand, as i pointed out,

> even there is no MAP at all, i don't think 4rd-u now is at the time of talking about wg acceptance. 

WKG acceptance of 4rd as experimental isn't a long term commitment.

> may i suggest, as you have promised that you will code the stuff, to start the coding work as soon as possible. i don't like to make out a testing list but finally see nothing to test. thanks! 

Could you please at least describe, without waiting for anything else, the worst challenging scenario you have in mind?
This is a way to make progress.

Thanks,
RD

> Sent: Monday, April 09, 2012 5:52 PM
> 
> 
> To: Sheng Jiang
> fine. we'd love to see it out with good amount of data and good amount of feedback from testing operators. if you invite me to test, i'd love to provide challenging scenarios. ;-) but it doesn't mean we should postpone current process of standardization of MAP, because the result of 4rd-u is still unsure. - maoke 
> 
>  
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 9 Apr 2012 19:40:17 +0200

> if you invite me to test, i'd love to provide challenging scenarios.

Providing such challenging scenarios to the WG will be welcome.
That's a way to make progress.
Thanks,

> ;-) but it doesn't mean we should postpone current process of standardization of MAP,

Publishing MAP and 4rd as experimental doesn't slow down publication of specifications, on the contrary.
It just expresses that work in Softwire has made very serious progress, but isn't finished yet.
  
> because the result of 4rd-u is still unsure.

... MAP-T+E is unsure too, with its unfinished specification, and without report on tested scenarios.

Besides, each of T and E  (which until recently were well understood as TWO proposed standards) has sure limitations that are, as you know, avoided by design with 4rd-U. 

Regards,
RD

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 9 Apr 2012 22:21:59 +0000

Hi Congxiao,

Thanks for sharing with us some of the tests MAP has been tested. Could you
please share some test cases and data to the team? This is the way to clear
our doubts. 

Thanks,
Yiu

From:  Congxiao Bao <[email-masked]>
Date:  Mon, 9 Apr 2012 13:41:06 +0800
To:  "Yiu L. LEE" <[email-masked]>
Cc:  "Liubing (Leo)" <[email-masked]>, Simon Perreault
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as
transparent as MAP-E

Hi,
 
MAP-T has been tested in CERNET2 and we have tested applications such as
http, telnet, ssh，ftp, icmp echo request/reply, qq, skype, msn,  video (for
example: youku.com <http://youku.com> , xunlei.com <http://xunlei.com> ,
etc)  without any problem.
 
Congxiao

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 9 Apr 2012 22:45:50 +0000

Dear Maoke,

Comments inline:

From:  Maoke <[email-masked]>
Date:  Mon, 9 Apr 2012 07:24:30 +0000
To:  Sheng Jiang <[email-masked]>
Cc:  "Yiu L. LEE" <[email-masked]>, "Liubing (Leo)"
<[email-masked]>, Simon Perreault <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as
transparent as MAP-E

hi Yiu and others, 

[YL] I can live with both stay as draft format. When Remi proposed 4rd-u,
what he saw was a way to use reverse-header to support encapsulation w/o
encapsulation overhead. This is why he called it "Unified". However, this
doesn't mean it must replace MAP-E/T. This recalls me when L2-MPLS started
the work, we had BGP and LDP for signaling. In the end, we have RFC4761 and
RFC4762. It isn't end of the world, is it?

[YL] I think we have at least one volunteer in the ML taking this job.
Thanks Sheng Jiang.

[YL] Sorry for my lack of knowledge. Please explain how MAP isn't coupling
address format and header mapping?

[YL] Again, MAP has started the work couple years earlier back to
double-IVI. Thanks for the good work. 4rd-u only started in few months.  All
I asked is to give time to understand both protocols better. That's it.

[YL] Last remark. MAP and 4rd-u both work inside the operator network, they
are connected by IPv4 network, they don't need to interwork with each other,
so incompatibility isn't a concern here. In theory, an operator can deploy
4rd-u in one test site and MAP in other test site to compare their good and
bad. We do this all the time for other technologies, why when we come to MAP
vs 4rd-u, we can't do something similar?

4. even there were no MAP at all, current level of 4rd-U is far premature to
be 
   talked about any working group acception.

thanks, 
maoke

> We would like to see both solution published. So that, operators can choose
> according to their own networks and preference. There are enormous number of
> operators, who do not come to IETF meeting or do not participate in ML either.
> They also need to choose IPv6 transition mechanisms. They should be provided
> enough technical supports. That's the response of IETF, in our understanding.
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 9 Apr 2012 22:52:01 +0000

I am sorry, the two drafts should be RFC4447 and RFC4761. My mistake.

From:  "Yiu L. LEE" <[email-masked]>
Date:  Mon, 9 Apr 2012 22:45:50 +0000
To:  Maoke <[email-masked]>, Sheng Jiang <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as
transparent as MAP-E

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 9 Apr 2012 22:59:50 +0000

I am sorry flooding the mailing list. Rajiv is kind to remind me I am wrong.
RFC4761/4762 are meant for VPLS. According to this link
http://www.networkers-online.com/blog/2009/01/draft-martini-draft-kompella-a
nd-l2vpn-services/, draft-martini was published as RFC4906 (Categorized as
Historic). Both LDP and BGP was combined to be RFC6074. draft-kompella was
never standardized.

Date:  Mon, 9 Apr 2012 22:52:01 +0000

---

From: Maoke <[email-masked]>
Date: Tue, 10 Apr 2012 10:04:17 +0000

2012/4/9 Rémi Després <[email-masked]>

> feedback from testing operators.
>
>
>

thanks, Remi, for the encouragement. i think the first step is to clarify
"what is needed to be ensured through the test". for this purpose, i made
out an I-D (as i already posted to the wg), discussing the semantics issue
of 4rd-U according to my understanding up to now. i think i wrote that as
neutral as possible, and took my best effort in avoiding to write what i
have not understood. if you (also others) find anything misunderstood,
please don't hesitate to point out.

thanks,
maoke

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 9 Apr 2012 09:44:47 +0000

Best regards,

Sheng

From: Maoke [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, April 09, 2012 3:24 PM
To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; [email-masked]<mailto:[email-masked]>

hi Yiu and others,

thanks,
maoke

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 9 Apr 2012 10:00:34 +0000

Best regards,

Sheng

hi Yiu and others,

thanks,
maoke

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 9 Apr 2012 10:04:11 +0000

To: Sheng Jiang

Best regards,

Sheng

hi Yiu and others,

thanks,
maoke

---

From: Maoke <[email-masked]>
Date: Wed, 11 Apr 2012 03:29:48 +0000

hi Yiu,

sorry but i just found i missed a technical issue you left in this message.

2012/4/9 Lee, Yiu <[email-masked]>

> address format and header mapping?

tight coupling here, i mean, that 4rd-u header mapping mechanism sometimes
depends on features of the address format, like the CNP and the V-octet.
for example, it removes the L4 checksum adjustment, this makes the whole
system MUST following the addressing with CNP.

for the MAP, things are different. boxes are implemented with existing
header processing modules but only need to add MAP address mapping module
into them. once the operator deploys MAP following its addressing plan
paradigm (we are still working on a better guidance for this in the MAP
deployment draft), the operator can choose either MAP-T or MAP-E for the
header mapping without the need of changing their addressing plan. if the
operator find translation is suitable for this part after a certain period
of practice on encapsulation, it can switch the mode by informing the CE to
change the mode of working (surely sometimes such an action of informing is
not easy in practice for, e.g., the home CE subscribers but it is feasible
for enterprise networking). another example of de-coupling is translation
approach: RFC6052 defines a stateless address mapping while RFC6145 defines
the header processing which is usable for both stateless and stateful
solutions, both 1:1 case for non-renumbering transition and residual
deployment of MAP.

implementation does also benefit from the de-coupling. the RFC6145
translation module can directly work with address mapping module of MAP or
RFC6052. the MAP address module can work with header processing module of
RFC2473 (for MAP-E) or translation module of RFC6145 (for MAP-T).

it doesn't mean the tight coupling doesn't work. like the Burton snowboard,
it works fantastically with its own system of bindings, not interchangable
for other brands ;-) however, in most of time, we really think
interchangability, supported by loose coupling, is preferred.

cheers,
maoke

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Apr 2012 11:30:24 -0500

On Tue, Apr 10, 2012 at 10:29 PM, Maoke <[email-masked]> wrote:
> depends on features of the address format, like the CNP and the V-octet. for
> example, it removes the L4 checksum adjustment, this makes the whole system
> MUST following the addressing with CNP.
>

I fail to understand why there is so much hype around these standards,

6145 is the good old SIIT
6052 defines NAT64 prefixes.

Behcet

---

From: Maoke <[email-masked]>
Date: Thu, 12 Apr 2012 07:14:47 +0900

2012/4/12 Behcet Sarikaya <[email-masked]>

> to
> 4rd-u.

2765 is the old SIIT. 6145 changes it to a certain extent.

the above is just my understanding on the content separation of 6052, 6144,
6145, 6146. what i said was only one point -- "decoupling". and i like
these standards having this. i don't see where there is "so much".  as to
the "hype", well, no comment. out of technical discussion. ;-)

- maoke

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Apr 2012 21:35:39 -0500

>> >>    mapping without difficulty.

[Behcet]
So you see MAP as a single protocol and say that the operator can
start with either one and then change it to the other one?
Then you negate yourself saying that it may not be so easy.

My simple argument then is why not start with three as some people
suggested and interchange between the three?

All these three are different flavors of the 4rd protocol.

Somehow you don't like to hear the words 4rd.

---

From: Maoke <[email-masked]>
Date: Thu, 12 Apr 2012 03:30:34 +0000

> start with either one and then change it to the other one?

well, easy to change in the term that the device support both and only a
switch-on/off is enough to work.

> Then you negate yourself saying that it may not be so easy.

not easy to change in the term that in some deployment cases (like home
network), CPE are controlled by users rather than the provider, so
informing them to do the switch-on/off might be a sort of work. ;-)

interchangeability between the three is fine but costs. MAP modules for
header processings have been ready but 4rd-u header processing module must
be code and administered separately. MAP address scheme is different from
4rd-u and therefore the address mapping modules are also needed to
separate. you may wonder why the address format cannot be unified. i wonder
too. the story is, MAP design team was aiming to make a unified address
mapping format and it has reached a rough consensus on the format, as we
see now in MAP draft, where V-octet and CNP are decided by the team not to
include. however, some insist they are critically important.

> Somehow you don't like to hear the words 4rd.

:) well, actually, i was the one who wrote in the MAP deployment draft that
MAP is defined for IPv4 residual deployment. i like the 4rd word very much
because this word helps the understanding of MAP addressing plan starting
from IPv6 prefix delegation, (which is quite different from the typical use
case of RFC6052). recently i avoid using 4rd (but clearly MAP and 4rd-u)
just because some people recently mentioning 4rd actually refer to 4rd-u
only. i respect this way of calling but avoid to make any confusion by
myself.

hope it clarifies.

- maoke

---

From: "Jiang Dong" <[email-masked]>
Date: Wed, 18 Apr 2012 11:08:58 +0800

Hi Shishio,

It seems the definition of 6rd MIB is more acceptable than the extension of IP tunnel MIB according to the  Softwire meeting in Paris.

Since the 6rd MIB draft itself is quite clear, a clarification of using one specific way would be helpful : )

Regards!
Jiang Dong
2012-04-18

From: Shishio Tsuchiya
Date: 2012-03-26 22:19
To: jiangdong345
CC: cai.lei3; jacni; softwires; cuiyong
Subject: Re: [Softwires]Comments about 6rd MIB
Jiang
Thanks for comments.
I will do presentation this draft at Friday,and I will ask which idea is better to the audience and chairs.
If IP tunnel MIB extended is better than 6rdMIB,so we would update and define extension of IP tunnel MIB.
6rd MIB is completely reflecting to 6rd configuration.
http://tools.ietf.org/html/rfc5969#section-7
"sixRdIpv4MaskLen "  is same function as IPv4MaskLen.

IPv4MaskLen         The number of high-order bits that are identical
                       across all CE IPv4 addresses within a given 6rd
                       domain.  For example, if there are no identical
                       bits, IPv4MaskLen is 0 and the entire CE IPv4
                       address is used to create the 6rd delegated
                       prefix.  If there are 8 identical bits (e.g., the
                       Private IPv4 address range 10.0.0.0/8 is being
                       used), IPv4MaskLen is equal to 8 and IPv4MaskLen
                       high-order bits are stripped from the IPv4
                       address before constructing the corresponding 6rd
                       delegated prefix.

Regards,
-Shishio

(2012/03/26 15:59), Jiang Dong wrote:
> Hi,authors of 6rd MIB,
> I get some comments about 6rd MIB draft.
> 1) You mentioned the "tunnelIfXTable" in section 5.2. I think it is a good idea to extend the tunnel MIB, some scenario cannot be included in RFC4087, such as point to multi-point tunnel like softwire mesh.
> 2) It seems you miss the conformance part in the definition.
> 3) I'm not quite sure what's the "sixRdIpv4MaskLen " used for, can you explain it?
> Regards!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Jiang Dong
> Tsinghua University
>

---

From: Jacni Qin <[email-masked]>
Date: Wed, 18 Apr 2012 15:28:01 +0800

Re-,
Thanks Jiang Dong, for your comments, I'll discuss with the authors
about it.

Cheers,
Jacni

On 4/18/2012 Wednesday 11:08 AM, Jiang Dong wrote:
> HiShishio,
> It seems the definition of 6rd MIB is more acceptable than the
> extension of IP tunnel MIB according to the Softwire meeting in Paris.
> Since the 6rd MIB draft itself is quite clear, a clarification of
> using one specific way would be helpful : )
> Regards!
> Jiang Dong
> 2012-04-18
> *From:* Shishio Tsuchiya <mailto:[email-masked]>
> *Date:* 2012-03-26 22:19
> *To:* jiangdong345 <mailto:[email-masked]>
> *CC:* cai.lei3 <mailto:[email-masked]>; jacni
> <mailto:[email-masked]>; softwires <mailto:[email-masked]>;
> cuiyong <mailto:[email-masked]>
> *Subject:* Re: [Softwires]Comments about 6rd MIB
> Jiang
> Thanks for comments.
> > 1) You mentioned the "tunnelIfXTable" in section 5.2. I think it is
> a good idea to extend the tunnel MIB, some scenario cannot be included
> in RFC4087, such as point to multi-point tunnel like softwire mesh.