Subject: Re: Stupid NAT tricks and how to stop them.

From: [email-masked] (Noel Chiappa)
Date: Tue, 28 Mar 2006 16:12:24 -0500 (EST)

> From: Keith Moore <[email-masked]>

    > what I mean is that a locator that means the same thing (refers to the
    > same destination) no matter where you are in the net, is a lot easier
    > to deal with than a locator with a meaning that changes (refers to
    > different destinations) depending on where you are in the net.

Oh, I absolutely, completely, totally agree with you on that one!

Names which look like they are global, but sometimes aren't, are just asking
for trouble. This is doubly true when they don't inherently i) identify when
they aren't, and ii) include identification of the binding environment in
which they are valid, when they aren't.

The complexity and potential confusion inevitably associated with such names
means there must be a very good reason for using them in a system design -
and offhand, I can't think of a good enough reason to do so. (Before someone
says something, NAT is different - they weren't designed in, there.)

    >>> locators are a lot easier to deal with if they're location-independent

    >> Huh? Did you mean "identifiers are a lot easier to deal with if they're
    >> location-independent"?

    > I really was talking about locators, not identifiers.

Now that I understand what you actually meant, I'm not freaked out! However,
you phrased your point in a way that almost guaranteed confusion!

You didn't mean "locators are a lot easier to deal with if the name has
nothing to do with where the thing it names is", you meant "locators are a
lot easier to deal with if their meaning (i.e. the thing they are bound to)
is the same no matter where you are when you evaluate them".

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Scott W Brim <[email-masked]>
Date: Wed, 29 Mar 2006 09:04:11 -0500

On Tue, Mar 28, 2006 04:12:24PM -0500, Noel Chiappa allegedly wrote:
>     >> Huh? Did you mean "identifiers are a lot easier to deal with
>     >> if they're location-independent"?
> 
> Now that I understand what you actually meant, I'm not freaked out!
> However, you phrased your point in a way that almost guaranteed
> confusion!
> 
> You didn't mean "locators are a lot easier to deal with if the name
> has nothing to do with where the thing it names is", you meant
> "locators are a lot easier to deal with if their meaning (i.e. the
> thing they are bound to) is the same no matter where you are when
> you evaluate them".

This is a problem for PIP-like schemes and mobility.  At any point in
the network, the locator to use to reach a particular target is
unique.  However, the locator to use to reach a particular target is
different at every point.  That would be okay except that when *I*
move, the way I address a target changes.  That's more of a problem
than having to adjust as my target moves.

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Mar 2006 09:17:34 -0500

> move, the way I address a target changes. 

well, no.  it would be okay if the only apps you needed to run were 
two-party apps.  in other words, it's not just users and hosts that need 
addresses to be the same from everywhere in the network - apps need 
stable addressing so that a process on host A can say to a process on 
host B, "contact this process on host C at address X and port Y"

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Mar 2006 16:23:28 +0200

On 29-mrt-2006, at 16:17, Keith Moore wrote:

> it would be okay if the only apps you needed to run were two-party  
> apps.  in other words, it's not just users and hosts that need  
> stable addressing so that a process on host A can say to a process  
> on host B, "contact this process on host C at address X and port Y"

Isn't this the kind of stuff the DNS was invented for?

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Mar 2006 09:43:34 -0500

> Isn't this the kind of stuff the DNS was invented for?

not really.  and even to the extent DNS was invented for this, it 
doesn't work well in practice.

- DNS is often out of sync with reality
- DNS is slow and unreliable.  DNS servers and the links to them do not 
share fate with the hosts whose RRs they serve.  DNS lookup delay is 
often considerably longer than the RTT to the host.
- many networks use other ways of doing name to address mapping for 
local hosts.
- there's no good way for hosts to know their own DNS names
- more generally, there's no good way for a host or an app to know what 
a DNS name means.  a DNS name is not irrevocably bound to a particular 
host for all time, but rather, associates some role or service name with 
a particular address.  a single host may support more than one such role 
or service at any particular time, but the set of roles or services 
supported on a host will change over time.
- furthermore a single role or service with a single DNS name might be 
supported on multiple hosts, and DNS be used to specify which hosts are 
providing that particular service.  this might be sufficient on an 
initial connection when any one of those hosts will do; but this is not 
sufficient when an app needs to know how to contact a process on a 
particular one of those hosts.

IMHO, DNS is best used as a sort of bootstrapping mechanism - a way for 
an app to get an initial contact point for some service.  After that 
initial contact is made, DNS is contraindicated.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Mar 2006 18:10:51 +0200

On 29-mrt-2006, at 16:43, Keith Moore wrote:

>>> it would be okay if the only apps you needed to run were two- 
>>> party apps.  in other words, it's not just users and hosts that  
>>> need addresses to be the same from everywhere in the network -  
>>> apps need stable addressing so that a process on host A can say  
>>> to a process on host B, "contact this process on host C at  
>>> address X and port Y"

> doesn't work well in practice.

Since when is that any kind of argument? The real questions are  
whether it CAN work well for this and whether there's something else  
that can do it better/easier.

> - DNS is often out of sync with reality

Dynamic DNS updates are your friend.

> - DNS is slow and unreliable.

It doesn't have to be, running a decent DNS service isn't rocket  
science.

> - many networks use other ways of doing name to address mapping for  

Not sure what you mean here.

> - there's no good way for hosts to know their own DNS names

Again, dynamic DNS updates. When IPv6 materializes where it's  
impossible to pre-populate the reverse tree and systems generate  
their own addresses, traditional DNS management will be out the  
window anyway.

> - more generally, there's no good way for a host or an app to know  
> what a DNS name means.

This one can be problematic but it's not a fundamental problem but  
rather a local management problem: apps should be able to obtain the  
local hostname that they can use for referral purposes. This isn't  
necessarily the same hostname that you'd get from a reverse lookup.

> IMHO, DNS is best used as a sort of bootstrapping mechanism - a way  
> for an app to get an initial contact point for some service.  After  
> that initial contact is made, DNS is contraindicated.

I wouldn't have a problem with that except that people somehow think  
that IP addresses DO fulfill all the requirements for being stable  
references. In traditional IPv4 they did to a large degree, but then  
NAT came along. With IPv6 a single host routinely has multiple  
addresses (of more than one scope), and with MIP and shim those  
addresses change from time to time. IP addresses are what get the  
packets from point A to point B. That's hard enough. Stable identity  
needs to happen at a higher level, and rejecting DNS names for this  
because of a few simple operational difficulties is a bad idea.

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Mar 2006 11:34:57 -0500

>>>> it would be okay if the only apps you needed to run were
>>>> two-party apps.  in other words, it's not just users and hosts
>>>> that need addresses to be the same from everywhere in the
>>>> network - apps need stable addressing so that a process on host
>>>> A can say to a process on host B, "contact this process on host
>>>> C at address X and port Y"
> 

 From an app developer's point-of-view, DDNS is worthless.  DDNS is far
from universally implemented, and when it is implemented, it's often
implemented badly.  DDNS can actually makes DNS a less reliable source 
of information about the host.

> It doesn't have to be, running a decent DNS service isn't rocket

Sometimes DNS is slow and unreliable because of poor server 
administration; sometimes it's slow and unreliable for other reasons. 
The very design of DNS is starting to look like an anachronism.

> Not sure what you mean here.

Let me put it another way - lots of hosts that need to participate in 
distributed apps aren't listed in public DNS.

> Again, dynamic DNS updates.

Doesn't solve the problem, especially when DDNS is done by some DHCP 
server rather than the host itself.

>  local hostname that they can use for referral purposes.

There's no standard way to do this - and the right name can vary from
one app to another on the same host.

>>  for an app to get an initial contact point for some service.
>> After that initial contact is made, DNS is contraindicated.
> 
> references.

Using DNS names as identifiers for referrals has problems.

Using IP addresses as identifiers for referrals has a different set of
problems.  But IP addresses are a lot closer than DNS names.

> In traditional IPv4 they did to a large degree, but then NAT came
> along. With IPv6 a single host routinely has multiple addresses (of 
> more than one scope), and with MIP and shim those addresses change
> from time to time. IP addresses are what get the packets from point A
> to point B. That's hard enough. Stable identity needs to happen at a
> higher level, and rejecting DNS names for this because of a few
> simple operational difficulties is a bad idea.

I wasn't talking about stable references - I was talking about 
references that are valid, for a short time, from anywhere
in the network.  Stable references are a different problem.
But even in that case, it's not clear how to fix DNS to be reliable. 
Protocol quality issues aside, there's not anything like a consensus on 
how DNS should be used.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Mar 2006 19:28:25 +0200

> implemented badly.  DDNS can actually makes DNS a less reliable  
> source of information about the host.

In network operations you always see that stuff that isn't really  
used is a big mess, because nobody cares to set it up correctly in  
the first place and/or maintain it after that. Since current peer to  
peer applications (the applications that use referrals) don't bother  
with the DNS and for non-servers its only other purpose is looking  
pretty, it's no surprise that DNS info isn't very good. But there is  
no fundamental reason why it can't be set up correctly and be kept in  
reasonable sync if people care to do so. DDNS is a great tool for  
that, and as I wrote in my previous message, almost a requirement  
with IPv6, but there are other ways to do it as well.

> administration; sometimes it's slow and unreliable for other  
> reasons. The very design of DNS is starting to look like an  
> anachronism.

If it's good enough for the web and email, why wouldn't it be good  
enough for p2p? (Which in itself is often very unreliable.)

> Let me put it another way - lots of hosts that need to participate  
> in distributed apps aren't listed in public DNS.

Because there is little reason for them to be. But even if that's  
something that continues to be so, it would still be better to use  
the DNS when available and use the address otherwise, rather than  
ignore the DNS completely.

> problems.  But IP addresses are a lot closer than DNS names.

With the difference that the DNS is the control plane where you have  
time to think about stuff, while IP is the data plane where you need  
to perform millions of lookups per second.

>> Stable identity needs to happen at a

> I wasn't talking about stable references

I wasn't talking about long-term stable either, just stable enough to  
make referrals work.

> But even in that case, it's not clear how to fix DNS to be  
> reliable. Protocol quality issues aside, there's not anything like  
> a consensus on how DNS should be used.

If we can agree which problem should be solved where, then consensus  
on the details becomes a lot easier. What I'm saying is that the IP  
address wont be an identifier stable enough to handle referrals in  
the future, so any protocols that make this assumption won't work  
very well.

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Mar 2006 13:03:11 -0500

> In network operations you always see that stuff that isn't really used 
> is a big mess, because nobody cares to set it up correctly in the first 
> place and/or maintain it after that. Since current peer to peer 
> applications (the applications that use referrals) don't bother with the 
> DNS and for non-servers its only other purpose is looking pretty, it's 
> no surprise that DNS info isn't very good. 

Of course a big part of the reason that distributed apps (not just p2p 
apps) don't consistently use DNS is that it doesn't work well.  But it's 
not quite a chicken and egg problem.  DNS cannot really work well for 
referrals.  Core design assumptions in DNS no longer apply.

> enough for p2p? (Which in itself is often very unreliable.)

I'd argue that DNS is NOT good enough for the web, and maybe not good 
enough for email.  When you click on a link and it takes seconds before 
the page even starts loading, that's probably DNS.  Email is less delay 
sensitive, but when you send mail and it bounces because the MX records 
were out of sync with reality, DNS is implicated there also.

Some p2p apps are unreliable because they are trying to layer over a 
network that imposes arbitrary restrictions on its use (unlike the IP 
design that assumes best effort) and on top of hosts that appear and 
disappear at a whim.  Even then, they sometimes work better than 
client-server apps that try to serve the same purpose.

> Because there is little reason for them to be.

But by expecting distributed apps to use DNS, you would be imposing the 
operational constraint that all of those hosts be listed in DNS.

> But even if that's something that continues to be so, it would still be better to use the 
> DNS when available and use the address otherwise, rather than ignore the 
> DNS completely.

adding complexity that makes your app less relable is usually not a good 
way to go.

> time to think about stuff, while IP is the data plane where you need to 
> perform millions of lookups per second.

no.  DNS is just an app that lets other apps find out certain kinds of 
information about certain resources on the network.  It's nowhere nearly 
flexible enough to be a control plane.

>> Protocol quality issues aside, there's not anything like a consensus 
>> on how DNS should be used.
> 
> If we can agree which problem should be solved where, then consensus on 
> the details becomes a lot easier. What I'm saying is that the IP address 
> wont be an identifier stable enough to handle referrals in the future, 
> so any protocols that make this assumption won't work very well.

What I'm saying is that if IP addresses won't be stable enough for 
referrals in distributed apps, they won't be stable enough for referrals 
in DNS either.

Keith

---

From: Francois Menard <[email-masked]>
Date: Wed, 29 Mar 2006 13:25:56 -0500 (EST)

Are you saying that ENUM is a dead end?

F.

--
[email-masked]
819 692 1383

On Wed, 29 Mar 2006, Keith Moore wrote:

>>> implemented badly.  DDNS can actually makes DNS a less reliable source of 
>>> information about the host.
>> 
>> In network operations you always see that stuff that isn't really used is a 
>> big mess, because nobody cares to set it up correctly in the first place 
>> and/or maintain it after that. Since current peer to peer applications (the 
>> applications that use referrals) don't bother with the DNS and for 
>> non-servers its only other purpose is looking pretty, it's no surprise that 
>> DNS info isn't very good. 
>
> Of course a big part of the reason that distributed apps (not just p2p apps) 
> don't consistently use DNS is that it doesn't work well.  But it's not quite 
> a chicken and egg problem.  DNS cannot really work well for referrals.  Core 
> design assumptions in DNS no longer apply.
>
>>> administration; sometimes it's slow and unreliable for other reasons. The 
>>> very design of DNS is starting to look like an anachronism.
>> 
>> If it's good enough for the web and email, why wouldn't it be good enough 
>> for p2p? (Which in itself is often very unreliable.)
>
> I'd argue that DNS is NOT good enough for the web, and maybe not good enough 
> for email.  When you click on a link and it takes seconds before the page 
> even starts loading, that's probably DNS.  Email is less delay sensitive, but 
> when you send mail and it bounces because the MX records were out of sync 
> with reality, DNS is implicated there also.
>
> Some p2p apps are unreliable because they are trying to layer over a network 
> that imposes arbitrary restrictions on its use (unlike the IP design that 
> assumes best effort) and on top of hosts that appear and disappear at a whim. 
> Even then, they sometimes work better than client-server apps that try to 
> serve the same purpose.
>
>> But even if that's something that continues to be so, it would still be 
>> better to use the DNS when available and use the address otherwise, rather 
>> than ignore the DNS completely.
>
> adding complexity that makes your app less relable is usually not a good way 
> to go.
>
>> With the difference that the DNS is the control plane where you have time 
>> to think about stuff, while IP is the data plane where you need to perform 
>> millions of lookups per second.
>
>> If we can agree which problem should be solved where, then consensus on the 
>> details becomes a lot easier. What I'm saying is that the IP address wont 
>> be an identifier stable enough to handle referrals in the future, so any 
>> protocols that make this assumption won't work very well.
>
> What I'm saying is that if IP addresses won't be stable enough for referrals 
> in distributed apps, they won't be stable enough for referrals in DNS either.
>
> Keith
>
>

---

From: Peter Dambier <[email-masked]>
Date: Wed, 29 Mar 2006 21:46:22 +0200

> Are you saying that ENUM is a dead end?

ENUM is a dead born child.

ENUM is supposed to be good for VoIP. Well, I do have VoIP but my VoIP
does work allthough ENUM does not. My router could use ENUM - but which
one should I ask, "e164.arpa" or "e164.org"?

Neither of them does know any of my phone numbers.

<cynikal>
I am told I could buy the domain that corresponds to one of my phone
numbers but I would have to bring in a birth certificate of both me
and my landlord to proove legal ownership of that phone number. The
gouvernement of germany would hold an election about the matter and
if everything was allright I might put my phone number on my tombstone
finally.
</cynikal>

In the meantime you can call me on

If your VoIP provider talks to sipgate.de

+49(6252)750-308

If your phone allows to do that

sip:[email-masked]

or via no-ip.com dynamic DNS

sip:[email-masked]

Please allow for my local time. It is Québéc + 6 hours
or Paris time :)

<cynikal>
I guess, right now ENUM could not do that no-ip.com trick.
I would have to ask parliament every time my ip changed,
to update my A record.
</cynikal>

Hope I was not too cynical.

Kind regards
Peter et Karine

-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Mar 2006 15:16:14 -0500

> Are you saying that ENUM is a dead end?

interesting question.  probably not, as long as it's only used for a few 
services that are implemented by large well-managed service providers.

---

From: "Francois D. Menard" <[email-masked]>
Date: Wed, 29 Mar 2006 19:31:57 -0500

ENUM is not deadborn if it forced onto the ILECs as a replacement for SS7
for E.164 URIs.

F.

-----Original Message-----
From: Peter Dambier [mailto:[email-masked]] 
Sent: March 29, 2006 2:46 PM
Cc: IETF Discussion
Subject: Re: Why DNS sucks for referrals (was Re: Stupid NAT tricks and how
to stop them.)

<cynikal>

+49(6252)750-308

sip:[email-masked]

<cynikal>

Kind regards
Peter et Karine