Subject: Re: [Softwires] Next step for Stateless Motivations I-D

From: Mark Townsley <[email-masked]>
Date: Wed, 6 Jul 2011 13:50:46 +0200

I also support draft-operators-softwire-stateless-4v6-motivation-02 becoming a WG document, and would like to see a last call on or before the Quebec meeting. 

Could one of the chairs please respond?

- Mark

On Jun 17, 2011, at 8:32 AM, Satoru Matsushima wrote:

> Dear Softwires Working Group chairs,
> 
> I support that an request from Mohamed to make WG adoption as appropriate charter item.
> I'm looking forward you to take your kind adoption procedure for the request.

> 
> Sincerely yours,
> 
> --
> Satoru Matsushima
> 
> 
> On 2011/06/10, at 20:31, <[email-masked]> <[email-masked]> wrote:
> 
>> Dear all,
>> 
>> An updated version of the "Motivations for Stateless IPv4 over IPv6 Migration Solutions" I-D has been submitted. The document is available at:
>> http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02
>> 
>> This document has been largely reviewed and inputs from other contributors has been taken into account.
>> 
>> Together with my co-authors, we ask the working group to consider the adoption of this document as a WG I-D.
>> 
>> Comments and suggestions are more than welcome.
>> 
>> Cheers,
>> Med
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 6 Jul 2011 09:33:54 -0500

Support.

Cheers,
Rajiv

> -----Original Message-----
> From: Satoru Matsushima [mailto:[email-masked]]
> Sent: Friday, June 17, 2011 2:32 AM
> To: <[email-masked]>
> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu;
> [email-masked]; [email-masked];
[email-masked]
> Subject: Re: Next step for Stateless Motivations I-D
> 
> I support that an request from Mohamed to make WG adoption as
appropriate
> charter item.
> On 2011/06/10, at 20:31, <[email-masked]>
> <[email-masked]> wrote:
> 
> > Dear all,
> >
> > An updated version of the "Motivations for Stateless IPv4 over IPv6
> Migration Solutions" I-D has been submitted. The document is available
at:
> > This document has been largely reviewed and inputs from other
contributors
> has been taken into account.
> >
> > Together with my co-authors, we ask the working group to consider
the
> adoption of this document as a WG I-D.
> >

---

From: <[email-masked]>
Date: Wed, 6 Jul 2011 16:35:18 +0200

+1

Cheers,

Christian. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Rajiv Asati (rajiva)
Envoyé : mercredi 6 juillet 2011 16:34
À : Satoru Matsushima; BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]; Softwire Chairs; Softwires-wg; [email-masked]
Objet : Re: [Softwires] Next step for Stateless Motivations I-D

Support.

Cheers,
Rajiv

[email-masked]
appropriate
contributors
the

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 6 Jul 2011 15:00:35 +0000

+1

---

From: GangChen <[email-masked]>
Date: Wed, 6 Jul 2011 23:23:16 +0800

+1

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 6 Jul 2011 08:49:45 -0700

+1

---

From: Xing Li <[email-masked]>
Date: Thu, 07 Jul 2011 07:16:26 +0800

Support. xing

于 2011/7/6 19:50, Mark Townsley 写道:
>> On 2011/06/10, at 20:31,<[email-masked]>  <[email-masked]>  wrote:
>>
>>> Dear all,
>>>

---

From: Shishio Tsuchiya <[email-masked]>
Date: Thu, 07 Jul 2011 12:36:36 +0900

+1

Tetsuya Murakami wrote:
>> 2011/7/6, Lee, Yiu<[email-masked]>:
>>> +1
>>>
>>> On 7/6/11 10:33 AM, "Rajiv Asati (rajiva)"<[email-masked]>  wrote:
>>>
>>>> Support.
>>>>
>>>> Cheers,
>>>> Rajiv
>>>>
>>>>
>>>>> To:<[email-masked]>
>>>>> On 2011/06/10, at 20:31,<[email-masked]>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 07 Jul 2011 03:44:28 +0000

+1

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代
> 表 Mark Townsley
> 发送时间: 2011年7月6日 19:51
> 收件人: Satoru Matsushima
> 抄送: Softwires-wg list; Isabel Borges; ChenGang; Softwire Chairs
> 主题: Re: [Softwires] Next step for Stateless Motivations I-D
> 
> 
> I also support draft-operators-softwire-stateless-4v6-motivation-02 becoming
> a WG document, and would like to see a last call on or before the Quebec
> meeting.
> 
> appropriate charter item.
> Migration Solutions" I-D has been submitted. The document is available at:
> >>

---

From: <[email-masked]>
Date: Thu, 7 Jul 2011 16:03:28 +0800

+1

Cheers,
Xiaohong.

open source PCP Client,
open source A+P
http://opensourcev6transtechnologies.weebly.com/

|
|+1
|
|Tetsuya Murakami wrote:
|> +1
|> 
|> On 2011/07/06, at 8:23, GangChen wrote:
|> 
|>> +1
|>>
|>>
|>> 2011/7/6, Lee, Yiu<[email-masked]>:
|>>> +1
|>>>
|>>> On 7/6/11 10:33 AM, "Rajiv Asati 
|(rajiva)"<[email-masked]>  wrote:
|>>>
|>>>> Support.
|>>>>
|>>>> Cheers,
|>>>> Rajiv
|>>>>
|>>>>
|>>>>> -----Original Message-----
|>>>>> From: Satoru Matsushima [mailto:[email-masked]]
|>>>>> Sent: Friday, June 17, 2011 2:32 AM 
|>>>>> To:<[email-masked]>
|>>>>> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; 
|Lee, Yiu; 
|>>>>> [email-masked]; [email-masked];
|>>>> [email-masked]
|>>>>> Subject: Re: Next step for Stateless Motivations I-D
|>>>>>
|>>>>> Dear Softwires Working Group chairs,
|>>>>>
|>>>>> I support that an request from Mohamed to make WG adoption as
|>>>> appropriate
|>>>>> charter item.
|>>>>> I'm looking forward you to take your kind adoption procedure for 
|>>>>> the
|>>>> request.
|>>>>>
|>>>>> Sincerely yours,
|>>>>>
|>>>>> --
|>>>>> Satoru Matsushima
|>>>>>
|>>>>>
|>>>>> On 2011/06/10, at 20:31,<[email-masked]>
|>>>>> <[email-masked]>  wrote:
|>>>>>
|>>>>>> Dear all,
|>>>>>>
|>>>>>> An updated version of the "Motivations for Stateless IPv4 over 
|>>>>>> IPv6
|>>>>> Migration Solutions" I-D has been submitted. The document is 
|>>>>> available
|>>>> at:
|>>>>>> 
|http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6
|>>>>>> -
|>>>>> motivation-02
|>>>>>>
|>>>>>> This document has been largely reviewed and inputs from other
|>>>> contributors
|>>>>> has been taken into account.
|>>>>>>
|>>>>>> Together with my co-authors, we ask the working group 
|to consider
|>>>> the
|>>>>> adoption of this document as a WG I-D.
|>>>>>>
|>>>>>> Comments and suggestions are more than welcome.
|>>>>>>
|>>>>>> Cheers,
|>>>>>> Med
|>>>>
|>>>
|>>> _______________________________________________
|>>> Softwires mailing list
|>>> [email-masked]
|>>> https://www.ietf.org/mailman/listinfo/softwires
|>>>
|>> _______________________________________________
|>> Softwires mailing list
|>> [email-masked]
|>> https://www.ietf.org/mailman/listinfo/softwires
|> 
|> _______________________________________________
|> Softwires mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/softwires
|> 
|
|
|
|

---

From: Alain Durand <[email-masked]>
Date: Thu, 7 Jul 2011 06:38:53 -0700

Following up on the 'stateless' thread from a wg chair perspective.

Yong and I are preparing a discussion FOR the Quebec meeting on the so-called stateless solution.

There are a number of points in the current draft that need discussion.

For example, no logging has been presented as a strong reason to do sateless. However, no logging can be achieved
with static port allocation on a centralized NAT. On this particular logging point, there are no obvious differences between the
'distributed on CPE' NAT solution and the centralized NAT solution.

More generally, it seems that what is described as a 'stateless' solution should be characterized as a
'distributed state' solution. As such, the tradeoff of maintaining the state centrally vs globally
needs to be analyzed.
 
Also, it is not clear from this document which set of issues listed in RFC6269 are mitigated and which ones are not.
In particular, I'd hold that a so-called 'stateless' solution does not change anything about the recommendations in RFC6302/BCP162
that are derived from RFC6269...

We, chairs, would like to prepare a 'organized' discussion around these points (and others). We need a small number of
volunteers to help frame this discussion. Please contact me and Yong directly if you want to help.
This is an important topic, and we intend to make sure there is ample time for discussion in Quebec.

   - Alain.

---

From: Mark Townsley <[email-masked]>
Date: Thu, 7 Jul 2011 19:16:44 +0200

Let's have discussion on the list instead, k?

> Following up on the 'stateless' thread from a wg chair perspective.

The thread was nothing but an announcement that the draft was present, and a bunch of people saying that they support it.

> There are a number of points in the current draft that need discussion.

Sure, based on your review of the document that's fine. But, not "the thread from a WG chair perspective" as stated above. That's ridiculous.

> 'distributed on CPE' NAT solution and the centralized NAT solution.

As you point out, the "no logging" part is really a function of the use of a static mapping to a range of ports. Any centralized NAPT function can use static mapping. When you use static mapping, then you get all the pros and cons that go along with it.

> 'distributed state' solution. As such, the tradeoff of maintaining the state centrally vs globally

"stateless operation" if you prefer. The point is that within the ISP network, there is no per-flow state that resides on any single endpoint running the protocol in question.  So, config can be static, and BRs can be reached via anycast. That's the heart of a stateless solution. Just like 6rd, if you will. 

> that are derived from RFC6269...

RFC6302/BCP162 is a Standards track document that makes an informational reference to an Informational RFC 6269, so I would hardly call that "derived from," else we would likely have a downref issue that would have needed to be called out during IETF Last call for RFC 6302. 

In any case, RFC 6269 has some very good information. In fact, it very correctly states:

   Whether we're
   talking about DS-Lite, A+P, NAT64, or CGN isn't especially important
   -- it's the view from the outside that matters, and given that, most
   of the issues identified below apply regardless of the specific
   address sharing scenario in question.

So, since most of the issues don't matter between stateful vs. stateless (A+P), we can dismiss most of this document pretty quickly for this comparison. Here are a couple of issues that do seem to matter though:

Section 13.4 Port Randomization - here the culprit is use of a static mapping again, and essentially the other side of the coin for "no logging". Put simply, if you want to reduce your logging with a predictable port, you also make your port more guessable by an attacker. . 

Section 18: Single Points of Failure - here, stateless wins pretty much hands down as it is not introducing any new single points of failure.

Perhaps there are a few more, but "most" should be insignificant by the own document's admission.

> This is an important topic, and we intend to make sure there is ample time for discussion in Quebec.

Why don't we just discuss it on the list and have a consensus call instead?

If we had a thread of 200 messages as we did for moving 6to4 to historic, OK maybe we need to have a big coordinated discussion. But, I'm not seeing anything on the thread here that would suggest that we need to spend a lot of time preparing some big discussion among a group of people you and Yong select. 

- Mark

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 7 Jul 2011 10:57:11 -0700 (PDT)

Hi Mark,

It seems that the chairs have some concerns on the a+p transition technology 
which I understand.

However here in so-called stateless solution, a+p is used in a very specific 
context, removing most of the concerns, at least to me.

Regards,

Behcet

>Following up on the 'stateless' thread from a wg chair perspective.

The thread was nothing but an announcement that the draft was present, and a 
bunch of people saying that they support it.

>Sure, based on your review of the document that's fine. But, not "the thread 
>from a WG chair perspective" as stated above. That's ridiculous.
>
>
>>with static port allocation on a centralized NAT. On this particular logging 
>>point, there are no obvious differences between the

As you point out, the "no logging" part is really a function of the use of a 
static mapping to a range of ports. Any centralized NAPT function can use static 

mapping. When you use static mapping, then you get all the pros and cons that go 

along with it.

More generally, it seems that what is described as a 'stateless' solution should 

be characterized as a
>'distributed state' solution. As such, the tradeoff of maintaining the state 

"stateless operation" if you prefer. The point is that within the ISP network, 
there is no per-flow state that resides on any single endpoint running the 
protocol in question.  So, config can be static, and BRs can be reached via 
anycast. That's the heart of a stateless solution. Just like 6rd, if you will. 

Also, it is not clear from this document which set of issues listed in RFC6269 
are mitigated and which ones are not.
>In particular, I'd hold that a so-called 'stateless' solution does not change 
>anything about the recommendations in RFC6302/BCP162

RFC6302/BCP162 is a Standards track document that makes an informational 
reference to an Informational RFC 6269, so I would hardly call that "derived 
from," else we would likely have a downref issue that would have needed to be 
called out during IETF Last call for RFC 6302. 

In any case, RFC 6269 has some very good information. In fact, it very correctly 

states:

   Whether we're    talking about DS-Lite, A+P, NAT64, or CGN isn't especially 
important    -- it's the view from the outside that matters, and given that, 
most    of the issues identified below apply regardless of the specific    
address sharing scenario in question.

So, since most of the issues don't matter between stateful vs. stateless (A+P), 
we can dismiss most of this document pretty quickly for this comparison. Here 
are a couple of issues that do seem to matter though:

Section 13.4 Port Randomization - here the culprit is use of a static mapping 
again, and essentially the other side of the coin for "no logging". Put simply, 
if you want to reduce your logging with a predictable port, you also make your 
port more guessable by an attacker. . 

Section 18: Single Points of Failure - here, stateless wins pretty much hands 
down as it is not introducing any new single points of failure.

Perhaps there are a few more, but "most" should be insignificant by the own 
document's admission.

We, chairs, would like to prepare a 'organized' discussion around these points 
(and others). We need a small number of
>volunteers to help frame this discussion. Please contact me and Yong directly if 
>
>you want to help.

If we had a thread of 200 messages as we did for moving 6to4 to historic, OK 
maybe we need to have a big coordinated discussion. But, I'm not seeing anything 

on the thread here that would suggest that we need to spend a lot of time 
preparing some big discussion among a group of people you and Yong select. 

- Mark

---

From: Tomoyuki Sahara <[email-masked]>
Date: Fri, 08 Jul 2011 14:37:00 +0900 (JST)

+1
Stateless protocols are easy to implement.

Thanks,
Tomoyuki

>From:  <[email-masked]>
>Date: Thu, Jul 7, 2011 at 5:03 PM
>Subject: Re: [Softwires] Next step for Stateless Motivations I-D
>
>
>+1
>
>Cheers,
>Xiaohong.
>
>open source PCP Client,
>open source A+P

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 8 Jul 2011 16:14:31 +0900

Dear Alain,

I'm very happy to have discussion, not only in Quebec meeting, but also on the list. 

Actually, we had two month from we submitted the initial version. While that time, we received many valuable comments and discussions from people. Most significant thing we did is that we have unified two drafts into the one. So we have accordingly asked you to adopt it as a WG document. IMHO, there's no concern to take this procedure, no alternatives but there are many supports from community. 

My understanding here is that this work is an appropriate charter item, WG document adoption is JUST starting point.

Best regards,
--satoru

---

From: Toshiya Asaba <[email-masked]>
Date: Fri, 08 Jul 2011 16:57:26 +0900 (JST)

+1

Operators love to keep stateless options for simple and robust
operations.

cheers!
asaba

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 Jul 2011 10:37:03 +0200

Dear So-Called chairs, (you did ask for that one! ;-))

> 'distributed on CPE' NAT solution and the centralized NAT solution.

indeed you can. then you loose the benefit of the stateful solution of offering port entropy.
the important points for the stateless solutions are:
 - direct CE to CE traffic (statful is hub and spoke) architecture
 - no new state to be maintained, or recovered, or scaled for in the network
 - implicitly does prefix delegation, full or shared IPv4 address provisioning

> 'distributed state' solution. As such, the tradeoff of maintaining the state centrally vs globally

see RFC1958:
   ..."This principle has important consequences if we require applications
   to survive partial network failures. An end-to-end protocol design
   should not rely on the maintenance of state (i.e. information about
   the state of the end-to-end communication) inside the network. Such
   state should be maintained only in the endpoints, in such a way that
   the state can only be destroyed when the endpoint itself breaks
   (known as fate-sharing). An immediate consequence of this is that
   datagrams are better than classical virtual circuits.  The network's
   job is to transmit datagrams as efficiently and flexibly as possible."

the stateful solutions add new state in the middle of the network. this state has to be maintained and recovered in case of failure.
the stateless solution does not. when we refer to 'state' here, we are talking about state in the network. you can argue if a CE is the real end point or not, regardless the stateless class of solutions do not introduce any _new_ state.

> that are derived from RFC6269...

the stateless solutions on the table can do more than just address sharing. but, to your point. all solutions that we are discussing for prolonging the life of IPv4 are based on address sharing. the issues discussed apply to all the IPv4 address sharing mechanisms, doesn't it?CGNs (NAT444 or DS-lite) or A+P variants.

> This is an important topic, and we intend to make sure there is ample time for discussion in Quebec.

I don't understand what is asked for here? or how a small number of volunteers are going to 'frame' the discussion? does it mean 5 of us sitting on Randy so he doesn't get to the mike? I'm happy to volunteer then. ;-)

appears to me we are having the discussion on the mailing list. based on what has been posted to this thread(s) and the discussion at the last IETF meeting, let us accept the draft as a working group item, and start working on it as a wg. the draft more than justifies why a stateless solution is needed, I don't want to see us spend the discussion time in Quebec on state versus no state. the Internet community made that choice when I was still in diapers.

cheers,
Ole

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 8 Jul 2011 17:37:40 +0900

> Sure, based on your review of the document that's fine. But, not "the thread from a WG chair perspective" as stated above. That's ridiculous.

I hope that the chair take adoption to be a WG document.
Please discriminate your chair role from your personal technical view.

> "stateless operation" if you prefer. The point is that within the ISP network, there is no per-flow state that resides on any single endpoint running the protocol in question.  So, config can be st…

Good point. 'no per-flow state' is goodness for redundancy, load-sharing, etc., These are usual expectations of IP network operations.

>> that are derived from RFC6269...

The draft explains motivation of stateless solution for ISP networks where are going to share IPv4 address. Consequence of server side should be same with other solutions.

-- snip --

> Section 18: Single Points of Failure - here, stateless wins pretty much hands down as it is not introducing any new single points of failure.

Yes.

> Perhaps there are a few more, but "most" should be insignificant by the own document's admission.

Agree.

> If we had a thread of 200 messages as we did for moving 6to4 to historic, OK maybe we need to have a big coordinated discussion. But, I'm not seeing anything on the thread here that would suggest t…

Again, would you take appropriate procedure for the adoption?

Best regards,
--satoru

---

From: Miya Kohno <[email-masked]>
Date: Fri, 8 Jul 2011 17:42:20 +0800

+1

I see no reason to eliminate this option. 

Miya
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Toshiya Asaba
> Sent: Friday, July 08, 2011 4:57 PM
> To: [email-masked]; [email-masked]

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 8 Jul 2011 12:19:45 +0200

+1

-Wojtek.