Subject: [v6tc] Re: Tunneling and Transition Drafts

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Apr 2005 02:30:53 +0200

Hi Fred, all,

First of all, I think is a very good question to know if the v6tc is really
dead, or what, unless I've missed something, there was not any message about
this. I was about to ask soon in v6tc list (copied now).

Then regarding the rest of your email, without entering into many details at
this point, basically agree with your view.

When I started looking into the tunneling/transition work (with several
documents such as TED auto-discovery and solution, auto-transition,
zero-tunneling-configuration, etc.), my main goal was precisely to be able
to pick up those gazillion existing mechanism and:

1) Try to automate the mechanism selection and configuration process as much
as possible (and probably this doesn't need a new protocol but some
guidelines about how to use existing things to do it). The idea is that this
could be done even w/o modifying the existing mechanisms. I think the work
here is almost done (but has not received for some of the documents, almost
any feedback from the WG, specially for proposed solutions).

2) Define a new mechanism, which actually takes advantage of existing ones
and a lot of deployment experience (including IPv6-dominant environments,
which I'm already deploying for some customers, so there is a real need
here). Clearly the deployment experience that we have now is not all what we
need, but is much more than what we had when we started working in the
existing mechanism (at least some of them). The point is probably to
consider two basic environments narrow-band and broad-band networks (for
example 3GPP or ISDN and xDSL/WLAN), but have a single mechanism, a kind of
one-fits-all (or very close to that), which can self-adapt, starting from
the "worst" situation (so it fits for 3GPP folks, with limited features, but
no new network requirements/devices), but can improve the features offered
in case there is a better link (example WLAN). For example I see the point
of a cellular phone with 3GPP and WLAN, moving from one network to another.
Why we need to have different mechanisms in that device, if instead we can
have one which can "self-adapt" (even using different encapsulation if
required, automatically).

For 2) We have a draft document (even a set of slides) which depict our idea
on this (our team worked the last 3-4 months on this already, in addition to
all the work done in 1) and v6tc documents). If this sounds a good idea, we
will be able to have an initial i-d probably in 10-15 days (may be earlier,
but need to recheck some other priorities).

The important thing that we have kept in mind always while working on 2) has
been also to avoid designing something completely new, but instead, looking
into all the existing mechanism to see which one seems to fit better and
modify it a bit to match the "one-fits-all". So, insisting a bit, the point
was here not to "mine is better" but "take the best and try to put it
together".

Our view not necessarily is perfect, of course, but we don't want to be 100%
as good as native IPv6, and of course, if we start working on this in the
WG, we really need a lot of input to be able to reach a consensus.

Obviously choice 1) somehow exist in some OSs, but could be improved and
will also support choice 2). We also need to understand that existing
implementations may decide not to go quickly or 2), so some parallel work
here is good and required.

So answering your final question, I will opt for the consensus, and actually
will like to continue our work on this (in the WG if possible), and I think
it can be done in a short time if the WG contributes a bit (just a bit more
than now !).

Despite that, I would not exclude that some of the mechanisms want to follow
their actual process and go for informational, in a parallel. At the end,
depending on timing, results of 2), market will take the decision, but at
least we will be able in the position, as IETF, to provide a good solution.

Regards,
Jordi

> De: Fred Baker <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 5 Apr 2005 16:34:52 -0700
> Para: "[email-masked]" <[email-masked]>
> CC: Lindqvist Erik Kurt <[email-masked]>, David Kessens
> <[email-masked]>
> Asunto: Tunneling and Transition Drafts
> 
> I need a consensus of the WG.
> 
> In what I am about to say, someone might possibly feel their toes
> stepped on. Apologies in advance - and get used to it. I have big feet,
> and I often put them in my mouth.
> 
> In taking over the working group, Kurt and I basically were presented
> with the following scenario:
>   - this group is for operational questions (not protocols)
>   - this group seeks to conform to RFC 1958 (we are not here to bless
> very lame solution that comes along)
>   - transition mechanisms are generally out of scope.
> 
> As I understand it, v6tc (which was intended to take over all the
> tunneling stuff, which is to say a large proposition of the transition
> stuff) is dead in the water. The expectation was that all the
> tunneling/transition stuff would move there, but the BOF was a
> non-event. There isn't likely to be a v6tc WG. (Dear AD: if you
> disagree, this would be a good time to say so).
> 
> That said, there are roughly 80 gazillion different transition
> solutions out there, including at least silkroad, teredo, DSTM, secure
> tunnels, etc. To deploy IPv6 in a network that is in parts IPv4-only,
> in parts IPv6-only, in parts dual, and in parts what Jim Bound calls
> "IPv6-dominant" (which is not a bad term, btw), which I think I would
> say is ipv6-only in its service but might use IPv4 internally, it seems
> to me that one needs six things said or defined:
> 
>   - "please turn IPv6 on by default in your end systems"
> 
>   - "please turn IPv6 on in your enterprise network"
> 
>   - "please turn IPv6 on in your access/ISP network"
> 
>   - how to tunnel IPv6 through an IPv4-only/dominant network between
>     IPv6-only/dominant hosts or networks
> 
>     key attribute: static or dynamic IPv6/IPv4 tunnels between tunnel
>     endpoints, and appropriate routing through the IPv4 domain to
>     determine what the appropriate tunnel endpoint router would be.
>     Could be done with a DNS name not unlike a reverse lookup for
>     the IPv6 address but delivering an IPv4 "A" record. Could also
>     be done through simple routing if the tunnels sty up or use a
>     concept like RFC 1793.
> 
>   - how to tunnel IPv4 through an IPv6-only/dominant network between
>     IPv4-only/dominant hosts or networks
> 
>     key attribute: static or dynamic IPv4/IPv6 tunnels between tunnel
>     endpoints, and appropriate routing through the IPv4 domain to
>     determine what the appropriate tunnel endpoint router would be.
>     Could be done with a DNS name not unlike a reverse lookup for
>     the IPv4 address but delivering an IPv6 "AAAA" record. Could
>     also be done through simple routing if the tunnels sty up or use
>     a concept like RFC 1793.
> 
>   - how to translate IPv6->IPv4 and IPv6-IPv4 between an
> IPv6-only/dominant
>     and an IPv4-only/dominant domain
> 
>     key attribute: translation system captures DNS lookups and
>     re-advertises its own address in some way, so that IPv4 hosts
>     seeking IPv6 peers connect to it and it translates, and IPv6
>     hosts connect to it and it translates.
> 
> Note that I didn't say what kind of tunnel. GRE, MPLS, IP/IP, IPSEC,
> L2TP, who knows what else - they all must be addressed.
> 
> I have a fairly large number of ways to do those - silkroad, teredo,
> dstm, and a list of others. Each one, when it looks at the others, says
> "but mine is better" or "my customers want to deploy mine now".
> 
> I have no idea how this transition is going to happen if we can't sound
> a clear signal on how to do it.
> 
> Which brings me to my question. I am being asked by various proponents
> of various things what the working group wants to do with their
> approach. I need to know what the game plan for this working group is:
> let a thousand flowers bloom (they can all ask for informational status
> from the RFC Editor and the probability that the transition will happen
> in an orderly fashion rapidly approaches zero), or I need a consensus
> statement from the working group that every single approach on the
> table will be set aside and the working group will actively work on
> providing a single solution that meets all those needs that the IETF
> can look at and say "yes, that will accomplish an orderly transition in
> a timely fashion and *I*will*support*that*in*favor*of*all*others".
> 
> Opinions?
> 

************************************
Barcelona 2005 Global IPv6 Summit
Registration open. Information available 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.

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 5 Apr 2005 17:49:00 -0700

On Apr 5, 2005, at 5:30 PM, JORDI PALET MARTINEZ wrote:

> their actual process and go for informational

I obviously have no problem with informational notes. Teredo is going 
that route, Silkroad is going through the Chinese Standards Agency, 
DSTM appears to be opting for "just do it", and so on.

I'm trying to figure out what, if anything, the IETF is going to do.

---

From: Jerome Durand <[email-masked]>
Date: Wed, 06 Apr 2005 09:55:36 +0200

>>Opinions?

I am not sure I share the view that the BOF was a non-event. There was 
an agreement from a *large majority* of people in the room to say that 
the WG should take TSP that fulfills all requirements presented, and 
make it a standard. Now I guess it's time to move on in that direction.

Jerome

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Apr 2005 11:01:37 +0300 (EEST)

On Wed, 6 Apr 2005, Jerome Durand wrote:
>>> Opinions?
>
> I am not sure I share the view that the BOF was a non-event. There was an 
> agreement from a *large majority* of people in the room to say that the WG 
> should take TSP that fulfills all requirements presented, and make it a 
> standard. Now I guess it's time to move on in that direction.

It will be interesting to see BoF minutes, because I didn't see large 
majority.  For what it's worth, my recollection was:

I saw less than about 5-10 people supporting TSP.
I saw less than about 5-10 people supporting doing something new.
I saw less than about 5-10 people being comfortable with existing
   mechanisms (like L2TP).

Bottom line is that if we don't need to care about the RTT and 
overhead concerns at all, I can't clearly see real benefits for TSP 
instead of just using L2TP.

-- 
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: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Wed, 06 Apr 2005 12:29:37 +0300

Fred,

> DSTM appears to be opting for "just do it", and so on.

Just a simple correction: Teredo is going to Proposed as individual
submission. ISATAP on the other hand is going to Informational. 

> I'm trying to figure out what, if anything, the IETF is going to do.

Tell me as well, if you find out... ;)

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Jerome Durand <[email-masked]>
Date: Wed, 06 Apr 2005 16:01:51 +0200

Well, on my notes I have the question Alain asked at the end that was: 
"Who would be happy if TC just take TSP and make it an RFC?" You don't 
mention this question that had a large majority of yes. Then I would be 
happy to get the "official" minutes as well :)

Jerome

Pekka Savola wrote:

> Bottom line is that if we don't need to care about the RTT and overhead 
> concerns at all, I can't clearly see real benefits for TSP instead of 
> just using L2TP.
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 07 Apr 2005 14:54:40 -0400

Note: v6ops bcc'ed, followups in v6tc please.

> this. I was about to ask soon in v6tc list (copied now).

To be honest, I'm not entirely sure myself. And this is after a rather
lot of hallway conversation in Minneapolis.

Truth in advertising: I've always been a bit skeptical of this work,
and probably continue to be, with the main reason being that I do not
see a clear/easy/obvious solution here and I worried alot (while I
still wore an AD hat) about starting a WG that wouldn't be able to
actually come to closure and complete useful work. It is not enough to
want a solution -- a solution must also be achievable. (This comment
applies mostly the "tunnel endpoint discovery problem".)

I do detect that there are folk that want to form a WG and that there
are some that believe there is a problem here to be solved (that needs
solving), but so far (AFAIK) the problem hasn't been articulated
clearly and (still) strikes me as a bit of a moving target.

One (big!) example. There was lots of talk at the BOF and in the
presentation about the need for low latency, i.e., it was a
"requirement". And I hear "wireless" mentioned and "3G" at
approximately the same time. But, my understanding is that 3GPP has
already decided to go with ISATAP. So, they aren't a customer for this
work. But if that is the case, where is the real requirement for low
latency coming from?

Is my understanding correct in this regard?

Thomas

---

From: Jerome Durand <[email-masked]>
Date: Fri, 08 Apr 2005 09:55:54 +0200

> clearly and (still) strikes me as a bit of a moving target.

The problem that was explained is how an ISP gives easily connectivity 
to its customers, waiting for access networks/equipments/technologies to 
be upgraded. I think this is a good problem that needs to be solved 
(talking here as an ISP)

Now I guess what is important to get is that we need something quickly, 
or new equipments will come before we have adopted anything. One could 
argue we can wait 5 more years and don't bother much. This is not what 
we did and we (as other ISPs) started to buy some commercial tools 
(tunnel brokers) fulfilling all our requirements (low latency is not a 
requirement for us). Tunnel discovery is not a problem for an ISP that 
doesn't care much  giving a TEP IP address to its customers (or 
preconfiguring the tunnel broker client). Then I can't understand that 
this could be a stopper for not making the group.

The point here is that as an ISP, I'd prefer to work with a standard, 
manageable and available solution. Is one already available? If yes that 
is worth documenting how to use/deploy it (in v6ops WG). If not, then we 
have to adopt a new standard (in v6tc as v6ops is not made for it).

Jerome

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 08 Apr 2005 10:41:54 +0200

> this could be a stopper for not making the group.

The only thing you need is a well known anycast IP address where your
clients can find the TSP server at. Currently you configure this using a
hostname which can found in DNS and giving your clients this preconfiged
tool. What you want is that the default configfile that comes with TSP,
the one defaultly installed by the various OS's already supporting it,
have the anycast IPv4 address in it. You just announce that IP to your
customers, maybe leaking it to other ISP's who are allowed to use your
TSP and done.

The same thing is what I would want to have for my TIC thing, currently
we simply 'hardcode' tic.sixxs.net, as TIC is only used by SixXS anyway,
this is not an issue, when others would like to use it though they would
need to provide an entry for the tic server in the config file, though,
like TSP they can also request that certain accounts are redirected to
another server which will handle the client.

Just in case people wonder why I did not go with TSP: it did not fulfill
the various requirements we had, like being able to use it to turn
tunnels on/off, move tunnels and a lot of other things, in a command
oriented way, thus without having to use/depend on xml. TSP for the rest
works fine and for instance AICCU can easily be converted to make use of
it, though we will need to devise a couple of templates for things like
AYIYA and heartbeat in those cases then though.

Btw, with "low latency", people still mean 'the minimum amount of
packets required to do the configuration phase' or do they mean the
actual latency towards the endpoint of the tunnel, that is the latency
caused when the packet goes over the network? In the latter case, as
these tunnel endpoints are mostly inside the ISP's network, that is
maybe 2ms more than the path would be in native IPv6. At least that is
the case with my home dsl line.

As for "Setup latency", setups maybe happen only once an hour, does a
delay for maybe 10ms really annoy you then when every packet needs 30ms
to reach the other site afterwards anyway?

Finally a call up for 'what is the problem':

Could the people who 'require' an alternate solution than TSP, specify
what the problems are with it and possibly list what their proposed
solution* would be?

Greets,
 Jeroen

* = simply saying 'can't use that' without having an argument on how to
possibly solve it is imho quite useless ;)

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Apr 2005 13:12:25 +0300 (EEST)

On Fri, 8 Apr 2005, Jerome Durand wrote:
> manageable and available solution. Is one already available? If yes that is 
> worth documenting how to use/deploy it (in v6ops WG). If not, then we have to 
> adopt a new standard (in v6tc as v6ops is not made for it).

L2TP ?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 08 Apr 2005 12:49:14 +0200

L2TP will be a good solution if it works in any situation, but more and
more, unfortunately, I find hotspots where I can use 6in4, Teredo, other,
but my L2TP VPN doesn't work !

That's why I think we need a protocol that can try several encapsulations in
case the best one doesn't work.

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 8 Apr 2005 13:12:25 +0300 (EEST)
> Para: Jerome Durand <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Asunto: Re: [v6tc] Re: Tunneling and Transition Drafts
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 08 Apr 2005 07:04:43 -0400

> clients can find the TSP server at.

I keep hearing this like its a slam-dunk obvious solution. It is not
(at least not if I listen to what some other people say). The use of
anycast addresses for service discovery is controversial. Do the words
"dns discovery" bring to mind anything about the obviousness and
likeliness of having quick success of choosing this solution?
Everytime you (or anyone else - not picking on you in particular)
brings up this approach are you also oblivious to other folk that
don't think this is a reasonable way to go?

> tunnels on/off, move tunnels and a lot of other things,

What does "move tunnels" mean?

Also, it would be useful if you would specify the "lot of other
things", so we could understand better what the real requirements are.

> in a command oriented way, thus without having to use/depend on xml.

It's not immediately obvious to me what "without having to use/depend
on xml" has to do with "command oriented way". How commands are
implemented underneath doesn't have to be visible to the user
interface.

> what the problems are with it and possibly list what their proposed

Actually, I prefer just the "what is the problem part". We have enough
of an issue where the problem is "handwave handwave", but "my pet
solution" solves the problem perfectly.

Thomas

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 08 Apr 2005 13:15:32 +0200

> > adopt a new standard (in v6tc as v6ops is not made for it).

Client for all OS's that support it doing IPv6 ?

Greets,
 Jeroen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 08 Apr 2005 13:22:02 +0200

Hi Jerome,

I think I basically agree with your email, but disagree regarding the TEP
discovery.

The reason for that is that within an ISP is easy, but if you're a user
moving (traveling), you need to be able to discover it, not ask for a manual
configuration. Example, I don't want to manually change my configuration at
every hotel where a different ISP provides either via wired or wireless
access.

Regards,
Jordi

> De: Jerome Durand <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 08 Apr 2005 09:55:54 +0200
> Para: Thomas Narten <[email-masked]>
> CC: <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Apr 2005 14:21:14 +0300 (EEST)

> Client for all OS's that support it doing IPv6 ?

AFAIK, as L2TP layers on top of PPP, you only need PPP to support 
IPv6, right ?

Anyway, anything that's in the real of implementations has issues in 
one way or another.

As I've said in the past, I see no point in standardizing TSP as it is 
because L2TP provides the same functionality.  One the other hand, if 
we had requirements which cannot be satisfied (in a backward 
compatible manner) by either L2TP or TSP, it makes sense to design 
something new.

One such requirement could be low latency and overhead; at the moment, 
however, it is not obvious whether the different wireless communities 
(including what Mobile IPv6 and NEMO WGs are currently discussing wrt 
NAT traversal -- _yet another_ tunneling mechanism, this time 
(probably) specific to Mobile IP!) were sufficiently aware of this 
effort to bring forth theirs requirements.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 08 Apr 2005 13:40:00 +0200

I don't think the L2TP client is a problem, even if they aren't available
now, is equivalent to the availability of a new protocol.

My point regarding the lack of support of L2TP in more and more hotels and
hot spots, and that's why I think the encapsulation should be flexible.

I've also no idea about how much the 3G folks will like to implement L2TP.

Regards,
Jordi

> De: Jeroen Massar <[email-masked]>
> Organización: Unfix
> Fecha: Fri, 08 Apr 2005 13:15:32 +0200
> Para: Pekka Savola <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, Jerome Durand <[email-masked]>

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 08 Apr 2005 13:46:52 +0200

> AFAIK, as L2TP layers on top of PPP, you only need PPP to support 

Correct. Now guess what one the biggest OS, that is deployed at
consumers, does not support :)

Ah, indeed Windows XP, even SP2 does not support IPv6 PPP (at least last time I checked).
Have fun implementing that and then passing it to your clients.

> Anyway, anything that's in the real of implementations has issues in 

Then I suggest that, like I asked MS when they implement the above, when
those issues get fixed. That is a vendor problem, not a protocol problem I hope.

> because L2TP provides the same functionality.

Since when does L2TP support anonymous tunnels?
Since when does proto-115 cross NAT's ?

> One the other hand, if 

Why design something new if people who are happy with L2TP can use that,
while people who are happy with TSP can use that.

Both suffer one thing, as I mentioned previously: "discovery".

> effort to bring forth theirs requirements.

There is even NAT traversal for HIP and a lot of other protocols being done.
The pain it brought was not to be foreseen ;)

> but my L2TP VPN doesn't work !

L2TP typically does not work for the same reason why proto-41 does not
work: NAT boxes don't forward proto-41 nor proto-115.

Also LT2P has the limitation that it requires authenticated use, which
was not acceptable according to some people on this and the v6ops list.

One conclusion I can make from all these discussions is though that:
- There are a number of mechanisms
- These mechanisms all have their distinct advantages

Or better said: let the market decide on what to use.

The IETF is afaik supposed to make standards, of which there are many,
many of which most people won't use, because they don't fit the thing
they want to do. In this specific problem there are a lot of ways to do
something and there are a lot of problems which simply can't be solved
with one problem especially because of the broad set of requirements.

My take on this thus becomes:
- In general tunneling IPv6 over UDP works *everywhere*
  (unless there is an administrative filter prohibiting it
   in which case we should not try to override it either)
- TSP is deployed and works (*)

For that reason I would suggest that combination. People with other
requirements can pick their own.

> case the best one doesn't work.

And then have the thing to try to get around a limitation which might
quite well be an administrative barrier?

I thought there where people concerned with 'setup latency' ;)

Greets,
 Jeroen

* = also with the few shortcomings I noted already a couple of times.

---

From: Vladimir Kotal <[email-masked]>
Date: Fri, 8 Apr 2005 13:58:11 +0200

> Have fun implementing that and then passing it to your clients.

And according to the answer I received from Leigh Huang from Microsoft 
(Program Manager - IPv6, Windows Networking and Device Technologies)
cca year ago, IPV6CP will be supported only in Longhorn. They do not even
consider putting in to XP. This means no native IPv6 dial-up for most 
clients at least for one year from now.

Regards,

v.

---

From: Jerome Durand <[email-masked]>
Date: Fri, 08 Apr 2005 14:04:00 +0200

> I think I basically agree with your email, but disagree regarding the TEP

What I meant here is that it can be a good thing as you said, but it is 
not something absolutely required for an ISP to have a working solution.
So when discussing forming the WG or not, I think TEP discovery should 
not be taken as a reason for not creating TC as we can anyway achieve 
good results without it.

Hope this clarifies :)

Jerome

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 08 Apr 2005 14:06:21 +0200

[hmmm I should aggregate replies better :) ]

> I think I basically agree with your email, but disagree regarding the TEP

And how are you going to discover a "TEP" in a place like a hotel which
is already limiting you completely?

I guess what you want is a globally available VPN-alike dialin network
so that you get the protocols you want as for the moment when you go to
a hotel in, say, South America, where are you going to tunnel to?

Heartbeat-alike tunnels solve this partially. Turn on the client, let it
beat, and your tunnel works. The latency will not be perfect, but in
those locations you won't have that a low latency anyway.

I actually wonder also what the state of 6to4 connectivity is in a place
like, say the US, seeing that 6to4 is already not good quality in most
places around Europe, though it has significantly improved over the last
couple of years.

Nevertheless the case you mention is a really specific one and I think
that this really can't be covered easily, just like requesting multicast
everywhere you go, it is not there yet.

Greets,
 Jeroen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 08 Apr 2005 14:32:22 +0200

I got the same answer. But company roadmaps could change, I'm not sure about
the actual roadmap on this.

Regards,
Jordi

> De: Vladimir Kotal <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 8 Apr 2005 13:58:11 +0200
> Para: Jeroen Massar <[email-masked]>
> CC: Pekka Savola <[email-masked]>, <[email-masked]>,
> "[email-masked]" <[email-masked]>
>>>>>> is

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 08 Apr 2005 14:53:43 +0200

> the actual roadmap on this.

Longhorn will be out in 2007? 2008? Even then, it would require people
to install patches, and hearing that many have not even bothered to
install SP2 I don't see many people installing such an upgrade either.
I do hope it changes, but still L2TP will not cross most NAT's.
If it did why do people think MS made Teredo in the first place?
(which crosses most NAT's and is automatically configured, except for a
bit of latency, this btw also would benefit from an anycast prefix to
get the closest one)

On Fri, 2005-04-08 at 07:04 -0400, Thomas Narten wrote:
> (at least not if I listen to what some other people say).

I've never seen a valid argument against it. Otherwise if people do have
them, it might very well be that I missed out on a lot of them, please
state them. If anycast is so 'flawed' why do we then use it for the Root
DNS servers and for many other high-availability services? :)

Also, these anycast prefixes will be inside an ISP's network most of the
time, thus there will not be much if any flapping and or changes in the
actual endpoint.

Actually the only thing I ever heared 'against' it was that it was
'difficult to configure'. Well if you are not able to configure routing
then you should not be in the ISP or networking business in the first
place and one should start reading a number of books, but that is my
take on that.

>  The use of

I am one of the (few?) persons who still does not understand why there
is no well defined anycast address which provides a (caching) recursive
nameserver.

What is more easy than having in your /etc/resolv.conf or similar file:
nameserver 192.0.2.53
nameserver 2001:db8::53

or only one of the two for that matter. The route for the above being
announced into the IGP by your own ISP and thus actually pointing to
their own nameserver or provided globally by $random ISP who wants to
help out the ISP's who apparently don't know how that thing called
routing works.

Draft for the above with a nice addon for .service domain is still
coming up ;)

> What does "move tunnels" mean?

That when the IPv4 endpoint of a host changes, eg because of DHCP
changes, moving to a different wireless subnet etc. One has to configure
the endpoint on the Tunnel Server so that that one knows where to send
the packets, also see:
http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-heartbeat-00.txt

> things", so we could understand better what the real requirements are.

Private Key Distribution for eg tinc tunnels, Cookie based
authentication, reconfiguration of tunnels, eg changing location of
tunnels and a lot of other items we found useful and are most likely
totally not needed for a generic protocol like TSP and could easily be
covered by other separate protocols like LDAP.

This does thus still not mean that TSP is good for everybody else on
this planet :)

> implemented underneath doesn't have to be visible to the user

When typing on a Cisco IOS console you type commands like:
ip show route 2001:db8::/48

you do not have to type:
<command>
 <section "ip">
   <route>2001:db8::/48</route>
 </section>
</command>

or some other XML syntax. I am not a computer, I am very happily totally
human fortunately (au contraire what some might think ;) but that is
their opinion which they can have). XML is (mostly) meant for
communicating between computers and having a generic way of specifying
things.

> solution" solves the problem perfectly.

The problem for ISP's is, as far as I know:

- You have a network that does IPv4
- This network provides access to clients, who get one, or more, IPv4
  address(es) per DHCP/static/PPP etc
- Due to equipment problems the routers and other access equipment
  can't be upgraded easily to support IPv6. (Cost etc)

proto-41 could solve this already, but there is NAT in this world,
because the ISP's gave only 1 IP in the first place and quite a number
of NAT's can't be reconfigured/upgraded, which would require the user to
it. These NAT's usually also block L2TP and PPTP btw, though the latter
is less common. Next to that some networks don't allow proto-41, or
worse networks that are completely behind a NAT*.

My proposed solution for this problem:
 - Use TSP to get the configuration
 - Use AYIYA/v6UDP to cross the NAT

And this works magically good, at least I have had a lot of happy
comments from users who are using this now, though with a TIC/AYIYA
combination. But I am not going to push TIC in anyway while TSP supports
it too if we just make a template for an AYIYA tunnel, which would be an
easy step to do.

Greets,
 Jeroen

* = One of the many fine examples, oh and they have 10k or was it 100k
users behind it? :)
inetnum:      81.208.74.176 - 81.208.74.191
netname:      FASTWEB-RESIDENTIAL-07
descr:        Infrastructure for Fastweb's main location
descr:        NAT IP addresses for residential customer, public subnet

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 08 Apr 2005 15:42:18 +0200

Sooner and better than that:

Microsoft VP Describes IPv6 Product Roadmap
http://www.new.eu.ipv6tf.org/news/newsroom.php?id=1058

Regards,
Jordi

> Responder a: <[email-masked]>
> Fecha: Fri, 08 Apr 2005 14:53:43 +0200
> Para: <[email-masked]>, Thomas Narten <[email-masked]>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 08 Apr 2005 10:06:45 -0400

> I do hope it changes, but still L2TP will not cross most NAT's.

Jumping in with my old l2tpext hat on just to correct this inaccuracy: L2TP 
operates over UDP 1701. Port 115 is for RFC3931 L2TPv3 "IP" mode that was 
created for people who don't like the 8 bytes of UDP, however, we kept a UDP 
mode in the L2TPv3 spec as well - largely for NAT traversal. The PPP/L2TP that 
is widely deployed today and for which the GPL source is available certainly 
operates over UDP 1701.

Windows XP not supporting IPv6 in PPP *is* a problem - not just for v6tc though.

Back to your lively debate....

- Mark

> ------------------------------------------------------------------------
>

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 08 Apr 2005 18:11:22 +0200

> operates over UDP 1701. Port 115 is for RFC3931 L2TPv3 "IP" mode that was

Thanks for the correction & clarification. I'll take that you meant
"Proto 115" instead of the port. When used in this mode then it will,
just like the others cross a NAT with ease, unless firewalled of course.
Because of the Keepalive protocol it will also stay 'up'. When the
source address changes (dhcp change, change of wireless net) one will
also automatically reconnect, might have a small delay but should work.

We still miss an actual implementation on the more widely deployed
platforms and as those are in the big target area this will be something
many people will want. I am actually tempted all of a sudden to just
implement it, but unfortunately not enough time for that.

Greets,
 Jeroen

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 08 Apr 2005 12:42:12 -0400

Jeroen Massar wrote:

> "Proto 115" instead of the port.

Yes, IP "Protocol" 115. Typo.

 > When used in this mode then it will,

Or be tempted to implement IPv6 for PPP on Windows XP and sell it (or offer it 
as shareware) for ~$9.95 for a while... Until Longhorn comes out, you might make 
a little money on the side... (whether L2TP is used for v6tc or not).

In the end, a lot of implementations may actually be CPEs rather than hosts, in 
which case having the linux implementation helps.

- Mark

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 Apr 2005 19:32:11 +0200

In your previous mail you wrote:

   L2TP ?
   
=> L2TP works in very bad networks (private addressing, paranoid filtering,
etc) so IMHO we should keep it in our toolkit. It is a standard,
there are many implementations (I use it over every Linuxes and BSDs)
and it is ISP friendly (ISPs are still fond of PPP :-).

Regards

[email-masked]

PS: it seems a cleaned TSP and L2TP are enough for v6tc stuff.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 Apr 2005 19:42:00 +0200

=> Can you explain what is the problem? Filtering of some UDP ports?
Something else?

=> ADSL folks have already L2TP: only new 3G folks could have a problem
with L2TP.

Regards

PS: the real problem of L2TP is its overhead, but as I said at the IETF,
this makes it a good candidate for clever header compression...

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 Apr 2005 20:06:35 +0200

=> usually L2TP is run over UDP, not protocol 115.

   Also L2TP has the limitation that it requires authenticated use, which

=> I don't understand your concern: is it about the optional shared secret
to protect L2TP control or PPP authentication?

   
=> I agree but not for the same reasons...

=> there are two very different instances of this: Teredo and L2TP.
I don't believe we need a third one.

=> yeah! TSP is great in the (common) cases you can use it. Perhaps too
great so there are not enough TSP services where I am...

Regards

PS: I don't believe we have to spend a lot of time on marginal improvements:
the ultimate target should to get *native* IPv6!

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 08 Apr 2005 20:24:02 +0200

On Fri, 2005-04-08 at 12:42 -0400, W. Mark Townsley wrote: 

<SNIP>

> a little money on the side... (whether L2TP is used for v6tc or not).

Asking money for a transition tool is silly. Helping people get it for free
and with ease is my target. There is, at the moment, IMHO, no big point in
demanding money for such services. And especially with the 'free copying'
going on in this world it doesn't make sense anyway unless you are able to
afford time and money on reclaiming it, which simply is not possible anyway.
For these cases, just let people donate if they need to. Anyway this is the IETF ;)

Nevertheless I'll put it somewhere on that big list, lets see how many parties
get canceled this week...

> which case having the linux implementation helps.

Linux supports it, but not too many people want to actually touch their gear.
and for most of those people Linux is still scary.

> PS: it seems a cleaned TSP and L2TP are enough for v6tc stuff.

With, IMHO an addition of a discovery protocol.

Do note btw that TSP is a configuration protocol, it does not cover the
NAT-crossing case.

> => usually L2TP is run over UDP, not protocol 115.

As was indeed pointed out already ;)

> to protect L2TP control or PPP authentication?

I actually like authentication, as that is a good thing, because it
allows also to track abuse easier. But I recall that there where a
number of scenarios where people demanded 'anonymous tunneling'.

> I don't believe we need a third one.

Teredo could be used for the case where the ISP doesn't supply it, L2TP
for the case where they do.

> great so there are not enough TSP services where I am...

Off-list/topic/subject:

Afaik you are in France. Should I enable the TSP server for the
SixXS system? Then you have near-European wide coverage...
If someone wants to push me over the convince border, yell privately.

Next to that, you are in an french educational network, thus I guess
that Jerome Durand / Renater can supply you with such connectivity.

Also makes the claim that "TSP" is not deployed go away.

> the ultimate target should to get *native* IPv6!

My idea ;) But unfortunately not always possible.

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Fri, 8 Apr 2005 11:49:23 -0700

BOF chair hat still on, I'm going to try to summarize the discussion so 
far.

- Time to market is critical.
- TSP & L2TP are the two natural candidates
- The end point discovery is a difficult but orthogonal issue that 
should not
    clout the discussion on tunnel configuration. I'm not going to 
address
    it in this email.

Back to TSP & L2TP.

	- L2TP is standardized, but a document explaining how to use it
	  in the IPv6 transition phase might be needed.

	- 3 issues have been raised with L2TP:
		- large number of RTT. This is only on issue in low latency networks
		   such as 3G. If we are NOT looking for a combined solution for 
fixed/wireless 3G
		   this is a non issue, if we are, this is a show stopper.
		- Lack of a supported implementation of IPv6 over PPP on a very 
critical OS.
		  IMHO, this is issue for the company that makes this OS, not for the 
IETF...
		  ... on the other hand, time to market is critical.
		- Lack of a complete non authenticated mode.
		  This needs to be investigate further, as it is not absolutely clear 
to me
		   it can't be done.

	- Issues with TSP:
		- not been through community review (i.e. no RFC to point to)
		- re-opening TSP might sounds like duplicating L2TP

Now, here are the questions I would like this group to try to answer:

1) is a combined mechanism for fixed/wireless 3G network still 
important?

2) Is it the case that we have to define BOTH an L2TP based mechanism 
AND TSP
      with all the operational/implementation headaches of having to 
support 2 things
      in order to "let the market decide" or do people think we need one 
and only one
      mechanism?

Please focus your answers on those two questions.

	- Alain.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 08 Apr 2005 15:21:54 -0400

Jeroen Massar wrote:

> and with ease is my target. 

Much agreed, just putting the $ argument out there to point out that this is an 
area where there may be demand due to a hole in Microsoft's current IPv6 
offering (Again, v6tc aside - I'm really talking about the lack of IPv6 for PPP 
in general).

 > There is, at the moment, IMHO, no big point in

Hence the shareware reference. Again, the $ reference was just an aside (and 
perhaps an unwanted distraction at this point).

> get canceled this week...

I think a decent GPL or free IPv6 PPP for Windows XP would be a service to the 
community in general. Please write one.

> and for most of those people Linux is still scary.

For a CPE? Linksys uses Linux.

- Mark

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 08 Apr 2005 21:13:54 +0200

Hi Alain,

My comments below, in-line.

Regards,
Jordi

> De: Alain Durand <[email-masked]>
> Fecha: Fri, 8 Apr 2005 11:49:23 -0700
> Para: "[email-masked]" <[email-masked]>
> Asunto: [v6tc] Let the market decide or not: L2TP and/or TSP
> 

Or something better if we can make it quickly.

> - re-opening TSP might sounds like duplicating L2TP

The other issue with TSP that was commented was the unnecessary overhead
because the usage of XML, this could be improved very easily, I guess.

> 1) is a combined mechanism for fixed/wireless 3G network still

Somehow I could say yes, because we don't want to have in the small devices
(such as cellular phones, both protocols, for example when they have both 3G
and WLAN interfaces).

But an alternative is a self adaptative protocol which is actually like both
well integrated.

>       in order to "let the market decide" or do people think we need one

Yes, I will say so, if possible. But I'm still not excluding the option of
something else. I mean, if we do it quickly, why not choose among L2TP, TSP
or a new protocol which integrates the good things that we learned from
several of the available protocols (I explained this in my first email on
this thread).

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 08 Apr 2005 20:41:12 +0200

Hi Francis,

Unfortunately not every day have time to investigate why I can't use L2TP
VPNs, but it happens, that's the important issue. Probably they filter
something ... I've even found situations where they were filtering L2TP, but
proto-41 not (probably they do on purpose the L2TP filtering, for some
reason that I can't see, but they aren't aware that some people could make
use of proto-41, or they just don't care).

Regards,
Jordi

> De: Francis Dupont <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 08 Apr 2005 19:42:00 +0200
> Para: <[email-masked]>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 08 Apr 2005 16:05:12 -0400

> But an alternative is a self adaptative protocol which is actually like both

I think the clients would only really need to implement one type of protocol, 
though the servers would need to implement all.

- Mark

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 08 Apr 2005 23:15:56 +0200

Short summary first, what supports it:
 - Windows XP SP2 does not have it
 - Windows Longhorn will have it (they say),
   but out in 2007 or most likely later and then needs to be deployed
   and be fed to the users, who will stick with XP for some time anyway.
 - *BSD
 - Linux
 - Most CPE's (Cisco/Yahama/...)

But Windows is a huge market for most ISP's...

> community in general. Please write one.

Some other people convinced me and I actually was under the impression
that L2TP would not work over NAT thus I need to make up for it. It also
allows quite a number of scenarios to be solved more easily.
I don't really like GPL but that is off topic for sure. Well the night
reading is printed out ;) <hint> Let's make L2TP a viable option.

> For a CPE? Linksys uses Linux.

I know, but I meant the original image, as customers might still be
holding back on using a non-vendor image. It would thus be really nice
to have images that defaultly are IPv6 enabled, and I mean this for
*all* the products that are available.

The OpenWRT images, with which I flashed my box, indeed support IPv6 and
getting a lt2p client/daemon on it should not be an issue indeed.

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Fri, 8 Apr 2005 14:18:41 -0700

On Apr 8, 2005, at 1:05 PM, W. Mark Townsley wrote:
> I think the clients would only really need to implement one type of 
> protocol, though the servers would need to implement all.

What about dual mode handsets (3G & 802.11)?

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 9 Apr 2005 03:00:39 +0300 (EEST)

On Fri, 8 Apr 2005, Alain Durand wrote:
> 1) is a combined mechanism for fixed/wireless 3G network still important?

I still believe so, yes.

> 2) Is it the case that we have to define BOTH an L2TP based mechanism AND TSP
>     with all the operational/implementation headaches of having to support 2 
> things
>     in order to "let the market decide" or do people think we need one and 
> only one
>     mechanism?

L2TP seems sufficient.  Or if the ISP is worried about Windows 
clients, it can always run Teredo in tunnel server mode (provided that 
a reasonable server implementation exists), as that client is already 
supported and deployed.

...

Of course, I think it would probably be a good idea for the TSP 
authors to submit the draft as informational through RFC-editor to 
document the protocol, but IMHO if we're just looking at TSP, L2TP and 
"cleaned up TSP", I don't think it makes sense to spend energy in 
spinning up a WG in cleaning up TSP.

IMHO, with an informational spec and deployed code, the market can 
already decide between the two if it comes to that.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Apr 2005 11:29:29 +0200

L2TP:

=> this is not true but L2TP security is a bit complex. I'll try
to summarize it here for L2TP v2 over an IPv4 network:
 * the basic way to use L2TP is over UDP, i.e., with
   IPv4 - UDP - L2TP - PPP - IPv6 - etc
 * the highest security is provided by IPsec ESP in transport mode:
   IPv4 - ESP - UDP - L2TP - PPP - IPv6 - etc
 * as the previous solution kill the NAT traversal, it is possible to
   use IPsec in NAT traversal with L2TP directly over IP:
   IPv4 - UDP - ESP - L2TP - PPP - IPv6 - etc
 * without IPsec which can be too hard to use (no anonymous tunnel with it),
   L2TP can be protected using a shared secret (shared between the server
   and its clients) and a CHAP-like mechanism. The idea is to protect
   the L2TP control against unauthenticated access.
 * PPP itself can (should!) be protected using PAP, CHAP, ..., and
   things like MPPE. Perhaps not very good from the security point of
   view but easy to use and often already deployed.
 * last point: most L2TP servers can be configured in function of the
   client addresses so it is possible to use a fully unauthenticated
   L2TP in a closed (by anyway) network. BTW the IPsec solutions are
   a special case of this.

Regards

PS: in conclusion there is a complete non authenticated mode in L2TP
but as one should expect it must not be used in an open network...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 09 Apr 2005 11:39:02 +0200

I guess you forget:
1) Cellular phones, I don't think none of them support or even has plans for
L2TP.
2) Lots of low cost CPEs.

Both of this options represent also a big market share.

Regards,
Jordi

> Fecha: Fri, 08 Apr 2005 23:15:56 +0200
> Para: "W. Mark Townsley" <[email-masked]>
> Asunto: l2tp support on OS's Re: [v6tc] Re: Tunneling and Transition Drafts
>

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 09 Apr 2005 12:52:27 +0200

> Both of this options represent also a big market share.

Too bad for the phone guys, they should then start hiring some real
folks or giving out free phones + a lot of minutes so people can
implement it for them. Not evening thinking of an SDK ;)

And be honest, you really are ssh'ing into boxes using a cellphone?
For that matter, I am already getting annoyed when the connectivity is
under 5mbit and I guess there are a lot of people doing that.
For that matter, I have seen people dialing into an ISP using their cell
phone as a modem, but never seen them *use* IPv6 using the thing.

The phones that get used for these toys, have some spicky new thing,
which costs a lot of money, which requires a lot of new hardware, which
also costs a lot of money, thus let the phone people implement native
IPv6.

Greets,
 Jeroen

PS: I think I can claim that the code runs, that is without CHAP auth
and no GUI etc yet, but that is not that hard to add.
Though only tested against l2tpd.org (which dns entry is removed from
the DNS servers it seems) LT2Pv2 implementation.
No Cisco or other devices around to test it against...

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sat, 09 Apr 2005 07:42:46 -0400

> 1) Cellular phones, I don't think none of them support or even has plans for

Yes, from what I have seen this is probably quite true.

> 2) Lots of low cost CPEs.

I have seen low cost linksys CPEs running IPv6/PPP/L2TP. I can't imagine it is 
too difficult for others.

> Both of this options represent also a big market share.

Certainly. Big enough perhaps that each can support their own tunneling protocol.

Given the different characteristics of the underlying network, variant platform 
geneology, as well as intended application, usage and necessary time-frame, I 
have wonder if there is a lot to be gained from trying to force a single 
one-size-fits-all protocol here.

- Mark

---

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Apr 2005 15:25:35 +0200

I guess you forget:

=> I disagree: L2TP will be heavily used in this context, not for its ability
to run over nearly anything, but for its primary function: extend PPP / move
PPP endpoints.

=> I can see exactly the opposite, for instance L2TP is supported by
the last code on Linksys WRT54G/GS which is the cannonical example of
low cost CPEs.

=> L2TP is like PPPoE, a natural and common variation over PPP.
I'd like IPv6 will be the same for IPv4...

Regards

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 09 Apr 2005 17:53:10 +0200

Agree that should not be so difficult for others, but is a question of what
is available in real life. Is like asking why the default Linksys image
doesn't include IPv6 ;-)

The advantage of one-fits-for-all, in my point of view is two very important
fold:
1) Making easier for vendors to have a single choice, and consequently
making easier and more successful the interoperability.
2) Making easier for users and ISPs to have IPv6, when native is not
possible, in transparent way, as much as possible.

The results is to help the deployment of IPv6, in the medium-long term (2-3
years), and consequently the development of new and more advanced apps.

Regards,
Jordi

> De: "W. Mark Townsley" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Sat, 09 Apr 2005 07:42:46 -0400
> Asunto: Re: l2tp support on OS's Re: [v6tc] Re: Tunneling and Transition
> Drafts
> 
> 
> 
>> 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: Jerome Durand <[email-masked]>
Date: Mon, 11 Apr 2005 12:19:47 +0200

> Or if the ISP is worried about Windows clients, 
> it can always run Teredo in tunnel server mode (provided that a 
> reasonable server implementation exists), as that client is already 
> supported and deployed.

Short comment: and ISP needs manageable solutions, and TEREDO doesn't 
look like this. (same for 6to4 BTW).

Jerome

---

From: Jerome Durand <[email-masked]>
Date: Mon, 11 Apr 2005 12:29:16 +0200

> already decide between the two if it comes to that.

I am not sure I understand the goal of "Informational" here if there are 
implementations behind? Shouldn't it be PS? I agree with this "let 
market decide" stuff, sounds good, as this is always what happens anyway ;)

Jerome

---

From: Tim Chown <[email-masked]>
Date: Tue, 12 Apr 2005 15:30:54 +0100

> happy to get the "official" minutes as well :)

Jerome, I took rough notes (which I sent to Thomas and Kurtis).

The key thing was that half the room voted 'yes' to taking forward v6tc
work for 6-in-4 and 4-in-6 (and not for general tunnels, for non IPv6 uses).

Here are the lines from my notes where I counted votes, rest of session
notes snipped.   My feeling is the questions were not well thought out in
advance, which is a shame as the rest of the v6tc session was very useful
and (apparently :) well prepared.   After the first few questions, I think
people in the room lost interest/focus... we didn't have 3 or 4 well
considered questions prepared.

--

(Durand) How many people interested in TC work for 6 in 4 or 4 in 6 only?
- Maybe 50%
(Durand) For any kind of tunnels?  
- Maybe 10
(Narten) Worried if we're short-sighted like this
(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 Boniker?) Suggest rule out any solution that can't be generalised to other domains.
(Savola) Need to analyse 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.   Concerned that we are reinventing deployed solutions? (broker?)
(Durand) (hat off) Schizophrenia or 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?  
(Narten) Go with TSP as is?
- 10 people
(Durand) Is TSP good enough to get by on?
- about 10 people
(Durand) Need something more?
- 10 people
(???) Is there a crying demand for this by the ISPs?
(Durand) Common implementations would be nice
(Narten) Which ISPs need to solve this problem?
- 4 people
(Durand) Which ISPs think all is done?  No problem?
- ???
(JDurand) I'm happy with TSP.
(Durand) Happy if just do TSP to RFC?
(Parent) TSP is just a draft - need expert review
(Thaler) Maybe L2TP is enough?    TSP doesn't solve TEP discovery.
(Durand) Who wants TEP discovery solved?
- 12 yes
(Durand) And not?
- none

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Apr 2005 17:39:35 +0300 (EEST)

On Mon, 11 Apr 2005, Jerome Durand wrote:
>> IMHO, with an informational spec and deployed code, the market can already 
>> decide between the two if it comes to that.
>
> implementations behind? Shouldn't it be PS?

The point is that an Informational RFC can be produced quickly, with a 
disclaimer like,

=====
IESG Note

This RFC is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this RFC for
any purpose and notes that the decision to publish is not based on
IETF review apart from IESG review for conflict with IETF work.
The RFC Editor has chosen to publish this document at its
discretion.  See RFC 3932 for more information.
=====

in essence, such Informational RFCs don't get the official IETF "seal 
of approval", thorough review, can be insecure, etc. -- but may be 
sufficient to create interoperable implementations.

Proposed Standard has a much higher bar.. what's the point (if ISPs 
want something today if not 3 years ago) if we spin a year or two 
revising and maybe even making backwards-incompatible changes to the 
spec?

---

From: Fred Baker <[email-masked]>
Date: Wed, 13 Apr 2005 02:44:49 +0800

On Apr 12, 2005, at 10:30 PM, Tim Chown wrote:
> (Hinden) Have a zillion tunnel protocols and I don't see advantage of 
> new generic one.  I vote for limited scope.   Concerned that we are 
> reinventing deployed solutions? (broker?)
> (Durand) (hat off) Schizophrenia or IETF - requirements analysis vs 
> desire to be generic... ball going back and forth.   Chances of 
> success higher if we stay focused on IPv6.

<head uncovered>

My sense is that this sort of hits the point, but in fact misses it 
pretty widely.

The issues with IPv4/IPv6 transition and coexistence boil down, I 
think, to the questions of rendezvous and how/when to use a tunnel vs a 
translation mechanism. The discussion of "do we need 
yet-another-GRE-format" is beside the point - we *don't* need another 
GRE, but we need to know how and when to use the one we have, and in 
that case which one to use, and when the only option is to translate 
(NAT-PT or whatever).

The key question is how one enables two systems to talk with each 
other. This is trivial if we have a parallel implementation - dual 
stacks in both hosts and the entire network. In that case, pick one and 
go with it, and those systems that have not yet turned on IPv6 use 
IPv4. That is already a pretty strong recommendation.

But it also misses something basic - the value that IPv6 brings to the 
party is mostly related to increasing the address pool. If that is not 
true, if we have enough IPv4 addresses that we can build parallel 
networks everywhere, then we don't need a new protocol in the first 
place. If it is true (and it is) then you have to assume that there 
will be edge networks and service networks that are IPv6-only or 
IPv6-dominant pretty early - pick your reason. Once you have an 
IPv6-only/dominant service network, you have the question of IPv4 hosts 
having to use it to communicate over it, IPv6-only/dominant hosts 
needing to communicate over IPv4-only/dominant networks, and IPv6-only 
hosts needing to communicate with IPv4-only hosts.

At that point we have to solve a rendezvous problem. When two of one 
kind of host need to communicate over a network of the other kind, we 
obviously want to tunnel. We can do this using static tunnels, but that 
is a lot of manual configuration. What we really want is some kind of 
auto-tunneling, which means some kind of automated tunnel-endpoint 
location. We could do it by routing, which some proposals suggest: 
inject one type of routes into the other type of network using an 
interesting addressing scheme and make it all automagic. We could do it 
by naming - have what amount do DNS translators and tunnel brokers that 
insert the local-form-addresses of gateways into networks, and as a 
result both communicate to systems of one type of the address of the 
translator/tunnel endpoint and communicate to systems of the other type 
who to route a tunnel to. There are probably other approaches. But if 
we do this in multiple ways, we create a new layer of problems - how 
does a Teredo gateway talk to a Silkroad gateway talk to a DSTM gateway 
talk to a ...? We really need, I think, to pick *one*. and make it work 
well for 90+% of the cases. Note I don't say "cover every case". I'd 
like to, but I also wonder at what point doing so slows down getting 
the protocol out or slows down the transition itself.

I'm perfectly happy to standardize on existing types of tunnels - 
IPsec, GRE, IPv4/IPv6, IPv4/IPv4, IPv6/IPv4, IPv6/IPv6, L2TP, or 
whatever. If we don't solve the rendezvous problem (and btw communicate 
to the peer what kind of tunnel a given gateway is willing to support) 
we have not *touched* the transition problem.

And what I would like to see happen is for someone, somewhere - and 
note that I am very willing to do this in v6ops if people want and also 
willing to send it to v6tc or wherever else - to solve that rendezvous 
problem. As a result, I would like to see the various competing 
transition strategies all rendered OBE and get everyone to converge on 
a single transition approach.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 12 Apr 2005 22:25:03 +0200

> we have not *touched* the transition problem.

L2TP seems to cover the hole quite well. Except for the fact that there
is no discovery and the datastream of L2TPv2, as LTPv3 has some magic
stuff to fix it, can easily be spoofed, just like proto-41. IPSec can
solve this, but requires authentication and external setup again.

L2TP covers imho 90% of the cases. But... if you don't have a PPP infra
it will be (harder) to setup. And it doesn't allow for quick mobility
like in AYIYA or proto41+heartbeat. Thus when switching IP addresses
(walking to another floor with your wireless) the tunnel needs to notice
(L2TP StopCCN) that it is failing and renegotiate, which takes a few
secs, not more, but might give a different IP etc as it will do RA's
again or DHCPv6, which might take a bit longer and most likely will
break your SSH session if you like this. But we are not standardizing
Mobile IP here ;)

It might be, according to some that L2TP+PPP is heavy code, including
definitions about 2k lines of code for a minimal implementation that
works. Overhead of a L2TP tunnel including PPP is minimal. At least it
won't be noticed much when you are streaming video's over your neato
G3's or whatever cellphone.

Btw, anonymous tunnels in L2TP can be solved by not letting the server
request authentication and letting it reject auth attempts from the
client. Though I have not been able to verify how many servers support
this.

TSP or a similar protocol is IMHO a must, because L2TP simply can't be
deployed everywhere and better, not everybody wants it: Market::Decide()
TSP is handy in all cases, it can also have a template pointing to a
L2TP server etc. Next to that there is a client available for all
platforms.

As for the point made in the minutes that there is only one
implementation, AICCU will support TSP too as an option in the near
future.

> a single transition approach.

I've finally submitted my "_service" draft to the secretariat, it should
appear shortly in dnsop. I'll forward it to v6ops + v6tc when it is
there.

In "short":

Anycast prefix 1.2.3.0/24, on which on 1.2.3.53 there is a DNS server
listening. This is a (caching) recursive server which can be used for
looking up anything (www.google.com www.ietf.org etc). It is also
authoritive for the "_service." domain, in which we stick SRV records.
Usually _service is a DNAME to _service.example.net. Which fulfills the
searchpath, if the user does not have this special DNS server
configured, but does have it's ISP's domain in the searchpath, then the
resolver will come to _service.example.net because of the searchpath.

Thus, client gets turned on, it gets connectivity, it needs to lookup
something, resolver is default configured to 1.2.3.53, resolving thus
works. The prefix is anycasted by it's or another ISP, who can filter on
wish etc. If user needs a service, eg SMTP, it resolves the SMTP SRV
records, which can specify load balancing and other stuff. Same for
POP3, IMAP, or lookup eg help.www._service which returns a TXT record to
the URL of the servicedesk of the ISP you are using.

For the v6ops/v6tc case a client can first try l2tp.ipv6._service if
that exists, use it, then try tsp.ipv6._service, if that exists, use
that one. Discovery solved in the most generic way. It does indeed take
a couple of resolves, but hey people want it automatically. As for the
ones screaming "but I don't want a default thing" then configure the
client you are using for doing this.

Of course a similar prefix for IPv6 so that this also solves dns
configuration. Another good thing is that, assuming you have
connectivity you will always have the closest dns server, also ISP's can
then nicely block all the RFC1918 registrations in those, but that is
most likely just a good hope from me, most don't even filter...

Greets,
 Jeroen

---

From: Fred Baker <[email-masked]>
Date: Wed, 13 Apr 2005 04:36:45 +0800

Realistically, I think all of the various tunneling technologies will 
in fact be used. The important question is the rendezvous problem.

On Apr 13, 2005, at 4:25 AM, Jeroen Massar wrote:

>> whatever. If we don't solve the rendezvous problem (and btw 
>> communicate to the peer what kind of tunnel a given gateway is 
>> willing to support) we have not *touched* the transition problem.
>
> L2TP seems to cover the hole quite well. Except for the fact that 
> there is no discovery and the datastream of L2TPv2, as LTPv3 has some 
> magic stuff to fix it, can easily be spoofed, just like proto-41. 
> IPSec can solve this, but requires authentication and external setup 
> again.
>
> L2TP covers imho 90% of the cases. But... if you don't have a PPP 
> infra it will be (harder) to setup. And it doesn't allow for quick 
> mobility like in AYIYA or proto41+heartbeat. Thus when switching IP 
> addresses (walking to another floor with your wireless) the tunnel 
> needs to notice (L2TP StopCCN) that it is failing and renegotiate, 
> which takes a few secs, not more, but might give a different IP etc as 
> it will do RA's again or DHCPv6, which might take a bit longer and 
> most likely will break your SSH session if you like this. But we are 
> not standardizing Mobile IP here ;)
>
> deployed everywhere and better, not everybody wants it: 
> Market::Decide() TSP is handy in all cases, it can also have a 
> template pointing to a L2TP server etc. Next to that there is a client 
> available for all platforms.
>
>> note that I am very willing to do this in v6ops if people want and 
>> also willing to send it to v6tc or wherever else - to solve that 
>> rendezvous problem. As a result, I would like to see the various 
>> competing transition strategies all rendered OBE and get everyone to 
>> converge on a single transition approach.
>
> I've finally submitted my "_service" draft to the secretariat, it 
> should appear shortly in dnsop. I'll forward it to v6ops + v6tc when 
> it is there.
>
> In "short":
>
> Usually _service is a DNAME to _service.example.net. Which fulfills 
> the searchpath, if the user does not have this special DNS server 
> configured, but does have it's ISP's domain in the searchpath, then 
> the resolver will come to _service.example.net because of the 
> searchpath.
>
> works. The prefix is anycasted by it's or another ISP, who can filter 
> on wish etc. If user needs a service, eg SMTP, it resolves the SMTP 
> SRV records, which can specify load balancing and other stuff. Same 
> for POP3, IMAP, or lookup eg help.www._service which returns a TXT 
> record to the URL of the servicedesk of the ISP you are using.
>
> that one. Discovery solved in the most generic way. It does indeed 
> take a couple of resolves, but hey people want it automatically. As 
> for the ones screaming "but I don't want a default thing" then 
> configure the client you are using for doing this.
>
> connectivity you will always have the closest dns server, also ISP's 
> can then nicely block all the RFC1918 registrations in those, but that 
> is most likely just a good hope from me, most don't even filter...
>
> Greets,
>  Jeroen
>

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 12 Apr 2005 22:40:35 +0200

> in fact be used. The important question is the rendezvous problem.

Full ack. Which is why I decided to stick most of them into AICCU ;)
Has a BSD-alike license so vendors can abuse it if they want to.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Apr 2005 11:31:09 +0200

On Wed, 2005-04-13 at 11:01 +0200, [email-masked] wrote:
> On Wed, Apr 13, 2005 at 02:44:49 +0800, Fred Baker wrote:

> > obviously want to tunnel.
> 
> The 6bone ended up in a useless tunnel mess. Keep it simple has always
> turned out to be the best approach. I think a dual-stack network is
> easier to manage than a tunneled network. When users on an IPv4-only
> network want to use IPv6-only services, they should convince the network
> managers to upgrade to dual-stack. Otherwise, the tunnel mess will stay
> forever, because there is no incentive to upgrade to dual-stack.

Of course dual-stack is the way to go, but the biggest reason that
people do not upgrade to dual-stack is the lack of support in their
hardware. If they where able to dual-stack stuff, they would not even
bother with tunneling.

Also we are talking about tunneling inside the same AS here, not like
the 6bone globally. A packet over a tunnel will thus have 90% the same
path it would take when being native. See my traceroutes below, I'll
post the diffs to the native path when it becomes native as my ISP
indeed moved to their own ATM trunk and now can provide it natively,
before they couldn't as the technology didn't allow for it.

> Isn't the main reason for tunneling the fact that too few networks are
> deploying IPv6? Trying to force IPv6 deployment by creating complicated
> tunnel overlays seems to me like wrong engineering.

No, the main reason seems to be support and stability.

Also, they don't earn money selling IPv6 thus they are not allowed
politically to deploy it.

Greets,
 Jeroen

--
IPv4:

jeroen@purgatory:~$ traceroute www.bit.nl
traceroute to http-unix.bip.bit.nl (213.136.12.232), 64 hops max, 40
byte packets
 1  213-136-24-1.adsl.bit.nl (213.136.24.1)  12 ms  11 ms  11 ms
 2  i49.ge-0-1-0.jun1.kelvin.network.bit.nl (213.136.31.33)  11 ms  22
ms  11 ms
 3  http.lb.network.bit.nl (213.136.12.232)  12 ms  11 ms  11 ms

IPv6:

jeroen@purgatory:~$ traceroute6 www.bit.nl
traceroute to http-unix.bip.bit.nl (2001:7b8:3:5::80:1) from
2001:7b8:300:0:290:27ff:fe24:c19f, 30 hops max, 16 byte packets
 1  gw-1.ede-01.nl.sixxs.net (2001:7b8:2ff::1)  16.866 ms  13.277 ms
13.863 ms
 2  sixxs-gw.ipv6.network.bit.nl (2001:7b8:3:4f:290:6900:4fc6:d81f)
13.697 ms  13.612 ms  19.932 ms
 3  2001:7b8:3:5::80:1 (2001:7b8:3:5::80:1)  12.444 ms  19.834 ms
13.277 ms

And just in case one is wondering, the tunnel box is found over this
path:

jeroen@purgatory:~$ traceroute nlede01.sixxs.net
traceroute to nlede01.sixxs.net (193.109.122.244), 64 hops max, 40 byte
packets
 1  213-136-24-1.adsl.bit.nl (213.136.24.1)  12 ms  11 ms  11 ms
 2  i49.ge-0-1-0.jun1.kelvin.network.bit.nl (213.136.31.33)  11 ms  11
ms  11 ms
 3  nlede01.sixxs.net (193.109.122.244)  13 ms  11 ms  10 ms

Which explains the 1ms difference in latency ;)

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Apr 2005 10:44:28 +0100

On Wed, Apr 13, 2005 at 11:01:32AM +0200, [email-masked] wrote:
> You seem to assume also that upgrading the IPv4-only network to dual
> stack is not an option.

Between networks the "enough IPv4 addresses that we can build parallel
networks everywhere" argument works, for the ISP systems.  In end user 
or customer systems, I would expect we'll see a lot of dual stack that 
is IPv4+NAT alongside global IPv6.    From the ISP perspective what they
might see now is a handul of users achieving that by using a tunnel broker
(probably not one run by the ISP itself) and the challenge is offering 
(native, dual-stack) IPv6 from the ISP infrastructure directly.

-- 
Tim/::1

---

From: Fred Baker <[email-masked]>
Date: Wed, 13 Apr 2005 17:52:51 +0800

On Apr 13, 2005, at 5:01 PM, [email-masked] wrote:
>> But it also misses something basic - the value that IPv6 brings to 
>> the party is mostly related to increasing the address pool. If that 
>> is not true, if we have enough IPv4 addresses that we can build 
>> parallel networks everywhere, then we don't need a new protocol in 
>> the first place. If it is true (and it is) then you have to assume 
>> that there will be edge networks and service networks that are 
>> IPv6-only or IPv6-dominant pretty early - pick your reason. Once you 
>> have an IPv6-only/dominant service network, you have the question of 
>> IPv4 hosts having to use it to communicate over it, 
>> IPv6-only/dominant hosts needing to communicate over 
>> IPv4-only/dominant networks, and IPv6-only hosts needing to 
>> communicate with IPv4-only hosts.
>

No. I presume that it is optional, and I know of a number of networks 
that as we speak are deploying in a form that Jim Bound at the March 
meeting described as "ipv6-only"or "ipv6-dominant". IPv6-only is what 
it sounds like; IPv6-dominant is the case where a network deploys dual 
stacked but offers no IPv4 service to its customers.

> deploying IPv6? Trying to force IPv6 deployment by creating 
> complicated tunnel overlays seems to me like wrong engineering.

In the discussion I had with a university network this afternoon, it 
was to connect the IPv4 islands over the central IPv6 infrastructure.

Yes, we had that discussion too, and continue to have it. But I have 
never particularly noticed that the fact that I thought my customer was 
doing something unnecessarily self-limiting ever made much of a dent.

---

From: [email-masked]
Date: Wed, 13 Apr 2005 11:01:32 +0200

> IPv4. That is already a pretty strong recommendation.

Right.

	rvdp

---

From: [email-masked]
Date: Wed, 13 Apr 2005 12:18:29 +0200

> (native, dual-stack) IPv6 from the ISP infrastructure directly.

I fully agree with this. I was not suggesting to hand out more IPv4
addresses. I was suggesting to hand out more IPv6 addresses and give
them them native IPv6 access instead of tunneled access.

	rvdp