[802SEC] FW: [New-work] WG Review: Softwires (softwire)
- To: STDS-802-SEC@listserv.ieee.org
- Subject: [802SEC] FW: [New-work] WG Review: Softwires (softwire)
- From: "Congdon, Paul T (ProCurve)" <paul.congdon@HP.COM>
- Date: Mon, 10 Oct 2005 21:46:19 -0700
- Reply-To: "Congdon, Paul T (ProCurve)" <paul.congdon@HP.COM>
- Thread-Index: AcXNsKPEMjdMSPPGRuGc6/1StCIWAgAbgT+A
- Thread-Topic: [New-work] WG Review: Softwires (softwire)
The following new work announcement from the IETF may be of interest to
your working group members.
From: email@example.com [mailto:firstname.lastname@example.org] On
Behalf Of The IESG
Sent: Monday, October 10, 2005 8:27 AM
Subject: [New-work] WG Review: Softwires (softwire)
A new IETF working group has been proposed in the Internet Area. The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list (email@example.com) by October
Current Status: Proposed Working Group
Internet Area Directors:
Mark Townsley <firstname.lastname@example.org>
Margaret Wasserman <email@example.com>
Internet Area Advisor:
Mark Townsley <firstname.lastname@example.org>
General Discussion: email@example.com
Send mail to: firstname.lastname@example.org With a subject line: subscribe
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,
IPv6 networks across IPv4 networks in a way that will encourage
multiple, inter-operable vendor 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 use between a node and the corresponding
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
- 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
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
3. Develop the softwire MIB module and submit it to the IESG for
publication as a Proposed Standard.
Goals and Milestones:
Jan 06 Submit a problem statement to the IESG to be considered as an
Jul 06 Submit softwire encapsulation and control protocol to the IESG to
be considered as a Proposed Standard
Oct 06 Submit softwires MIB to the IESG to be considered as Proposed
New-work mailing list
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.