2.3.23 Softwires (softwire)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-10


Alain Durand <alain_durand@cable.comcast.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Mark Townsley <townsley@cisco.com>

Mailing Lists:

General Discussion:
To 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 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:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Softwires WG NotesChairs - Alain Durand and David Ward

Notes - Spencer Dawkins 

Agenda bashing: none noted.

The IESG approved Softwire as a working group this morning... Some editorial 
nits, but we are a working group.

Congrats to Mark Townsley, now a father... (applause)

A) Overview of meeting in Paris

Held in Paris on Oct 11-12, with 18 participants and intense discussion.

Focused exclusively on the problem statement for Softwires. Draft problem 
statement submitted "just in time" for draft cut-off, needs cleanup.

Identified two problems, based on topology ("hubs and spokes", "mesh"). Will 
look at problems independently, but HOPE they will share "enough" common 
technology - not independent.

Goals - NOT to do new encapsulation, tunneling, or routing technologies.

B) Durand: Hub and Spoke Problem Overview

Not a new problem, has been discussed, Paris work was to describe it formally.

Access network, customer initiated, one exit path (no routing)

Dual stack core and points of presence, may be connected by 
single-address-family path elements.

Two components, Softwire Initiator and Softwire Concentrator are dual-stack. 
Initiator may be directly connected to the Internet, or via router that is NOT 

Some use cases do IPv4-over-IPv6, others do the reverse.

Assumtions - NAT/PAT in IPv4, CPE router may not be upgraded, want stable IPv6 
address/prefix ...

Scaling to millions, setup latency is "fraction of the setup time of the CPE 
router". multicast uses classic solution over softwire

Must support secure user authentication, but may be turned off. Must support 
payload security when desired.

Operation and Management - keep-alive, usage accounting, endpoint failure 
detection, path failure detection

Targeting v6/v4, v6/udp/v4, v4/v6

Is the model datagrams over datagrams, or datagrams over connections, or? 
datagrams over datagrams

B1) Shin, Carl, Jordi:Hub and Spoke Illustration

Shin showed same IPv6 over IPv4 illustration as Paris (IETF and Interim 

Would do native IPv6, but don't want to require CPE replacement in this 

Jordi showed two example cases which he often finds when dealing with

1) A 5000-sites network diagram from Spain (although there are other similar
networks elsewhere). Has an IPv6 core and access, but dual stack in the
sites. Most of the traffic is tending to be IPv6-only, either among the
sites or to the data center, which remains dual stack in order to support
also Internet (IPv4) applications (in/out initiated).

2) An ISP network with has an IPv4 only core and access network. The core
could be also dual stack, and actually more often is this way. The end sites
are dual stack, being the CPE NAT (most typically) or not, IPv4-only or dual

Carl showed KDDI's home deployment network diagram - based on ISP backbone 
that's IPv6, but has IPv4 access networks and NAT boxes. Very similar network 
diagram for hotspots supporting IMS services. Mutual authentication is needed 
for these applications.

C) Ward: Mesh Problem Overview

Mesh problem is for core networks with complex routing topologies. Difference is 
that softwires are ISP-provided and initiated

"Address Family Boundary Router" - new component terminology

Core can be exclusively one address family, islands don't need to be upgraded.

AFBR peering can be intra-AS or inter-AS

Connectivity is many-to-many - not a single uplink routing situation

Must support multiple encapsulation mechanisms

Must support 2547bis L3VPNs (cannot break these with our solution)

Number of AFBRs is related to number islands/exit points from an island. We 
think the range is for 10s-100s of islands - not thousands, or higher, but 
islands can use a full routing table

Must support L2VPN, L3VPN-overlapping addresses, multicast

Don't think we need keepalives, but do need accounting, failure detection, 
flexible encapsulation

C1) Prof Li: Mesh Illustration

Professor Li showed the Chinese Next-Generation Internet project CERNET2 network 
diagram. IPv6 is being used for political reasons.

25 POPs, 20 cities connected by transport network, about 100 access networks

Not easy to port applications from IPv4 to IPv6 - need high-performance IPv4 
connectivity - want to support IPv4 access networks and applications

Using edge routers that correspond to AFBRs in softwire description with IPv6 
core network

Can use same architecture in reverse if there are IPv4-only core networks

Concerns about scalability and broadcast storms if they use level two solution

Initial requirement is within an AS, but multi-AS support is desirable

Pekka Savola - not really an IPv6 core if you have 100 PE routers that are 

??? - this is similar to what is done in North America using level two solutions

D) Presentation of draft problem statement

Next version will not be edited by Alain...

Are there other designs that could be used? Almost certainly - probably 
infinitely so.

Mesh network questions - scale (answered today), L2 versus L3 (probably need 
both), initiated from PE or CPE, or both (most likely PE, for mesh)

Greg Shepards - Don't see any of this coming from a technical driver, only from 
a business driver

E) Next steps

Well, celebrate, and then ...

Need to rev nits on charter, rev problem statement draft (immediately), WG last 
call ends December 8th, Interim meeting on solution space in January/February

Will not work on solutions until problem statement goes to IESG

F) Questions and comments

Pekka - supportive of hubs and spokes, see it a lot and it's been discussed 
extensively. More sceptical about mesh networks, have only heard this 
requirement from one or two operators and need to get operator feedback for a 
generic solution

Jim - good job, do you need help offline? I'm seeing the same thing in North 
America, and now in South America as well. Operators will send relayed e-mail, 
but don't want to join the mailing list and see the other discussions

Mark - having two problems in the same document limits the hub from trying to 
solve the mesh problem - we actually need this in order to make progress

Mark - we have a good turnout on readers for the problem statement - working 
group last call of 01 by December 1, so we go into the working group interim 
meeting? Sense of the room is "don't wait for six months"...

Dino - do you think these are new problems or old problems that have never been 
Dave - hubs and spoke has almost come and gone with non-standard solutions, and 
mesh is similar to comparable problems - we don't need more solutions, we just 
need to choose some of the solutions we've already got

Shin - will this be rough consensus and running code, or more theorectical?
Alain - running code is not an absolute requirement until draft standard, but 
we'd love to make few/no changes. We will not be here for five years

Tom - can we start documenting existing solutions?
David - we can do this in parallel.

Pekka - would like to see mesh network deployers send description to the mailing 
list, because we don't want solutions based on one or two inputs.
David - we can't force people to send stuff to the mailing list, but we'd love 
to see them do this

Jim - we know the mesh problem exists. We're not the Gardner group, we're 
engineers. We would love to have operator inputs but we can't wait on this, or 
we would never do anything. I can wait for customer requirements at work.

Pekka - we can define a problem statement around CERNET's presentation, but what 
if it's not a typical mesh network?
Alain - please encourage operators who are deploying different mesh solutions to 
tell us about them!


Hub & Spoke, NTT example
Hub & Spoke, KDDI example
Mesh, Cernet example