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

Re: [v6tc] Re: Tunneling and Transition Drafts

Attachment: signature.asc