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

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Mar 2007 07:03:13 -0700

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
[email-masked]

--
to unsubscribe send a message to [email-masked] 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

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Mar 2007 17:22:38 -0700

>      and returns the resolution to the source as response to the

What happens when I type "ping <global-address>" on the source? What  
if DNS is down, do I lose global connectivity? What if one of the two  
domain names don't exist in DNS? What if network administrators are  
totally against making routers DNS servers? What if your ITR is a low- 
end router where it can store both the DNS cache and mapping database?

What I am trying to say is, some things need to go into the network  
and some things should just stay out of the network.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Mar 2007 17:29:20 -0700

> What happens when I type "ping <global-address>" on the source?  
> What if DNS is down, do I lose global connectivity? What if one of  
> the two domain names don't exist in DNS? What if network  
> administrators are totally against making routers DNS servers? What  
> if your ITR is a low-end router where it can store both the DNS  
> cache and mapping database?

Typo, ... if your ITR is a low-end router where it cannot store ...".

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 01:51:30 -0700

Dino, 

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 5:23 PM
> To: Templin, Fred L
> Cc: rrg; [email-masked]
> Subject: Re: [RAM] dns discover in map-and-encaps schemes
> 

Not quite certain what you mean; do you mean ping the source IP
address from the destination IP address after the source has done
the DNS mapping for the destination. The intent is the egress tunnel
router nearest the destination will have cached the source IP to
locator mapping and so the ping will succeed.

> What if DNS is down, do I lose global connectivity?

What happens if the DNS is down in today's Internet? You can
ping any global IPv4 address and connect to any global IPv4
services by specifying an IP address instead of a FQDN, and
the very same will be true for this scheme. The only thing
you *won't* be able to do is ping IPv6 addresses and connect
to IPv6 services that are deeply embedded in distant sites,
but that is the very same condition as for devices that are
deeply embedded behind NATs in todays Internet. Bottom line
is the situation for loss of global DNS is no different from
and no worse than for the existing condition of today's Internet.

> What if one of the two domain names don't exist in DNS?

The idea is that the global DNS will only ever contain FQDNs
for IPv4-based services; not for any IPv6-based services. So,
there will be only one FQDN in the DNS ("egress.example.com"),
and the FQDN "peer.example.com" will be in the site-specific
name service for the peer's site. The "egress.example.com"
gives the ingress tunnel router unambiguous indication that
the egress tunnel router is participating in the scheme, so
the absense of this FQDN is a clear indication that the peer's
site does *not* implement the scheme. This only means that the
egress tunnel router is responsible for ensuring that its FQDN
is well-maintained in the global DNS. 

> What if network administrators are totally against making routers DNS
> servers?

I want that the function be moved closer to the end devices, and
not in core routers - but, see more below:

> What if your ITR is a low-end router where it can (not) store both the
> DNS cache and mapping database?

The router doesn't need to store the full DNS cache, because the
function it is performing is not exactly that of a full DNS server.
It is really a "two-faced" DNS server that can resolve the FQDNs
for end nodes that are within the same site, but acts as a DNS
resolver for FQDNs for end nodes that reside within different
sites. So, it does not keep a database of global FQDN-to-resource
record mappings - it resolves them from another DNS server just
the same as an ordinary DNS resolver would do.
 
> and some things should just stay out of the network.

I'm all for pushing the function closer to the end devices, and
preferrably on the end devices themselves. That would be consistent
with RFC1955.

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 03:28:49 -0700

> locator mapping and so the ping will succeed.

No, it was a simple statement about what if a host uses addresses to  
send packets and not DNS names.

> What happens if the DNS is down in today's Internet? You can

I can still "[ping,traceroute] <global-address>". I can still send  
packets, I can still type in "http://192.168.0.1/" in my browser.

> the very same will be true for this scheme. The only thing

How do you get locators when the DNS is down?

> to IPv6 services that are deeply embedded in distant sites,

A problem.

> not in core routers - but, see more below:

That still won't make network administrators happier.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 05:28:18 -0700

> Sent: Tuesday, March 20, 2007 3:29 AM
> To: Templin, Fred L
> Cc: rrg; [email-masked]

Everything that works today for IPv4 would work tomorrow for IPvLX
for IPvLX nodes that are dual-stacked, which I anticipate would be
the normal case. The only nodes that would not be able to do a ping
to a global address  when the DNS is down would be IPv6-only nodes,
but IMHO those would only occur on very small devices on the very
extreme edges of the network.

> How do you get locators when the DNS is down?

When the DNS is down, you will still be able to use IPv4 in the
same way we use IPv4 in the Internet today. The draft doesn't
explicity say this, but the preferred access method is IPv4,
with IPv6 used only for nodes that do not have a FQDN and IPv4
addresses in the global DNS. IPvLX augments the current
architecture, it does not compromise it.
 
> > to IPv6 services that are deeply embedded in distant sites,

See above; the situation is no different than for the Internet
today. Again, IPvLX augments the existing architecture; it does
not compromise it.
 
> That still won't make network administrators happier.

Howso? Why should the network administrator care if the end
node is simply behaving as an ordinary DNS resolver from an
outward appearance. That the end node is behaving as a
two-faced DNS server on behalf of its downstream-attached
devices (and internal virtual hosts) is no business of the
network administrator's.

Fred

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 20 Mar 2007 06:29:31 -0700

this is not a reply to your msg but a question of where you'd like to  
direct the discussion to: I am very sure I'm not the only on both  
lists and found double-copies on every msg confusing (given how far  
I'm behind, this does not help)

I strongly discourage any future posts going to both ram and rrg,  
given the potential high overlap in membership between the two. One  
can easily send a note to list 1 telling others that he has posted an  
important thing to list 2.

Fred you started this double-list posting, which list would you like  
to continue on?
Personally it seems to me mostly belonging to RAM, though you may  
feel otherwise.

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 20 Mar 2007 10:31:58 -0400 (EDT)

> From: Russ White <[email-masked]>

    > What happens if I "ping <id>," and the LISP server is down?

Umm, pretty much the same thing that happens when you click on a URL and the
DNS server(s) for that domain are down/unreachable... :-) But to be serious
about it:

    > Is it okay for the network to fail when some set of network reachable
    > servers, or some network accessible service, fails? ...
    > Consider the problem of reachability being predicated on a service.
    > This is a fundamental change in architecture

Here is a slightly extended design-philosophical soliloquy on this general
topic (and maybe some of this was already in your mind when you sent that
message out...):

It is certainly true that systems which i) don't modify the hosts at all and
ii) introduce a new location-namespace underneath the current internetwork
layer, thereby iii) turning the current internetwork "addresses" into names
which are basically purely identity, and therefore iv) require mapping into
location-names to be usable for forwarding traffic, are a significant
architectural change - and one with new failure modes.

I don't necessarily consider the extra complexity (and *necessarily*
consequent extra potential failure modes) to be necessarily bad. Abraham
Lincoln was once asked how long a man's legs should be; his reply was "long
enough to reach the ground". So too with complexity in large information
systems. You need as much as you need.

And you need more complexity as the system gets bigger. [Anyone who doubts
that this is a general law should consider, for example, the anatomy of a
single-celled organism versus your average mammal: the mammal has all sorts
of specialized sub-systems - e.g. the circulatory system, which has its own
specialized failure modes such as blockages caused by a variety of buildups -
which the smaller - and simpler - organism lacks. (And no matter which side
of the evolution/design split you fall on, you have to agree that something
pretty intense decided it *really needed* that extra complexity! :-)]

So the questions really are:

- Do we need this extra complexity (and necessarily consequent new failure
modes), and
- If so, how do we deal with the problems this extra complexity brings,
e.g. how to protect against those failure modes, how to make sure we
can debug/fix failures (i.e. operations/maintainence issues), etc.

If our goals are i) to not modify hosts, and ii) add another namespace -
both goals which I think are reasonable - then *necessarily*, something out
there is going to have to do mappings. So now the only question left is "how
to deal with the problems this inventably brings, such as new failure modes".

Now, that's a reasonably well-understood field. Systems designers have been
dealing with these issues for many decades now. Some of the tools we use
to do this are:

- a) Make sure we don't have any dependency loops (i.e. subsystem A depends
on subsystem B which depends on subsystem A)
- b) Make sure our debugging tools for debugging system Y (which depends on
X and below) only depend on X and below, and make sure we have direct
access to X and below, without going through Y
- c) In a distributed system, use replication to ensure availability

These are tools we already use - e.g. when you type IP addresses directly
into a tool, without using DNS, you're doing b); and DNS itself uses c) to
increase its robustness. And there are more techniques, I won't go into a
long spiel on them - the point is we know how to do this.

And while I'm in this general area, I'd like to rant a bit about people who
assume addresses, and routing (path-selection) mechanisms, are somehow
fundamentally different - more reliable, more trustworthy, more available,
more *special* - from every other mechanism (e.g. mapping services).

They aren't.

It kind of drives me batty when people assume raw IPvN-style addresses are
somehow fundamentally different from all other possible mechanisms, that they
have some ethereal quality which necessarily makes them more reliable, more
dependable, than all other mechanisms.

They aren't.

Path-selection and forwarding are also complex distributed system with all
sorts of failure modes. The people who designed them are fully aware of how
critical they are, and have used a lot of ingenuity, and in many cases some
pretty complex and heavy-weight mechanisms (try read the IS-IS or OSPF specs)
to make sure they *are* reliable and dependable. But they accepted that
complexity to make the *overall* operation one that one can rely on.

So, circling back to where we started, given a certain goal-set (not modify
hosts, and add another namespace) then something out there is going to have to
do mappings; and we'll just have to deal with the problems this inventably
brings: but I think we know how.

    > this brings up a fundamental point we need to consider in all cases of
    > locator/id split ...
    > ... reachability being predicated on a service ... one of the possible
    > negative side effects, of a locator/id split of any type.

If you get to change the hosts, you can avoid this problem in a number of
ways. One is to say that *all* DNS entries have to contain both location and
identity names, and the lookup returns them both, and they travel around
forever thereafter as a tuple (unless the binding is modified in some
suitably-secure way). Another is to keep the existing DNS (returns
location-name only), and pass identities in the connection-open packets in
each direction. Etc, etc...

	Noel

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 07:33:48 -0700

Hi Lixia, and thanks for the guidance on this. I certainly agree
with minimizing the clutter, and am happy to move to just one list.
I don't have a preference as to which one, so I defer to your
judgement and will use just one list from now on.

But, a procedural question: how can we decide which is the
appropriate list on a case-per-case basis? (I think we still
have all three of the ram, rrg, and architecture-discuss lists
to choose from?)

Thanks - Fred

> From: Lixia Zhang [mailto:[email-masked]] 
> Sent: Tuesday, March 20, 2007 6:30 AM
> To: Templin, Fred L
> Cc: Dino Farinacci; rrg; [email-masked]
> Subject: Re: [RRG] RE: [RAM] dns discover in map-and-encaps schemes
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 07:34:18 -0700

>> What if
>> DNS is down, do I lose global connectivity? What if one of the two
>> totally against making routers DNS servers? What if your ITR is a
>> low-end router where it can store both the DNS cache and mapping  
>> database?
>>
>> What I am trying to say is, some things need to go into the  
>> network and
>> some things should just stay out of the network.
>
> Don't these same questions/issues apply to the LISP 1.5/2.0/etc  
> schemes
> which follow LISP 1? Perhaps just replacing "DNS server" with  
> something
> else?

Exactly why I asked the questions.

> In fact, won't these questions apply to any real locator/id split
> system, in some form or another?

Yep.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 08:23:34 -0700

> architecture, it does not compromise it.

You told me why it would work. I want to know how. You didn't answer  
my question. So if a host sends a DNS query to the router (you have  
said the router is a DNS server), and the router then needs to  
resolve egress.example.com and can't, please tell me what happens.

You can't say just like IPv4 today because this doesn't happen in  
IPv4 today.

> outward appearance. That the end node is behaving as a

I didn't say they cared about that. They want to manage DNS servers  
in what has been traditionally known as "host systems", like one  
running FreeBSD, Linux, or Windows Server.

> devices (and internal virtual hosts) is no business of the

Right, give me a break. The network administrator manages this stuff  
and is responsible for making it work and keeping it working.

Dino

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 20 Mar 2007 10:19:38 -0700

> have all three of the ram, rrg, and architecture-discuss lists

let me try a paraphrase of Leslie's answer when this question was  
raised at RRG meeting last Saturday (I copied Leslie here in case I  
say it wrong):

RRG list should be used for messages related to RRG's efforts
   in developing a scalable routing&addressing architecture.
RAM list should be used for messages related to Internet routing and
   addressing that are out of RRG scope.
arch-d list should be used for all other architecture related issues.

Lixia