[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tunnel broker auto-discovery [RE: Tunneling scenarios and mechanisms evaluation]
Pekka,
The "auto-discovery" feature is part of the work that we are doing as "auto-transition", and we will an I-D on this in a few weeks, hopefully.
Regards,
Jordi
----- Original Message -----
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Jeroen Massar" <jeroen@unfix.org>
Cc: "'Alain Durand'" <Alain.Durand@Sun.COM>; <v6ops@ops.ietf.org>
Sent: Monday, March 15, 2004 8:51 AM
Subject: tunnel broker auto-discovery [RE: Tunneling scenarios and mechanisms evaluation]
> Taking the "auto-discovery" part of the thread apart from the rest...
>
> I think one should soon try to write a draft about different tradeoffs
> of tunnel service discovery procedures (inter-domain anycast,
> intra-domain anycast, DNS (at least two methods), DHCP, manual config
> ec.). This might help us a lot in trying to figure out what we
> actually want in this space.
>
> Maybe someone(s) in the WG would be interested in drafting such a
> document in a fast-track fashion (e.g., within a week or two at
> most)..
>
> On Sun, 14 Mar 2004, Jeroen Massar wrote:
> > Pekka Savola [mailto:pekkas@netcore.fi] wrote:
> > > I.e., it's OK for techies, but looking at wider deployment, it's
> > > unacceptable. But I guess it depends on who are you aiming the
> > > mechanism for; if we standardized a solution in this space, I
> > > think it
> > > would certainly have to be much simpler than that administratively.
> >
> > Indeed, I guess it would be a good idea to pursue the anycast
> > configuration service or a similar technique. ISP's that don't
> > want to allow other ISP's users on their service can always
> > not announce the prefix to other ISP's and can always announce
> > the prefix to other users.
> >
> > Having a single hostname, eg "ipv6.tunnelbroker.arpa" or something
> > would not work as ISP's would then have to depend on the instance
> > running that service to distribute the clients. Unfair competition
> > and other blabla comes to mind.
>
> Yes, single hostname wouldn't work, I think. However, one could say
> that you could check for the local tunnel broker by looking up e.g.
> 'ipv6-tunnel-server.' appended with your DNS search path, right?
>
> That would work just fine in certain scenarios: if the broker doesn't
> exist, you get negative reply and use a different mechanism (e.g.,
> anycast or manual config); if positive, you use that. This has
> drawbacks in the cases when you're mobile/nomadic (i.e., have to re-do
> the DNS lookup, not just re-route by anycast, but as the prefix when
> moving would change as well, this might not be a significant
> drawback).
>
> One item I'd like to know more is how large ISPs which offer e.g., DSL
> service, in different geographical areas, configure the DNS search
> paths. That is, whether the DNS search path trick would be sufficient
> in finding the closest broker, or whether anycast would have to be
> used on the side (note: nothing of course prevents you from anycasting
> the IPv4 tunnel broker address that gets returned from the DNS).
>
> The main question here is, I think, whether there would be pushback in
> the DNS community for standardizing such "special-case local names".
> I recall there is precedent for doing something like this, but I'm not
> fully certain. This would have to be investigated in advance..
>
> > To sum up the features I would like to have in such a protocol:
> > - anycast address or similar to choose the closest TB and
> > this could quite well be the service the ISP operates or
> > a friendly ISP announcing this prefix. One problem though
> > there is no way of having multiple TB's this way.
> > But if a user knows which TB she wants she can always go
> > directly to that TB.
>
> Precisely.
>
> > - Restricting users to only certain prefixes
> > using the anycast announcement, just don't announce and/or
> > redirect the users to another service, never say NO...
>
> Yep.
>
> > - user authentication (optional)
> > this is mainly to track users, know who is using what etc
> > it also allows giving the same prefix to the same user even
> > when the user changes IP addresses.
> > This could also be done using a cookie mechanism.
>
> I think this should probably be out of scope for anycast mechanism, at
> least in some sense.
>
> That is,
> - the anycast service must not lead to a tunnel server, which
> requires user authentication; that is, "zero-configuration" must
> always be possible.
>
> - the user might try to perform user authentication with the tunnel
> server, but if the tunnel server does not know the user, the user
> would not have other fallbacks than manually selecting the tunnel
> server.
>
> I think it might even be better that the anycasted services would not
> offer any kind of user auth -- because if the closest server changes,
> the authentication won't work anyway (or you'd have to redo it), and
> it's just wasted effort.
>
> > - static prefix delegation
> > could be done using normal RA techniques.
>
> This would probably depend on user authentication or some kind of
> identification being there. If it isn't, the prefix can be only as
> stable as it is (i.e., until the IPv4 address or IPv4 address + port
> changes). So, in my book, "static" is not a requirement. I'd rather
> tie the requirement to the staticity of the v4 address and or UDP port
> (if coming through a NAT).
>
> Are you referring to advertising a /64 and doing something like
> ND-proxying, something like draft-bykim-ipv6-hpd-01.txt or what?
>
> Without ND-proxy I don't think prefix delegation would work with
> currently specified mechanisms except for DHCPv6.
>
> > - DNS server configuration for that prefix.
>
> You mean reverse DNS. Delegation and/or full configuration (e.g., a
> wildcard record for the whole prefix)?
>
> > - Protocol 41 at first but optionally over UDP eg
> > after detecting that proto-41 doesn't work.
>
> Yep.
>
> > - UDP mode to be able to cross a NAT.
> > Every single NAT I know of can be configured to
> > forward UDP packets, thus that should work.
> > There is one but, the first packet must come
> > from the client and there should be some packet
> > flow to not zero the NAT's counter.
>
> Yep.
>
> > The above service could also announce a list of TB's
> > to the client and let the user pick, they seem to be
> > quite good at that.
>
> Clarification: are you referring to TB's controlled by the
> anycast-replying entity (e.g., a large ISP having a dozen
> geographically distributed tunnel servers), or referring to other TB's
> as well?
>
> The former doesn't make sense with anycast, as there is no need for
> that.
>
> The latter doesn't seem to be feasible, as it would require sharing
> information with about all the tunnel brokers in the world. How would
> one do that? Not manually I hope. So, this seems equally problematic
> as well.
>
> > This feature should then be released for all major OS's
> > as otherwise it still wouldn't deploy... and it will
> > just be the same as 6to4, a very good idea but little usage.
>
> You never know.. it could be little usage, but if implemented and used
> by e.g. Microsoft, you would immediately have 5+ million IPv6 users
> through a tunnel broker.. for the good or bad :)
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line 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.