[v6tc] Tunnel endpoint discovery summary/tradeoffs

[Pekka Savola <[e-mail]>]

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