[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty fo r 3GPP]
As you pointed out the 3gpp-analysis draft addresses these
issues and I have no problems with that. It points to the
work to be done in SIPPING and says that such a solution
could reuse parts of NAT-PT.
IMO this discussion concerns the nat-pt applicability draft.
The outstanding issue is the understanding behind the NAT-PT
applicability draft which contains different wording. I proposed
to solve it by putting in alternative wording (in the nat-pt draft)
referring to the work that will be done in SIPPING which, as you
write below, could reuse parts of NAT-PT. That would make the
IMS parts of the nat-pt applicability draft more similar to the
3gpp-analysis draft.
/Karim
> I think there aren't any major open issues considering
> documenting this case in 3GPP Analysis
>
> - we state clearly, that "dual stack" based solution is not
> feasible and a translator is needed as a part of the solution
>
> "As the IMS is exclusively IPv6 [3GPP 23.221],
> translators have to
> be used in the communication between the IPv6 IMS and
> legacy IPv4
> hosts, i.e. making a dual stack based solution is not feasible.
> This section aims to give a brief overview on how that
> interworking
> can be handled."
>
> - we document a higher level solution and refer to SIP(PING)
> wg to make a generic solution
>
> "This section presents higher level details of a
> solution based on
> the use of a translator and SIP ALG. [3GPPtr] provides
> additional
> information and presents a bit different solution
> proposal based on
> SIP Edge Proxy and IP Address/Port Mapper. The authors
> recommend to
> solve the general SIP/SDP IPv4/IPv6 transition problem
> in the IETF
> SIP wg(s)."
>
> - because NAT-PT is the closest possible (=PS RFC) solution
> to be used in this "Interworking Unit" as a translator, we state:
>
> " 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. "
>
> - Finally, I think that documenting this case in 3GPP
> Analysis is important and details must not be dropped.
>
> Right?
>
> Cheers,
> -Juha-
>
> P.S. I still can't understand what can be so horribly bad in
> NAT-PT, but let's not start that discussion using this mail
> thread, because it isn't a 3GPP-specific problem.
>
> -----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
>
>