Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: Leonid Yegoshin <[email-masked]>
Date: Tue, 25 Apr 2000 10:52:27 -0700

>From: Keith Moore <[email-masked]>
>
>> >even if you do this the end system identifier needs to be globally
>> >scoped, and you need to be able to use the end system identifier
>> >from anywhere in the net, as a means to reach that end system.
>>
>>   DNS is a bright and successfull example of such deal.
>
>actually, DNS is slow, unreliable, and often out of sync with reality.
>
>DNS reverse lookup tables (PTR) are not as well maintained as forward
>lookup tables (A) so they're even less reliable.
>
  (Bill Manning has another mind here - read it, please)

>hosts often don't know their own DNS names, so they wouldn't know
>their connection endpoint names either.
>
>DNS names are often ambiguous - because a single DNS name corresponds
>to multiple hosts (all implementing the same service) or because a
>single host supports multiple DNS domains (a different name for each
>service) or both.
>
   Yes, it is a reason why we can't use today domain names as system ID.
But it means that we should shift consideration to appropriate level -
- IP addresses. The second level of indirection arises but it is not
bad as long as we do not decrease a setup speed.

>the binding between a DNS name and an address is not the same thing
>as the binding between an address and a connection endpoint.  the
>two have different purposes and different lifetimes.
>
  I agree here.

>when people say "DNS can do the job" they may be saying different
>things, e.g.
>(a) they are thinking in terms of using existing DNS servers,
>(b) they are thinking in terms of using the DNS protocol, having
>translation occur at the boundaries between routing goop realms
>(similar to NAT's DNS ALG), or
>(c) they are thinking in terms of a DNS-like system, but not DNS
>
   I speak about (c). Routing addresses may be handled by providers
but not end-user. It should be

   (1) more accurate
   (2) more fast
   (3) independent in terms "rule of game" (may be chanded later
       without rewriting all)

>with separate servers (whether they are existing DNS servers or not)
>there is the problem of keeping the servers updated as to the
>current condition of the network.
>
>with DNS at translation boundaraies there is the problem of
>"call setup overhead" (having queries propagate through
>multiple layers of translation until they reach their destination
>network) also in this case DNS becomes a routing protocol of
>sorts, since the thing you advertise from one realm to another
>becomes a DNS suffix rather than than an address prefix.
>it's not at all clear that this scales.
>
  Keith, it depends from design. I can propose
 (1) caching,
 (2) implicit router resolution on each DNS A? query (each TCP setup
     precedes DNS A? query or using cached values) - "router DNS" may track
     each DNS query/response and append routing prefix to response.
     In this case there isn't any time lag... at least up to TTL expiration.
 (3) Separate network datagram service addresses from connection-oriented.
     We have two real network datagram services now - DNS and may be NTP
     (Voice RTP traffic or like UDP is in real a connection-oriented srvs)

But I don't afraid "call setup overhead" (see previous) because I afraid
only call setup speed decrease and support issues. As long as call setup
speed is not changed and support simple I like it.

>in either case having to do a DNS-like query before you can transmit
>is slow compared to just sending a packet to an IP address.
>
   We can implement technics which do both in the same time.
We do not need to replicate DNS again. We should admit that DNS is
network service in conrast with end-customer srvs and handle it different.
It means that different service rules and may be different set of addresses
may be used for this. The same is in BGP - there is a practice to hide
inter-router addresses of provider backbone, for exam to increase security
and give additional flexibility of backbone configuration.

>Keith
>
>p.s. if there's ever going to be a split between endpoint names and
>routing goop, I'm convinced that endpoint names have to be usable
>by themselves

  Yes.

>              (perhaps with some speed penalty), that the
>mapping between endpoint names and routing goop needs to be maintained
>by the routing infrastructure rather than in some separate database,

  Yes ! Yes !

>and that the lookup needs to be able to be done implicitly (as a side
>effect of sending packets without routing goop to their destination)
>rather than explicitly.  I think such a separation might be a good idea,
>because our current means of propagating reachability information
>and computing routes does have limitations.  but I don't see any need
>to change the packet format seen by hosts (from IPv6), or any need to
>change end hosts at all, in order to do this.

   Keith, sorry, didn't read this p.s. before I wrote answer on main
mail body. You absolutely understand me, thank you.

			       - Leonid Yegoshin, LY22