Subject: Re: IP network address assignments/allocations information?

From: Thomas Narten <[email-masked]>
Date: Wed, 01 Dec 1999 07:31:28 -0500

John,

> You are absolutely right.  Time should be spent developing "good
> algorithms" which is common "good architecture".  What NAT does is just
> another form of the same thing that X.25, ATM, and MPLS do with different
> identifiers.  It is not bad algorithm there nor bad architecture.

This is the second time you've said this, the first time I just
cringed.

> I would tend to agree.  As I have said elsewhere, NATs in and of themselves
> do nothing wrong.  They are doing things within the Internet/Network Layer
> that are perfectly legal.  (In essence, they are treating the network
> address in much the same way that X.25, ATM, and MPLS treat their
> addresses.)

I find this assertion to be amazing. It's perfectly legal for a device
to modify any field in the IP header if it so desires? Do you also
agree that it's legal to modify the IP ident field (and potentially
break fragmentation?) What about the length field, or flags field,
etc., etc.??

Also, NATs have to modify the TCP/UDP checksum, i.e., look inside the
upper layer protocol it is carrying and modify the payload. This is
also not "bad architecture"?

> The problem is that applications lacking an "application address
> space" are using the Network address space inappropriately.

IMO, this is a widespread oversimplification of the situation.

If you want to point fingers, TCP is also broken from the perspective
of NAT, because transport layer addresses are formed from both IP
addresses and port numbers. It's not just applications sending
addresses in payloads that "are broken", it's a key aspect of the
basic TCP (and UDP) design.

Sure, there are folks that say "fix TCP". But this is also naive.
There is a good reason why TCP is designed this way. Having transport
addresses be completely independent of the IP address in the IP header
requires having some way of mapping from one name space (e.g., the TCP
transport identifier of a service one wants to communicate with) to
the IP address (so that the TCP header can be put into an IP packet
and sent to the actual destination).

Although folks have talked about doing something like this for years,
it has not been done (i.e., where is a document showing how it can be
done?) and folks have argued endlessly about whether building such a
system is feasible or really solves the problem as opposed to just
creating a new (hard) problem elsewhere that then needs solving.
 
Thomas

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 01 Dec 1999 13:06:47 +0100

At 22:52 30.11.99 -0500, John Day wrote:
>At 18:12 -0500 11/30/99, Mark Atwood wrote:
> >John Day <[email-masked]> writes:
> >>
> >> Correct.  Lets get an application name space so we don't need to worry
> >> about it.
> >>
> >
> >Please gods below, not more ASN.1
>
>What a strange reaction!?  What does an arcane syntax notation have to do
>with Shoch's observation that there are 3 kinds of addresses:
>applications, hosts, and routes?  What have you been smoking?

For those who missed the previous round.....
at the time ASN.1, X.400 and X.500 were defined, ISO/ITU (mostly ISO) also 
defined the concept of an "application" to be (......) (that's about the 
right level of precision) that you could address by using an "application 
entity title" or similar entity.

Somehow this idea never turned into anything that real products use for 
real operations, but you sometimes stumble across the relics of the idea 
here and there.

Naming applications something different from host:port would be nice. But 
we haven't managed to do it yet.

                        Harald A

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 01 Dec 1999 13:06:47 +0100

Harald A

---

From: John Day <[email-masked]>
Date: Wed, 1 Dec 1999 12:37:20 -0500

>break fragmentation?) What about the length field, or flags field,

Cmon, surely you can come up with a better counterargument than that!  ;-))
I certainly could.  If it is architecturally acceptable for those protocols
to rewrite the address field at every hop, why shouldn't it be for IP?  How
does it differ?  Basically a NAT is doing what an ATM switch does. How does
an MPLS tag differ?

The answer of course is that MPLS tags, etc. have a much smaller scope and
rely on the layer above to provide an address of broader scope "to bind the
tags together."  The problem for NATs is that IP doesn't have a name space
of broader scope "to bind the tags together."
>also not "bad architecture"?

That is more questionable given the architecture that has been put forward.
If IP and TCP are supposed to be in different layers then the pseudo-header
is also bad architecture.  If they aren't in different layers, then it
isn't and neither is modifying the checksum.
>IMO, this is a widespread oversimplification of the situation.

Only partly,  But it would be a big step to solving the problem.  However,
there are so many special cases now of people doing strange things with IP
addresses that they shouldn't be doing that there may not be anyway out of
the problem.
>basic TCP (and UDP) design.

This can be dealt with in the NAT.
>and sent to the actual destination).

Not really.  I recently heard Dave Clark say (and in a rare case I actually
agree with him based on  my own investigations into protocol design
principles) that it would probably have been better if socket ids were part
of the IP address and there was no addressing in TCP at all.
>creating a new (hard) problem elsewhere that then needs solving.
Yes, I am aware of this.  In the very early days, it was assumed that it
would have to be done.  Then there was a long hiatus where the only
applications were telnet and ftp and by the time it was really needed it
would seem that reticence to change had set in and lots of people continued
to do ad hoc things that made change difficult.

I am well aware of the issues, but I did want to push back on people who
see no problem with applications exchanging IP-addresses.  The longer we
keep putting this off the messier the problem gets.  Frankly, I have heard
these arguments for years that to fix anything will only create problem
elsewhere and so far I have seen no examples that were not either "bad
architecture" or should be accomplished in a different way.  Where the
"desired" approach was an artifact of not having the right tools to solve
the problem.

Take care,
John

---

From: John Day <[email-masked]>
Date: Wed, 1 Dec 1999 12:37:20 -0500

Take care,
John

---

From: John Day <[email-masked]>
Date: Wed, 1 Dec 1999 12:09:02 -0500

>entity title" or similar entity.

Interesting.  So someone else picked up on early ARPANet/Ethernet ideas and
tried to use them.
>real operations, but you sometimes stumble across the relics of the idea
Does this mean that if someone else tries to use an idea in their
environment from our environment that then makes it a bad idea for us to
use?

I still don't understand why you even brought up this line of discussion.
I don't see its relevance at all.  Shoch's paper laid down some basic
concepts in naming and addressing and he did it very early on.  I don't see
that they have been contradicted by anything that has transpired in the
meantime.  So what is your problem with Shoch's paper?

>we haven't managed to do it yet.
Maybe we should.  It might make a number of things easier.

Take care,
John

---

From: John Day <[email-masked]>
Date: Wed, 1 Dec 1999 12:09:02 -0500

Take care,
John