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

[Suresh Satapati <satapati@cisco.com>]

Juha,

One more thing.

You can drop:

>     The problems related to NAT-PT are discussed in appendix A. "

Since you are refering to Applicability, the above is not needed.

-- 
Suresh

>
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of ext Pekka Savola
> Sent: 18 November, 2003 00:22
> To: Suresh Satapati
> Cc: Karim El-Malki (HF/EAB); 'Randy Bush'; v6ops@ops.ietf.org
> Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty
> for 3GPP]
>
>
> On Mon, 17 Nov 2003, Suresh Satapati wrote:
> > > 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.
>
> 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).
>
> > > 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.
>
> 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.
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>
>