Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP]

[Suresh Satapati <satapati@cisco.com>]

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.

On Wed, 19 Nov 2003, Jasminko Mulahusic wrote:

> suresh,
>
> i really do not understand what your concern is?
>
> > I'd like to get a sense on where the WG Chairs stand regarding:
> >
> > <---- from my prev. mail ------>
> >
> > 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".
> >
>
> <....>
>
> > 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.
> >
> >
>
> 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
>
>