Subject: [BEHAVE] ICE and v4v6NATs

From: marcelo bagnulo <[email-masked]>
Date: Wed, 26 Mar 2008 19:34:42 +0100

Hi,

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.

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?
I am kind of confused cause using ICE would imply exposing v6 addresses 
to v4 nodes and viceversa, right? i don't know if that makes sense...

any comments on this would be really helpful

thanks, marcelo

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 26 Mar 2008 15:58:13 -0700

You might check out draft-rosenberg-mmusic-ice-nonsip-00.txt ("NICE") which
describes how ICE would be used in protocols-other-than-SIP.  The basics of
what ICE needs is a way for both ends (client and server) to indicate a bunch
of IP addresses and ports to the other end, and then both ends try to
establish connectivity with all of those various IP addresses and ports.  For
a v4/v6 transition strategy, of those 'bunch of IP addresses', if the address
family is the host does not understand (IPv8, let's say), or the address
family is something the host understands but knows it cannot route (IPv4,
let's say), the host will not attempt to establish connectivity using that
address family.  Connectivity is tested by doing an ICE connectivity check.

In SIP, ICE is useful for v4/v6 transition and v4/v6 interworking.  For this,
the v4-only endpoint shown in your diagram below could obtain its v4 address
(its local interface address, which is probably in a non-routable network
behind a NAT), and could obtain a v6 address from its NAT -- using, say,
Teredo (just for argument's sake; the v4 host could also use
draft-ietf-behave-turn-ipv6 to obtain a v6 address).  The v4 host would then
send a SIP message, containing both its v4 address and its v6 address towards
the v6 host.  The v6 host would receive that, and would do an ICE connectivity
check with the v6 address (the v6 host doesn't speak v4, so it would ignore
the v4 address from that SIP message).

I don't know if my description helps; I believe the problem of using ICE with
any arbitrary protocol is that each protocol would need to be demultiplexed
with STUN (draft-ietf-behave-rfc3489bis).  This is easy, from a protocol
perspective, but may be difficult from an implementation perspective.  For
example, IPsec ESP can easily demultiplex an IPsec ESP packet from a
draft-ietf-behave-rfc3489bis packet, but it requires changing the IPsec stack
to do so.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of marcelo bagnulo
> Sent: Wednesday, March 26, 2008 11:35 AM
> To: [email-masked]
> Subject: [BEHAVE] ICE and v4v6NATs
> 
> Hi,
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 27 Mar 2008 12:40:43 +0200

> boxes and ICE should be required.

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

> The scenario that we are considering is the following one:

There are two ways:

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

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

-- 
Rémi Denis-Courmont

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 18:49:35 +0100

Hi Dan,

thank you very mich for your answer, this is very helpful

Dan Wing escribió:
> describes how ICE would be used in protocols-other-than-SIP.

right, but i understood that this is more oriented to other protocols 
that need to do IPv4 NAT traversal and want to use ICE. It seemed to me 
that we are in a different case here, since we have a different NAT box, 
so i am not sure how much of that applies
>  The basics of
right
my concern was if we have an IPv4 host that is running ICE with an IPv6 
host (and a NAT64 in between), the candidates that the IPv4 host will 
learn are v6 addresses. So assuming that the IPv4 has no IPv6 
implementation, how does this works?
Note that in this case, even if the v4 has no IPv6 implementation, it is 
importnat that the v4 node send the discovered IPv6 candidate of the 
NAT64 box, cause this will be meaninful for the IPv6 peer to send 
packets to the IPv4 box.
So my understanding, is that it doesn't matter that the IPv4 box doesn't 
have an IPv6 stack, but that ICE is able to deal with the IPv6 
addressesm, discover them (using TURN or TEREDO as you mention) and send 
them to the IPv6 peer using ICE and then the IPv6 peer will be able to 
use them, right?

I mean, the point is that the v4 node will be able to handle the IPv6 
candidtes cause the ICE protocol will handle them and there is no other 
IPv6 support needed in the v4 node to support this, is that correct?

> with STUN (draft-ietf-behave-rfc3489bis).
but in this case, we would be changing the IP version rather than 
encapsulating a differnet protocol. I mean, we will not be encapsulating 
IPv6 in IPv4, but changing Ipv4 header with an IPv6 header, so we are 
likely to be able to deal with any protocol that normal IPv4 ICE deals with.

My understandiong at this point is that a NAT64 box should be able to 
support ICE, as long as it complies with the BEHAVE requirements for 
TCP, UDP and ICMP, so i was planning to include a new requirement that 
would sate something like:

- NAT64 boxes MUST comply with RFC4787, draft-ietf-behave-tcp-07.txt and 
draft-ietf-behave-nat-icmp-07.txt when applicable.

that should be enough to make ICE work?

would that make sense to you?

regards, marcelo

>   This is easy, from a protocol

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 18:55:05 +0100

> provides that mapping to the other node, as an ICE candidate.
right, this is what i had in mind

In order to make this work, i understand that there are no special 
requirements to be imposed to the NAT64 box, other than behve req for 
TCP/UDP and ICMP?

regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 28 Mar 2008 12:01:26 -0700

> From: marcelo bagnulo [mailto:[email-masked]] 
> Sent: Friday, March 28, 2008 10:50 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [BEHAVE] ICE and v4v6NATs
> 
> Hi Dan,
> 
> > You might check out 
> > draft-rosenberg-mmusic-ice-nonsip-00.txt ("NICE") which
> that we are in a different case here, since we have a 
> different NAT box, so i am not sure how much of that applies

I agree it is a different use case than v4/v6 NAT.

> learn are v6 addresses.

Yep.

> So assuming that the IPv4 has no IPv6 
> addressesm, discover them (using TURN or TEREDO as you 
> mention)

Not TURN (draft-ietf-behave-turn), but rather with TURNv6
(draft-ietf-behave-turn-ipv6).

> and send 
> them to the IPv6 peer using ICE and then the IPv6 peer will 
> be able to use them, right?

Correct.

> IPv6 support needed in the v4 node to support this, is that correct?

The IPv4-only node doesn't need IPv6 support in its operating system's
IP stack.  However, the IPv4-only node's (ICE-aware) application would 
need understand the ICE encoding of IPv6 addresses, and it would need to 
obtain a v6 address from its TURNv6 server, and it obviously needs a TURNv6
server that is able to relay the traffic from v4 to v6.

> TCP, UDP and ICMP, so i was planning to include a new 
> requirement that would sate something like:
> 

Yes, makes sense.

-d

> >>  |                                  |                      
>          |

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 20:07:07 +0100

> server that is able to relay the traffic from v4 to v6.
ok
>> would that make sense to you?
ok, will do that

thanks!

Regards, marcelo