STUN feature for v4/v6 transition

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
jdrosencisco.com                              FAX:   (973)
952-5050
http://www.jdrosen.net 
                       PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave

STUN feature for v4/v6 transition

Thread: STUN feature for v4/v6 transition