[Behave dropped, this is an architectural level discussion. If we don't want
this on ietf we should start a different forum]
I don't think that this claim is right: "Promoters of NAT, particularly
vendors, seem to have a two-valued
view of the network in which inside is good and outside is evil."
Lets go back to the original concept of an inter-network as something that is
different from a network. Here I think you will find that the writings of
Clark, Postel, Crocker and co. make a clear distinction. A network is under a
single administrative control while an internetwork is not, there is no one
party that you can rely on to synchronize major changes. That is in fact the
reason that IPv4-to-6 is a really hard problem.
So the distinction here is not between 'good and evil', it is between that
which I am responsible for and that which someone else is responsible for. And
that is why I expect that there will always have to be some form of perimeter
control device in future network architectures.
Now lets turn to the issue that I raised in the plenary: encapsulation.
Encapsulation is an important principle in object oriented programming
precisely because having rules about what is allowed to depend on what makes it
much easier to innovate in useful ways in the future. Discipline is not
incompatible with creativity.
Today the Internet architecture looks a bit like a program written in Cobol.
The program works, it performs an important function but it is not written in
the way that we would write it today knowing what we know today. And the reason
is much the same: Cobol was research, the Internet was research. The objective
of research is to know more at the end than you did at the beginning.
In particular the biggest problem we fact in the Internet is precisely the fact
that it is very hard to change and to innovate. The reason people turned to
object oriented programming was that encapsulation led to programs that were
easier for others to maintain. This is also the reason that we use the single
inheritance model of Java and C# rather than the multiple inheritance model of
C++ or LISP.
What I am looking for here is an encapsulation that allows the application
programmer to rely on a small set of simple assumptions and be able to be
maximally confident that the result will be compatible with the network of the
future.
That is not stiffling creativity or the 'generative' power of the Internet. On
the contrary, every standards process involves removing choices from the
programmer. We decide on particular RFC822 headers to use, we decide on
particular semantics, above all we decide on one way to do something not five.
The question here then, is not whether an assumption is likely to be true or
not, it is whether it is necessary.
Over the next few years application programs are going to have to cope with a
minimum of four separate transport protocols even if there is no NAT
whatsoever: IPv4, IPv6, IPv46, IPv64. Add NAT in and we have four different
variations of IPv4 alone: IPv4, IPv44-4, IPv44-4-44, IPv4-44. And that is
before we start thinking about multiple layers of NAT.
To me this argues that the only possible credible position has to be that the
application protocol makes absolutely no assumptions whatsoever on the basis of
the IP layer address. In fact it would be best for the O/S to provide an API
which hides the details of the IP address from the application entirely in the
same way that the ethernet MAC address is hidden.
What we absolutely cannot afford is allowing people to insert 'assumptions'
into the application layer design that simply are not true for the purpose of
mandating support for some particular network architecture. This is tinkerbell
logic: if we wish hard enough it will make true something that is not.
In the original Inter-network design the role of Internet Protocol was only
mandated as the protocol for use between networks. The idea that IP has to be
end to end is a subsequent assumption that has no grounding in the actual
history.
What I want to see in an Internet Architecture is a set of assumptions that can
be reified as an API that can then remain stable for a century or so. For
example:
A well formed Internet application MUST:
* Identify a service endpoint by means of a URI
* Resolves a service endpoint to a server and port address through the Domain
Name System [1]
A well formed Internet application MUST NOT:
* Employ IP addresses and/or port numbers as inbound signalling
The contract here is that we write down the shortest possible list and then we
try to keep those promises true for the longest possible time, like a century.
[1] Note that the Domain Name System need not necessarily entail the DNS
protocol.as described in RFC 2181, it is the consistency of the mapping, not
the protocol instantiation that is essential. Not that I consider it likely
that there would be a change, it is not necessary to assume that there will
never be a change.
Not only is this proposal more robust, it allows almost infinitely greater
generative power. In fact I can quantify it. With the port numbering scheme we
are limited to 2^16=65536 different protocols. That is not very many in a world
with a billion Internet users. Using DNS/SRV for service endpoint discovery on
the other hand allows for 36^12 = 4.7E18 different combinations, 72 trillion
times more than there are port numbers. And if we ever run out we can work on a
new scheme and burn another DNS RR.
It is also, I would suggest, supported by a considerably greater consensus in
the application area than the arguments being made that NAT is evil. From the
apps area point of view we would like programs to work using the networks we
have and we really do not believe that IPv6 is going to save us.
Going NAT free is not going to be an incentive to move to IPv6 because there is
no possible transition plan that is not going to involve IPv4-6 translation and
thus the problem is going to get worse for the next ten years if we are foolish
enough to write any more application protocols that rely on the IP address
being constant along the network path.
Publishing a simple architectural contract of this form would greatly ease the
IPv4-6 transition and help clarify questions such as when/where we should
employ UDP, TCP and Multicast.
My view is that UDP should only be used for the lowest level facilities, we
need it for DNS and we appear to need it for time. After that I think that any
other use looks more like a different protocol 'lossy TCP'.
The principal problem with using a streaming layer other than TCP or using
multicast is the lack of support which in turn is a defect of our service
endpoint discovery strategy. If we could use an extended version of SRV which
gave us information about the range of transport protocols on offer it would be
possible for endpoints to negotiate better choices. So the consumer whose local
ISP supports 'lossy TCP' can use a videophone client application that makes an
intelligent choice of transport protocol.
The same is true of several other features that were discussed in the IAB
presentation. So applications are using faulty heuristics to make guesses as to
what the network state is? Well provide them with a principled means of
publishing and obtaining the same information. For example, ISPs could publish
network performance stats in the reverse DNS.
________________________________
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of
michael(_dot_)dillon(_at_)bt(_dot_)com
Sent: Wed 11/26/2008 4:27 AM
To: ietf(_at_)ietf(_dot_)org; iab(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
Subject: RE: [BEHAVE] Lack of need for 66nat : Long termimpact to
applicationdevelopers
Yeah, but we're trying to get rid of that stuff, or at least
considerably reduce the cost and complexity, because (among other
things) it presents a huge barrier to adoption of new multiparty apps.
Promoters of NAT, particularly vendors, seem to have a two-valued
view of the network in which inside is good and outside is evil.
But network operators, who sit on the outside of the NAT,
do not share that view. In fact, we see a future in which
cloud computing centers within the network infrastructure
will lead to a wide variety of new multiparty applications.
In many cases the network operator also takes management
responsibility for gateway devices, so the idea of evil on
the outside is even further fetched.
That said, if there is to be some form of NAT66 because there
are real requirements elsewhere, it would be preferable if
the defined default state of this NAT66 was to *NOT* translate
addresses. This is not crazy if you see it in the context
of a NAT device which includes stateful firewalling.
I suggest that if part of the problem is an excess of
pressure from vendors, then the IETF could resolve this
by actively seeking greater input from other stakeholders
such as network operators.
--Michael Dillon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf