Re: [v6tc] Re: Tunneling and Transition Drafts
"W. Mark Townsley" <townsley@cisco.com> Fri, 08 April 2005 14:15 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23613; Fri, 8 Apr 2005 10:15:56 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJuPu-0008Kx-IR; Fri, 08 Apr 2005 10:25:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJu8W-0005n5-Gf; Fri, 08 Apr 2005 10:07:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJu8U-0005mw-Uz for v6tc@megatron.ietf.org; Fri, 08 Apr 2005 10:07:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22467 for <v6tc@ietf.org>; Fri, 8 Apr 2005 10:07:01 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJuHF-0007u9-Kb for v6tc@ietf.org; Fri, 08 Apr 2005 10:16:07 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Apr 2005 10:06:52 -0400
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j38E6njI020870; Fri, 8 Apr 2005 10:06:50 -0400 (EDT)
Received: from [10.83.1.101] (rtp-townsley-vpn4.cisco.com [10.83.1.101]) by fruitpie.cisco.com (MOS 3.4.6-GR) with SMTP id BGQ01323; Fri, 8 Apr 2005 07:06:46 -0700 (PDT)
Message-ID: <42568FF5.8020401@cisco.com>
Date: Fri, 08 Apr 2005 10:06:45 -0400
From: "W. Mark Townsley" <townsley@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeroen Massar <jeroen@unfix.org>
Subject: Re: [v6tc] Re: Tunneling and Transition Drafts
References: <200504081104.j38B4hh4023080@cichlid.raleigh.ibm.com> <1112964824.26936.102.camel@firenze.zurich.ibm.com>
In-Reply-To: <1112964824.26936.102.camel@firenze.zurich.ibm.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e
Content-Transfer-Encoding: 7bit
Cc: "v6tc@ietf.org" <v6tc@ietf.org>
X-BeenThere: v6tc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: v6tc.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/v6tc>
List-Post: <mailto:v6tc@ietf.org>
List-Help: <mailto:v6tc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=subscribe>
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 1.8 (+)
X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41
Content-Transfer-Encoding: 7bit
Jeroen Massar wrote: > On Fri, 2005-04-08 at 14:32 +0200, JORDI PALET MARTINEZ wrote: > >>I got the same answer. But company roadmaps could change, I'm not sure about >>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. 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 > 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: > >>>The only thing you need is a well known anycast IP address where your >>>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). > > > 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 >>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? > > > 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 ;) > > >>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? >> >> >>>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, >> >>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 > > >>Also, it would be useful if you would specify the "lot of other >>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 :) > > >>>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. > > > 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. > > >>>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? >> >>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. > > > 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 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc
- [v6tc] Re: Tunneling and Transition Drafts (fwd) Pekka Savola
- Re: l2tp support on OS's Re: [v6tc] Re: Tunneling… JORDI PALET MARTINEZ
- [v6tc] Re: Tunneling and Transition Drafts JORDI PALET MARTINEZ
- [v6tc] Re: Tunneling and Transition Drafts Fred Baker
- Re: [v6tc] Re: Tunneling and Transition Drafts Jerome Durand
- Re: [v6tc] Re: Tunneling and Transition Drafts Pekka Savola
- Re: [v6tc] Re: Tunneling and Transition Drafts Soininen Jonne (Nokia-NET/Helsinki)
- Re: [v6tc] Re: Tunneling and Transition Drafts Jerome Durand
- RE: [v6tc] Re: Tunneling and Transition Drafts Bound, Jim
- RE: [v6tc] Re: Tunneling and Transition Drafts Bound, Jim
- Re: [v6tc] Re: Tunneling and Transition Drafts Thomas Narten
- Re: Fwd: [v6tc] Re: Tunneling and Transition Draf… Thomas Narten
- Re: [v6tc] Re: Tunneling and Transition Drafts JORDI PALET MARTINEZ
- Fwd: [v6tc] Re: Tunneling and Transition Drafts Fred Baker
- Re: [v6tc] Re: Tunneling and Transition Drafts Fred Baker
- RE: [v6tc] Re: Tunneling and Transition Drafts Soohong Daniel Park
- Re: [v6tc] Re: Tunneling and Transition Drafts Radhakrishnan Suryanarayanan
- Re: [v6tc] Re: Tunneling and Transition Drafts Jerome Durand
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- Re: [v6tc] Re: Tunneling and Transition Drafts Pekka Savola
- Re: [v6tc] Re: Tunneling and Transition Drafts JORDI PALET MARTINEZ
- Re: [v6tc] Re: Tunneling and Transition Drafts Thomas Narten
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- Re: [v6tc] Re: Tunneling and Transition Drafts JORDI PALET MARTINEZ
- Re: [v6tc] Re: Tunneling and Transition Drafts Pekka Savola
- Re: [v6tc] Re: Tunneling and Transition Drafts JORDI PALET MARTINEZ
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- Re: [v6tc] Re: Tunneling and Transition Drafts Vladimir Kotal
- Re: [v6tc] Re: Tunneling and Transition Drafts Jerome Durand
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- Re: [v6tc] Re: Tunneling and Transition Drafts JORDI PALET MARTINEZ
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- Re: [v6tc] Re: Tunneling and Transition Drafts JORDI PALET MARTINEZ
- Re: [v6tc] Re: Tunneling and Transition Drafts W. Mark Townsley
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- Re: [v6tc] Re: Tunneling and Transition Drafts W. Mark Townsley
- Re: [v6tc] Re: Tunneling and Transition Drafts Francis Dupont
- Re: [v6tc] Re: Tunneling and Transition Drafts Francis Dupont
- Re: [v6tc] Re: Tunneling and Transition Drafts Francis Dupont
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- [v6tc] Let the market decide or not: L2TP and/or … Alain Durand
- Re: [v6tc] Re: Tunneling and Transition Drafts W. Mark Townsley
- Re: [v6tc] Let the market decide or not: L2TP and… JORDI PALET MARTINEZ
- Re: [v6tc] Re: Tunneling and Transition Drafts JORDI PALET MARTINEZ
- Re: [v6tc] Let the market decide or not: L2TP and… W. Mark Townsley
- l2tp support on OS's Re: [v6tc] Re: Tunneling and… Jeroen Massar
- Re: [v6tc] Let the market decide or not: L2TP and… Alain Durand
- Re: [v6tc] Let the market decide or not: L2TP and… Pekka Savola
- Re: [v6tc] Let the market decide or not: L2TP and… Francis Dupont
- Re: l2tp support on OS's Re: [v6tc] Re: Tunneling… JORDI PALET MARTINEZ
- Re: l2tp support on OS's Re: [v6tc] Re: Tunneling… Jeroen Massar
- Re: l2tp support on OS's Re: [v6tc] Re: Tunneling… W. Mark Townsley
- Re: l2tp support on OS's Re: [v6tc] Re: Tunneling… Francis Dupont
- Re: [v6tc] Let the market decide or not: L2TP and… Jerome Durand
- Re: [v6tc] Let the market decide or not: L2TP and… Jerome Durand
- Re: [v6tc] Re: Tunneling and Transition Drafts Tim Chown
- Re: [v6tc] Let the market decide or not: L2TP and… Pekka Savola
- Re: [v6tc] Re: Tunneling and Transition Drafts Fred Baker
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- Re: [v6tc] Re: Tunneling and Transition Drafts Fred Baker
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- Re: [v6tc] Re: Tunneling and Transition Drafts Jeroen Massar
- Re: [v6tc] Re: Tunneling and Transition Drafts Tim Chown
- Re: [v6tc] Re: Tunneling and Transition Drafts Fred Baker
- Re: [v6tc] Re: Tunneling and Transition Drafts Ronald.vanderPol
- Re: [v6tc] Re: Tunneling and Transition Drafts Ronald.vanderPol