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

[Suresh Satapati <satapati@cisco.com>]

Pekka

I think you are digressing too much here..

On Tue, 18 Nov 2003, Pekka Savola wrote:

> On Tue, 18 Nov 2003, Suresh Satapati wrote:
> > > 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.
>
> 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.
>

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

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.