The End-To-End Internet (was Re: Blocking MX query)

William Herrin bill at
Mon Sep 10 21:14:04 UTC 2012

On Sun, Sep 9, 2012 at 6:24 PM, Masataka Ohta
<mohta at> wrote:
> Oliver wrote:
>>>> You're basically redefining the term "end-to-end transparency" to suit
>>>> your own
>>> Already in RFC3102, which restrict port number ranges, it is
>>> stated that:
>>>     This document examines the general framework of Realm Specific IP
>>>     (RSIP).  RSIP is intended as a alternative to NAT in which the end-
>>>     to-end integrity of packets is maintained.  We focus on
>>>     implementation issues, deployment scenarios, and interaction with
>>>     other layer-three protocols.
>> Just because something is documented in RFC does not automatically make it a
>> standard, nor does it necessarily make anyone care.
> That's not a valid argument against text in the RFC proof read by
> the RFC editor as the evidence of established terminology of the
> Internet community.

In case Nick's comment wasn't obvious enough:

RFC 1796:

"Not All RFCs Are Standards

It is a regrettably well spread misconception that publication as an
RFC provides some level of recognition.  It does not, or at least not
any more than the publication in a regular journal."

RFC 3102:

"This memo defines an Experimental Protocol for the Internet
community.  It does not specify an Internet standard of any kind."

As to your original point that software could be constructed that
restores end-to-end through a NAT device by some kind of dynamic but
published assignment of incoming ports to specific hosts behind the
NAT... that's not really true. End-to-end is generally described as a
layer 3 phenomenon. Dinking around with ports means you're at layer 4.
Which means that only specific pre-programmed transports can pass even
it you would like all protocols to be able to.

There is another technology, also called NAT and described in RFC
1631, which translates layer 3 addresses 1:1, exactly one address
inside for one address outside. While it's possible to talk about
end-to-end with that technology, we are for practical, operational
purposes just shy of -never- talking about or using that kind of NAT.

Bill Herrin

William D. Herrin ................ herrin at  bill at
3005 Crane Dr. ...................... Web: <>
Falls Church, VA 22042-3004

More information about the NANOG mailing list