Re: draft-palet-v6ops-tun-auto-disc-01.txt

[Pekka Savola <pekkas@netcore.fi>]

This has been sitting too long in my "to be responded" queue.. :-(

On Wed, 16 Jun 2004, Jeroen Massar wrote:
> On Sat, 2004-06-12 at 11:58, Pekka Savola wrote:
> > Thanks for comments..
> > 
> > I think your assumptions are different from those based on which this
> > draft was written.  They might warrant spelling out, but in the
> > interests of learning how to enhance the document, it would be best if
> > you could state more clearly which parts of the document you find
> > objectionable (and how to fix the issue, if possible).
> 
> No, I think I am looking the issue from a different perspective.
> 
> The document is talking about 'tunnel endpoints' while IMHO these should
> be 'tunnel services'. Who provides them and how they are negotiated is
> not mentioned at all in the document and is up to the various
> configuration protocols, while this document is targetted solely afaik
> at the discovery part.

As clarified by Miguel, these are out of scope for this doc, to be 
described in the specifications themselves, in 
draft-palet-v6ops-auto-trans-00.txt, or whatever.

This doc just tries to analyze different ways to discover the
end-point, without taking any stance on the actual protocol.

> > To make it clear, IMHO, for wide-scale deployment, non-automatic
> > configuration is completely unacceptable. I want to do away with such
> > manual configuration.  The main point of the automatic discovery
> > document is to describe mechanisms how the host stacks can run a
> > simple procedure which can lead to a result like, "yes, tunnel service
> > is available, at IPv4 addrexx a.b.c.d", or, "no, tunnel service is not
> > available."
[...]
> But I would rather see the discovery part say:
> The service is available from:
>   - here
>   - there
>   - there too
> 
> Or when the client only has one choice or thinks it is feasible enough
> for a certain choice to use that directly.

This is not really feasible, because doing such would require
coordination among different parties, and complexity increases every
time you need to coordinate between different people.  This could be
mostly doable with Centralized Broker -mechanisms, but the draft tries
to justify that those aren't scalable / feasible.

Most discovery methods, however, support the discovery of multiple 
end-points.  Whether those would be under a different administration 
is a separate question.  And the user can always manually configure 
the endpoint if he knows of something better..

Text suggestions to make this clearer?
 
> You also note 'host stacks' but wouldn't this be better to place simply
> as an additional tool. radvd isn't a part of the stack either in most
> OS's at the moment. Also I am quite sure that there a lot of people who
> don't want something to automatically configure it for them so anything
> using this tool would need to either be setup by the user or have enough
> knowledge to not run in a native network.

A separate tool (but shipped with the base system) is probably closer
to the reality, yes.
 
> > > Basically I see three steps:
> > >  - Discovery of the 'best' tunneling service
> > >      <great gaping gap>
> > 
> > It doesn't have to discovery of the *best* service necessarily, but 
> > discovery of the service.  There's sufficiently large great gaping gap 
> > here... and this is what this document aims to address.
> 
> 'best' is the one that fits mostly in the situations that the discovery
> is taking place in. 'best' could thus be the one that is anycasted
> closest to the host etc and depends totally on the discovery method.
> This is what the doc should describe.

Isn't it what this is describing?  Shared-address unicast is one of 
the most prominent techniques in the draft.

Also note that if there are multiple potential mechanisms, figuring
out which one to use is out of scope here (see the auto-trans work).  
We're just concerned about the mechanisms to discover the end-point.
> 
> > >  - Tunneling
> > >      (proto-41, 6to4, teredo, ayiya, tinc, openvpn, ...)
> > 
> > These two are out of scope of this document.
> 
> Thus my assumption that this document is targeted at the gap above is
> correct. Then one should not be finding the best tunnel _endpoint_ but
> the tunnel _service_ which can provide that endpoint. TSP for instance
> does its own endpoint negotiation. Having a discovery method do that
> would thus make TSP either be only for that single Tunnel Server or it
> would require another step. The 'endpoint' wording thus is wrong IMHO
> and should be resplaced by 'service'.

Again, I disagree.

Let's take TSP as an example as you mention it.  TSP has a great 
"gaping gap" (in your words): there is no way to discover the closest 
tunnel broker!

For tunnel broker solutions, this document tries to address finding
the tunnel broker end-point (where you can begin the negotiation).  
The tunnel broker negotiation specifies the ultimate endpoint where
you'll build your tunnel (such address could of course be anycast or
whatever as well).  What happens after getting the initial broker 
end-point it out of scope of this specification.

For tunnel server solutions, this document tries to address finding 
the tunnel server end-point (where you can beging tunneling or 
negotiation, whatever the mechanism specifies).

So, I have to disagree with you here.  We just want to discover the 
end-point.

Any suggestions how to make it clearer?

> As the Discovery service can in no way know the load of the Tunnel
> Service and any other properties that the provider of the service wants
> to include into the calculation, wouldn't it be better after one has
> discovered the 'best' service to then hand it over to for instance TSP
> or STEP?

For broker-like techniques, hand-over is what happens -- see above.

For server-like techniques, the assumption is that the load-balancing
and whatever features are achieved using different means (anycasting,
modification of DNS records if one server gets full, etc.)

> > > The text, abstract and actually the complete text mentions
> > > "configuring the IPv6 tunnel endpoint on a node."
> > > I would change that part to 'tunneling service' instead of 'tunnel endpoint'.
> > > As mentioned in 3.1, the service could consist of multiple servers though
> > > there is only one 'endpoint'. A service eg a Tunnel Broker, might even
> > > have multiple endpoints etc.
> > 
> > I'd be reluctant to say 'tunnel service', as you don't configure 
> > anything about the service itself, just the tunnel end-point.  All 
> > other means of configuring (or reconfiguring if there is a broker) are 
> > out of scope of this specification.
> 
> With 'tunnel service' you designate the closest possiblity of giving you
> the 'service' which is "providing IPv6 connectivity". With a tunnel
> endpoint one would mean 'exactly that endpoint'.

Yes, that's the intent -- end-point only.

> > (Later, why you said this becomes clearer: you have the assumption 
> > that the service would be used for general purpose service discovery, 
> > for multiple tunneling mechanisms.
> 
> Not entirely, this discovery method _could_ point to multiple tunneling
> mechanism, but if the IETF reaches concensus one single protocol, then
> it could be just that. Still it would be better to let the service
> determine the real endpoint. Based on DNS or anycast this is simply not
> an option.

Are you saying that such a discovery process would have to implement
the tunnel broker logic for picking the right tunnel server endpoint
for the users?  Multiple times, once for each tunnel broker (or other)
technique?  This doesn't seem feasible to me..

> What if you have a dialin pool for 'low paying' clients and 'high
> paying' clients, you might want to give a better service to the ones
> that give you more money, anycast nor DNS will not work here unless one
> does a lot of tricks. Letting a service decide it, after that that
> service has been automatically discovered is a better and more flexible
> option. The service can then also either redirect the user somewhere
> else or give a nice visual error message through one protocol or
> another. The mechanisms described in this draft allow no such thing
> because the endpoint of the tunnel is directly configured.

This is something that should happen in the tunnel broker or server
protocol, not in the discovery process.  For example, what kind of
prefix would get delegated could depend on these factors (I hope it
won't, but it could).
 
> > I don't make this assumption -- 
> > this method would be mechanism-specific.)
> 
> If this document is mechanism specific shouldn't these descriptions then
> be included in that mechanism ?

Exactly the other way.  This document is NOT mechanism-specific, but
mechanism documents will have to implement one (or multiple of)  
mechanism described in this document for discovery.

This is just a common place for discussing end-point discovery.  How 
that's integrated in the mechanisms is out of scope.
 
> > > Therefor I miss one possible scenario & solution:
> > > One could announce a standardized anycast address (eg 192.0.2.6), which
> > > can then be hardcoded into clients, maybe better to have something like
> > > tunnelautodiscovery.ietf.org as DNS can always be changed, this could
> > > then also be combined with the DNS prefixing path search etc.
> > 
> > There is is mentioned in section 3.1 as so-called "global anycast".
> 
> Which targets a completely different audience: a local (organisational)
> network and nothing bigger, eg providing service to a complete IX.

Please re-read.  Section 3.1 includes both global and local anycast, 
and global is exactly what you describe.

Please submit text clarification proposal if this is not clear enough.

> > > 8<----
> > > www.example.org tunnelbroker
> > > tsp.example.org TSP
> > > 6to4.example.net 6to4
> > > teredo.example.net teredo
> > > ...
> > > ---->8
> > > The user will be presented with an optionlist to choose from or
> > > alternatively based on properties/policies etc the client could
> > > automatically pick the best out of the list and use that. Then
> > > either the website, TSP, 6to4, teredo, etc take over on the process.
> > > The discovery is really discovery here and nothing else.
> > 
> > You make the assumption that the discovery process would be common for
> > all the the mechanisms.  I don't.  Making it common might have an
> > advantage or two,
> 
> The biggest advantage would be that it is generic and that it will work
> for all situations and not just a few. If you only want a few, then that
> would be like designing IPv6 only for the polar caps as there it freezes
> but nowhere else. I don't see any OS vendor wanting to include a tool
> then. The scale of Teredo is the target, aka every desktop user pc
> should have it. And every of the above mechanisms solves a different
> problem which the others don't. Then if one just says 'always use this'
> it won't work for a large chunk of the other users and or ISP's who
> might want to deploy it and they will not adopt it.

As described before, you seem to think that the discovery part would 
be independent of the mechanisms -- that you would first run the 
discovery (one tool), and then you would run the mechanism (another 
tool).

I don't expect that.  I'd expect discovery to be integrated with the 
transition mechanism tool.

Trying to create an independent tool which achieves everything that
the different transition mechanisms might need is unfeasible -- such a
tool would by necessity be extremely complex, having to implement N
different mechanisms for different tools.
 
> > > ISP's which don't announce this service will recieve the prefix from
> > > another ISP and of course could simply optional nullroute the prefix if
> > > they want to disable this service from other ISP's and when they don't
> > > want their users to use this service due to administrative policy etc.
> > > 
> > > Having the above would then be probably better solved with an anycast
> > > DNS server to be able to ask that server multiple different questions
> > > and maybe directly supply a default DNS server for many hosts solving
> > > quite a number of problems.
> > 
> > Global anycast has disadvantages as well, as noted in the draft (maybe 
> > not clearly enough).
> 
> Using anycast for discovery doesn't have any drawbacks as the packet
> exchange between the client and the 'server' would be minimal.

I disagree.  Please re-read.

What happens if nobody is advertising the prefix so that your packets 
would get routed to it?  What happens if the only one globally 
advertising is 300 ms away?

> If you want to use anycast as a tunnel _endpoint_ that is a different
> story, but this was about discovery thus we are hopefully talking
> services here and not endpoints...

This is about discovery of the *endpoint*, so depending on how that 
information is used (remember the difference of broker vs server), it 
could be used for longer as well.
 
[...]

> > All the solutions assume that the tunneling mechanism -specific means 
> > are used to obtain that.  E.g., one could have a pseudo-interface 
> > which creates tunnels on the receipt of the first packet, or 
> > something.  This should not be a problem.
> 
> I already see that script kiddy spoofing IPv4 packets with ease and
> generating a lot of interfaces at random, but how was that configured?
> Or better said how did you authenticate the user to the tunnel service?
> Especially when the user is not directly coming from your own IPv4
> space, a remote mobile user, a user visiting another ISP's network etc.
>
> l2tp / AYIYA / ... etc could be used as those protocols provide
> authentication inside the protocol stream, but proto-41, which is the
> most common used setup doesn't work in this case.

Obviously, you should not run such a service (if it depends on the
first packet, etc.) except to your customers or such which you have
ensured that cannot spoof the address.

Again, this is out of scope from this document.
 
> > > How is it going to know which prefix to use and how is the TS going
> > > to know where to route packets destined for that prefix?
> > 
> > The client doesn't need to know the prefix but it might.  It could 
> > just learn the prefix from the TS, similar to the process STEP uses.
> 
> STEP/TSP fall under the "Configuration" header in the 3-phase list.
> These should IMHO determine the type of protocol for the data being
> tunneled. STEP though doesn't define any protocol, thus would be limited
> to the underlying protocol that would be used, which would then make
> this only applicable in a few scenarios of the many that exist.
> Which again doesn't make it applicable for the many users and varying
> setups out around the world.

Out of scope from this doc.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings