Subject: [BEHAVE] STUN feature for v4/v6 transition

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Jun 2007 18:18:30 -0400

STUNbis has some mysterious text in it, dealing with v4/v6 and mapped 
addreses. It says this:

  It is possible for an IPv4 host to receive a MAPPED-ADDRESS
    containing an IPv6 address, or for an IPv6 host to receive a MAPPED-
    ADDRESS containing an IPv4 address.  Clients MUST be prepared for
    this case.

The spec is entirely unclear on what it means to be prepared for this. 
Indeed, when would this even happen? Here is the deployment model 
envisioned for this case:

    Please view in a fixed-width font such as
                    Courier.

        +-----------+
        |    v4     |
        |  STUN     |
        |   Server  |
        |           |
        +-----------+               +----------+
                                    |          |
                                    | v4-only  |
                                    |   host   |
               v4 Internet          |          |
                                    +----------+

        +-----------------+
        |   v4 to v6 NAT  |
        +-----------------+

            v6 local net

         +----------+
         |          |
         | v6-only  |
         |  host    |
         |          |
         +----------+

There is a v6-only host behind a NAT. This NAT is v6 on the private side 
and v4 on the public side. It does twice-NAT; for packets outbound from 
the private to public sides, it converts the v6 source IP to a v4 
IP/port from a pool on the v4 public Internet side. It also converts the 
destination addresses from v6 to v4; the v6 address would need to be a 
v4-encapsulated v6 address or something for which there is a static 
mapping.

So the v6 only host sends a STUN request to a v6 destination. This goes 
through the NAT, which allocates the host a v4 binding and translates 
the destination to the corresponding v4 destination - the STUN server. 
The STUN server returns the v4 mapped address in the MAPPED-ADDRESS.

Now, this v6 host is going to get a STUN response that has a 
MAPPED-ADDRESS that is v4. If we consider the usage of STUN binding 
indication without ICE as a simple example, the v6-only host would 
include the v4 address into the SDP of an INVITE, and send it out. If 
the target host is v4-only as in the picture, the media will work from 
the v4-only host to the v6 host.

The story is similar with ICE and it works quite well in fact.

None of this requires the v6-only host to have a v4 address, it just 
needs to 'be prepared' to use a v4 address in this way. Now, there are 
lots of other things you need to assume are working in this story for 
the whole thing to come together, but this is the envisioned use case.

So, are people interested in this use case? Is this a valid transition 
scenario? If not, we can remove this vague text from 3489bis. If so, we 
need to add some clarity about what it means.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 09 Jun 2007 10:51:46 +0300

Hi,

I think we should remove the text from the STUNbis spec. We should talk 
about these issues in draft-ietf-behave-turn-ipv6-02.txt. We have had 
some good discussions on this draft on this list and I will be putting 
together a new revision reflecting our conclusions as soon as I can 
(right now, I am on the road).

Regarding the use case you provide in your email, note that the NAT-PT 
spec is being moved to Historic. Therefore, you are right to question if 
that is a valid transition scenario:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-historic-00.txt

In any case, I agree with you that the STUNbis spec is not the place to 
deal with those issues. If we wanted to cover the few legacy networks 
using NAT-PT for v4/v6 transition directly in the STUNbis spec, we could 
say that a client receiving an address whose address family it 
understands, it can use it. If the address family, and thus the address 
itself, is not understood, it is discarded.

Cheers,

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Jun 2007 10:20:37 -0400

OK, so suggest that perhaps the text say that handling of a 
mapped-address using a different address family is outside the scope of 
this specification, and clients that don't know what to do with it, 
should treat it as an error.

-Jonathan R.

Gonzalo Camarillo wrote:

>> There is a v6-only host behind a NAT. This NAT is v6 on the private 
>> side and v4 on the public side. It does twice-NAT; for packets 
>> outbound from the private to public sides, it converts the v6 source 
>> IP to a v4 IP/port from a pool on the v4 public Internet side. It also 
>> converts the destination addresses from v6 to v4; the v6 address would 
>> need to be a v4-encapsulated v6 address or something for which there 
>> is a static mapping.
>>
>> So the v6 only host sends a STUN request to a v6 destination. This 
>> goes through the NAT, which allocates the host a v4 binding and 
>> translates the destination to the corresponding v4 destination - the 
>> STUN server. The STUN server returns the v4 mapped address in the 
>> MAPPED-ADDRESS.
>>
>> scenario? If not, we can remove this vague text from 3489bis. If so, 
>> we need to add some clarity about what it means.
>>
>> Thanks,
>> Jonathan R.
> 
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 11 Jun 2007 10:02:29 +0300

On Saturday 09 June 2007 01:18:30 ext Jonathan Rosenberg wrote:
> Indeed, when would this even happen?

My main concern with this text is that it breaks terribly whenever the server 
sends a redirect to another server, as the client has no idea how to send 
traffic to a server that has a different address family than the one it is 
using.

That being said, while v6/v6 NATs are not supposed to be used (so that IPv6 
binding discovery should not be ever needed, though keep-alives might well 
be), there are v6-to-v4 NATs. I just do not know if we need to care about 
them, since I assume they are pretty scarce. There might also be v4-to-v6 
NATs later on to connect legacy devices, but I guess they won't handle IPv6 
addresses from STUN properly anyway.

Therefore, I am overall fine with suppressing the sentence.

Regards,

-- 
Rémi Denis-Courmont