Subject: [v6tc] Tunnel endpoint discovery summary/tradeoffs

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Dec 2004 21:34:50 +0200 (EET)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Alain Durand <[email-masked]>
Date: Wed, 22 Dec 2004 12:54:22 -0800

> revision of draft-palet-v6ops-tun-auto-disc.

Another open issue is the re-use of existing RR in the DNS (regardless 
of the forward/reverse tree issue)
or the creation of a new one, as recommended by the IAB.

Summarizing the issues with forward DNS:
	- does not map the physical topology
	- does not work well for large domain
	- assume that the local domain configured at the customer site is the 
ISP one and not a private one

Summarizing the issues with reverse DNS:
	- requires population of large trees, instead of just one record.
	- does not work well for addresses behind a NAT, some more or less ugly
	  work around exists.	

	- Alain.

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Thu, 23 Dec 2004 08:52:13 +0100

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" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 22, 2004 8:34 PM
Subject: [v6tc] Tunnel endpoint discovery summary/tradeoffs

> revision of draft-palet-v6ops-tun-auto-disc.

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