2.3.13 Lightweight Reachability softWires (lrw)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-20

Chair(s):

David Ward <dward@cisco.com>
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:
Archive:

Description of Working Group:

No description available

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Softwires BOF Notes Lightweight Reachability softWires BOF (lwr)

Thursday, August 4 at 0900-1000
===============================

CHAIRS: David Ward <dward@cisco.com>
Alain Durand <alain_durand@cable.comcast.com >

Notes: Spencer Dawkins <spencer@mcsr-labs.org>


DESCRIPTION:

The LRW (Lightweight Reachability softWires) BOF is to discuss the problem
space of: discovery, control and encapsulation methods for connecting IPv4
networks across IPv6 networks and IPv6 networks across IPv4 networks. Due
to the fact that some networks are mandated that certain network functions
must be IPv4 or IPv6 (e.g. due to financial or political reasons); dynamic
tunnels or 'softwires' are suited for the inter-networking job. The goal
of the BOF is to form the LRW WG that will work on these issues.

AGENDA:

Softwires@ietf.org will be the new mailing list.

- Agenda was bashed but not changed.

Intro and past history: Alain and David - 20 mins

- New draft charter is at http://bgp.nu/~dware softwires/Softwires_charter.html

Problem Statement and network deployment issues: Prof Li - 30 mins

- Pure IPv6 backbone arguments - resources, finances, politics. All matter!

- But still need IPv4 applications - porting is not difficult but not automatic, and some applications will never be ported to IPv6.

- So doing IPv4 over IPv6, even as part of a transition to IPv6.

- Requirements - transparent, lightweight, unicast/multicast, intra-AS/inter-AS routing, dynamic address, authentication, mobility ...

- Control and  discovery plus encapsulation.

- Chinese requirement for 83 /8s driving this now - and transition to IPv6 is very slow.

- China has second largest Internet population behind US.

- CERNET2 will be IPv6-only, 25 POPs in 10 cities, 100+ access networks.

- Chris - why would IPv6-only be more secure? single-stack routers have fewer features (even though IPv6 implementations are less mature)

- Jordi - we have similar situations elsewhere (Spain, etc.)

Problem Statement and network deployment issues: Comcast - Shin

- Want to allow users to create IPv6 over IPv4 tunnnels to "taste" IPv6 easily.

- For Comcast, dual stack is OK.

- MUSTs - NAT traversable, authentication

- MAYBEs - encryption, automatic tunnel endpoint discovery

- More details on termination box on slides? want a small, cheap termination box instead of replacing current access box

- Pekka - Customers using tunneling service in another network? Does have impacts on authentication.

Problem Statement and network deploymenti ssues: 3GPP2 - KDDI Labs - Carl Williams

- for home deployments, access network may not be owned by KDDI, and may be IPv4

- Putting IPv6 networks in cars, etc. in 3GPP environments

- Need to discover tunnel endpoint servers in local networks (for tunnels back to home networks)

- Need multilevel support, and need efficient use of wireless resources

- Also includes wired networks, etc.

- Pekka - you want prefix delegation even if you're not using DHCPv6, right? And have requirements on tunnel latency, right?

Problem Statement and network deployment issues: Sprint - Michael

- Nearly zero demand for native IPv6 connectivity - not mature, mostly still research networks, no killer apps

- Cost-prohibitive to upgrade given demand (capex and opex) - no justification to deploy IPv6

- Technical problems - MCAST for V6 customers over IPv4 core, dual stack scalability on legacy hardware

- Upgrade your hardware! Can I use your Visa? Most transit services in Amsterdam are free...

- Jordi - I radically disagree with tunneling in the core networks. New customers are asking for native connectivity, you guys are offering tunnels.

- Kurt - hardware deployed isn't going to do v6. Accept it.

- Shim - we are limited to offer native service. Nobody pays for network protocol anyway - they pay for services.

- there is not enough demand for v6 to justify native support!

Renater - Jerome Durand

- Goal is to provide TEMPORARY IPv6 connectivity for sites not connected to Renater IPv6, mobile users, temporary events, enterprises/R&D departments

- Need accounting, NAT bypass, multicast, manageable solution, maintenance/vendor support, not waiting for something that doesn't exist now.

- Performance is NOT a requirement - initially. Service discovery is not a requirement (we'll target the customers anyway).

Comcast - Alain

- IPv6 deployment being planned now. Net 10 is too small. We would like a "trial balloon" - now! Limited functionality is a feature, not a bug.

WG charter proposal and bashing: Alain and David

- Should have new mailing list by end of week.

- Want interim working group meeting immediately working on problem statement, define a softwire setup negotiation protocol, (MAYBE recharter and) define a softwire discovery mechanism

- Problem statement by March, November 06 is protocol and MIB

- Thomas - Why publish candidate choices before WG creation date? Need to be well-known solutions. Individual submissions get no review. Would like to have something more stable than a draft. Being in RFC editor queue is irrelevant. ADs are requiring proposed standard that won't be based on a draft.

- Mark Townsley - IESG would say "do not publish" if you try to indivdual-submit solution after working group is chartered.

- Margaret Wasserman - this is complicated with lots of concerns on all sides. May not have found the right answer yet. Is it fair to prefer published RFCs? but we don't want a sea of 14 drafts when the working group starts.

- Pekka - don't propose anything that hasn't been implemented? Dave - we want to reuse technology

- Is this end site connectivity or carrier connectivity? Dave - solutions today don't cover the problem space. Trying to solve both.

- Jordi - what's the difference between this and what was previously proposed in v6tc? We've broken the process. Mark - if we don't form the working group now, we never will. Dave - trying to solve the problem, not work through the solution set.

- Tim - v6tc charter is almost identical - what happened? Mark - at the last BOF, was very new on the job...

- Jonne - v6tc explicitly left out encapsulation mechanisms - Dave - may need to tweak existing proposed encapsulations, but at least we need to pick one.

- Kurt - "tweak" scares me ... need to tweak mechanisms in the groups that developed them! - pick a date for submissions? No, we're just saying can't submit to RFC editors while working group is active.

- Thomas - March 06 is a long time from today - problem statement is important in getting the charter in order. We're asking for trouble. Need to understand the problem space

- Francis - MIP6 can get a solution to this particular problem.

- Everyone has a legitimate problem, and this is helpful. Consider a transition mechanism?

Sense of the room? to create a working group - 2 against, a lot for...

Slides

IPv4 over IPv6 Problem Statement and Network Deployment Issues
On the tunnel service
Scenarios and network deployment requirements
V6 over v4 Discussion
Migration Broker: Our requirements
IPv6 @ Comcast