[v6tc] background information / potential text for a charter for v6tc

[Alain Durand <[e-mail]>]

Problem statement:
--------------------------
Enable ISPs (ISPs are defined as traditional broadband ISP, 3GPP,  
enterprise IT department, ...)
who have upgraded their core network to v6 one way or another (using  
native links or tunnels)
to offer production v6 service to their customers without upgrading all  
  their access network
at once (which can be cumbersome, expensive,...)
Essentially, it decouples the issue to upgrade the core and the access  
networks.
Automatic transition mechanisms like 6to4, teredo do not really  
leverage the infrastructure
the ISP had put in place and offer little insight on how to gradually  
introduce native
IPv6 in the access network.
Configured tunnels are better suited for the job, and a number of  
deployment
have been undertaken using the tunnel broker approach. However, the lack
of standard on how to configure those tunnels remains a serious  
obstacle and
manual configuration of all the parameters is out of reach of typical  
customers.

ISP assumptions:
-----------------------
It is assumed that the ISP has upgraded its core network so it can have  
global IPv6
connectivity. It is also assumed that the ISP has obtain its address  
space, either
from the RIRs or an upstream ISP.
The ISP can be small, large or extra large and span the entire planet.  
In that case,
it is expected that a number of IPv6 point of presence will be deployed  
all over the
word and that customers will 'connect' to the 'closest' one.

Access media assumptions:
--------------------------------------
No assumptions are made on the access network. They will have high or  
low
bandwidth, high or low latency, high or low access cost, and there will  
be
more or less secure. Especially in the case of wireless access network,
confidentiality of the data cannot always be guaranteed. Address  
spoofing
may or may not be a problem.
Although those environment vary widely, it is expected that a single  
configuration
protocol with a number of options can be designed to accommodate all  
the different cases.

Customer assumptions:
--------------------------------
Customers connecting with IPv6 to their ISP can have multiple  
configurations.
The most common topologies expected to be encountered are:
	 - a single node, directly attached to the ISP access network
	 - a router, directly attached to the ISP access network
	 - a router, behind an unmodifiable IPv4-only customer owned NAT
The IPv4 addresses of the customer may change over time and be  
dynamically allocated.
In the case of NAT environment, both the internal and the external  
addresses
may be dynamically allocated.
Another case to consider in the "roaming" user. When the customer is  
roaming within
the ISP network(s), this is not really different than having a dynamic  
IPv4 address,
except that the "nearest" ISP tunnel end point to use may be different.  
When the
customer is roaming in another ISP network that does not offer IPv6  
service, the
"home" ISP may be willing to still offer tunneling service, however the  
security
implications and the tunnel end point discovery mechanism to use will  
be different.


Work items:
----------------
The problem can be decomposed into two independent areas:
	a) Having a way for an ISP to indicate that it is offering tunnel  
services to its direct customers,
	    and how to invoke them. This is also known as tunnel end-point  
discovery.
	    Due to the large variety of customer configuration expected,  
classic mechanisms
	    like DHCP or SLP cannot be used (they would have a hard time to  
work through
	    an unmodified NAT).
	    This mechanism will be limited to the administrative domain  
controlled by the ISP
	    and thus could not be used by customers roaming in other ISPs  
networks.

	b) Setting up of a tunnel, maybe with some negotiation about various  
parameters.
	     For reasons of efficiency over very high latency networks,  
minimizing the number
	     of packet exchanges is important, thus it is possible that some  
parameters
	     that would normally be obtained over a subsequent DHCPv6 exchange
	     (like IPv6 addresses and/or prefixes) would be optionally  
piggybacked into this
	     configuration negotiation.

Focus:
---------
This work is not about creating a new transition mechanism, but to  
offer a standardized
way to configure v6 over v4 tunnels, potentially using UDP as an extra  
layer of encapsulation
to work over NAT. The work perform in a) and b) will be made generic  
but will
focus essentially on v6 over v4 case. It is expected that it could be  
reused to help
configuring v4 over v6 tunnels, but this will not be the priority of  
this working group.

Way forward:
------------------
The v6tc working group will do three things in parallel:

1. Merge the three v6Ops requirement documents into a v6tc combined  
goal document,
      dropping things that are not necessary and anchoring each goal  
into characteristics
      of the different access networks considered. This document would  
also described
      targeted customer environments. The outcome of this work item is a  
Informational RFC.

2. Finalize the  tunnel end point discovery mechanism tradeoff analysis  
document.
     This work will collect input from other related working groups,  
mainly DNSop
     and be published as an Informational RFC.
     When this will be understood, we'll standardize one solution. This  
will be published
     as an Standard Track RFC.

3. Use the issue tracker to document the different tradeoff in the  
solution space
      some of the issues initially explored are:
	- Could we live with UDP encapsulation always on?
	- Do we need mutual authentication? How strong should this be?
	- Should some of this authentication mechanism "follow-on" atfer the  
tunnel set-up phase
	  as finished?
	- Should we embed some kind of signaling in the tunnel?
	- How much of the wheel are we going to re-invent?
  	  e.g. if we define a new packet exchange and there is a goal
	  to minimize the total number of RTT needed, there is a temptation
	  to piggy-back configuration information in this protocol that could
	  be over wise obtained via DHCP...
      When those tradeoff will be understood, the v6tc working group  
will define
      a configuration protocol that will be published as Standard Track  
RFC.

List of documents to be used originally as input to v6tc:
------------------------------------------------------------------------ 
--
http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf- 
reqs-01.txt
draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
draft-palet-v6ops-tun-auto-disc-02.txt

Goals & Milestones:
--------------------------
01/2005: initial merged goals document
01/2005; initial tunnel end point discovery analysis document
01/2005: issue tracker set-up for configuration trade-off analysis

04/2005: initial configuration protocol specification document

06/2005: wg last on  tunnel end point discovery analysis document
06/2005: initital tunnel end point discovery specification document
06/2005: wg last call on goals documents

12/2005: wg last call on configuration protocol specification document


_______________________________________________
v6tc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/v6tc