Softwires (softwire)
--------------------

 Charter
 Last Modified: 2006-02-22

 Current Status: Active Working Group

 Chair(s):
     Alain Durand  <alain_durand@cable.comcast.com>
     David Ward  <dward@cisco.com>

 Internet Area Director(s):
     Jari Arkko  <jari.arkko@piuha.net>
     Mark Townsley  <townsley@cisco.com>

 Internet Area Advisor:
     Mark Townsley  <townsley@cisco.com>

 Technical Advisor(s):
     Xing Li  <xing@cernet.edu.cn>

 Mailing Lists: 
     General Discussion:softwires@ietf.org
     To Subscribe:      softwires-request@ietf.org
         In Body:       With a subject line: subscribe
     Archive:           http://www.ietf.org/mail-archive/web/softwires/current/index.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 (financial or political), native IPv4 and/or IPv6
transport may not be available in all cases, and there is need to 
tunnel
IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is 
not
IPv4 or IPv6 capable. Configured tunnels or softwires are suited for 
the
inter-networking job. Non-interoperable tunneling mechanisms have been
developed based on the RFC3053 tunnel broker concept, and in addition,
standardized mechanisms like RFC2893, RFC2473, GRE, L2TP, etc.
have been used in some scenarios. Other deployments use
non-standardized, incomplete solutions. The lack of interoperable 
and/or
standardized solution in that space has been noted in the v6ops WG
scenario analysis.

The focus of this WG is to define a softwire setup negotiation protocol
and encapsulation to be used between a node and the corresponding
softwire end-point. Softwire configuration includes two phases: 
softwire
end point discovery and softwire set-up. The WG will attempt to reuse
existing technologies as much as possible and if necessary, create
additional building blocks. It is expected that existing encapsulations
will be the starting point.

In the softwire set-up phase, the initator and the ISP negotiate the
parameters necessary to establish the softwire. Those include:

- The encapsulation type: IPv4-over-IPv6 or IPv6-over-IPv4 with a
possible intermediary layer (e.g. UDP). This encapsulation negotiation
should be extensible to cover future methods of both unicast and
multicast traffic.

- How to obtain the IP addresses to use for the softwire end-points.
This could be done with an out-of-band mechanism or directly negotiated
at set-up phase.

In the softwire end point discovery phase, the initiator gets a name or
an IP address for the ISP-side end point of the softwire to establish.
This phase is orthogonal to the set-up one.

The initial milestone for this working group will be the set-up phase.
This WG is not chartered to work on the discovery phase and a re-
charter
will be needed prior to undertaking such work; once the base work has
been completed (or is well under way), WG may consider re-chartering to
address discovery.

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

The WG is chartered to complete the following work items:

1. Document problem statement and submit to IESG as Informational. If
this problem statement cannot be written within the IETF process of
rough concensus, then the following items will not be advanced.

2. Document softwire encapsulation and control protocol usage for
IPv4-over-IPv6 or IPv6-over-IPv4 with possible intermediary layer and
submit the specification to the IESG for publication as a Proposed 
Standard.

3. Develop the softwire MIB module and submit it to the IESG for
publication as a Proposed Standard.

 Goals and Milestones:

   Jan 2006       Submit a problem statement to the IESG to be considered as an 
                Informational RFC 

   Jul 2006       Submit softwire encapsulation and control protocol to the IESG 
                to be considered as a Proposed Standard 

   Oct 2006       Submit softwires MIB to the IESG to be considered as Proposed 
                Standard 


 Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Jun 2006 Jan 2008   <draft-ietf-softwire-hs-framework-l2tpv2-08.txt>
                Softwire Hub & Spoke Deployment Framework with L2TPv2 

Jun 2006 Feb 2008   <draft-ietf-softwire-security-requirements-06.txt>
                Softwire Security Analysis and Requirements 

Apr 2007 Jan 2008   <draft-ietf-softwire-mesh-framework-03.txt>
                Softwire Mesh Framework 

Jan 2008 Jan 2008   <draft-ietf-softwire-v4nlri-v6nh-00.txt>
                Advertising an IPv4 NLRI with an IPv6 Next Hop 

Jan 2008 Jan 2008   <draft-ietf-softwire-bgp-te-attribute-00.txt>
                Traffic Engineering Attribute 

Jan 2008 Jan 2008   <draft-ietf-softwire-encaps-safi-00.txt>
                BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute 

Mar 2008 Mar 2008   <draft-ietf-softwire-encaps-ipsec-00.txt>
                BGP IPSec Tunnel Encapsulation Attribute 

 Request For Comments:

  RFC   Stat Published     Title
------- -- ----------- ------------------------------------
RFC4925 I    Jul 2007    Softwire Problem Statement