[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: NAT-PT Applicabilty for 3GPP





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

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