2.3.22 Tunneling Configuration (tc)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-09

Chair(s):

Thomas Narten <narten@us.ibm.com>
Alain Durand <alain.durand@sun.com>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion:
To Subscribe:
Archive:

Description of Working Group:

ISPs will likely deploy IPv6 incrementally, meaning that parts, rather
than all of their networks will support native IPv6 service. They will
need a way to provide IPv6 service to customers without requiring that
native IPv6 service be provided on the access link.  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
deployments 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 a significant burden for typical customers.


ISP assumptions:

It is assumed that the ISP has upgraded its core network and has
global IPv6 connectivity. It is also assumed that the ISP has obtained
global address space (that it will delegate to its customers), either
from an RIR or an upstream ISP.  They key point is that the ISP does
not (yet) provide native IPv6 access to all of its customers, but does
want to provide an IPv6-over-IPv4 tunneling service. It is also
assumed that large ISPs will have multiple POPs, and roaming customers
will want to use a tunnel service topologically close to the current
POP, rather than always using the same 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 within its home ISP
network. 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:

A "generic" tunnel setup protocol. The key requirement is to allow the
creation of a tunnel for sending IPv6 over IPv4. In order to setup a
tunnel, some negotiation may be needed in order to determine such
properties as the encapsulation (e.g., GRE, IPv6-over-IPv4, etc.), MTU
parameters, authentication and/or security properites, etc.  For
reasons of efficiency over very high latency networks, minimizing the
number of packet exchanges is desirable.

This group will not create new tunneling encapsulations. Moreover, it
will reuse the work of other WGs rather than inventing unneeded
mechanism. For example, IPsec can be used to create tunnels. The setup
protocol could determine that an IPsec tunnel is needed, and then rely
on IKE (as specified elsewhere) to setup up the appropriate tunnel.

--------------------------------------------
A key question the BOF should answer is if the tunnel set-up protocol
should be limited to IP in IP tunnel (with a focus on IPv6 in IPv4) or
if it should be extended to other types of encapsulation, like GRE,
MPLS,...
--------------------------------------------

Another possible work item is a way for an ISP to indicate that it is
offering tunnel services to its direct customers. This is also known
as tunnel end-point discovery.

--------------------------------------------
The BOF should answer is if this second work items should be covered
by the same wg or not.
--------------------------------------------

Focus:

This work is not about creating a new transition mechanism, but to
offer a standardized way to configure tunnels.

Some of the issues initially explored are:
- Do we want to focus on IP in IP tunnels or extend to GRE,
MPLS,...
- Do we want to address the tunnel end point discovery problem?
- 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 has finished?
- Can we have separate channels, one for configuration and one
          for the tunneled traffic or should we maintain only one
          channel to help traverse NAT?
- Should we embed some kind of signaling in the tunnel channel?
- 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...

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

TC BoF

IETF62, 3.30pm Monday 7th March

Chairs: Alain Durand, Thomas Narten
Mail list: v6tc@ietf.org

Problem Statement (Narten)
---------------------------
[See presentation "Problem Statement"]
IPv6 enabled core, but no IPv6 in access network.
How to set up tunnel between a home site and core?
Need to agree properties: authentication, mtu, encapsulation
Also need to find the TEP.
Can make assumptions about the ISP
e.g. ISP may have multiple POPs around world, so need to pick 'nearby' TEP
Can make assumptions about the customer
e.g. might be a node, or a router, with IPv4-only connection to ISP
Need to have negotiation due to wide variety of access media and whether
features like authentication are required, encryption of tunnel, etc.
Need to consider keep alives, NAT refresh, etc.
TEP discovery is orthogonal to the configuration.
Generic automatic discovery is 'difficult' in the general case.
Note that SMTP, SIP etc do not provide general discovery like this.
Encapsulation: IPv6 over IPv4, or IPv6 over UDP over IPv4, or specialist encapsulation
Some limitations, e.g. 64K port numbers for a NAT box with many TEPs behind it
e.g. L2TP includes a demux key for the TEP.
Might we do something generic enough to be used for other tunnel types?
Are there off-the-shelf solutions?

[Discussion]
Miakawa) ISPs might have some access networks that are upgraded some not
(Bound) Change to say ISP does not offer IPv6 natively to *all* customers
(Palet) Auto decide whether to tunnel or not depending on whether native available
(Palet) Some networks are IPv6-only, so need IPv4-in-IPv6 tunneling here
(Hans Trefini) You have one solution providing light weight solution with out mandatory authentication. This should be negotiated. Do you also consider mobile end points? Not part of the current problem statement, but inside or outside of NAT could be dynamic, but we do not want to consider Mobile IP. Might want to consider IPSec tunnel paradigm.
(Ron Bonica) Could be applicable elsewhere, change IPv6 to any arbitrary service, e.g. IPv4 multicast.


Merging goals (Palet)
-----------------------------
draft-palet-v6tc-goals-tunneling-00
[see presentation "merged Goals"]
Converged three separate documents to work on a single document
Basic objective to describe set of goals, and cross check against scenarios.

[Discusssion]
(Meyer) IPv4 multicast tunneling often doesn't get removed from service.
(Narten) Not engrained here, ISP can just stop using it.
(Savola) multicast tunnels were inter-domain not to end user
(Narten) tunnel setup is important for service, but also need addresses... maybe combine all into one,
(Chown) ISP has cost for tunnels - concentrator cost, customers can't talk direct, tunnel overhead in bandwidth, so will want to remove.
(Chown) On the draft, the scenario section should just be removed since you have aggregated requirements into the first sections. The first sections could be compressed more.
(Kurtis) Mixing service description and tunnel configuration protocol
(Mark Townsley) 'latency' is a vague term, what is acceptable latency? is it set up once and stays, or fired up frequently?
(Palet) Design protocol with different functionalities for different networks? May not want keep alives in some networks for example.
(Mark Townsley) Lots of issues - scalability, QoS, ...?
(Thaler) On TEP, what is scope? Is it discovering endpoint in same ISP or could it be larger?
(Narten) Open question.
(Thaler) Great if in scope, but makes it harder
(Bound) Spec doesn't belong in this BoF or the IETF. No innovation or technical creativity - is an interesting deployment spec but not sure why I'm here listening to this. It should go away.
(Ross Callen) If were some way to tell a v6 router there is someone trying to get to you you may be able to fire up a tunnel dynamically?
(Dave Green) Many systems integrators are doing this already, so why not BCP?
(Durand) Not clear something off the shelf ready yet
(Dave Green) Firewall an issue if bypassing site security



Existing protocol analysis (Parent)
[see presentation "Protocol Analysis"]
ISATAP, STEP, AYIYA, TSP, L2TP (RFC2661)
Differences tend to lie in prefix delegation, NAT traversal, (un)registered mode, security, setup latency, otherwise most goals are met.
[Discussion]
(Mark Townsley) Again, latency is a tough thing to measure, e.g. 13 packets in AYIYA, is this an issue? Maybe total round trips would be a better measure?
(Bound) You missed IPv6 dominant network scenario and DSTM? No Teredo either.
(Parent) We can add them in.
(Bound) Who are you representing? You missed some of the past five year's work
(Narten) I'd question whether Teredo is appropriate - not setup to ISP TEP.
(Bound) All you want to do is define parameters?
(Narten) You need a tunnel, and you need to originate from client to clear TEP in ISP.
(Bound) Mechanisms will not be defined here
(Durand) Not here to do that, just here to configure tunnels
(Thaler) Clarify address stability please
(Parent) IPv6 address will not change if underlying IPv4 address changes, thus ISP uses own IPv6 address space.
(Narten) If you roam to multiple POPs, do you keep stability?
(Parent) Good question.
(Townsley) Is it a strict requirement? Affects solution dramatically
(Parent) Main issue is not embedding IPv4 addresses in IPv6 addresses, for example.
(Dupont) We used L2TP and I have that for any Linux or BSD.

L2TO or not (Durand)
----------------------------
[See presentation "L2TP"]
Need to look at total latency, e.g. if using DHCPv6 on top of the tunnel, you add more latency, e.g. L2TP(8), PPP+CHAP(11), DHCPv6(4) = 23 packets.
May be a big issue if RTT is 0.5 sec in 3GPP.
Strength of this requirement will vary with the scenario.
Can we collapse all this into one protocol?
<some example 'maths' presented>
Layers there for a reason
e.g. PPP does MTU adaptation, L2TP is doing tunnel management, e.g. keepalive and can make sure packets ordered
If we don't use L2TP the node may need to do that.

[Discussion]
(Hans) Investigate IKE?
(Durand) Yes, this is a candidate.
(Dupont) L2TP is good candidate for header compression
(Townsley) Few people implement header compression
(Thaler) DHCPv6 isn't a major contributor to latency, but you donít want to have to duplicate all new DHCPv6 options. Push back on putting DHCPv6 into this. Stick to Layer 2.

Solution Space Analysis (Savola)
--------------------------
[See presentation "Solution Space Analysis"]
First issue is tunnel link configuration
What to be configured, and how to configure it.
Separate question is how to do IP configuration of the tunnel, e.g. DHCPv6, RA.
Avoid reinventing IP configuration or DHCPv6.
Generic solution might lead to some L2TP 'reinvention'
A specific solution might address only IPv6 over (UDP) IPv4.
So, main approaches would be
- use L2TP, maybe modify it
- use TSP
- create collapsed in-band mechanism, reusing DHCPv6 or RAs
Some considerations, like NAT detection (maybe just assume there is a NAT?)
Probably just pick the IPv6 over UDP IPv4 for encapsulation
Authentication supported, but probably only when roaming? (otherwise use IP check)

(Durand) You have described in-band and out-of-band mechanisms. Will now look at an example of each.


(Savola)
<presented STEP as in-band solution>
[See presentation "Step"]
IP and link configuration is just 2 or 4 packets.
(Parent)
<presented TSP as out-of-band solution>
[See presentation "TSP"]


Open Discussion
------------------------
(Hans) Why do you use XML if worried about efficiency? Other efficiency issues exist
(Savola) Were we redesigning it may be done in a more optimal way
(Chown) Where are the potential ISP users of this? Note 'costly' is a vague term - where is cost - e.g. user support, which is same for native or tunneled? Would actual ISPs make a deployment using this now ahead of a full native deployment? Any ISPs here?
(Durand) Please comment
(Miakawa) No implementation, we can't use it, timeline is important. Not sure why no IPsec on the list. Problem space similar to VPN extension issues.
(Palet) Main difference is in Enterprise VPN don't need tunnel discovery, will be manually configured.
(Miakawa) Users donít care to configure network number.
(Savola) VPNs must use encryption, here you may not want to do that for scalability
(Miakawa) Have to authenticate users.
(JDurand) we deployed a broker, so surprised to see work on this. networks in the middle, hence deployed broker, otherwise would go native.
(Narten) some ISPs donít want to upgrade across the board
(JDurand) We bypass equipment in the middle
(Miakawa) We are doing IPv6 native because cheaper than tunnel
(Chown) Enterprise wants to offer v6 to remote users e.g. at home or at WLAN hotspot - so see Thaler cross-ISP issue
(Palet) Some existing tunnel brokers donít work in some cases, hence this generic work. Also make the broker discovery automatic.
(Bound) WG should do 4-in-6 and 6-in-4 and security should be included. If broker can be made better its code that runs in user space, so that's fair game.

TEP discovery (Savola)
--------------------------------
[see presentation "End Point Discovery"]
Proposed solutions work using one of:
- Well-known unicast address (anycast) for discovery of 'real' unicast address
- DNS forward or reverse
- DHCP or PPP options
- SLP
If need to work through NAT, options limited.

[Discussion]
(Kurtis) This is problem we donít want to solve. Closer to service description than having much to do with tunnel configuration protocol. Should be separated. Only solutions I believe we could do are signed reverse tree or manual configuration. Others wont scale or work. Draft is weak on security.
(Savola) I don't buy argument anycast can't be secured.
(Kurtis) As a user I don't know if network is secure or not (i.e. is anycast address configured locally or leaked from somewhere else - no way to verify).
(Savola) Could also spoof DNS!
(Miakawa) I agree with Pekka. From ISP point of view we donít care. Need username or password off client anyway.
(Savola) TC and TEP discovery could be deployed without username or passwd and just use IPv4 access authentication.
(Kurtis) ISP may not care less, but me as a user, I do. No idea who is receiving anycast traffic.
(Williams) With millions of users we need to load balance tunnel servers, can't statically allocate?
(Durand) Layer 4 load balancer?
(Narten) Dynamic discovery can be good, but is it a strong requirement? Or is it 'needed' because it's nice to have.

Wrap up
------------
(Durand) Time to wrap up.

[Question]
(Durand) How many people interested in TC work for 6 in 4 or 4 in 6 only?
- Lots, maybe 50%
(Durand) For any kind of tunnels?
- Few, maybe 10

(Meyer) Would be to everyone's benefit to find balance of IPv6 need and generic solution for other uses.
(Kurtis) We don't know enough yet. Getting a consolidated effort across WGs doing this would be useful.
(Ron Bonica) Suggest rule out any solution that can't be generalized to other domains.
(Savola) Need to analyze generic issue if we go wider, else lose IPv6 deadlines
(Hinden) Have a zillion tunnel protocols and I don't see advantage of new generic one. I vote for limited scope.
(Durand) (hat off) example of the schizophrenia of IETF - requirements analysis vs desire to be generic... ball going back and forth. Chances of success higher if we stay focused on IPv6.
(Townsley) Naive to think we'd create something to kill other protocols.
(Narten) Brokers are being shipped - why is that not good enough?

[Question]
(Narten) Go with TSP as is?
- about 10 people
(Durand) Is TSP good enough to get by on?
- about 10/20 people
(Durand) Need something more?
- less than 10 people
(Narten) Which ISPs need to solve this problem?
- 4 people

(Parent) TSP is just a draft - need expert review
(Thaler) Maybe L2TP is enough? TSP doesn't solve TEP discovery.

[Question]
(Durand) Who wants TEP discovery solved?
- 12 yes
(Durand) And not?
- none

(Miakawa) Need implementations. Only Hexago client is GPL.
(Savola) need to pick the TC protocol before pick TEP discovery
(Townsley) Why not separate?
(Savola) If some using L2TP, TSP, then can't assume same service elements in place, need to make it interoperable.

Meeting closed at 17.50pm.



Slides

TC ďTunnel ConfigurationĒ
Goals for Tunneling Configuration
Existing protocol analysis
L2TP or not L2TP?
Solution space analysis
Tunnel Setup Protocol (TSP)
Simple Tunnel Set-up Protocol (STEP)
Tunnel End-point Discovery