Subject: (NAT) requested terminology changes to draft-ietf-nat-terminology-02.txt

From: Keith Moore <[email-masked]>
Date: Wed, 26 May 1999 02:15:32 -0400

These changes were originally requested by me as part of my review
of the document for IESG.  After discussions with the document author
and other Area Directors, I have been asked to bring these change 
requests to the attention of the NAT working group, in the hope that 
discussion among the working group will result in changes which 
are acceptable to everyone.

In particular, because the terminology in this document will be used 
by people on both sides of the NAT debate, it is important that the 
terminology chosen be "neutral" with respect to that discussion.

Therefore, aside from several specific, and minor, suggested changes 
to draft-ietf-nat-terminology-02.txt, I have suggested two general 
terminology changes as follows:

1. regarding "routing realm" 

As there are many more reasons than NATs to limit the scope of 
routing advertisements, use of the term "routing realm" in conjunction 
with NATs seems somewhat imprecise and likely to invite misunderstanding.
Since the distinguishing feature of NATs is that they separate 
networks which potentially conflict in the way they assign *addresses*,
and since normal (BGP etc) routing advertisements (i.e. between
the other kind of "routing realms") generally cannot cross NATs,  
I believe that the term "addressing realm" should be used instead of 
"routing realm", when speaking of the realms separated by NATs.

It would also be acceptable to just use the term "realm" if that
term were clearly defined (within the document) in terms of 
addresses rather than routes.

2. regarding use of the term "transparent"

As applied to NATs and ALGs, the term  "transparent" can be interpreted 
two ways:

- the NAT/ALG is not "visible" to the application or end hosts

- the insertion of a NAT/ALG doesn't affect the data transferred
  between the applications, or the ability of the application
  to function. ("data transparency")

The first meaning is, I think, generally true. Although applications can 
test for the presence of NATs, most are not designed to do so.  Most
applications that function through a NAT, do so without having to be 
aware of the NAT and without taking special action to work in the 
NAT environment.

However the second meaning is less true, because NATs and ALGs do 
sometimes change the data in ways that affect the application.
This aspect of transparency differs from one application to the next.

Because of this ambiguity I think the term "transparent" should be 
used sparingly.  In a few places, its use seems inappropriate without 
some qualification, because it might be taken to mean "transparent"
in the second sense rather than in the first sense.  

I therefore believe that most uses of "transparent" should be replaced 
with more descriptive and precise words, or that additional words be 
added to make the meaning of "transparent" less ambiguous.  

Keith
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 27 May 1999 16:51:06 -0700 (PDT)

> terminology chosen be "neutral" with respect to that discussion.

Keith - You make it sound like the terminology is biased, as it exists. 
That is not true. This terminology has been used by folks in the work 
group since the inception of this work group. We have members with varied 
points of view with regard to NAT in the mailing list and they all
actively contribute to it.

I believe, this is mostly a matter of semantics you are ascribing 
to these terms.
	
> with NATs seems somewhat imprecise and likely to invite misunderstanding.

A routing realm is not a network that is described by the extent of 
routing advertisements made into or out of it. By that definition, 
you could say every router is at the boundary of one or more 
routing realms. But, that is not the case. A router is at the boundary 
of one or more protocol specific networks.

I also get the impression that you assume a router to be one that takes 
part in routing protocols (i.e., routing advertisements and such). That 
is not what I would call a "router". To put things in perspective, below
is my definition of a router.

     When a packet is forwarded from one interface to another 
     interface of the same node, that is an act of routing. The 
     intermediate node performing such an act is a "router".

A router may also take part in routing protocols. But, that is not a 
requirement. NAT does not take part in routing protocols, but is still 
a router by the above definition of a router. NAT does not scope routing 
advertisements. But, NAT does route packets between two distinct routing 
realms. Each routing realm is distinct in that each realm has a set of 
nodes with a unique set of addressing and routing protocols.

Lastly, Routing realm is specifically defined as follows in the draft
to avoid misinterpretations.

   A routing realm is a network domain in which the network addresses
   are uniquely assigned to entities such that datagrams can be
   routed to them. Routing protocols used within the network domain
   are responsible for finding routes to entities given their network
   addresses. Although NAT routers may be used with IPv6, this document
   is limited to describing NAT routers in a IPv4 environment.

> Since the distinguishing feature of NATs is that they separate 
                                                        ^^^^^^^^
> networks which potentially conflict in the way they assign *addresses*,

The distinguishing feature of NATs is that they bridge networks
which potentially conflict in the way they assign addresses. 
A NAT router facilitates routing of datagrams between disparate
routing realms.

> "routing realm", when speaking of the realms separated by NATs.

A routing advertisement from one realm may cross a NAT device.
That depends on the properties of the routing realms supported
by the NAT device.

Once again, your reference to routing advertisements and BGP 
seems to imply the same difference in semantics as far as what 
constitutes a router and hence a routing realm.

A regular protocol specific router operates within a routing realm. 
A NAT router operates between routing realms.

> addresses rather than routes.

The terms "addressing realm" and "realm" do not sufficiently
characterize what a NAT router supports.

Nodes in one realm cannot depend on the routing protocols (in 
that realm) alone to have the packets delivered. They need NAT 
to facilitate the routing.
 
For example, take Basic-NAT. When a packet leaves private realm, 
NAT modifies the source address. While this has no impact on the 
forwarding of the packet itself (not assuming ingress filtering), 
it sure has an impact on the forwarding of the return packet 
(i.e., packet inbound to the private realm). When the reply packet 
reaches the NAT device, NAT changes the destination address and 
uses the private realm routing table to forward the packet within 
private realm.
  
NAT is different from something like DHCP, which is merely an 
address (and other resource) assignment mechanism.

> in the second sense rather than in the first sense.  
 
NAT devices attempt to provide routing transparency. I.e., the 
routing service provided by a NAT device is not visible to end
hosts, even as the peering end hosts are in different routing
realms.
  
Nowhere in the document does it claim application level 
transparency.  Application level transparency (in some cases) 
happens to be a by-product of routing transparency. The intent 
of ALGs is to bring about application transparency.
   
> added to make the meaning of "transparent" less ambiguous.  

I do believe, the term "transparent" has been used with caution 
throughout the draft mostly in the context of routing alone. 
The draft has gone through extensive fine combing by many folks, 
including many IESG members.

> 'unsubscribe nat' in the body of the message.

regards,
suresh
-

---

From: Steve Deering <[email-masked]>
Date: Thu, 27 May 1999 18:38:52 -0700

>actively contribute to it.

I agree with Keith, and I have also raised the same points in this
working group to no avail.   I don't know for sure that the term
"routing realm" is biased, but it does serve to obscure rather than
clarify what's going on.  If that obscurity was intentional, then it
would qualify as biased, but I don't know if that was the case.

>which potentially conflict in the way they assign addresses.

I believe Keith was using the term "separate" to mean "form the boundary
between", not "prevent communication between".

And your sentence states exactly the point that Keith was raising.
The property that requires two pieces of topology to be joined by
a NAT box is the reuse of *address space* in those two pieces of
topology, *not* anything to do with routing within or across those
pieces of topology.  Thus, NATs join different "realms" of addressing,
not realms of routing.  Saying that they join different routing realms
just leads to misunderstanding, because (a) routing is not the issue, and
(b) "routing realm" is too easily confused with "routing domain", which
is what Keith was getting at.

>characterize what a NAT router supports.

No, they characterize the the pieces of topology that NATs are used
to join.

Steve

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 28 May 1999 07:09:12 -0700 (PDT)

> working group to no avail. 

Steve - I checked through the mail archives and I cant find any e-mail
in which you expressed the concern in the past. This is the first time 
we are hearing you say that. So, it is not fair to say that your raised 
a comment to no avail in the working group. Your comments are 
valuable and are viewed as such by the working group.

I vaguely recall your asking Yakov to give a definition of what a 
"routing realm" is, in Munich IETF (i.e., 08/97, before the working 
group was even formed) and that was that. Once again, I dont see 
this as expressing a concern - merely asking for a clarification.

>                              I don't know for sure that the term
> not realms of routing.  

NAT routes packets between two routing realms, which would otherwise
not route between themselves.

>                         Saying that they join different routing realms

Routing is a significant piece of what NAT does. 

> is what Keith was getting at.
The definition for the term "routing realm" is clearly specified in the
document.

> No, they characterize the the pieces of topology that NATs are used

I disagree.

-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 May 1999 10:21:15 -0500

I deeply regret having accepted the phrase "routing realm" when 
we were writing RFC 2101, which is where it comes from.

"Addressing realm" is precise and accurate; "Routing realm" isn't.

A NAT is the boundary between two address spaces; therefore what
it separates is two addressing realms. It does not in any way
need to run a routing protocol; therefore it is not a router.

Often, NATs are implemented in the same box as a router, but they
are logically separate functions.

I agree with Keith on this one; we got it wrong in RFC 2101 and now
is a good time to fix it.

The "transparency" issue is less clear in my mind; I have a draft
out on this subject, but it's a very fuzzy word. One thing that is
mathematically clear is that no NAT or ALG is transparent.
Since the word is fuzzy, it's a good idea to use it as little as
possible.

   Brian Carpenter
-

---

From: Daniel Senie <[email-masked]>
Date: Fri, 28 May 1999 11:56:22 -0400

> "Addressing realm" is precise and accurate; "Routing realm" isn't.

I don't personally have a problem with it being an "addressing realm." I
would like this issue settled, though, so that the terminology can be
used consistently in other documents.

> need to run a routing protocol; therefore it is not a router.

Brian, I object to the definition of a "router" as a thing which runs a
routing update protocol. To suggest that is to suggest that any device
set up with static routes is not a router. This is simply contrary to a
great deal of historical use of the term "router."

OSPF, RIP, BGP, and so forth are NOT requirements of a router. Read RFC
1812, section 7.2.2. There are no statements there which indicate a
router MUST implement a dynamic update protocol (it does say that IF a
router implements a dynamic update protocol, it MUST implement OSPF, but
it doesn't require any dynamic update protocols). Implementing static
routes alone is acceptable under RFC 1812, "Router Requirements."

> are logically separate functions.

A router picks packets up on one network, and routes them to another
after making some changes to the packet. A router implementing NAT
functionality in a router does much the same thing. Let's see how the
IETF defines a router (RFC 1812):

"An IP router can be distinguished from other sorts of packet switching
devices in that a router examines the IP protocol header as part of the
switching process. It generally removes the Link Layer header a message
was received with, modifies the IP header, and replaces the Link Layer
header for retransmission."

By that definition, a NAT gateway is a router. Perhaps we should update
RFC 1812 to say that we really only wanted SOME changes to the IP
header, and not others.

> is a good time to fix it.

If this is something which should be fixed, then perhaps we need to
generate a draft to update RFC 2101. It's not clear that the NAT
terminology draft is the place to be updating that document.

> mathematically clear is that no NAT or ALG is transparent.

Nor is any router, in a sense, transparent. The packet emitted does not
match the packet received, bit-for-bit. Bridges are transparent.

> Since the word is fuzzy, it's a good idea to use it as little as

No disagreement.

Dan

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 May 1999 11:48:42 -0500

Daniel Senie wrote:
...
> great deal of historical use of the term "router."

Daniel, you're correct of course; a router may have static routing
tables instead of running a routing protocol. It doesn't change
the point I was trying to make about routing being a completely
distinct function from address translation, even if they occur in the
same box.

...
> terminology draft is the place to be updating that document.

To be clear, my only issue with 2101 is the phrase "routing realm";
I think the analysis is still correct.

   Brian
-

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 28 May 1999 10:03:47 -0700 (PDT)

> distinct function from address translation, even if they occur in the
Brian - A NAT device does routing. It forwards packets from one 
interface (belonging to one realm) to another interface
(belonging to a different realm). Address translation is done prior 
to forwarding to ensure packet routability within each realm.

> I think the analysis is still correct.

"routing realm" would be a wrong phrase, if NAT wasnt providing the 
routing service and packets could have been routed between the two realms
without a NAT device being present enroute.

-

---

From: Steve Deering <[email-masked]>
Date: Fri, 28 May 1999 10:04:50 -0700

At 7:09 AM -0700 5/28/99, Pyda Srisuresh wrote:
>a comment to no avail in the working group.

In one of the working group meetings (I don't remember which one), I
got up and said I thought the term "routing realm" was inaccurate and
misleading and I suggested that the term "addressing realm" be used
instead.  Yakov responded with some argument justifying the use of
the term "routing realm", an argument that I disagreed with.  No one
else said anything, and no change of terminology was made.  It is true
that I didn't press the issue, because it seemed futile at the time.

>not route between themselves.

NAT forwards packets between realms whose salient characteristic --
the reason why the NAT is needed -- is their re-use of address space.
That's why the devices are called network *address* translators.

>Routing is a significant piece of what NAT does.

Address translation is the most relevant piece of what NAT does.

Probably "forwarding" would be a better term than "routing" in what you
are trying to say here, because of the lack of consensus on what
"routing" means (i.e., does it or does it not mean "runs a routing
protocol"?).  Yes, this is another area where the community's use of
terminology could use some improvement.

Anyway, I can guess we can all agree that NATs do IP forwarding (of
modified IP packets), but they do not necessarily run routing protocols.

Steve 

-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 May 1999 15:01:26 -0500

Pyda,

We disagree fundamentally. I can only repeat that address
translation is one thing, and routing is another.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
As of May 24, 1999: on assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 28 May 1999 15:44:57 -0400

>      intermediate node performing such an act is a "router".

Actually, that would be forwarding.  Routing is the determination of an
appropriate interface for a next hop (sometimes by determining an entire
path, with possible abstraction of sections of it).  Forwarding is,
minimally, the act of sending a packet out that interface.

I'm with Keith on addressing realms as well.

...Scott

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 28 May 1999 13:26:01 -0700 (PDT)

> In one of the working group meetings (I don't remember which one), I
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
I believe, this is the NAT BOF in Munich IETF (08/97).

> that I didn't press the issue, because it seemed futile at the time.

I donot recall the exact details of what was said. But, my recollection
is that the explanation from Yakov addressed the questions you raised.
(Unfortunately, the meeting minutes donot capture this).

> That's why the devices are called network *address* translators.

Your point is well taken. 

But, what is being sidelined (and perhaps not as apparent to folks) is 
the fact that NAT operates at network level and performs routing
functionality (at least, as per the definition in RFC 1812). A NAT 
device is application neutral and principally operates on the IP header. 
Hence, I believe, routing transparecy is a salient characteristic
of NAT devices, in addition to address translation.

> Address translation is the most relevant piece of what NAT does.

A NAT device is characterized by 
(a) transparent Address Translation and 
(b) transparent routing. 

It takes both. Not just one or the other.

> terminology could use some improvement.
In reality, most NAT devices also run some kind of dynamically updating
routing protocol on the realm-specific interface(s).

> modified IP packets), but they do not necessarily run routing protocols.

OK.

> 'unsubscribe nat' in the body of the message.

cheers,
suresh
-

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 28 May 1999 16:47:02 -0400

> From: Andrew Brown <[email-masked]>
>
> actually...to look at it from the converse point of view: if a network
> device receives a packet on one interface and doesn't think about
> which interface to forward it out of, then that device is (almost) a
> hub (or repeater).  routers use a little more brains.  it's the brains
> that makes all the difference.

There are devices which are fed their fowarding databases.  They don't
create their FIBs, even from static routes.  They're forwarders, but not
routers.

-

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 28 May 1999 17:45:39 -0400

Given the routing-vs-forwarding distinction, i'm surprised nobody has
suggested "forwarding realm" as an alternate term..

(I think "addressing realm" is better, though..)

					- Bill
-

---

From: Steve Deering <[email-masked]>
Date: Fri, 28 May 1999 14:53:58 -0700

> > In one of the working group meetings (I don't remember which one), I

I think it was later than that.  I can mentally picture the room that
the BOF was held in, and the room that I made my suggestion in, and
the two rooms look different.  :-)

>(a) transparent Address Translation and 

Sure, but the one thing that makes a NAT different than other kinds of
routers is characteristic (a).  The property of the "realms" on either
side of the NAT box that require the presence of the NAT box is an
addressing property, not a routing property.

The re-use of addresses in different realms indeed impedes the ability
to route between nodes in those realms, but it also impedes the
ability to establish TCP connections between them, to do reverse DNS
lookups between them, and to do a number of other things between them
that depend on all nodes having distinct addresses.  The effect on
routing is only one of several consequences that flow from what is
an addressing property of a realm.  Thus, singling out "routing" as
the significant property of the realm is, I contend, misleading.

I'll stop now.

Steve

-