BEHAVE Working Group D. Wing
Internet-Draft Cisco
Intended status: Informational March 4, 2009
Expires: September 5, 2009
Referrals Across a NAT64
draft-wing-behave-nat64-referrals-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes several scenarios where an IP address is
referred across a NAT64 translator.
Wing Expires September 5, 2009 [Page 1]
Internet-Draft NAT64 Referrals March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Application Referrals Across IP Address Families . . . . . . . 3
2.1. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. SIP using a Media Relay . . . . . . . . . . . . . . . 4
2.1.2. SIP without a Media Relay . . . . . . . . . . . . . . 7
2.2. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Wing Expires September 5, 2009 [Page 2]
Internet-Draft NAT64 Referrals March 2009
1. Introduction
Historically, NATs (and firewalls) have been accused of "breaking
referrals". At this point in time, the author is aware of two
widely-available protocols that operate on the IPv4 Internet which
perform referrals: SIP and BitTorrent. It is important that the
community understand how referrals can work across an address family
translator considering that existing IPv4 nodes do not understand
IPv6 addresses, referrals to IPv6 nodes behind a NAT64 will not cause
a DNS64 query, and other factors.
This document describes how referrals work in BEHAVE's "An IPv6
network to the IPv4 Internet" scenario. In this BEHAVE scenario, an
IPv6-only host utilizes a stateful NAT64 [I-D.bagnulo-behave-nat64]
to communicate to an IPv4-only host on the Internet. After this
communication is established, the document examines IPv6-only host
refers the IPv4-only host to a variety of other hosts that are
connected to the Internet.
This document is intended to assist the IETF community to understand
the scenarios where referrals across a NAT64 translator are
successful. This document is not expected to be published as an RFC.
This document is part of the consideration for a NAT64 prefix
[I-D.miyata-behave-prefix64] [I-D.baker-behave-v4v6-framework].
2. Application Referrals Across IP Address Families
This section describes how SIP and BitTorrent perform referrals
between IPv6 and IPv4, and between IPv4 and IPv6.
2.1. SIP
A SIP call involves two the SIP signaling, sent to SIP proxies, and
the media, sent directly between the SIP hosts. This is often
referred to as the SIP "trapezoid", as shown in the following figure.
This section shows that IPv4 addresses can be successfully referred
to both IPv4 hosts and to IPv6 hosts, if those IPv6 hosts support the
IPv6 transition strategy for SIP [I-D.ietf-sipping-v6-transition].
Because an IPv6 address is not referred, the success is not dependent
on the NAT64 prefix (well-known prefix versus LIR prefix).
Wing Expires September 5, 2009 [Page 3]
Internet-Draft NAT64 Referrals March 2009
SIP signaling
sip-proxy.example.com-------------------------sip-proxy.example.net
/ \
/ \
/ SIP signaling SIP signaling \
/ \
/ \
Host-A-----------------------------------------Host-B
media path
Figure 1: SIP Trapezoid
It is the media path which is interesting for SIP referrals and is
the subject of this section. The SIP signaling messages are
exchanged on the upper part of the trapezoid and is not the subject
of this section. The SIP signaling messages contain SDP [RFC4566]
which conveys the IP address and UDP port of the hosts as well as
other information (e.g., audio codec).
The IPv6 transition strategy for SIP [I-D.ietf-sipping-v6-transition]
states the requirements for the IPv6 transition:
An IPv6 node SHOULD also be able to send and receive media using
IPv4 addresses, but if it cannot, it SHOULD support STUN relay
usage [I-D.ietf-behave-turn-ipv6]. Such a relay allows the IPv6
node to indirectly send and receive media using IPv4.
Thus, all IPv6 nodes running SIP are expected to support ICE
[I-D.ietf-mmusic-ice] which allows simultaneous referral of multiple
IP addresses, even from different IP address families. IPv4-only
endpoints do not have to support ICE, although such support assists
both hosts by choosing the most optimal path (e.g., avoiding a media
relay).
There are two documented mechanisms for SIP endpoints to communicate
across IP address families. The first mechanism uses uses media
relays (TURN servers [I-D.ietf-behave-turn]) and is described in
Section 2.1.1. The second documented mechanism uses NAT64
translators, does not use media relays, and is described in
Section 2.1.2.
2.1.1. SIP using a Media Relay
Section 4.2 of [I-D.ietf-sipping-v6-transition] documents how an
IPv6-only SIP endpoint can use a media relay (a TURN-IPv6 server) to
exchange media with an IPv4-only SIP endpoint. This can be
accomplished using two methods.
Wing Expires September 5, 2009 [Page 4]
Internet-Draft NAT64 Referrals March 2009
The first method is shown in Figure 2, where the Host-A (IPv6-only)
communicates with a TURN-IPV6 [I-D.ietf-behave-turn-ipv6] server
directly (that is, using IPv6). In this communication, Host-A
allocates a relayed-transport-address from the TURN server. This
relayed-transport-address is an IPv4 address. Host-A learned
Host-B's IPv4 address via SIP signaling.
+------------+ ------ +------------+
| Host-A | +---------+ / IPv4 \ | Host-B |
|SIP endpoint+---+TURN-IPv6+--<Internet>---|SIP endpoint|
| IPv6-only | | server | \______/ | IPv4-only |
+------------+ +---------+ +------------+
<--IPv6----------------><---------- IPv4 --------------->
Figure 2: SIP using IPv6-capable Media Relay
The second method is shown in Figure 3. This method is not mentioned
in Section 4.2 of [I-D.ietf-sipping-v6-transition] because NAT-PT was
deprecated at the time and NAT64 was not yet on the horizon. So it
is discussed in this document. In this method, Host-A (IPv6-only)
communicates across a NAT64 to an TURN server. This TURN server
might be IPv4-only. Host-A allocates a relayed-transport-address
IPv4 IPv4 address from the TURN server and uses that IPv4 address to
communicate with Host-B. Host-A learned Host-B's IPv4 address via
SIP signaling.
+-------+
| IPv4 |
+------------+ | media | ------ +------------+
| Host-A | +-----+ + relay | / IPv4 \ | Host-B |
|SIP endpoint+---+NAT64+--+ (TURN +--<Internet>---|SIP endpoint|
| IPv6-only | +-----+ |server)| \______/ | IPv4-only |
+------------+ +-------+ +------------+
<--IPv6------------><---------- IPv4 ------------------------->
Figure 3: SIP using NAT64 and IPv4 Media Relay
In both Figure 2 and Figure 3 Host-A (IPv6-only) obtains the IPv4
address of Host-B via SIP signaling and uses that address for any
later referrals. Media is exchanged between Host-A and Host-B
through the TURN server, which functions as a media relay.
The following sections detail what occurs when Host-A refers Host-B's
IP address to different hosts. These hosts are connected to the
Internet in different ways: to the IPv6 internet (both with and
without a NAT64) and to the IPv4 network. In a SIP referral, Host-A
Wing Expires September 5, 2009 [Page 5]
Internet-Draft NAT64 Referrals March 2009
sends a SIP message through SIP proxies to another host. As with
most SIP messages, this SIP message contains an SDP [RFC4566]
bodypart. The SDP has the IP address and UDP port of Host-B which is
used to exchange media with Host-B.
Note that, prior to the referral, Host-A does not know (and cannot
learn) how other hosts are connected to the Internet.
2.1.1.1. Referring to IPv4-only host (Host-D)
In both methods above, Host-A knows Host-B's IPv4 address.
If Host-A (IPv6-only) refers Host-B's IPv4 address to an IPv4-only
host, the referral will be successful.
2.1.1.2. Referring to IPv6-only or dual-stack host with NAT64 device
(Host-B)
If Host-A (IPv6-only) refers Host-B's IPv4 address to an IPv6-only
host, the referral will succeed if Host-A's SIP stack understands
IPv4 addresses and can obtain an IPv4 address from a media relay
(similar to shown in Figure 3).
As part of the IPv6 transition, IPv6-only SIP implementations need to
understand IPv4 addresses, as already required (SHOULD) by IPv6
transition strategy for SIP [I-D.ietf-sipping-v6-transition].
Thus, this referral is also successful.
2.1.1.3. Referring to IPv6-only or dual-stack host without NAT64 device
If Host-A (IPv6-only) refers Host-B's IPv4 address to an IPv6-only
host, the referral will succeed if Host-A's SIP stack understands
IPv4 addresses and can obtain an IPv4 address from a media relay
(similar to shown in Figure 2).
As part of the IPv6 transition, IPv6-only SIP implementations need to
understand IPv4 addresses, as already required (SHOULD) by IPv6
transition strategy for SIP [I-D.ietf-sipping-v6-transition].
Thus, this referral is also successful.
If Host-A (IPv6-only) refers Host-B's IPv4 address to an dual-stack
host, it will succeed because the dual-stack host will be able to
successfully use Host-B's IPv4 address.
Wing Expires September 5, 2009 [Page 6]
Internet-Draft NAT64 Referrals March 2009
2.1.2. SIP without a Media Relay
Section 6.2 of [I-D.ietf-sipping-nat-scenarios] describes an IPv6-
only SIP endpoint using a NAT64 to exchange media with an IPv4-only
SIP endpoint. To do this, the IPv6-only SIP endpoint implements ICE
[I-D.ietf-mmusic-ice] and is configured with a STUN server on the
IPv4 side of the NAT64 translator (that is, on the IPv4 Internet).
This section analyzes how such an IPv6-only SIP endpoint, exchanging
media across a NAT64 translator with an IPv4-only SIP endpoint, would
refer the synthesized IPv6 address to another SIP endpoint.
[[Editor's note: which of the two diagrams, below, is clearer?]]
In the following diagram all of the hosts belong to different ISPs:
Host-A Host-B
IPv6 only IPv6 only
| |
+----+----+ +-----+-----+
| IPv6 | | IPv6 |
| Service | | Service |
| Provider| | Provider |
+-+-NAT64-+ +-NAT64---+-+
| | | |
| +---------+ | |
| IPv4| |IPv4 |
IPv6| IPv6 | | |
| +-------------------+
| | | |
| | | |
+--+---+-+ +---+-+---+
| IPv6 | | IPv4 |
|Internet| | Internet|
+-+----+-+ +-+-+---+-+
| | | | |
| | +------+ | +---+
| | | | |
Host-F | | Host-C Host-D
IPv6-only | | IPv4-only IPv4-only
| |
Host-E
dual-stack
Wing Expires September 5, 2009 [Page 7]
Internet-Draft NAT64 Referrals March 2009
In the following diagram all of the hosts belong to different ISPs:
:
IPv6 Internet : IPv4 Internet
:
:
Host-A-------NAT64 Host-C
IPv6-only : IPv4-only
:
Host-B-------NAT64 Host-D
IPv6-only : IPv4-only
:
Host-F :
IPv6-only :
Host-E
dual-stack
:
In the following scenarios, Host-A (IPv6-only) is communicating with
Host-C through the NAT64 device. Host-A knows Host-C's synthetic
IPv6 address (because it is sending traffic to it) and Host-C's IPv4
address (because it received Host-C's IPv4 address in SIP signaling).
The following scenarios describe how referrals to other nodes would
function.
Note that, prior to the referral, Host-A does not know (and cannot
learn) how other hosts are connected to the Internet.
2.1.2.1. Referring to IPv4-only host (Host-D)
If Host-A refers to Host-D (IPv4-only), only the IPv4 address can be
successfully referred. The IPv6 address cannot be successfully
referred (no matter if well-known prefix or LIR prefix).
Thus, this referral is successful.
2.1.2.2. Referring to IPv6-only or dual-stack host with NAT64 device
(Host-B)
If it refers to Host-B (IPv6-only, using a different NAT64 device) or
to a dual-stack host (not shown) with a NAT64 device in the service
provider, the IPv4 referral is also successful. It is successful
because the IPv6-only host (with a NAT64 device) or the dual-stack
host both have to be able to communicate with IPv4 hosts, as required
by IPv6 transition strategy for SIP [I-D.ietf-sipping-v6-transition].
Wing Expires September 5, 2009 [Page 8]
Internet-Draft NAT64 Referrals March 2009
2.1.2.3. Referring to IPv6-only or dual-stack host without NAT64 device
(Host-F)
If it refers to Host-F (IPv6-only, with no NAT64 device), the
referral fails because Host-F cannot communicate with any IPv4 hosts.
This failure is expected, because not only would a referral fail, but
two hosts in two different IP address families cannot initiate their
own communication -- they need an address family translator (or media
relay) or one host needs to be dual-stack.
If it refers to Host-E (dual-stack), the IPv4 address can be
successfully referred.
2.2. BitTorrent
BitTorrent trackers use HTTP URIs and DNS names. Thus, if an IPv6-
only host running a web browser can connect to an IPv4-only web site
using a translator (e.g., using NAT64 and DNS64), that same IPv6-only
host running a BitTorrent client can connect to an IPv4-only
BitTorrent tracker. While some BitTorrent trackers are beginning to
track IPv6 addresses of BitTorrent peers, most trackers only track
IPv4 peers. Most content is only available on IPv4.
When an IPv6-only BitTorrent peer obtains IPv4 addresses from its
tracker, it cannot use those IPv4 addresses. To do so, the
BitTorrent client software would need to prefix the IPv4 address with
the prefix of a NAT64 that will perform the necessary address family
translation on behalf of the IPv6-only BitTorrent client. This could
be done with updates to BitTorrent clients to prefix the IPv4 address
with the IPv6 prefix of a NAT64 translator which will both authorize
and route the communication to the IPv4 BitTorrent peer. BitTorrent
clients do not perform this function today.
3. Security Considerations
It is anticipated that an ISP would not allow non-customers to
utilize the ISP's NAT64 device.
4. IANA Considerations
There are no IANA considerations for this document.
5. Acknowledgements
This draft was fostered by discussion with Marcelo Bagnulo Braun and
Wing Expires September 5, 2009 [Page 9]
Internet-Draft NAT64 Referrals March 2009
discussions on the BEHAVE mailing list.
Thanks to Mohamed Boucadair and Philip Matthews for their review
comments.
6. References
6.1. Normative References
[I-D.bagnulo-behave-nat64]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-bagnulo-behave-nat64-02 (work in
progress), November 2008.
[I-D.baker-behave-v4v6-framework]
Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6
Translation", draft-baker-behave-v4v6-framework-02 (work
in progress), February 2009.
6.2. Informative References
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-13 (work in progress),
February 2009.
[I-D.ietf-behave-turn-ipv6]
Camarillo, G. and O. Novo, "Traversal Using Relays around
NAT (TURN) Extension for IPv4/IPv6 Transition",
draft-ietf-behave-turn-ipv6-05 (work in progress),
October 2008.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sipping-nat-scenarios]
Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet,
"Best Current Practices for NAT Traversal for Client-
Server SIP", draft-ietf-sipping-nat-scenarios-09 (work in
progress), September 2008.
Wing Expires September 5, 2009 [Page 10]
Internet-Draft NAT64 Referrals March 2009
[I-D.ietf-sipping-v6-transition]
Camarillo, G., "IPv6 Transition in the Session Initiation
Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work
in progress), August 2007.
[I-D.miyata-behave-prefix64]
Miyata, H., "PREFIX64 Comparison",
draft-miyata-behave-prefix64-00 (work in progress),
October 2008.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Author's Address
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Wing Expires September 5, 2009 [Page 11]