BOUNCE v6ops@ops.ietf.org: Non-member submission from [Rémi Denis-Courmont <remi.denis-courmont@nokia.com>] (fwd)

[Kurtis Lindqvist <kurtis@kurtis.pp.se>]

From Remi.Denis-Courmont@nokia.com Thu Mar 27 10:41:13 2008
From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= <remi.denis-courmont@nokia.com>
Organization: Nokia Devices R&D
To: behave@ietf.org
Subject: Re: [BEHAVE] ICE and v4v6NATs
Date: Thu, 27 Mar 2008 12:40:43 +0200
User-Agent: KMail/1.9.9
Cc: "ext marcelo bagnulo" <marcelo@it.uc3m.es>,
        IPv6 Operations <v6ops@ops.ietf.org>
References: <47EA9742.1070808@it.uc3m.es>
In-Reply-To: <47EA9742.1070808@it.uc3m.es>
MIME-Version: 1.0
Content-Disposition: inline
Reply-To: behave@ietf.org
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <200803271240.43429.remi.denis-courmont@nokia.com>

Le Wednesday 26 March 2008 20:34:42 ext marcelo bagnulo, vous avez =E9crit=
=A0:
> In the v6ops WG we are defining the requirements for next generation v4
> <-> v6 NATs.
> One issue that it is not clear to use (among many), is what level of ICE
> support shoudl be required, or what type of interaction between these
> boxes and ICE should be required.

Quick note: ICE packets are integrity-protected: the only thing a middlebox=
=20
can do with them: IP/port number changes, and/or drop/delay transmission.=20
Unless the middlebox is willing to re-do SHA1-hashing _and_ learns the=20
hashing material off-band from the "signaling channel", such as the chain o=
f=20
SIP proxies.

> The scenario that we are considering is the following one:
>
>  +----------------------------------+-------------------------------+
>  |           v4 Internet            |         v6 Internet           |
>  | +------+                   +------------+               +------+ |
>  | | IPv4 |                   |   NAT64    |               | IPv6 | |
>  | | only |-------------------|  v4 |  v6  |---------------| only | |
>  | | node |                   | Translator |               | node | |
>  | +------+                   +------------+               +------+ |
>  +----------------------------------+-------------------------------+
>
> Now, would it be possible to use ICE in this scenario?

There are two ways:

UNSAFish way: One node obtains an IP/port mapping within the other realm, a=
nd=20
provides that mapping to the other node, as an ICE candidate.

ALGish way: ICE candidates are translated on the signaling path. Ugly.

=2D-=20
R=E9mi Denis-Courmont