Subject: RE: NAT-PT Applicabilty for 3GPP

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Thu, 13 Nov 2003 22:59:36 +0100

I brought up the same issue during the DT work and agree with Randy's
point that if a scenario exists that requires a subset of NAT-PT (i.e. 3GPP
IMS) then it does not necessarily imply that NAT-PT as specified in RFC 2766
is applicable. The draft could however point out which parts of NAT-PT are
applicable in this case.

Regarding the actual SIP solution there is a reference in 3gpp-analysis-07
to draft-elmalki-sipping-3gpp-translator-00. Following Margaret's comments
last time and the recommendation in draft-ietf-3gpp-analysis it is on the
SIPPING agenda this time. For those who may be interested here's a new version
of the draft:
http://standards.ericsson.net/karim/draft-elmalki-sipping-3gpp-translator-00.txt

/Karim

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On
 > Behalf Of Randy Bush
 > Sent: den 13 november 2003 00:25
 > To: Suresh Satapati
 > Cc: [email-masked]
 > Subject: Re: NAT-PT Applicabilty for 3GPP
 > 
 > 
 > > In the above, though a SIP-specific translation mechanism is being
 > > recommended, I do not see how the recommended solution will be
 > > fundamentally different from NAT-PT. In this sense, the 
 > applicability
 > > of NAT-PT is still valid.
 > 
 > if A is a proper subset of B, a need for A does not mandate B,
 > especially if A is a very localized hack and B is global, generic,
 > and questionable.
 > 
 > randy
 > 
 >

---

From: Suresh Satapati <[email-masked]>
Date: Fri, 14 Nov 2003 13:36:32 -0800 (PST)

Karim,

This may be redundant to you, but to seek WG opinion I will repeat the
argument here on this list.

> http://standards.ericsson.net/karim/draft-elmalki-sipping-3gpp-translator-00.txt

This whole "subset applicability" argument stems from incorrect assumption that
NAT-PT (RFC 2766) mandates DNS-ALG.

In the past for v4 land, ALGs have been specified in separate documents.
For e.g. RFC 2663/3022 clearly defines the role of "NAT", and for
DNS-ALG there is RFC 2694.

RFC2766 mentions DNS-ALG (and FTP-ALG) as an example, in addition to
basic NAT-PT operation. There is no text that states NAT-PT mandates
DNS-ALG.

This clarification came from the author of NAT-PT, as well. Pls refer to
previous posting:

http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01460.html

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Nov 2003 13:40:38 +0200 (EET)

Hi,

I hijacked the thread to bring up a point about IMS/SIP transition in the 
3GPP analysis document as it is now..

On Fri, 14 Nov 2003, Suresh Satapati wrote:
> This whole "subset applicability" argument stems from incorrect
> assumption that NAT-PT (RFC 2766) mandates DNS-ALG.

Maybe, maybe not..

> DNS-ALG there is RFC 2694.

Yes, but then again, you don't need DNS-ALG in the v4<->v4 NAT, because
the destination address families are the same.  On the other hand, you
*do* need it in NAT-PT (or, you have to get the corresponding
functionality in some other way, e.g. manual configuration).

But that aside...

The critical point, I think, is whether the 3GPP analysis about IMS
interworking is written so that it recommends NAT-PT.  Personally, I don't
think we should do that.  

Instead, we should defer the problem to a SIP working group (SIPPING?) to
figure out.. because *they* will be using SIP for interaction, and they
know best which kind of solution they'd need (whether based on NAT-PT or
something else).  I don't think v6ops has the expertise to specify which
method would be most appropriate in this SIP/IMS internetworking scenario.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Suresh Satapati <[email-masked]>
Date: Mon, 17 Nov 2003 13:06:28 -0800 (PST)

Pekka,

> the destination address families are the same.  On the other hand, you

I am afraid you are *wrong*.

DNS-ALG is not used *merely* for translation between address families.
DNS-ALG is used to translate addresses contained in PTR queries and any addresses
in DNS responses (like Answer, Additional RRs). The translation could be
be replacing a private (rfc 1918) address w/ a public address.

This has been extended to v6<->v4, where an IPv6 address is being
replaced w/ an IPv4 one.

> interworking is written so that it recommends NAT-PT.  Personally, I don't

I think IMS interworking is indeed better understood by 3GPP folks. Let's
not add to confusion w/ personal opinions.

> know best which kind of solution they'd need (whether based on NAT-PT or

No concerns on defering the problem to SIP folks, as long as we agree what
the problem is. If the problem is figuring out the bindings during SIP
signalling through an external mechanism, then yes I agree. That is all to
the problem.

Defining a translator that uses those bindings to do header translation
has already been defined in RFC2766. SIP wg. should not invent another
one.

> method would be most appropriate in this SIP/IMS internetworking scenario.

See my point above.

--

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 00:22:11 +0200 (EET)

> be replacing a private (rfc 1918) address w/ a public address.

Again, it is not required.  Many NAT boxes do implement this, but many 
others do not.  IPv4 NAT is fully functional without a DNS ALG.
 
> This has been extended to v6<->v4, where an IPv6 address is being

Right, but you cannot implement NAT-PT without DNS-ALG, or something to
replace the functionality (whereas with v4 NAT, there is no need for the
functionality).
 
> has already been defined in RFC2766. SIP wg. should not invent another

I'm not sure actually what the problem is.  All it is that folks think 
that an optional mechanism for v6-only SIP <-> IPv4 SIP should be 
specified.  I don't personally care much for the details, but the SIP 
folks probably know better which kind of tool might solve the problem.  If 
it's sufficiently close to NAT-PT, why not reuse parts of it and specify 
something to create the mappings; if not, maybe it's worth doing something 
else.  I just don't think this WG is the right place to define that.

---

From: Suresh Satapati <[email-masked]>
Date: Tue, 18 Nov 2003 09:37:23 -0800 (PST)

Pekka,

> replace the functionality (whereas with v4 NAT, there is no need for the

Just like you can make a v4NAT work, you can make NAT-PT work without
a DNS-ALG. The model is the same.

> specified.  I don't personally care much for the details, but the SIP

Briefly, the problem is SIP-ALG i.e., parsing SIP payload for addresses
/ports and replacing them w/ v4/v6 equivalents is not recommended. Folks
are calling it "SIP editing".

> else.  I just don't think this WG is the right place to define that.

SIP(ping) folks should just worry about the problem that I stated above,
and nothing more.

The above tells me that this WG is deliberately letting another WG define
"yet another" translator without understanding what the problem is, and
use this as means to eventually deprecate RFC2766.

---

From: Senthil Sivakumar <[email-masked]>
Date: Mon, 17 Nov 2003 21:35:53 -0800

>else.  I just don't think this WG is the right place to define that.

I am not sure what the problem is, either. It is very clear if you have a 
v4 only
application/node/network, talking to a v6 only application/node/network you 
need
a protocol translator. It is a no brainer. Why can't we concede that and 
move on?
The generic protocol translator is a transition mechanism and it belongs in
this WG.

Senthil

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 20:00:40 +0200 (EET)

On Mon, 17 Nov 2003, Senthil Sivakumar wrote:
> I am not sure what the problem is, either. It is very clear if you
> have a v4 only application/node/network, talking to a v6 only
> application/node/network you need a protocol translator. 

Right (for some definition of translator).

> It is a no
> brainer. Why can't we concede that and move on? The generic protocol
> translator is a transition mechanism and it belongs in this WG.

The question here is, if we don't want a generic protocol translator, 
how could we define a translator very specific to achieve the SIP 
requirements?

At some point there may be a decision which way is preferable,
augmenting NAT-PT by defining a SIP ALG, or specifying a separate
mechanism (which may or may not be using some of NAT-PT concepts).  

The point is, that we should not lock ourselves out of either
possibility at this point, until we see what kind of requirements
SIPPING WG has.

Note to Karim et al: has SIPPING discussed this issue at 
"requirements" level rather than "solutions" level?

Note that our charter says:

  If the satisfactory resolution of an operational or security
  issue requires the standardization of a new, widely-applicable
  transition mechanism that does not properly fit into any other
  IETF WG or area, the v6ops WG will standardize a transition
  mechanism to meet that need.

.. the high-order bit for this debate seems to be, "if we need to get 
a transition mechanism done, try to do it somewhere else (w/ area 
expertise) first; if it fails, do it here".

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 20:09:42 +0200 (EET)

> a DNS-ALG. The model is the same.

I do not know why you insist on that, because it's clearly wrong, or 
you have a lot of assumptions about what you mean with "make NAT-PT 
work".

If I am behind a v4 NAT without DNS-ALG, and I try to connect to 
www.google.com, the connection succeeds and it works.

If I am behind NAT-PT, without DNS-ALG, have v6-only host, and I try 
to connect to www.google.com, the connection fails because the NAT-PT 
cannot find the AAAA record for www.google.com.

These models are NOT the same.

You probably assume some other mechanism for providing similar mapping
than DNS-ALG for NAT-PT.  For example, manual assignment could be OK
for "inbound" services.  But that's completely unspecified.

---

From: Suresh Satapati <[email-masked]>
Date: Tue, 18 Nov 2003 12:23:40 -0800 (PST)

Pekka

I think you are digressing too much here..

> for "inbound" services.  But that's completely unspecified.

I agree it is much simpler in v4NAT to do that, than in v6<->v4. As
you mentioned above, the way to do w/o ALG maybe unspecified in the RFC.
But then most RFC's are like that. They leave a lot for the implementors.
Because something is unspecified doesn't rule out the possibility.

I'd request you to stop this and get back to the original thread
[Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP]]

I'd like to get a sense on where the WG Chairs stand regarding:

<---- from my prev. mail ------>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2003 11:15:00 +0200 (EET)

Hi,

> I'd request you to stop this and get back to the original thread
[...]

In turn, I'd request you to stop spreading the gross simplification
that NAT-PT is equal to plain old v4 NAT, and NAT-PT works as 
specified without DNS-ALG.  This is definitely not the case.

If we refer someone to RFC2766 for translation, there are two options:  
either implementing DNS-ALG or inventing a replacement on your own; I
don't think there exists even an internet-draft describing other
possibilities to achieve the same effect.  Making such a referral
without explicit mention to requirements regarding DNS-ALG or similar
behaviour is necessary to avoid causing any more confusion.

Of course, vendors are free to deploy any unspecified mechanisms they
want.  But that doesn't fix the problem for those who haven't
developed an unspecified mechanism for achieving the same effect;  
for all intents and purposes, unless something has been specified or
documented, it does not exist.

> I'd like to get a sense on where the WG Chairs stand regarding:
[...]

I take it that you're asking for an "official" standing.  Could you
clarify what the question is, or would you just want us to comment?
I'll add that on our agenda, but the response could take a while..

---

From: Jasminko Mulahusic <[email-masked]>
Date: Wed, 19 Nov 2003 14:03:35 +0100

suresh,

i really do not understand what your concern is?

> are calling it "SIP editing".

<....>

> use this as means to eventually deprecate RFC2766.

have you read draft-elmalki-v6ops-3gpp-translator-00.txt?

which part you do not understand/like?

the draft is explicit about what i believe is your concern:

-------------
As specified in [4] SIP messages may be end-to-end integrity
protected, therefore it may not possible to modify them en-route. In
general the SIP WG discourages the use of intermediaries which alter
the contents of SIP messages. This is a very important consideration
for a 3GPP Translator solution.
-------------

jasminko

---

From: Suresh Satapati <[email-masked]>
Date: Wed, 19 Nov 2003 08:23:12 -0800 (PST)

> specified without DNS-ALG.  This is definitely not the case.

When I referred to the model, I meant with NAT or NAT-PT, for certain
applications (think non-DNS) you need the binding to be setup during
signalling. This could be done by an ALG (or your favorite) residing on
the same or a different box that does header translation. This would enable
subsequent data/media to go through using the bindings. Maybe I wasn't clear
about this earlier.

> documented, it does not exist.

You have combined two arguments, which is actually misleading.

model(that i mentioned above) + DNS_ALG being a part of NAT-PT ?
We can keep arguing about this and get no where. This will be my last mail
on this topic.

> I'll add that on our agenda, but the response could take a while..

Yep. official standing. That's what I meant.

---

From: Suresh Satapati <[email-masked]>
Date: Wed, 19 Nov 2003 08:47:20 -0800 (PST)

Jasminko,

I've read the draft.

My only concern with the draft is:

---------------------------------------------------------------------
4.1.2 IP Address and Port Mapper (IPAPM)

   The IPAPM (IP Address and Port Mapper) is needed because the 3GPP
   IPv6-only host and the IPv4-only host cannot send media traffic to
   each other due to IP layer incompatibility. The IPAPM will simply
   perform the IP address mapping for the appropriate IP address, port,
   protocol tuples on both incoming and outgoing media packets. The SIP
   Edge Proxy will install and delete this bidirectional state in the
   IPAPM (see 4.4). It should be noted that the IPAPM operation is
   similar to that of a bidirectional NA(P)T-PT [16] after having
   installed state for a particular connection. That is, the translation
   algorithm (SIIT) is the same, the main difference is the method used
   to install state in the translator. Hence, if needed, an IPAPM may
   also operate as a normal NA(P)T-PT for other (non-IMS) traffic for
   which it does not have an address/port binding.
------------------------------------------------------------------------

IMO the above is nothing but NA(P)T-PT with a fancy name, w/ which the
authors and Pekka disagree.