Subject: RE: NAT-PT Applicabilty for 3GPP

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Mon, 17 Nov 2003 16:25:08 +0100

> This may be redundant to you, but to seek WG opinion I will 
> repeat the
> argument here on this list.
> 
> > I brought up the same issue during the DT work and agree 
> with Randy's
> > point that if a scenario exists that requires a subset of 
> NAT-PT (i.e. 3GPP
> > IMS) then it does not necessarily imply that NAT-PT as 
> specified in RFC 2766
> > is applicable. The draft could however point out which 
> parts of NAT-PT are
> > applicable in this case.
> >
> > Regarding the actual SIP solution there is a reference in 
> 3gpp-analysis-07
> > to draft-elmalki-sipping-3gpp-translator-00. Following 
> Margaret's comments
> > last time and the recommendation in 
> draft-ietf-3gpp-analysis it is on the
> > SIPPING agenda this time. For those who may be interested 
> here's a new version
> > of the draft:
> > 
> >http://standards.ericsson.net/karim/draft-elmalki-sipping-3gp
> p-translator-00.txt
>
>
>This whole "subset applicability" argument stems from incorrect assumption that
>NAT-PT (RFC 2766) mandates DNS-ALG.

That is not the only issue IMO.
According to RFC 2766 an implementation will take incoming packets destined
to PREFIX::a.b.c.d and translate them to IPv4 destination a.b.c.d. It will also
locally assign and use an ipv4 source addr/port. We don't want this behaviour
when the binding between IPv6 and IPv4 address/ports is set and must be known by
an external box (e.g. SIP proxy). This is a solution we've been looking at.
NAT-PT does not allow the bindings to be set by another box. So I am still of the
opinion that what we want for the SIP case is likely to be different from RFC2766,
but that is in contrast with what is written in the applicability draft.

>
>In the past for v4 land, ALGs have been specified in separate documents.
>For e.g. RFC 2663/3022 clearly defines the role of "NAT", and for
>DNS-ALG there is RFC 2694.
>
>RFC2766 mentions DNS-ALG (and FTP-ALG) as an example, in addition to
>basic NAT-PT operation. There is no text that states NAT-PT mandates
>DNS-ALG.

It does however mandate a certain way of establishing v4/v6 address bindings
(above) and it does not consider that the bindings may be set by an external
box. To me this in effect assumes that a SIP ALG will be there to intercept
and modify packets in order to make use of the NAT-PT for SIP services. However
we already got some input from SIP folks that going for SIP editing is not a
good solution (discussions to be continued on SIP IPv6/v4 translation in SIPPING).

/Karim

---

From: Senthil Sivakumar <[email-masked]>
Date: Mon, 17 Nov 2003 09:00:03 -0800

>locally assign and use an ipv4 source addr/port. We don't want this behaviour

Can you please point out where in the NAT-PT RFC it says it should be 
locally assigned
or where it explicitly prohibits mappings installed from an external entity?

Senthil

---

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Mon, 17 Nov 2003 19:05:03 +0100

> >to PREFIX::a.b.c.d and translate them to IPv4 destination 
 > a.b.c.d. It will 
 > >also

I assume your question wants to highlight the fact that RFC 2766
doesn't rule that out. OK. Still I don't see your point? If it allows
local pools, which are in fact the most likely thing people
implement, and does not specify communication with an external box
then it is not the spec we want to recommend.

My point is that if we say NAT-PT is applicable for SIP then people
will expect to read RFC 2766 and implement it. If they do that
they are likely to implement a local pool of v4 addresses and a
SIP ALG (that does SIP editing). Since SIP folks are not in favour
of SIP editing I don't think we should say that NAT-PT is applicable
to the SIP case. It is much cleaner to create a SIP specific solution
for this case that is not related to generic NAT-PT and its problems.

/Karim

---

From: Senthil Sivakumar <[email-masked]>
Date: Mon, 17 Nov 2003 10:34:03 -0800

At 07:05 PM 11/17/2003 +0100, Karim El-Malki (HF/EAB) wrote:
>doesn't rule that out. OK. Still I don't see your point? I

My point was, RFC2766 does not mandate you installing the mappings
locally, nor does it prevent you to install mappings from an external entity,
unlike what you have stated in your earlier email.

>f it allows

NAT-PT RFC does not specify anything about how SIP ALG/Proxy should be 
implemented.
That could be a seperate document, if one needs it. If you want a SIP 
ALG/Proxy, you
could implement as per the SIP protocol specification and make use of the 
NAT-PT
header translator functionality to let the media pass through the 
translator. So NAT-PT
is applicable there and that is what is noted in the applicability 
statement. Re-inventing
something that has already been done seems to be a waste of time.

Senthil

---

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Tue, 18 Nov 2003 18:35:06 +0100

> > above which I could agree with. Also I do not think it is as simple
 > > as implementing an external SIP Proxy according to SIP specs as you
 > > say above, since some changes to the binding mechanism is needed in
 > > the translator and some interactions with other e2e 
 > protocols may be
 > > needed. Given the discussions so far I would replace the statement
 > 
 > Please spell out "some changes to the binding mechanism", and the
 > "interactions needed with other e2e protocols". Then we can debate.
 > Until then, my stance doesn't change as far as Applicability 
 > is concerned.

Have a look at the 3gpp-translator draft and the past emails.

/Karim