tunnel broker auto-discovery [RE: Tunneling scenarios and mechanisms evaluation]

[Pekka Savola <pekkas@netcore.fi>]

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