Subject: Fwd: Application protocols and Address Translation

From: Patrik Fältström <[email-masked]>
Date: Wed, 5 Mar 2003 09:33:53 +0100

Do you remember the discussion which started with this message?

We in apps area really need to work on this, and remember that the 
audience for a potential paper (I think Keith has a strawman proposal, 
is that right Keith?) are _NON_APPS_PEOPLE_.

Much of the discussion that took place after this mail of mine I find 
was within apps, only relevant for people already knowing how an 
application works. I.e. "details".

It would be good if I can get some volunteers writing a document which 
can help work going on in other working groups.

     paf

Begin forwarded message:

> From: Patrik Fältström <[email-masked]>
> Date: sön dec 1, 2002  14:01:22 Europe/Stockholm
> To: [email-masked]
> Subject: Application protocols and Address Translation
>
> You might be aware of the discussions in the IPv6 working groups in 
> the IETF. They talk over and over again about (a) transition from IPv4 
> to IPv6 (b) addressing mechanisms in IPv6.
>
> It is time Applications Area give some major input into that 
> discussion.
>
> Several of you are working very hard within these working groups, and 
> I thank you for your hard work. I do though think we need some 
> coordinated action.
>
> From my point of view, address translation in the IP layer is a VERY 
> BAD THING from an application perspective. It means two end nodes can 
> not open direct connection to each other. This is something very 
> different from firewalls which are there to block some traffic due to 
> some policy someone want to apply on the path.
>
> But, if the policy on a path is such that certain traffic is ok, then 
> that traffic should be able to pass through using globally unique IP 
> addresses.
>
> Yes, in IPv4 land we have NAT all over the place. When doing IPv4 and 
> IPv6, we will have NAT-like things all over the place.
>
> My number one argument for moving to IPv6 is that we have enough 
> addresses to have unique addresses on every device, so NAT will not be 
> needed in v6 only land.
>
> In the addressing architecture there is something called "Site Local", 
> which one can claim (in a naive way) that they are like RFC 1918 
> addresses. "Not to be used on the global Internet". The arguments for 
> using those is that sometime one is not connected to the global 
> Internet. My problem is that that was the fact with RFC 1918 addresses 
> as well, but see what we have today! People connect these networks, 
> but apply a NAT box between the RFC 1918 network and the Internet.
>
> What I want to see is that the wording and design of the Site Local 
> addressing should be such that NAT boxes is a bad thing. Even better, 
> I want an addressing scheme which makes "RFC-1918-like" addresses 
> non-existing in IPv6.
>
>
> Now, yes, I am one of the two Area Directors for Applications Area. 
> And I have this very strong view.
>
> I now hand over the work to you. I need to know if I have a different 
> view than "applications area".
>
> What I want to have is a common view of the Applications people in the 
> IETF on these "RFC 1918-like" addressing schemes.
>
> Are they ok?
> When and why?
> What can they be used for?
> What is they not good for?
>
> I would like to have an I-D talking about these issues, from an 
> application layer perspective.
>
> Any takers on being the editor on a document like this?
>
>      Patrik
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Mar 2003 07:17:23 -0500

> is that right Keith?) 

yep, though it's been awhile since I worked on it.
so much brain-damage, so little time...

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 5 Mar 2003 20:40:43 +0100

On onsdag, mar 5, 2003, at 17:57 Europe/Stockholm, Leif Johansson wrote:

> So is it a paper listing types of applications that break and why 
> those "design patterns" are
> important and/or difficult to avoid?

No, the other way around.

Rather "this is how you should build a network so (even sip/ftp etc) 
applications 'just work'".

Something that explain Internet from application perspective is 
peer-peer, and not client-server. I.e. any node might open a connection 
to any other node. We can not from application perspective only have 
applications which rely on "servers" as rendezvous points. (And in 
cases like SIP, having that server doesn't help the final RTP which is 
used for the interesting communication.)

Not design document for applications. A design document for network 
creators.

    paf

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Mar 2003 16:42:06 -0500

> peer-peer, and not client-server. I.e. any node might open a
> connection to any other node. We can not from application perspective
> only have applications which rely on "servers" as rendezvous points.
> (And in cases like SIP, having that server doesn't help the final RTP
> which is used for the interesting communication.)
> 

The trick to doing this is to give 'network creators' examples of
applications that they've heard of, and would consider valuable,
that break when NATs, firewalls, scoped addresses, etc. are imposed on
the networks they run on.  In my experience people just don't believe
the arguments that this breaks things because the web and email work
just fine for them, and they hardly ever try to run anything else.

Okay, that's a slight exaggeration.  But for any app to be widely
deployed it tends to need to work with NAT.  Which means that apps that
inherently can't be made to work with NAT are unlikely to get wide
deployment.  Which means that most 'network creators' have never heard
of those apps, so they don't understand that they're missing valuable
functionality.

I know of several apps that can't be made to work well over NAT, and I
can explain why.   But most network designers have never heard of those
apps, and they don't believe that the same problems I'm familiar with
are shared by other apps that do very different things.

Keith

p.s. someone really needs to whack the zeroconf WG with a clue-by-four -
otherwise they're essentially going to impose NAT-like restrictions on
every IP network in existence.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 6 Mar 2003 10:02:51 +0100

> are shared by other apps that do very different things.

So, will you start writing this down? Leif, are you helping? You work 
with SIP a lot, so I am sure you have some real world experience.

We _need_ this document.

As I said, _we_ know they exist, but saying that on this mailing list 
will not help.

It might even help the zeroconf wg doing the right thing.

What we mostly need this for is the site local addressing story in IPv6 
though...

    paf

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Mar 2003 07:46:16 -0500

On Thu, 6 Mar 2003 10:02:51 +0100

> with SIP a lot, so I am sure you have some real world experience.

I will write this down for the apps I know about.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Wed, 05 Mar 2003 17:57:13 +0100

> application works. I.e. "details".
So is it a paper listing types of applications that break and why those 
"design patterns" are
important and/or difficult to avoid?

---

From: Leif Johansson <[email-masked]>
Date: Wed, 05 Mar 2003 17:54:39 +0100

>so much brain-damage, so little time...
I'd like to read it...

---

From: Leif Johansson <[email-masked]>
Date: Wed, 05 Mar 2003 20:57:40 +0100

> Not design document for applications. A design document for network 

Right. This is what I tried to express: explain to netheads why 
applications do what
they do and what the network must support. We probably need to explain 
why you
"can't just redesign your applications" to a client/server paradigm.

          MVH leifj

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 7 Mar 2003 05:21:11 +0100

On onsdag, mar 5, 2003, at 17:57 Europe/Stockholm, Leif Johansson wrote:

>> audience for a potential paper (I think Keith has a strawman 
>> proposal, is that right Keith?) are _NON_APPS_PEOPLE_.
>>

Yes.

For example, a document describing for example SMTP, HTTP, FTP and SIP 
opening a set of RTP. That doing these three things are hard with NAT.

Or something like that.

The conclusion should be "Only use global addresses, and no NAT for 
things connected to the Internet -- only a few very simple 
client/server applications like SMTP and HTTP work in reality through 
NAT, so it is not worth it. NAT is _not_ a firewall (security device) 
from an application perspective.".

Or whatever...

   paf

---

From: Keith Moore <[email-masked]>
Date: Fri, 7 Mar 2003 09:02:54 -0500

> Sure I'll help. Keith: do we continue on your text or what? That would 
> seem to be the easiest solution. Send me what you have and I will continue.
> Maybe we can sit down for a couple of minutes in SFO if you will be there...

I should be in SFO.  Let me gather up what I have.  I've made several attempts
to describe this problem, ranging from a document on 'how to write distributed
applications that tolerate NATs'  (which illustrates just how much trouble it
is and how much extra infrastructure you need) to another document called
something like 'scoped addresses considered harmful'.

Maybe we can sit down in SFO and try to outline a document more on the lines
of what Patrik is asking for, and hopefully we can reuse pieces that are
already written.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Fri, 07 Mar 2003 14:40:15 +0100

Patrik Fältström wrote:

> What we mostly need this for is the site local addressing story in 
> IPv6 though...
>
>    paf

Sure I'll help. Keith: do we continue on your text or what? That would 
seem to
be the easiest solution. Send me what you have and I will continue. Maybe we
can sit down for a couple of minutes in SFO if you will be there...

---

From: Leif Johansson <[email-masked]>
Date: Fri, 07 Mar 2003 15:30:24 +0100

>something like 'scoped addresses considered harmful'.
I started thinking in terms of good design patterns that break. For 
instance "separated
signaling and transport" (sip, ftp), "unsolicited notifications" (afs). 
Explain why those
patterns are important and why alternative designs lead to increased 
complexity and
loss of functionality.

>of what Patrik is asking for, and hopefully we can reuse pieces that are
That sounds like a plan!