Re: [v6tc] Re: Tunneling and Transition Drafts

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