[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] RE: [RAM] dns discover in map-and-encaps schemes



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.

On Mar 20, 2007, at 5:28 AM, Templin, Fred L wrote:

-----Original Message-----
From: Dino Farinacci [mailto:dino@cisco.com]
Sent: Tuesday, March 20, 2007 3:29 AM
To: Templin, Fred L
Cc: rrg; ram@iab.org
Subject: Re: [RAM] dns discover in map-and-encaps schemes

What happens when I type "ping <global-address>" on the source?

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.

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

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

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.

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.

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

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.

you *won't* be able to do is ping IPv6 addresses and connect
to IPv6 services that are deeply embedded in distant sites,

A problem.

See above; the situation is no different than for the Internet
today. Again, IPvLX augments the existing architecture; it does
not compromise it.

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:

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


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