Subject: [BEHAVE] STCP NAT terminolgy

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Nov 2008 16:25:16 -0600

Hi,

This is my follow up on todays comments on the mike regarding the
following figure:

   Internal Network      |         External Network
                         |
             Private     | Public                    External
 +---------+ Address     | Address     /--\/--\      Address +---------+
 |  SCTP   |          +-----+         /        \             |  SCTP   |
 |end point|==========| NAT |======= | Internet | ========== |end point|
 |    A    |          +-----+         \        /             |    B    |
 +---------+ Internal    |             \--/\--/     External +---------+
  Internal      Port     |                             Port    External
    VTag                 |                                       VTag

After having looked at the RFC 4787 (UDP NAT) I have to agree that the
terminology is  a bit mixed up. The terminology section uses private and
external and then the text that actually discusses behavior uses
another. I think the behavior part terminology is the one that is best
and used in also other documents. IF one looks at the UDP one both the
public and address that end point B has are in the External domain. But
they are either source or destination. They are also clearly annotated
so there can't be any confusion. If the SCTP NAT spec is going to use
words it needs to be clear and I think the below proposal makes more sense:

Private Address -> Internal Address
Public Address -> External Address
External Address -> Remote Address
External Port -> Remote Port
External VTag -> Remote VTag

Opinions?

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Nov 2008 16:45:36 +0100

> External VTag -> Remote VTag
Full support.
RD

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Nov 2008 14:23:35 -0600

> External VTag -> Remote VTag

I would prefer this:

	Internal VTag -> Local VTag
	Internal Port -> Local Port

In this way, the words "external" and "internal" identify the address  
realms attached by the NAPT gateway.  We use the word "local" as a  
complement to "remote" to denote those parameters that are not  
translated between address realms.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 20 Nov 2008 14:50:59 -0600

Hi James,

I like your suggestion.

Is it acceptable for others? Magnus?

Best regards
Michael

On Nov 20, 2008, at 2:23 PM, james woodyatt wrote:

> In this way, the words "external" and "internal" identify the  
> address realms attached by the NAPT gateway.  We use the word  
> "local" as a complement to "remote" to denote those parameters that  
> are not translated between address realms.
>
>
> --

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Nov 2008 15:27:31 -0600

I suggest entirely avoiding use of the terms External or Internal.
Because it's not always clear  what the reference point is.
And for some kinds of translators (e.g. split NAT) the terms External
and Internal are sort of meaningless because the NAT isn't translating
between an inside and an outside realm, but between two public realms.

Keith

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 20 Nov 2008 15:31:50 -0600

Hi Keith,

can you suggest what to use and not only what not to use?

Best regards
Michael

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Nov 2008 15:30:16 -0600

> Is it acceptable for others? Magnus?
Fine with me.

Cheers

Magnus Westerlund

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Nov 2008 15:34:15 -0600

> can you suggest what to use and not only what not to use?

best terms I've come up with so far are Public and Private, after
choosing and then discarding Internal and External.

Keith

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Nov 2008 15:36:40 -0600

> between an inside and an outside realm, but between two public realms.

This is IPv4 to IPv4 NAT that do have different realms. We have being
using internal and external in the previous documents. Thus, I think
using something else in this document is only confusing.

For the v4-v6 translators we are going to explain this for the different
direction on how to map this. Having to do this different only adds work.

My suggestion is to go with James's proposal.

Cheers

Magnus Westerlund

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Nov 2008 16:52:53 -0600

On Nov 20, 2008, at 15:27, Keith Moore wrote:
> Because it's not always clear  what the reference point is.  And for  
> some kinds of translators (e.g. split NAT) the terms External and  
> Internal are sort of meaningless because the NAT isn't translating  

Only in the case of "NAT64" protocol-version translation systems are  
we potentially talking about two public address realms, i.e. the  
public IPv4 address realm and the public IPv6 address realm.

In the NAT44 and NAT444 cases, there is only the one public IPv4 realm  
we have always known and loved.

> choosing and then discarding Internal and External.

In the NAT444 case, the subscriber NAT is not attached to the public  
IPv4 address realm.  It is a gateway between the provider IPv4 address  
realm and one or more subscriber IPv4 address realms, and *all* of  
them are private in NAT444, regardless of whether RFC 1918 address  
space is used by the provider and/or the subscriber.

The distinguishing feature of a public address realm is that IANA, and  
not just any private enterprise, is at the root of the number  
authority hierarchy.  It matters not at all if RFC 1918 addresses are  
still meaningless in any given private address realm.  To make an  
address realm private, it is sufficient only to usurp the number  
authority hierarchy from IANA.  You don't even have to deploy a single  
NAT device to do that.