[RRG] dns discover in map-and-encaps schemes

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

At the RRG meeting on Saturday, there may have been some confusion in
what was meant by DNS discovery in map-and-encaps schemes. For DNS
discovery, only locators are ever kept in the global DNS; identifiers
are *not* kept in the global DNS but rather in a site-specific name
resolution service for the site. From (IPvLX, Section 4):

"4.  DNS Assumptions

   The global DNS [RFC1035] today maintains resource records for Fully
   Qualified Domain Names (FQDNs) with global IPv4 addresses for
   traditional Internet services, and by design anticipates that their
   FQDN-to-address mappings will change relatively infrequently.  IPvLX
   asks only that the global DNS also maintain resource records for
   IPvLX gateways to provide tunnel endpoint addresses - again, under
   the assumption that those FQDN-to-address mappings will change
   infrequently.

   IPvLX further assumes a DNS-like "site-local" name resolution service
   (e.g., [LLMNR]) that is separate from the global DNS and records the
   FQDN-to-IPv6-address mappings for IPv6 application endpoints within a
   site.  Unlike the global DNS, IPvLX assumes that the FQDN-to-IPv6-
   address mappings within the site local name service may change
   dynamically as IPv6 application endpoints come into existence, move
   to new locations and terminate."

This means that a source's address resolution request would trigger
a lookup in the global DNS for the locator(s) associated with the
destination's site, and a lookup for the destination's identifier
in the destination site's name service. The following algorithm is
used:

  1) source does DNS lookup for the FQDN "dest.example.com".
  2) source's DNS server is co-resident on the ingress tunnel router
     and performs a lookup in the global DNS for a well-known prefix
     appended to the FQDN suffix, e.g.: "egress.example.com".
  3) source's DNS server gets back locators for the egress tunnel
     router from the global DNS, then sends an IP-in-IP encapsulated
     RFC4620 Node Information Query asking the egress tunnel router
     to resolve the FQDN "dest.example.com".
  4) egress tunnel router returns identifers associated with
     "dest.example.com"; ingress tunnel router caches the resolution
     and returns the resolution to the source as response to the
     "real" DNS query.

(The above algorithm omits the details of the tunnel setup btw the
ingress and egress tunnel routers, but it should be clear that the
tunnel is set up in parallel with the FQDN resolution.)

Note that (IPvLX, Section 7) currently uses a different mechanism
than RFC4620 because 4630 was not available at the time of the
writing; I'll fix that. Note also that IPvLX fails to reference
RFC1955; I'll fix that too.

Fred
fred.l.templin@boeing.com

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg