[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

BEHAVE Working Group                                             D. Wing
Internet-Draft                                                     Cisco
Intended status:  Informational                         October 19, 2009
Expires:  April 22, 2010


                Referrals Across an IPv6/IPv4 Translator
                  draft-wing-behave-nat64-referrals-01

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 April 22, 2010.

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 an IPv6/IPv4 translator.




Wing                     Expires April 22, 2010                 [Page 1]


Internet-Draft             IPv6/IPv4 Referrals              October 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
     2.3.  SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11



































Wing                     Expires April 22, 2010                 [Page 2]


Internet-Draft             IPv6/IPv4 Referrals              October 2009


1.  Introduction

   Historically, NATs (and firewalls) have been accused of "breaking
   referrals".  Several IPv4 protocols that perform referrals are
   discussed, including SIP, BitTorrent, and HTTP.  It is important to
   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 an IPv6/IPv4 translator
   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 translator and a DNS64 address rewriter 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 an IPv6/IPv4 translator are
   successful.  This document is not expected to be published as an RFC.
   This document is part of the consideration for the IPv6 prefix
   [I-D.xli-behave-v4v6-prefix] [I-D.baker-behave-v4v6-framework].


2.  Application Referrals Across IP Address Families

   This section describes how some applications 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 IPv6/IPv4 translator's prefix (well-known prefix versus LIR
   prefix).









Wing                     Expires April 22, 2010                 [Page 3]


Internet-Draft             IPv6/IPv4 Referrals              October 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 IPv6/IPv4
   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 April 22, 2010                 [Page 4]


Internet-Draft             IPv6/IPv4 Referrals              October 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 IPv6/IPv4 translation was not yet on the
   horizon.  So it is discussed in this document.  In this method,
   Host-A (IPv6-only) communicates across an IPv6/IPv4 translator 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+---+ 6/4 +--+ (TURN +--<Internet>---|SIP endpoint|
      |  IPv6-only |   +-----+  |server)|   \______/    | IPv4-only  |
      +------------+            +-------+               +------------+

      <--IPv6------------><---------- IPv4 ------------------------->

       Figure 3: SIP using IPv6/IPv4 Translator 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 an IPv6/IPv4 translator) and to the IPv4 network.  In a SIP



Wing                     Expires April 22, 2010                 [Page 5]


Internet-Draft             IPv6/IPv4 Referrals              October 2009


   referral, Host-A 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 Translator
          (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 Translator

   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 April 22, 2010                 [Page 6]


Internet-Draft             IPv6/IPv4 Referrals              October 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 an IPv6/IPv4 translator 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 IPv6/IPv4 translator (that is,
   on the IPv4 Internet).

   This section analyzes how such an IPv6-only SIP endpoint, exchanging
   media across an IPv6/IPv4 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  |
                        +-+--6/4--+     +--6/4----+-+
                          |    |           |      |
                          |    +---------+ |      |
                          |          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 April 22, 2010                 [Page 7]


Internet-Draft             IPv6/IPv4 Referrals              October 2009


   In the following diagram all of the hosts belong to different ISPs:
                                  :
                  IPv6 Internet          :     IPv4 Internet
                                         :
                                         :
                  Host-A-------6/4 Translator     Host-C
                  IPv6-only              :        IPv4-only
                                         :
                  Host-B-------6/4 Translator     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 IPv6/IPv4 translator 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 Translator
          device (Host-B)

   If it refers to Host-B (IPv6-only, using a different IPv6/IPv4
   translator device) or to a dual-stack host (not shown) with an IPv6/
   IPv4 translator device in the service provider, the IPv4 referral is
   also successful.  It is successful because the IPv6-only host (with a
   IPv6/IPv4 translator 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 April 22, 2010                 [Page 8]


Internet-Draft             IPv6/IPv4 Referrals              October 2009


2.1.2.3.  Referring to IPv6-only or dual-stack host without Translator
          device (Host-F)

   If it refers to Host-F (IPv6-only, with no IPv6/IPv4 translator
   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 IPv6/IPv4 translator 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 IPv6/IPv4 translator 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 IPv6/IPv4
   translator which will both authorize and route the communication to
   the IPv4 BitTorrent peer.  BitTorrent clients do not perform this
   function today.

2.3.  SMTP

   A minority of SMTP [RFC5321] clients and SMTP servers support 551 to
   redirect mail to another host,

     551 User not local; please try <forward-path>.

   If the <forward-path> includes an IPv4 address literal, the IPv6 host
   will need to know how to formulate an IPv6 packet that will traverse
   its IPv6/IPv4 translator.






Wing                     Expires April 22, 2010                 [Page 9]


Internet-Draft             IPv6/IPv4 Referrals              October 2009


3.  Security Considerations

   It is anticipated that an ISP would not allow non-customers to
   utilize the ISP's IPv6/IPv4 translator 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
   discussions on the BEHAVE mailing list.

   Thanks to Mohamed Boucadair and Philip Matthews for their review
   comments.  Thanks to Scott Brim for suggesting HTTP redirect and
   SMTP.


6.  References

6.1.  Normative References

   [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-16 (work in progress), July 2009.

   [I-D.ietf-behave-turn-ipv6]
              Perreault, S., Camarillo, G., and O. Novo, "Traversal
              Using Relays around NAT (TURN) Extension for IPv6",
              draft-ietf-behave-turn-ipv6-07 (work in progress),
              October 2009.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",



Wing                     Expires April 22, 2010                [Page 10]


Internet-Draft             IPv6/IPv4 Referrals              October 2009


              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.

   [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.xli-behave-v4v6-prefix]
              Bao, C., Baker, F., and X. Li, "IPv4/IPv6 Translation
              Prefix Recommendation", draft-xli-behave-v4v6-prefix-00
              (work in progress), April 2009.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.


Author's Address

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  dwing@cisco.com

















Wing                     Expires April 22, 2010                [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/