Re: [v6tc] Re: Tunneling and Transition Drafts

[JORDI PALET MARTINEZ <[e-mail]>]

Sooner and better than that:

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

Regards,
Jordi




> De: Jeroen Massar <[e-mail]>
> Organización: Unfix
> Responder a: <[e-mail]>
> Fecha: Fri, 08 Apr 2005 14:53:43 +0200
> Para: <[e-mail]>, Thomas Narten <[e-mail]>
> CC: "[e-mail]" <[e-mail]>
> Asunto: Re: [v6tc] Re: Tunneling and Transition Drafts
> 
> 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.
> 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
> 




************************************
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/v6tc