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

From: IESG Secretary <[email-masked]>
Date: Tue, 19 Apr 2011 09:36:54 -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, April 26, 2011.

Softwires (softwire)
**DRAFT 2011-04-14** (v03)
--------------------
Current Status: Active

 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. Developments for stateless legacy IPv4 carried over IPv6
     - develop a solution motivation document to be published as an
       RFC
     - develop a protocol specification response to the solution
motivation
       document; this work item will not be taken through WG last call
       until the solution motivation document has been published

  5. 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: Tom Taylor <[email-masked]>
Date: Tue, 19 Apr 2011 21:16:23 -0400

Would Gateway-Initiated 6rd [draft-tsou-softwire-gwinit-6rd] fit within 
the charter or would it have to go the AD-sponsored route?

On 19/04/2011 12:36 PM, IESG Secretary 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:
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 20 Apr 2011 15:33:20 +0900

Hello,

I have some comments for the recharter text.

>  4. Developments for stateless legacy IPv4 carried over IPv6

What does "legacy" mean?
I think that no adjective needs to what IPv4 is.

>       until the solution motivation document has been published

It is unclear for the milestone to indicate this item. I think that
the milestone should explicitly include the schedule for both solution
motivation document and protocol specification for stateless solution.
Here's one proposal:

Jul 2011 Submit solution motivation document for Stateless IPv4 over
IPv6 for Informational
Jul 2011 Adopt Stateless IPv4 over IPv6 protocol specification as WG document
Nov 2011 Submit Stateless IPv4 over IPv6 protocol specification for
Proposed Standard

> Sep 2011 Submit B4NAT for Informational

I don't understand what B4NAT is. Is there any discussion about B4NAT
in softwires WG so far?
If not, it hasn't appropriate yet that the charter includes B4NAT as an item.

Best regards,
--satoru

---

From: "Peng Wu" <[email-masked]>
Date: Wed, 20 Apr 2011 14:55:58 +0800

Hi Satoru,

About the item DS-Lite with no NAT or NAT on the B4, it's DS-lite without CGN on the AFTR.
Generally B4 will get public IPv4 address allocated from the ISP and use it for IPv4 access. The AFTR will only need to maintain IPv6-IPv4 address mapping without port information. 
Doing this the addressing and routing between IPv6 and IPv4 are still independent. It's a protocol extenstion to DS-lite, and it can work along with DS-lite.

We've already present it in last three IETF meetings. See http://tools.ietf.org/html/draft-cui-softwire-host-4over6-04. The general idea is out there, and the only confusion is that the mechanism name hasn't matched yet.
We'll come up with a new version with evolvement before next IETF for WG adoption. 

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

-------------------------------------------------------------
From:Satoru Matsushima
Date:2011-04-20 14:33:47
To:iesg
CC:softwires; cuiyong
Subject:Re: [Softwires] WG Review: Recharter of Softwires (softwire)

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 20 Apr 2011 17:52:38 +0900

Hi Peng,

> Doing this the addressing and routing between IPv6 and IPv4 are still independent. It's a protocol extenstion to DS-lite, and it can work along with DS-lite.

So you mean that your 4over6 document is a B4NAT document, isn't it?
But I don't find any B4NAT definition in your document though.
On the other hand, I understand that you propose another 4over6
deployment model, which you don't need to use ds-lite terminology. You
already define 4over6 initiator and concentrator, etc., So I think
that using "B4NAT" makes confusion.

> We'll come up with a new version with evolvement before next IETF for WG adoption.

I'm confused because current ds-lite document clearly define as follow
in section 4.2:

  "A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
   interface and a B4 interface, as the NAT function will be performed
   by the AFTR in the service provider's network.  That will avoid
   accidentally operating in a double NAT environment."

And section 5.1 describes as follow:

  "5.  B4 element
   5.1.  Definition

   The B4 element is a function implemented on a dual-stack capable
   node, either a directly connected device or a CPE, that creates a
   tunnel to an AFTR."

These mean that B4 is equal to CPE, so that B4 cannot has NAT function.
Is that correct?

Best regards,
--satoru

---

From: "Peng Wu" <[email-masked]>
Date: Wed, 20 Apr 2011 17:14:55 +0800

Hi Satoru,

------------------				 
Peng Wu
PhD candidate

>So you mean that your 4over6 document is a B4NAT document, isn't it?
Yes. 
>that using "B4NAT" makes confusion.
Like I said, the names haven't matched yet. That's the confusion. IMHO, B4NAT isn't a very formal name, right? The original words are "DS-Lite with no NAT or NAT on the B4 element", which covers the full semantic and however is quite long...That's part of the reason we use a new name. If you have any suggestions on the name, it'll be good.
About 4over6 TI and TC, we use the terminology because their functions are a little different to original DS-lite, and there're cases that one would like to deploy 4over6 independently with no DS-LITE address sharing. Anyhow it's a detailed issue.
>These mean that B4 is equal to CPE, so that B4 cannot has NAT function.
Well, that's why it's an “extension” to DS-lite, I don't see problems here.
BTW, in real word, CPEs like home gateway usually support NAT functions already.

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 20 Apr 2011 18:23:29 +0900

Hi Peng,

> Like I said, the names haven't matched yet. That's the confusion. IMHO, B4NAT isn't a very formal name,
> right? The original words are "DS-Lite with no NAT or NAT on the B4 element", which covers the full
> semantic and however is quite long...That's part of the reason we use a new name. If you have any
> suggestions on the name, it'll be good.

As in a recharter discussion, this is a problem. At least the charter
should clearly explain what each charter item is, and also what wg
will do. My point is that using words which make clear understand for
all people is quite important. So I think that using the word of
"B4NAT" as a next charter item is not appropriate.

Best regards,
--satoru

---

From: Mark Townsley <[email-masked]>
Date: Wed, 20 Apr 2011 18:58:28 +0000

> **DRAFT 2011-04-14** (v03)

No chance to do a detailed review as I am peeking in while on vacation.... But, I'd like to make two comments

#3 and #4 both seem to be part of the "legacy IPv4 carried over IPv6" problem space.

>       until the solution motivation document has been published

s/published/approved for publication by the IESG. 

- Mark

---

From: Yong Cui <[email-masked]>
Date: Thu, 21 Apr 2011 09:22:10 +0800

A couple of comments below.

-----Original Message-----
From: IESG Secretary <[email-masked]>
Reply-To: <[email-masked]>
Date: Tue, 19 Apr 2011 09:36:54 -0700 (PDT)
To: IETF Announcement list <[email-masked]>
Cc: <[email-masked]>, Yong Cui <[email-masked]>
Subject: [Softwires] WG Review: Recharter of Softwires (softwire)

>**DRAFT 2011-04-14** (v03)

Change "DS-Lite with no NAT or NAT on the B4 element" to "No NAT on AFTR"

>Jul 2011 Adopt B4NAT as WG document

Replace the item on B4NAT to the following two lines:
Jul 2011 Adopt DS-Lite without NAT as WG document
Jul 2011 Adopt DHCPv4 over tunnel as WG document
 
>Sep 2011 Submit B4NAT for Informational

Again, replace the item on B4NAT to the following two lines:
Sep 2011 Submit DS-Lite without NAT for Informational
Sep 2011 Adopt DHCPv4 over tunnel for Proposed Standard

Thanks,

Yong

---

From: Naoki Matsuhira <[email-masked]>
Date: Mon, 25 Apr 2011 12:00:24 +0900

some comments in line.

> **DRAFT 2011-04-14** (v03)

s/Active/Active Working Group/
It seem "Working Group" dropped in editing.

>    IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6).

"should support all combinations" seem strong expression with specific 
work #4, that is "Developments for stateless legacy IPv4 carried over 
IPv6". Maybe specific work #2 (6rd) is the same.

one of proposal below.

     For generality, all base Softwires encapsulation mechanisms prefer
     support all combinations of IP versions over one other (IPv4 over
     IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). However,
     all combinations may not be apply if it is useful.

>                                                             IPv4 to IPv6

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Apr 2011 18:14:19 +0900

I'm very confused to understand what DS-Lite is.

> Change "DS-Lite with no NAT or NAT on the B4 element" to "No NAT on AFTR"

However, "draft-ietf-softwire-dual-stack-lite-07" clearly express AFTR is carrier grade NAT44, 
and B4(CPE) should not operate a NAT function. So my question is what does the DS-Lite function deployment model include.
Current DS-Lite definition does not accept any extension for "DS-Lite with no NAT or NAT on the B4 element" to "No NAT on AFTR".
I think that to do this as a charter item, we need definition change of DS-Lite, or use another terminology instead of DS-Lite.

Best regards,
--satoru

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Fri, 29 Apr 2011 16:33:43 +0200

> I think that to do this as a charter item, we need definition change of DS-Lite, or use another terminology instead of DS-Lite.

"DS-Lite with no NAT or NAT on the B4 element" or "No NAT on AFTR" are 
fancy new names for A+P.

A+P was defined in DS-Lite as possible way of doing it some versions ago 
but disappeared through the time.

No idea why, but anyway. Basically DS-Lite and A+P are similar 
mechanisms with NAT at different places. See ymbk-aplusp draft, section 
"Overall architecture".

Cheers, Jan Zorz