Re: [v6tc] Tunnel endpoint discovery summary/tradeoffs

Hi, 

I agree with Pekka's view about the tunnel endpoint discovery analysis. Some next steps are required mainly to analyze advantages and drawbacks for reverse/forward DNS in order to get a "winner" solution, if possible.

Indeed we are (Jordi and myself) working on that and hopefully we'll have a new update of  the draft-palet-v6ops-tun-auto-disc document soon.

We would appreciate any suggestion or input.

Regards
Miguel

----- Original Message ----- 
From: "Pekka Savola" <pekkas@netcore.fi>
To: <v6tc@ietf.org>
Sent: Wednesday, December 22, 2004 8:34 PM
Subject: [v6tc] Tunnel endpoint discovery summary/tradeoffs

> Hi,
> 
> Below is my attempt to briefly summarize the situation with Tunnel 
> endpoint discovery analysis, and some next steps.
> 
> The most important document is draft-palet-v6ops-tun-auto-disc-02.txt.
> 
> 1) It analyzes different mechanisms (proposed or existing) for 
> discovering the tunnel endpoint:
>   - anycast address methods
>   - various forms of DNS lookups (reverse DNS to be added)
>   - centralized omniscient brokers (not feasible)
>   - DHCPv4
>     * not really feasible: oesn't work through NAT boxes, or
>       unmodified DHCP servers
>   - PPP (PPP not always used, ban on new extensions)
>   - SLP
>     * doesn't look promising (can't depend on multicast, etc.)
> 
> The document maybe needs to better justify why existing solutions are 
> not sufficient (after all, there has been a LOT of work in the IETF 
> for service discovery in general).
> 
> 2) It tries to describe the different scenarios how endpoint discovery 
> could happen.  This needs revision and discussion.  In summary there 
> are three options:
> 
>  a) no discovery: always assume the client pre-configures the endpoint
>     information.
>  b) discovery at the visited ISP only (compare to MIPv6 RO),
>     or manually ("home agent" -like tunnel broker).  The user/client
>     implemetation will have to pick preference:
>      1) first try local, if fails, try manual config
>      2) manual config first, then try local
>      3) only local or only manual config
>     This is a policy decision by the client, but no rocket science.
>     E.g., Microsoft's 6to4/ISATAP implementations work in a similar
>     manner this way.
>  c) discovery of the endpoint everywhere (like 6to4 anycast address).
>     This is likely very problematic both administratively, financially
>     and technically.
> 
>  c) seems to be out of scope for this discovery mechanism.
> 
> 
> There are three other relevant documents:
>  - draft-palet-v6ops-solution-tun-auto-disc-01.txt
>  - draft-yamamoto-naptr-service-discovery-00.txt
>  - draft-daniel-dhc-ipv6in4-opt-05.txt
> 
> The first describes a combination of potential mechanisms for 
> tunnel-endpoint discovery.  This likely needs a lot of work and 
> trimming down, to just one mechanism.  DNS lookups use forward tree.
> 
> The second describes using reverse DNS for service discovery.
> 
> The third describes DHCPv4 based solution, but very likely it won't be 
> a sufficient solution to the whole problem, and it may not be 
> productive to specify multiple ones.
> 
> At this point, the most important issue wrt. solutions is to 
> understand key implications between using forward DNS (using the DNS 
> search path) and reverse DNS (looking up information at your IP 
> address), but the tradeoffs will be analyzed at more depth in the 
> revision of draft-palet-v6ops-tun-auto-disc.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> v6tc mailing list
> v6tc@ietf.org
> https://www1.ietf.org/mailman/listinfo/v6tc
>

**********************************
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.