[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

DISPATCH working group                                           D. Wing
Internet-Draft                                            A. Yourtchenko
Intended status:  Standards Track                                  Cisco
Expires:  February 28, 2011                              August 27, 2010


        Migrating SIP to IPv6 Media Without Connectivity Checks
                  draft-wing-dispatch-v6-migration-00

Abstract

   During the migration from IPv4 to IPv6, it is anticipated that an
   IPv6 path might be broken for a variety of reasons, causing endpoints
   to not receive RTP data.  Connectivity checks would detect and avoid
   the user noticing such a problem, but there is industry reluctance to
   implement connectivity checks.

   This document describes a mechanism allowing dual-stack SIP endpoints
   to attempt communications over IPv6 and fall back to IPv4 if the IPv6
   path is not working.  The mechanism does not require connectivity
   checks.

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 February 28, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the



Wing & Yourtchenko      Expires February 28, 2011               [Page 1]


Internet-Draft  Happy Eardrums: SIP Media IPv6 Migration     August 2010


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  Operation for connectionless media (RTP over UDP) . . . . . . . 3
   4.  Operation, connection-oriented media (TCP)  . . . . . . . . . . 4
   5.  Considerations for recvonly/sendonly/inactive . . . . . . . . . 5
   6.  Bandwidth, Delay, and Asymmetric Results  . . . . . . . . . . . 5
   7.  Session Description Protocol  . . . . . . . . . . . . . . . . . 5
   8.  Sending SIP Re-Invite . . . . . . . . . . . . . . . . . . . . . 6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     12.1.  Normative References . . . . . . . . . . . . . . . . . . . 7
     12.2.  Informational References . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8





















Wing & Yourtchenko      Expires February 28, 2011               [Page 2]


Internet-Draft  Happy Eardrums: SIP Media IPv6 Migration     August 2010


1.  Introduction

   During the deployment of a dual-stack network and dual-stack SIP
   endpoints, the IPv4 network is likely to remain more robust and
   reliable than the newly-deployed IPv6 network.  An IPv6 network might
   be a disconnected island (not connected to another IPv6 network) or
   due to human error a firewall rule or routing error might prevent two
   IPv6 networks from communicating.  Non-SIP applications and their
   underlying hosts typically follow IPv6 address selection [RFC3484]
   which prefers IPv6 over IPv4, but will try IPv4 after timing out
   connection attempts to the IPv6 address.  This timeout obvious
   negative effects on the user's experience to such a degree that IPv6
   has been avoided by many large content providers on the Internet
   [whitelist].

   To achieve a similar function on the media plane, SIP endpoints are
   expected to use connectivity checks [RFC5245] to ensure there is IPv6
   (or IPv4) connectivity.  ICE has an advantage over the technique
   currently used by web browser, in that ICE does not wait for a user-
   noticeable timeout before trying other addresses.  However, ICE is
   considered overkill for the problem of migrating to IPv6 because of
   the overhead of timers, interaction with existing media state
   machines, and CPU impact of SHA1 on large devices processing many
   sessions and on small devices.

   The mechanism described in this document avoids these problems by
   combining the idea of "media-latching" (commonly used by SBCs,
   [I-D.ietf-mmusic-media-path-middleboxes]) with the preference for
   IPv6, while allowing dual-stack hosts the ability to fall back to
   IPv4.  In this way, dual-stack endpoints do not suffer broken media
   if the IPv6 network between two endpoints is down.


2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Operation for connectionless media (RTP over UDP)

   Offers and Answers are constructed containing both IPv6 and IPv4
   addresses, using an agreed-upon SDP syntax (see Section 7).  When a
   dual-stack SIP UA has media to send, it sends the media over IPv6,
   while at the same time simultaneously sending T milliseconds worth of
   data (Section 6) of the media over IPv4 using the same RTP sequence
   numbers and timestamps as thats RTP data sent over IPv6.



Wing & Yourtchenko      Expires February 28, 2011               [Page 3]


Internet-Draft  Happy Eardrums: SIP Media IPv6 Migration     August 2010


      Note:  an alternative is for y% of packets to be sent over IPv6,
      and x% of packets to be sent over IPv4 (x+y=100%).  For example,
      50%/50%, 90%/10%, or 10%/90%.  This has an advantage that we don't
      double the bandwidth used; however, it has the drawback that if
      IPv6 is broken, it is noticeable to the user.

   With two endpoints, Alice and Bob, there are four situations:

   1.  IPv6 from Alice to Bob is working and IPv6 from Bob to Alice is
       working.  This is the only situation handled by other proposed
       techniques which do not perform connectivity checks.

   2.  IPv6 from Alice to Bob is working, but IPv6 from Bob to Alice is
       failing

   3.  IPv6 from Alice to Bob is failing, but IPv6 from Bob to Alice is
       working

   4.  IPv6 from Alice to Bob is failing, and IPv6 from Bob to Alice is
       failing

   The success scenario (1) is straightforward.  To deal with the
   failure scenarios (2-4), the following procedures are followed by the
   endpoints:

   If a SIP endpoints has received T/2 milliseconds worth of RTP data
   over IPv4, and no packets over IPv6, it knows the IPv6 path from its
   peer is not working (it is the receiving peer in scenario 2, 3, or 4,
   above).  It assumes the IPv6 path to its peer is also not working,
   and assumes the IPv4 path to its peer is working.  So, it ceases
   sending RTP (and RTCP) over IPv6 and sends all subsequent RTP (and
   RTCP) over IPv4.

   If a SIP endpoint is sending RTP over IPv6 and receives ICMP hard or
   soft errors, it immediately stops sending RTP over IPv6 and starts
   sending RTP (and RTCP) over IPv4.  ICMP errors received from sending
   IPv4 are processed normally (they are usually ignored).

   Both endpoints MUST support Symmetric RTP and RTCP [RFC4961], which
   is already widely implemented and also a requirement of SBC 'media
   latching' [I-D.ietf-mmusic-media-path-middleboxes].


4.  Operation, connection-oriented media (TCP)

   First completed TCP handshake wins.  [[To be completed.]]





Wing & Yourtchenko      Expires February 28, 2011               [Page 4]


Internet-Draft  Happy Eardrums: SIP Media IPv6 Migration     August 2010


5.  Considerations for recvonly/sendonly/inactive

   An endpoint only sends RTP when it normally needs to send RTP.  Thus,
   if an endpoint is currently in 'recvonly' or 'inactive', it won't
   send RTP.  However, it may of course be receiving RTP over IPv6 or
   over IPv4.  This provides an indication to the receiver that the
   (incoming) IPv6 or IPv4 path is working.  Just as if it was sending
   RTP, the receipt of only IPvX indicates the IPvY path is broken.
   Thus, when it does eventually need to send RTP packets, it SHOULD
   only send using the working (IPvX) path.


6.  Bandwidth, Delay, and Asymmetric Results

   If IPv6 is not working and a switchover to IPv4 occurs, there will be
   an audible artifact (or visible artifact, if using video).  This can
   be avoided by sending data simultaneously over IPv4 and over IPv6
   until both ends see IPv6 traffic and both ends stop sending over
   IPv4.  However, this causes twice the bandwidth consumption at the
   beginning of the phone call and is undesirable.  That is why only "T"
   milliseconds of traffic are proposed to be sent.

   It is possible that IPv6 works in one direction but not the other.
   This can result in a false positive on one endpoint.  When this
   occurs, the other endpoint will have received no IPv6 packets (but
   will have received IPv4 packets), and will thus switch over to IPv4.
   So, this is self correcting and the traffic will be sent over IPv4.


7.  Session Description Protocol

   A new SDP session-level attribute, happy-eardrums, is defined.  It
   contains one value, T, expressed in milliseconds.  Presence of this
   attribute indicates the endpoint supports the mechanism described in
   this document.  The happy-eardrums attribute adheres to the RFC 4566
   "attribute" production.  The ABNF syntax of happy-eardrums is
   provided below:

                he-attribute = "a=happy-eardrums=" he-value
                he-value     = 1*5DIGIT

   Additionally, it is necessary to have SDP which encodes the IPv6
   address and port.  ANAT [RFC4091] has poor backwards compatibility
   with devices that do not understand ANAT, thus it SHOULD NOT be used.
   Superior to ANAT are the encodings described in
   [I-D.hutton-mmusic-icemicrolite], [I-D.boucadair-mmusic-altc], and
   [I-D.ietf-mmusic-sdp-capability-negotiation].




Wing & Yourtchenko      Expires February 28, 2011               [Page 5]


Internet-Draft  Happy Eardrums: SIP Media IPv6 Migration     August 2010


   However, for the mechanism in this draft to function, the Answer MUST
   include both IPv6 and IPv4 addresses in its answer.  All of the
   existing mechanisms (enumerated above) do not provide this
   functionality.  For example, ANAT recommends the answerer set the
   port number to 0 in the answer, and [I-D.hutton-mmusic-icemicrolite]
   has the answer only include the candidate address family.  Thus,
   existing O/A procedures for communicating IPv6 address do not work,
   as-is, with the mechanism proposed in this document.

      Note:  this draft is not dependent on any particular SDP encoding
      of IPv6.  But, of course, it does require that all end nodes use
      the same SDP encoding of IPv6.  A consensus on backwards-
      compatible IPv6 SDP encoding still needs to be reached.


8.  Sending SIP Re-Invite

   To provide information to on-path devices that elevate the QoS for
   certain flows, and to release resources on the other endpoint, an
   endpoint MUST send a SIP re-INVITE after it has decided which IP
   address family to use. [[details to be added.]]


9.  Security Considerations

   An attacker, sending UDP data on IPv6 to a newly-starting endpoint
   within the negotiated T time, could cause the endpoint to think IPv6
   is working when IPv6 is failing.


10.  Acknowledgements

   This idea was inspired from discussions with attendees and invitees
   to the SIP/IPv6 Bar BoF at IETF78.

   Thanks to Simon Perreault for his review.  Thanks to Marc Petit-
   Huguenin for his review, and for suggesting the 90%/10% media split.
   Thanks to Muthu Perumal for suggesting re-invite after deciding which
   address family works, and explaining problem with semantics of
   current mechanisms to exchange IPv6 address in SDP.

   The nickname of this draft is derived from Happy Eyeballs, which
   provides quick delivery of IPv6 or IPv4 content to HTTP browsers
   [I-D.wing-http-new-tech].







Wing & Yourtchenko      Expires February 28, 2011               [Page 6]


Internet-Draft  Happy Eardrums: SIP Media IPv6 Migration     August 2010


11.  IANA Considerations

   Register new SDP attribute.


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC4961]  Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
              BCP 131, RFC 4961, July 2007.

12.2.  Informational References

   [I-D.boucadair-mmusic-altc]
              Boucadair, M., Kaplan, H., Gilman, R., and S.
              Veikkolainen, "Session Description Protocol (SDP)
              Alternate Connectivity (ALTC) Attribute",
              draft-boucadair-mmusic-altc-00 (work in progress),
              February 2010.

   [I-D.hutton-mmusic-icemicrolite]
              Hutton, A. and J. Elwell, "A mechanism for conveying
              alternate addresses using ICE syntax",
              draft-hutton-mmusic-icemicrolite-01 (work in progress),
              March 2010.

   [I-D.ietf-mmusic-media-path-middleboxes]
              Stucker, B. and H. Tschofenig, "Analysis of Middlebox
              Interactions for Signaling Protocol Communication along
              the Media Path",
              draft-ietf-mmusic-media-path-middleboxes-03 (work in
              progress), July 2010.

   [I-D.ietf-mmusic-sdp-capability-negotiation]
              Andreasen, F., "SDP Capability Negotiation",
              draft-ietf-mmusic-sdp-capability-negotiation-13 (work in
              progress), March 2010.

   [I-D.wing-http-new-tech]
              Wing, D., Yourtchenko, A., and P. Natarajan, "Happy
              Eyeballs: Trending Towards Success (IPv6 and SCTP)",



Wing & Yourtchenko      Expires February 28, 2011               [Page 7]


Internet-Draft  Happy Eardrums: SIP Media IPv6 Migration     August 2010


              draft-wing-http-new-tech-01 (work in progress),
              August 2010.

   [RFC4091]  Camarillo, G. and J. Rosenberg, "The Alternative Network
              Address Types (ANAT) Semantics for the Session Description
              Protocol (SDP) Grouping Framework", RFC 4091, June 2005.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [whitelist]
              Google, "Google IPv6 DNS Whitelist", March 2008,
              <http://www.google.com/intl/en/ipv6>.


Authors' Addresses

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

   Email:  dwing@cisco.com


   Andrew Yourtchenko
   Cisco Systems, Inc.
   6a de Kleetlaan
   Diegem  1831
   Belgium

   Email:  ayourtch@cisco.com
















Wing & Yourtchenko      Expires February 28, 2011               [Page 8]


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