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

[Suresh Satapati <satapati@cisco.com>]

Pekka,

> 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
> > replaced w/ an IPv4 one.
>
> 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).

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

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

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

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

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.