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

[Suresh Satapati <satapati@cisco.com>]

Pekka,

> 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..
>
> > 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.
>
> 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

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.

> *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.

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

>
> 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

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.

> something else).  I don't think v6ops has the expertise to specify which
> method would be most appropriate in this SIP/IMS internetworking scenario.

See my point above.

--