Subject: Tunneling and Transition Drafts

From: Fred Baker <[email-masked]>
Date: Tue, 5 Apr 2005 16:34:52 -0700

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?

---

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
> 

************************************
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.

---

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: Pekka Savola <[email-masked]>
Date: Wed, 6 Apr 2005 09:13:24 +0300 (EEST)

On Tue, 5 Apr 2005, Fred Baker wrote:
> 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).

No, "[v6tc] intended to take over all the tunneling stuff" was *never* 
the goal of v6tc.

Many months ago (maybe it's at about a year now), when we first 
discussed how to move around with all the work that keeps coming to 
v6ops, one of the first proposals was to create "v6tuns" working 
group, working on the tunneling mechanisms.

The idea was rejected in the relatively short order, and has not been 
seen since.  We don't need another ngtrans, specifying all the 
transition mechanisms people come up with.

(However, one, slightly better idea was to create a maintenance WG to 
move 6to4 to Draft Standard, figure out what to do with so-called 
6over4, move rfc2893(bis) to DS, etc. -- but there would undoubtedly 
be a big slippery slope there, and it may be a bit too early for this 
activity.)

>   be done through simple routing if the tunnels sty up or use a

The DNS lookup (after you know what you're looking for -- including 
"discovery" part is trickier) is not a hard problem.  The real 
problem, which v6tc set out primarily to solve was how to set up the 
tunnel at both endpoints without requiring manual configuration 
(especially the endpoint addresses) at both ends -- and running a 
routing protocol between the two is a non-starter.

> - how to translate IPv6->IPv4 and IPv6-IPv4 between an IPv6-only/dominant

This must be badly worded because that you're saying is basically 
NAT-PT with DNS-ALG, which is exactly what we just decided was a bit.. 
um.. problematic, and requested reclassification as Experimental.

> 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

If I read this correctly, you see two options:

  1) let the authors publish their stuff as RFC-ed informational, if
     they want to, or
  2) produce a Grand Unified Mechanism somewhere (here or some other
     WG) which solves all the needs (and hopefully world hunger
     besides).  [This is a bit challenging as those needs include
     tunneling in every possible way, translation, etc.]

These are a bit polarized.  What I think we should do is:

  - obviously, allow 1) if that's what people want
  - not use the v6ops meeting time etc. on these proposals; short 
pointers on the list may be OK, but lengthy discussions should be 
elsewhere (discretion of the chairs to rule out stuff as out of scope, 
as always)
  - if a mechanism comes along that a lot of people actually want to 
work on, ask that they create a BOF, and then see if it gains 
sufficient momentum or not.
  - or the authors can obviously try to reach ADs and ask sponsoring 
the work; or use appropriate other WGs if the work is in scope there 
(e.g., 6PE (bgp tunneling) work has moved over to IDR wg)

-- 
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: 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.

---

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.

> 
> _______________________________________________
> v6tc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/v6tc
-- 
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: Alain Durand <[email-masked]>
Date: Thu, 7 Apr 2005 17:08:08 -0700

> disagree, this would be a good time to say so).

Is TC going to be chartered or not, I do not know yet, we are still 
talking about that.
That said, as Pekka mentioned, TC was never meant to pick up all the 
left-overs
from the NGtrans days that were not adopted by v6Ops, it was meant to 
be a very
focused wg.

I'll send later the minutes of the meeting, but what I got (and all the 
people I talk to after
shared the same feeling) is that:
- We are very late in the game, folks have started to deploy their own 
ad-hoc solutions,
   if we do anything, time to market will be critical
- What is being deployed is either not documented or not standardized 
(i.e. not been through
   community review)
- The focus on latency was to try to get a common solution that will 
fit the wired and wireless case,
    it seems that this may not be the best approach.

> 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".

let's get into the time machine...

Spring 1999. Grenoble IPng & NGtrans interim meeting.
Topic: we have too many transition mechanisms, can we converge on one 
and only one?

Summer 2002. Yokohama IETF.
Topic: too many transition mechanisms, shut down NGtrans and focus on 
scenarios in v6ops

Spring 2005. now.
Topic: too many transition mechanisms, can we converge on one and only 
one?

See a pattern here?

	- Alain.

---

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

Hi Alain,

I see the pattern ... But I don't think we actually tried to look into a
single solution, and that may be why we haven't moved forward.

By the way, I don't agree that the approach on a single solution for wired
and wireless isn't the best approach. The point is that it may be or not,
depending on the actual solution ;-)

Regards,
Jordi

> De: Alain Durand <[email-masked]>
> Fecha: Thu, 7 Apr 2005 17:08:08 -0700
> Para: Fred Baker <[email-masked]>
> <[email-masked]>, "[email-masked]" <[email-masked]>
> Asunto: Re: Tunneling and Transition Drafts
> 
>

---

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: 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: [email-masked]
Date: Wed, 13 Apr 2005 11:01:32 +0200

> IPv4. That is already a pretty strong recommendation.

Right.

> hosts needing to communicate with IPv4-only hosts.

You seem to assume also that upgrading the IPv4-only network to dual
stack is not an option.

> 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.

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.

	rvdp

---

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

> 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.

> 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

> You seem to assume also that upgrading the IPv4-only network to dual

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 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