Subject: I-D: Simple Configured Tunnel Setup Procedure

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Nov 2003 04:16:04 +0200 (EET)

Hi,

Based on the "simplified ISATAP" discussions and prior to that, my
desire to show that setting up configured tunnels in the 3GPP scenario
can be pretty simple, I banged the keyboard a bit and produced a
"proof-of-concept" draft:

     A Simple IPv6-in-IPv4 Configured Tunnel Set-Up Procedure

Abstract

   This memo describes a set of operational procedures and one
   implementation mechanism to provide a very simple and straightforward
   way to easily manage IPv6-over-IPv4 configured tunnels between an ISP
   and a customer.  The configured tunnels work even if the IPv4
   addresses change dynamically, or are private addresses; the procedure
   provides at least a /64 prefix per customer and requires no
   administrative set-up.  Support for NAT Traversal is currently out of
   scope.

I just sent it to the I-D repository, so in the meantime, it's 
available (less than 10 pages of content) at:

http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-setup-00.txt

Comments, etc. are welcome, of course.

(note, section 5.5.1 should have been 5.6 but no matter..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Nov 2003 10:38:28 +0200 (EET)

Hi,

Thanks for the comments. (Btw, you might want to resubscribe with the 
address you use because the mails bounce to the list admin.)

On Thu, 20 Nov 2003, Marc Blanchet wrote:
> my reading is that:
> - good idea.
> - if you go more into the details which makes a complete solution, you will
> end up redoing either tunnel broker or tunnel broker with TSP.
> - TSP automates the creation of tunnels with no complexity or overhead. and
> it manages the delegation of prefixes, the mobility of the v4 side (i.e.
> change of v4 address), can be part of a boot sequence of a node or router,
> etc... 
> - basically, you need a signaling protocol of some sort to help the two
> parties involved to setup the tunnel (and the various additional needed
> info, such as prefix allocation, ...)

I do not believe there is a need for signaling protocol at all, and I 
think the memo tries to proof-of-concept this.

You can manage the change of v4 address without a protocol; there are
already protocols for prefix delegation and they can be reused, etc.
(Obviously, if there is a need for a simpler prefix delegation
mechanism than DHCPv6, that's a separate issue on its own.)

I considered TSP before starting to write this, but I could not 
justify the signaling protocol overhead and complexity to myself, as 
there clearly didn't seem to be a need for one.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Nov 2003 22:43:23 -0500

my reading is that:
- good idea.

Marc.

> (note, section 5.5.1 should have been 5.6 but no matter..)

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Nov 2003 13:03:10 +0200 (EET)

Hi again,

After sleeping on the idea, I extended it a bit to include a 
limited form of NAT traversal, and beefed it up otherwise as well 
(e.g., by including an "out of scope for this draft" subsection).

Available at:

http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-setup-01.txt

Comments, etc. are of course still welcome :-)

Thanks to Suresh for a nice name and the acronym! :-)

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Nov 2003 16:29:24 +0000

> Comments, etc. are of course still welcome :-)

I do like the idea (but)... if the 'S' in STEP means simple to deploy
then couldn't you achieve the same by just using L2TP? the user runs
the LAC the ISP the LNS. IPv6/PPP/L2TP/UDP tunnelling between
them. the ISP would typically have the required infrastructure
already. authentication is defined and it should do NAT traversal.

/ot

---

From: Gert Doering <[email-masked]>
Date: Fri, 21 Nov 2003 19:32:19 +0100

Hi,

> already. authentication is defined and it should do NAT traversal.

Been there, done that, works :-)

The drawback is that it's only "simple" if you have an existing L2TP
infrastructure (that already can do IPv6).

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  57386  (57785)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 21 Nov 2003 20:23:47 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> infrastructure (that already can do IPv6).

tinc / OpenVPN works indeed.

I've implemented the first one in the SixXS framework and am currently
running a beta for it. Tinc does UDP and TCP using RSA keys etc.
Keys are 'uploaded' from the client to the SixXS configuration service
and then the noc box syncs the POP. Using the "heartbeat" client it
automatically works currently on both unices and Windows platforms.
It is still in beta because we like to provide a quality service
and there where still some minor details to be worked out.
Now the hardest part is getting a NIC handle to signup to SixXS :)

Also see http://www.sixxs.net/tools/configservice/
And http://www.sixxs.net/tools/heartbeat/

The 'heartbeat protocol' btw allows for true dynamic tunnels.
The client sends a md5 signed heartbeat to the POP every 60 seconds
or when the client notices an IP change, Windows has nice events
for this and unices can sigHUP the client causing an instant update.
which then adjusts it's proto-41 tunnel to the specified endpoint.
Yes, these are authenticated+configured tunnels.

Drafts for the configservice still have to be typed but it should
be clear how it works from the above url, a draft for the heartbeat
protocol is included in the unix tarball.

Sources available at http://www.sixxs.net/archive/sixxs/heartbeat/
Windows sources will be released soon but we'll have to clean
those up first for public release.

The rest of the SixXS system is also open and free btw but currently
not available for public download.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Nov 2003 22:18:23 +0200 (EET)

> infrastructure (that already can do IPv6).

I haven't really looked into L2TP myself, but I have a similar
impression than Gert -- L2TP -based system would be simple if all the
parties were already using L2TP.  

The simplicity is just borne by a different set of folks.  The current
STEP proposal (except for UDP encapsulation which is pretty trivial)  
has zero code changes and zero new software needed at the client side,
and very little to do at the ISP side. The ISP does have to hook the
system up to its lease/RADIUS/etc. databases somehow and/or implement
a small piece of code at the router that creates a tunnel dynamically
from a received packet.  So most of the work is done using unspecified
management methods.  For ISPs knowing what to do this should be
straightforward -- for those that don't, there might have to be some
additional ways to make it easier..

However, I would not want to discount L2TP as a solution.  Could
someone describe the infrastructure required a bit -- both at the
user, router and the other parts?

---

From: Gert Doering <[email-masked]>
Date: Fri, 21 Nov 2003 23:28:58 +0100

Hi,

> user, router and the other parts?

OK, I'll give it a try.

The formal specs can be found in rfc2661, so I'll try to be very brief 
here.

The pieces that form L2TP are:

 - UDP packets (port 1701)
 - PPP frames packed into those
 - plus some control stuff to glue the bits together (session mgmt)

So what really happens "down there" is that you run a normal PPP session
with all possible protocol-CPs (IPCP, IPV6CP, IPXCP, ...) inside a IPv4
UDP data stream.  The infrastructure in between, including NATs, just 
needs to know how to handle UDP (so it should be possible to run multiple
L2TP sessions from behind the same NAT, but I haven't tested that one 
yet).

On the client side, you (obviously) need a L2TP implementation.  On Linux,
the l2tp engine uses the stock system pppd for the PPP option and protocol
negotiation.  So as soon as you have a kernel that speaks IPv6 and a 
pppd that can do IPV6CP and setup IPV6 on the link, you're done.

Most client operating systems these days come with a L2TP implementation,
and adding IPv6 to the underlying PPP implementation should be something
the vendors are doing anyway (to support direct PPP via POTS/ISDN, or
PPPoE, etc., with IPv6).

On the server side, there is an implementation of L2TP for Linux (the
same implementation that also does the client side).  Allegedly it does
scale "well", but I have no idea how well.

A "standard" ISP would run the L2TP on his access servers that are
needed anyway to do end-customer dynamic DSL access (client side PPPoE 
that ends up in L2TP packets).  That access server would then do PPP
authentication versus some sort of AAA server, e.g. RADIUS, and the
Radius server sends down static IPv6 prefixes, or "allocate something
from the IPv6 pool <xyz>".  For anonymous/unregistered access, you'd need 
to do some sort of "everybody uses the same account" and make sure via
radius configuration that they get different addresses each.

For the router vendor, what needs to be done to get this working is 
(roughly, assuming basic IPv6 functionality is there):

  - add IPv6 functionality to PPP
  - implement some sort of RADIUS configuration management to get
    IPv6 attributes
  - implement IPv6 address pools for dynamic client assignments

all of which is needed for "PPP over ISDN/POTS with IPv6" anyway...

Conclusion: if, as an ISP (or a vendor of ISP hardware) you want to
support PPP over ISDN/POTS with IPv6 support, and at the same time you
want to support L2TP clients (DSL users), the required glue to get
IPv6 into L2TP should be very small.

The *overall* complexity of such a system is high, though.  The benefit
is only "most of it is there anyway".

Gert Doering
        -- NetMaster

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 24 Nov 2003 00:15:53 +0100

My feeling on this is that most of the ISPs will not accept off-band procedures, and TSP seems useful to avoid that.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "Marc Blanchet" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 21, 2003 9:38 AM
Subject: Re: I-D: Simple Configured Tunnel Setup Procedure

> there clearly didn't seem to be a need for one.

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 24 Nov 2003 09:40:16 +0100 (CET)

On Mon, 24 Nov 2003, JORDI PALET MARTINEZ wrote:

> My feeling on this is that most of the ISPs will not accept off-band
> procedures, and TSP seems useful to avoid that.

In my opinion if ISP wants to provide tunnel service they have to know in
advance that they will serve something - at least, in order to be able to
track the usage of service. If ISP is using RADIUS or Diameter
authentication for obtaining the customers' tunnel endpoint
addresses, they already had to have some form of agreement. It would be
very easy for the customer just ask IPv6 tunnel service via the
customer care center of ISP. Probably I would use this method to provide
IPv6 for DSL/dial-up or otherwise authenticated users.

Regards,

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

> > > my reading is that: - good idea. - if you go more into the details
> > > which makes a complete solution, you will end up redoing either
> > > tunnel broker or tunnel broker with TSP. - TSP automates the
> > > creation of tunnels with no complexity or overhead. and it manages
> > > the delegation of prefixes, the mobility of the v4 side (i.e. change
> > > of v4 address), can be part of a boot sequence of a node or router,
> > > etc...  - basically, you need a signaling protocol of some sort to
> > > help the two parties involved to setup the tunnel (and the various
> > > additional needed info, such as prefix allocation, ...)
> >

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Nov 2003 11:11:37 +0200 (EET)

> IPv6 for DSL/dial-up or otherwise authenticated users.

Right.. my feeling is, from the ISP point-of-view, that either they 
want to have a simple mechanism with little machinery, or they want to 
have a system that is also future-proof for the time they'll enable v6 
on the access link (e.g., a connection to the databases somehow, a 
system which requires only a small amount of changes, if any).

The one thing I am *not* aware of is, how many of the ISPs have this
L2TP + PPP stuff set up already.  AFAIK, L2TP is basically needed for
xDSL aggregation unless you do it with ATM (that's how many do it
around here, at least).

I could see why an ISP would not want certain "hackish" 
characteristics of a solution, like proposed in STEP in the "adhoc" 
mode.  I'm not even sure how many ISPs would be interested of the 
"adhoc" mode (i.e, no user registration for v6), but it seems that it 
seems desirable at least for certain types of 3GPP operators.