Subject: NAT-PT Applicabilty for 3GPP

From: Suresh Satapati <[email-masked]>
Date: Wed, 12 Nov 2003 15:17:43 -0800 (PST)

Randy,

The scenario in question is the one mentioned in the 3GPP Scenarios
document. Refer to RFC 3574 Section 4.2, subsection 1.

As per the analysis/solution for this specific IMS scenario, please refer
to Section 4.1 of "Analysis on IPv6 Transition in 3GPP Networks"
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-07.txt:

<snip>
    Figure 1 shows a possible configuration scenario where the SIP ALG
    is separated from the CSCFs. The translator can either be set up in
    a single device with both SIP translation and media translation, or
    those functionalities can be divided to two different entities with
    an interface in between. We call the combined network element on
    the edge of the IPv6-only IMS an "Interworking Unit" in this
    document. A SIP-specific translation mechanism, which could e.g.
    re-use limited subsets of NAT-PT [RFC2766], needs to be specified.
    The problems related to NAT-PT are discussed in appendix A.

</snip>

In the above, though a SIP-specific translation mechanism is being
recommended, I do not see how the recommended solution will be
fundamentally different from NAT-PT. In this sense, the applicability
of NAT-PT is still valid.

Thanks
--
Suresh

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Nov 2003 17:24:37 -0600

> of NAT-PT is still valid.

if A is a proper subset of B, a need for A does not mandate B,
especially if A is a very localized hack and B is global, generic,
and questionable.

randy

---

From: Suresh Satapati <[email-masked]>
Date: Wed, 12 Nov 2003 20:10:15 -0800 (PST)

Its a matter of how you deploy B, that translates to pain felt
locally or globally

Our document actually does mention the restricted deployment of B.
Besides there is no need to reinvent the wheel when there is B sitting
at PS. One could go and build what they need out of B.

--
Suresh