Subject: [Softwires] WG Review: Recharter of Softwires (softwire)

From: IESG Secretary <[email-masked]>
Date: Mon, 21 Mar 2011 14:29:44 -0700 (PDT)

A modified charter has been submitted for the Softwires (softwire)
working group in the Internet Area of the IETF.  The IESG has not made any
determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list ([email-masked]) by Tuesday, March 29, 2011.

Softwires (softwire)
---------------------------------------------------
Current Status: Active Working Group

 Chairs:
     Alain Durand <[email-masked]>
     Yong Cui <[email-masked]>

 Internet Area Directors:
     Ralph Droms <[email-masked]>
     Jari Arkko <[email-masked]>

 Internet Area Advisor:
     Ralph Droms <[email-masked]>

 Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       [email-masked]
     Archive:           
http://www.ietf.org/mail-archive/web/softwires/current/maillist.html

Description of Working Group:

  The Softwires Working Group is specifying the standardization of
  discovery, control and encapsulation methods for connecting IPv4
  networks across IPv6 networks and IPv6 networks across IPv4 networks
  in a way that will encourage multiple, inter-operable
  implementations.

  For various reasons, native IPv4 and/or IPv6 transport may not be
  available in all cases, and there is a need to tunnel IPv4 in IPv6
  or IPv6 in IPv4 to cross a part of the network which is not IPv4 or
  IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies
  two distinct topological scenarios that the WG will provide
  solutions for: "Hubs and Spokes" and "Mesh." In the former case,
  hosts or "stub" networks are attached via individual,
  point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a
  centralized Softwire Concentrator. In the latter case (Mesh),
  network islands of one Address Family (IPv4 or IPv6) are connected
  over a network of another Address Family via point to multi-point
  softwires among Address family Border Routers (AFBRs).

  The WG will reuse existing technologies as much as possible and only
  when necessary, create additional protocol building blocks.

  For generality, all base Softwires encapsulation mechanisms should
  support all combinations of IP versions over one other (IPv4 over
  IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6
  translation mechanisms (NAT-PT), new addressing schemes, and block
  address assignments are out of scope. DHCP options developed in this
  working group will be reviewed jointly with the DHC WG.  RADIUS
  attributes developed in this working group will be reviewed jointly
  with the RADEXT WG.  The MIB Doctors directorate will be asked to
  review any MIB modules developed in the SOFTWIRE working group.  BGP
  and other routing and signaling protocols developed in this group
  will be reviewed jointly with the proper working groups and other
  workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG,
  etc).

  The specific work areas for this working group are:

  1. Developments for Mesh softwires topology; the Mesh topology work
     will be reviewed in the l3vpn and idr WGs
     - multicast
     - MIB module

  2. Developments for 6rd:
     - multicast
     - operational specification
     - RADIUS option for 6rd server
     - MIB module

  3. Developments for Dual-Stack Lite (DS-Lite):
     - multicast
     - operational specification
     - RADIUS option for AFTR
     - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the
       B4 element
     - MIB module

  4. Finalize discovery and configuration mechanisms for a gateway to
     use DS-Lite or 6rd; these discovery and configuration mechanisms
     must take into a account other operating environments such as
     dual-stack and tunneling mechanisms not defined by the softwire
     WG.  Development of new mechanisms will involve the dhc and/or
     v6ops WGs as appropriate

Other work items would require WG approval and rechartering.

Goals and Milestones:
Apr 2011 Submit DS-lite RADIUS option for Proposed Standard
Apr 2011 Adopt DS-lite operational document as WG document
Jul 2011 Submit 6rd RADIUS option for Proposed Standard
Jul 2011 Submit GI DS-lite for Proposed Standard
Jul 2011 Adopt B4NAT as WG document
Aug 2011 Adopt 6rd operational document as WG document
Aug 2011 Adopt Multicast extensions document as WG document
Aug 2011 Submit DS-lite operational document for Informational
Sep 2011 Submit B4NAT for Informational
Nov 2011 Submit Multicast extensions document for Informational
Nov 2011 Submit 6rd operational document for Informational
Nov 2011 Adopt 6rd MIB module as WG document
Nov 2011 Adopt DS-lite MIB module as WG document
Nov 2011 Adopt Mesh topology MIB module as WG document
Nov 2012 Submit 6rd MIB module for Proposed Standard
Nov 2012 Submit DS-lite MIB module for Proposed Standard
Nov 2012 Submit Mesh topology MIB module for Proposed Standard

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2011 11:29:12 +1300

Hi,

It seems that a real world problem case is not covered by this
update: tunneling v6 over v4 when there is a legacy CPE NAT in the way,
in an ISP-managed way (unlike Teredo). At the moment this is a well
known but orphaned problem, which will remain with us until the last
NAT44-only consumer CPE device has gone.

It's certainly the case that this scenario doesn't quite match
RFC 4925 and doesn't need to "support all combinations of IP versions
over one other." However, that is just a matter of charter wordsmithing.

Nit: there's a reference to NAT-PT; maybe it should be NAT64 these days.

Regards
   Brian Carpenter

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Mar 2011 08:47:31 +0100

Brian,

> Nit: there's a reference to NAT-PT; maybe it should be NAT64 these days.

that was the problem one set out to solve with RFC5571 (L2TP).
what's missing from that solution?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Tue, 22 Mar 2011 09:27:12 +0100

> over one other." However, that is just a matter of charter wordsmithing.

+1

RD

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

---

From: Jiangsheng <[email-masked]>
Date: Tue, 22 Mar 2011 08:35:12 +0000

> > over one other." However, that is just a matter of charter

+1, Sheng

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Mar 2011 10:47:30 +0100

[removed ietf-announce]

as an active participant in the softwires working group, I found this announcement surprising.
isn't it customary that the working group is involved in rewriting the charter before the external review?

at least I haven't seen anything on the list, nor do I think it was discussed at IETF79 (although I cannot confirm that as the minutes haven't been posted).

cheers,
Ole

On Mar 21, 2011, at 22:29 , IESG Secretary wrote:

> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 22 Mar 2011 07:35:14 -0700

Hi Ole, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Tuesday, March 22, 2011 12:48 AM
> To: Brian E Carpenter
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire)
> 
> Brian,
> 

VET and SEAL address this space. With VET and SEAL, you
get a per-packet nonce so that off-path spoofing of IPv6
addresses is disabled even if IPv4 source address spoofing
is possible. You also get a path MTU discovery method that
does not depend on links and routers in the middle of the
network. Also route optimization, mobility management, IPv6
prefix delegation, multiple interface support, and more.

Thanks - Fred
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Mar 2011 11:18:29 -0400

Sorry, my oversight.  The chairs and I have been working on this new charter for several months and I should have run asked them to bring the final version to the WG before going to the IETF review.

Chairs, please add time to the agenda for discussion of the revised charter.

- Ralph

---

From: Rémi Després <[email-masked]>
Date: Tue, 22 Mar 2011 19:25:52 +0100

> what's missing from that solution?

Nothing that I know for its solution space, but this solution space is only stateful and hub-an-spoke.
In particular, two host in the same customer site communicate in IPv6 via the L2TP Network server, which is an important functional limitation. 

As you know, as co-author of RFC 5969 on 6rd, a complementary and useful solution space is that of stateless solutions.
In this pace, we all know that 6rd isn't sufficient to rapidly deploy IPv6 where there are legacy CPE's.
A solution for this complementary scenario is therefore desirable.
As it happens to be also possible, as shown in the 6a44 proposal, a work item on it has to be identified.

Softwire, where 6rd has been in scope, seems the logical place to finalize this complementary solution. 
(It is also the logical place to finalize the 4rd solution, but this wasn't your question and is a different discussion)

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Wed, 23 Mar 2011 08:21:05 +0100

Remi,

> (It is also the logical place to finalize the 4rd solution, but this wasn't your question and is a different discussion)

ah, OK I see.
stateless, managed, tunnels to a host behind a non IPv6 capable CPE. I missed the Teredo reference in Brian's mail.

I don't quite understand how these types of tunnels can be provisioned in a "managed" way though??

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 23 Mar 2011 09:21:36 +0100

> I don't quite understand how these types of tunnels can be provisioned in a "managed" way though??

It's plug and play in hosts (6a44 relays are the only ones to need management).
- Hosts obtain the necessary parameters by means of a bubble dialogue with 6a44 relays.
- 6a44 relays are reached at a well-known address and port couple.

We can discuss this in more details in Prague.

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 23 Mar 2011 12:30:23 +0100

Hello all,

Le 21 mars 2011 à 22:29, IESG Secretary a écrit :

> informational purposes only.  

> Please send your comments to the IESG

The main comment of this mail is a suggestion to add 4rd to the charter, in view of the following:  
- It is a tunnel solution for IPv4 across IPv6 networks
- Implementations have already been made
- Some ISP's have expressed their preference for this stateless solution over a stateful solution (DS-lite)
- A proposed specification is available for WG comments 

It is distinct from other solutions in that:
- Unlike 6rd it is for IPv4 over IPv6
- Unlike DS-lite, it optimizes routing between CE's with point to multipoint tunnels and needs no CGN. 
- Unlike Mesh solutions, it doesn't need a (stateful) BGP between AFBR's (it's route selections are stateless).

Proposed additions to the charter text are in line.

Regards,
RD

> Softwires (softwire)

5. Development for 4rd (stateless tunneling for IPv4 over IPv6)
  - architecture and protocol specification
  - operational specification
  - MIB module
> Jul 2011 Adopt B4NAT as WG document
July 2011 Adopt the 4rd architecture an protocol document as WG document
> Nov 2011 Adopt Mesh topology MIB module as WG document
Nov 2011 Submit the 4rd architecture an protocol document for Proposed Standard
Nov 2011 Adopt the 4rd operational document as WG document
Nov 2011 Adopt the 4rd MIB module as WG document
> Nov 2012 Submit Mesh topology MIB module for Proposed Standard
Nov 2012 Submit 4rd operational document for Informational
Nov 2012 Submit 4rd MIB module for Proposed Standard

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 23 Mar 2011 20:50:51 +0900

+1
I support 4rd as a charter item.

--
Satoru Matsushima

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 23 Mar 2011 22:29:04 +0900

+1
I support 4rd as wg item.
As same as Satoru-san,a lot of Japan operators are interesting in stateless tunneling for IPv4 over IPv6 such as 4rd.
But in my understanding,IETF had not enough time to discuss the solution until now.
I think softwire wg adapt forstateless tunneling for IPv4 over IPv6.

So I supportRemi's proposal.

Regards,
-Shishio
(2011/03/23 20:30), Rémi Després wrote:
>>      Alain Durand<[email-masked]>
>>      Yong Cui<[email-masked]>
>>
>> Internet Area Directors:
>>      Ralph Droms<[email-masked]>
>>      Jari Arkko<[email-masked]>
>>
>> Internet Area Advisor:
>>      Ralph Droms<[email-masked]>
>>
>> Mailing Lists:

---

From: Miya Kohno <[email-masked]>
Date: Wed, 23 Mar 2011 21:49:35 +0800

Support.

Miya
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Remi Despres
> Sent: Wednesday, March 23, 2011 8:30 PM
> To: [email-masked]
> Cc: Softwires-wg; Yong Cui; IETF Announcement list

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 23 Mar 2011 14:05:47 +0000

+1

I think this is an interesting solution and the WG should spend more time
to discuss this.

/Yiu

On 3/23/11 9:29 AM, "Shishio Tsuchiya" <[email-masked]> wrote:

>As same as Satoru-san,a lot of Japan operators are interesting in
>stateless tunneling for IPv4 over IPv6 such as 4rd.
>> - Some ISP's have expressed their preference for this stateless
>>solution over a stateful solution (DS-lite)
>> - Unlike Mesh solutions, it doesn't need a (stateful) BGP between
>>AFBR's (it's route selections are stateless).
>>

---

From: "Peng Wu" <[email-masked]>
Date: Wed, 23 Mar 2011 22:43:32 +0800

Hi guys,

I haven't cover the 4rd draft yet, but are you talking about the stateless case of host 4over6？ Maybe the two mechanism have overlaps.

The basic idea is to coupling IPv4 and IPv6 address of hosts/cpes using prefix mapping, in order to achieve stateless encapsulation on data forwarding.

It's an ongoing work and we've presented this draft in IETF before.

Please take a glance at section 5 of the 02 version draft

http://tools.ietf.org/id/draft-cui-softwire-host-4over6-02.txt

2011-03-23 

Peng Wu
PhD candidate
Department of Computer Science & Technology
Tsinghua University, Beijing, China

From： Lee, Yiu 
Date： 2011-03-23  22:06:11 
To： Shishio Tsuchiya; [email-masked] 
CC： [email-masked]; [email-masked]; [email-masked]; [email-masked] 
Subject： Re: [Softwires] WG Review: Recharter of Softwires (softwire) 
 
+1

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 24 Mar 2011 00:06:54 +0900

Hi Peng,

> http://tools.ietf.org/id/draft-cui-softwire-host-4over6-02.txt

The problem space of 4rd is that 4-over-6 with stateless IPv4 address sharing mechanism.
Please take a look at http://tools.ietf.org/id/draft-despres-intarea-4rd-01.txt

Best regards,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Wed, 23 Mar 2011 16:14:46 +0100

Hello Peng,

You are right, there is some commonality of objective.
There are however important differences:
- 6over4 is hub-and-spoke => It might be envisaged as a DS-lite extension. This isn't the case of 4rd which has direct paths between CE's.
- 6over4 as it is deals only with mappings of addresses. 4rd as it is includes a solution for shared IPv4 addresses (restricted port sets are algorithmically derived from bits of IPv6 prefixes). This could be added to 6over4 to extend its scope.

In view of the commonality, your comments on 4rd will be most welcome.

Regards,
RD

---

From: "Peng Wu" <[email-masked]>
Date: Wed, 23 Mar 2011 23:16:27 +0800

Well, I think address sharing is a one-step-further consideration.

The basic problem here is IPv4-over-IPv6 in a stateless way so the concentrator/AFTR doesn't need to maintain address/port mapping.

I'll read the draft and get back. 

2011-03-23 

Peng Wu
PhD candidate

From： Satoru Matsushima 
Date： 2011-03-23  23:07:07 
To： Peng Wu 
CC： Satoru Matsushima; Lee, Yiu; Shishio Tsuchiya; Rémi_Després; softwires; cuiyong; iesg 
Subject： Re: [Softwires] WG Review: Recharter of Softwires (softwire) 
 
Hi Peng,

---

From: "Peng Wu" <[email-masked]>
Date: Wed, 23 Mar 2011 23:30:18 +0800

I think I've got what you guys mean. It's the same problem we're talking about.

And, as long as it's stateless IPv4-IPv6 address mapping with routing support, traffic between CEs naturally doesn't need to go through the concentrator.

As to address sharing, I guess the basic idea is leveraging some bits in port space and some bits in IPv6 address, right? Again I think it's one step further upon stateless IPv4-over-IPv6.

I'll read the draft to get details.

2011-03-23 

Peng Wu
PhD candidate

From： R閙i_Despr閟 
Date： 2011-03-23  23:15:10 
To： Peng Wu 
CC： Lee, Yiu; Shishio Tsuchiya; [email-masked]; [email-masked]; [email-masked]; [email-masked] 
Subject： Re: [Softwires] WG Review: Recharter of Softwires (softwire) 
 
Hello Peng,

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 23 Mar 2011 15:36:02 +0000

Peng,

You are right. The 4rd is very similar to stateless 4over6. If the v6 routing is enabled between 4to6 clients, we don't need to use the 4over6 BR. The main difference is IPv4 address sharing. Perhaps, we can consider to work together for this.

/Yiu

From: Peng Wu <[email-masked]<mailto:[email-masked]>>
Date: Wed, 23 Mar 2011 23:30:18 +0800
To: R閙i_Despr閟 <[email-masked]<mailto:[email-masked]>>
Cc: <Lee>, Microsoft Office User <[email-masked]<mailto:[email-masked]>>, Shishio Tsuchiya <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Re: [Softwires] WG Review: Recharter of Softwires (softwire)

2011-03-23
________________________________
Peng Wu
PhD candidate
Department of Computer Science & Technology
Tsinghua University, Beijing, China
________________________________
From： R閙i_Despr閟
Date： 2011-03-23  23:15:10
To： Peng Wu
CC： Lee, Yiu; Shishio Tsuchiya; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject： Re: [Softwires] WG Review: Recharter of Softwires (softwire)
Hello Peng,
You are right, there is some commonality of objective.
There are however important differences:
- 6over4 is hub-and-spoke => It might be envisaged as a DS-lite extension. This isn't the case of 4rd which has direct paths between CE's.
- 6over4 as it is deals only with mappings of addresses. 4rd as it is includes a solution for shared IPv4 addresses (restricted port sets are algorithmically derived from bits of IPv6 prefixes). This could be added to 6over4 to extend its scope.
In view of the commonality, your comments on 4rd will be most welcome.
Regards,
RD
Le 23 mars 2011 à 15:43, Peng Wu a écrit :
> To： Shishio Tsuchiya; [email-masked]<mailto:[email-masked]>
> CC： [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Tim Chown <[email-masked]>
Date: Wed, 23 Mar 2011 15:46:25 +0000

> what's missing from that solution?

Or TSP... the 'managed tunnelling through a NAT' problem is solved today by thousands of IPv6 tunnel broker users who use services provided by providers like SixXS or HE.    We have students using these to access some of our services from their home DSL networks via IPv6, because it's so much more robust than 6to4.   The drawback though is that some user action (registration, etc) is generally required.

There's in interesting feature comparison chart that SixXS drew up here:  http://www.sixxs.net/faq/connectivity/?faq=comparison.

Tim

---

From: Bruno STEVANT <[email-masked]>
Date: Wed, 23 Mar 2011 16:31:24 +0100

To Softwire chairs,
Softwire H&S Phase 2 (IPv6 over L2TPv3) is not mentioned in this new charter. Does the group consider it as a low-priority work to be delayed until next charter ? I won't be in Prague, but if discussion on the charter is part of the agenda, I will try to push the question over Jabber.

-- 
Bruno STEVANT - TELECOM Bretagne

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 23 Mar 2011 16:56:47 +0100

Aside from the (poor) form of the sudden communique, without WG discussion,
allow me to ask for some clarification... The charter appears to
specifically exclude stateless techniques, like 4rd, with no NAT on an AFTR.
Why is that?

More inline...

> mailing list ([email-masked]) by Tuesday, March 29, 2011.

Could someone clarify what is meant by "new addressing schemes and block
address assignments"?

>     - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the

What is meant by the NAT on the B4 element clue here, esp in relation a NAT
on the AFTR?

-Woj.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 Mar 2011 09:19:56 -0700

Hi Tim, 

> [mailto:[email-masked]] On Behalf Of Tim Chown
> Sent: Wednesday, March 23, 2011 8:46 AM
> To: [email-masked]; [email-masked]
> Or TSP... the 'managed tunnelling through a NAT' problem is 
> solved today by thousands of IPv6 tunnel broker users who use 
> services provided by providers like SixXS or HE.    We have 
> students using these to access some of our services from 
> their home DSL networks via IPv6, because it's so much more 
> robust than 6to4.   The drawback though is that some user 
> action (registration, etc) is generally required.

VET and SEAL (as the core mechanisms behind IRON) also
provide a "managed tunneling through NAT" solution like
TSP and L2TP, but they also provide much more than that.

With VET and SEAL, the Client sets up a managed tunnel
to a nearby Server. But rather than sending everything
through its own Server, the Client dynamically discovers
a Server that is nearer the final destination as a means
of having a more optimal route.

With VET and SEAL, a provider like SixXS or HE could
distribute Servers globally throughout the Internet
and allow Clients to discover and utilize those that
are topologically close. This would balance the Server
load, and dynamic route optimization would maintain
generally shortest-path routes. Other benefits include:

  - native (i.e., non-IPv4-embedded) IPv6 prefixes
  - IPvANY-within-IPvANY encapsulation
  - mobility management
  - Client multihoming
  - traffic engineering
  - tunnel MTU handling
  - security

I would therefore like to see a charter item for the
completion of VET and SEAL within the softwire wg.

Thanks - Fred

> There's in interesting feature comparison chart that SixXS 
> drew up here:  http://www.sixxs.net/faq/connectivity/?faq=comparison.
> 
> Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2011 08:56:58 +1300

> There's in interesting feature comparison chart that SixXS drew up here:  http://www.sixxs.net/faq/connectivity/?faq=comparison.

Sure. I run a tunnel from home. But I had to configure it. Normal
users don't have to configure a solution like 6a44; as in the case of
6rd, only the ISP has to do careful config and management. The idea is
to do for Teredo what 6rd does for 6to4.

    Brian

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 23 Mar 2011 14:50:54 -0700

Hi All,

+1
I also support 4rd as a wg item.

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 24 Mar 2011 08:18:04 +0800

Hi all,

>      will be reviewed in the l3vpn and idr WGs

As for Mesh softwires, shouldn't the inter-AS solution be included in the
new charter?

Best wishes,
Xiaohu

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 24 Mar 2011 01:22:20 +0000

As much as I love the idea, would it be too early to define this? I would
like to see if there is a need for Inter-AS mesh in real world.

Regards,
Yiu

---

From: Rémi Després <[email-masked]>
Date: Thu, 24 Mar 2011 09:27:48 +0100

Please see in line.

Le 21 mars 2011 à 22:29, IESG Secretary a écrit :

>     - proxy extensions; GI-DS-Lite;

> DS-Lite with no NAT or NAT on the  B4 element

The DS-lite draft is clear that "the dual-stack lite model is built on IPv4-in-IPv6 tunnels to cross the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR)"
"DS-Lite with no NAT or NAT on the  B4 element" is therefore a self-contradiction.

IMHO, these confusing words should be deleted from the new charter.

Note that with 4rd included in the charter (a complement having received substantial support), the solution space does include a CGN-less solution.

Regards,
RD

---

From: Naoki Matsuhira <[email-masked]>
Date: Thu, 24 Mar 2011 21:39:17 +0900

Adding time for revised charter discussion sound like good. Thank you for AD and charis.

Anyway, because of non native English speaker, it will be not easy for me to do open mike discussion.

To fill that gap, and as author of sa46t drafts, I prepare slides for present how sa46t contribute IPv4 continuance and IPv6 shift after stage of IPv4 address running out. That means the usage and merit of sa46t, and how sa46t contribute to the Internet.

Here is the url of that slides.
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B4nW-tATujYiZGFjNGI0NDUtM2IxNS00Yzg4LWI3YTgtYmY2ZTE3YzQyNjIx&hl=ja

I believe these slides are one of the input to the charter discussion in softwire WG.

If you give me presentation chance, please cut and paste below.

how sa46t contribute IPv4 continuance and IPv6 shift
http://tools.ietf.org/html/draft-matsuhira-sa46t-spec,
Naoki Matsuhira, 10min

And I propose to add the following sentences to the charter of softwire WG.

n. Development for sa46t (Stateless Automatic IPv4 over IPv6 Tunneling)
- protocol specification
- sa46t MIB

Regards

Naoki Matsuhira

On Tue, 22 Mar 2011 11:18:29 -0400

---

From: Rémi Després <[email-masked]>
Date: Thu, 24 Mar 2011 16:33:49 +0100

Hello all,

I just noted that he reference to a 4rd draft in the Softwire page "datatracker.ietf.org/wg/softwire" is obsolete.

For IETF 80, the right reference is:
 datatracker.ietf.org/doc/draft-despres-intarea-4rd/
(the ref to intarea is just historical)

Regards,
RD

<<<
Internet Engineering Task Force                          R. Despres, Ed.
Internet-Draft                                                 RD-IPtech
Intended status: Standards Track                           S. Matsushima
Expires: September 15, 2011                                     SoftBank
                                                             T. Murakami
                                                             IP Infusion
                                                                O. Troan
                                                                   Cisco
                                                          March 14, 2011

      IPv4 Residual Deployment across IPv6-Service networks (4rd)
                        ISP-NAT's made optional
                      draft-despres-intarea-4rd-01

Abstract

   This document specifies an automatic tunneling mechanism for
   providing IPv4 connectivity service to end users over a service
   provider's IPv6 network.  During the long transition period from IPv4
   to IPv6-only, a service provider's network will have to support IPv6,
   but will also have to maintain some IPv4 connectivity for a number of
   customers, for both outgoing and incoming connections, and for both
   exclusive and shared IPv4 addresses.  The 4rd solution (IPv4 Residual
   Deployment) is designed as a lightweight solution for this.

   In some scenarios, 4rd can dispense ISPs from supporting any NAT in
   their networks.  In some others it can be used in parallel with NAT-
   based solutions such as DS-lite and/or NAT64/DNS4.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 25 Mar 2011 22:19:12 +0100

> Softwire H&S Phase 2 (IPv6 over L2TPv3) is not mentioned in this new charter. Does the group consider it as a low-priority work to be delayed until next charter ? I won't be in Prague, but if discu…

When we chartered softwires and set it on its path, it's goal was to choose, adapt, or create a limited set of standards track protocols for a limited set of problem spaces that involved connecting various types of IPvX islands over IPvY networks. This was back in 2005, and included a number of parameters for our decision criteria. In what became labeled as the "hub and spoke" case (which looking back is a bit of a misnomer), we were driving towards solving the problem of connecting wireline broadband users with IPv6 over a clearly non-IPv6 last-mile network. One criteria we weighed very heavily was availability of multiple implementations of running code in the various platforms we needed to interconnect, which is one reason why L2TPv2 (RFC 2661) came out on top. The idea to move to L2TPv3 was mostly centered around optimization, and the thought that one day the broadband market might move from L2TPv2 to L2TPv3 on its own accord and that the available implementations would move as well. The latter never really happened (funny how protocol version transitions don't always go as expected!), and L2TPv3 remains relegated to the domain where it started supporting Ethernet, Frame-Relay, ATM,  MPLS, etc. rather than PPP for broadband where L2TPv2 remains in wide usage.

Around 2008-9, the WG took a turn toward a more mesh-oriented stateless approach for the IPv4-only access network problem in the form of 6rd, while picking up a new stateful hub-and-spoke form for IPv6-only network traversal with dual-stack-lite. Had 6rd been present with running code in the earlier days, it may have supplanted L2TP, or perhaps we would have ended up with a different division of problem spaces and solutions. In any case, it seems we have converged on the point that IP-in-IP tunneling solutions come in stateless and stateful varieties with different tradeoffs for each. 

Back to the original point of whether we should pursue L2TPv3 for "Phase II" of "Hub and Spoke". No, I don't think so. For IPv6 over IPv4, L2TPv2 continues to work fine for cases where 6rd does not fit and between these two we have a stateless/stateful pair of alternatives. Ds-lite + something like 4rd would give us a stateful and stateless pair for the IPv4 over IPv6 case. Going forward, I think we would be better served making the most sense of this matrix of solutions than optimizing the L2TPv2 case with L2TPv3.

- Mark

---

From: Jiangsheng <[email-masked]>
Date: Sat, 26 Mar 2011 08:52:11 +0000

Remi> Note that with 4rd included in the charter (a complement 
> having received substantial support), the solution space does 
> include a CGN-less solution.

It is even better if 4rd can be explicitly mentioned in the new charter. And milestones should be set for 4rd document, too.

Regards,

Sheng
________________________________________
From: [email-masked] [[email-masked]] on behalf of Mark Townsley [[email-masked]]
Sent: 26 March 2011 5:19
To: Bruno STEVANT
Cc: [email-masked]; [email-masked]
Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire)

- Mark

---

From: Rémi Després <[email-masked]>
Date: Sat, 26 Mar 2011 09:55:06 +0100

> Support.

Thank you Miya.
It looks like you won't be in Prague.
Do you know if some colleague of yours would also be supportive?

Kind regards,
RD

PS: I am really sorry for what happens to Japan right now.
I hope this will soon improve, ant that it isn't too bad for you and your relatives.

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Mar 2011 09:31:57 +0200

>     WG.  Development of new mechanisms will involve the dhc and/or

I don't understand what is missing here. both 6rd and DS-lite has specified provision mechanism(s).
the 'state machine' to choose between them is being worked on in v6ops.
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-00

propose to remove this bullet from the charter.

cheers,
Ole