SIP collides with IPv6

Transcription

1 collides with IPv6 Thomas Hoeher and Slobodanka Tomic ftw. (Telecommunications Research Center Vienna) Vienna, Austria Richard Menedetter Institute of Broadband Communications Technical University Vienna Vienna, Austria Abstract In the near future we are faced with the challenge to provide based services in heterogeneous IP networks. Call signaling as well as media transport for Voice over IP (VoIP) must traverse interconnected IPv4 and IPv6 network domains to work successfully. Indeed there are several classical IPv6 transition techniques but are they appropriate for voice interaction? On the one hand signaling requires reliable IP interworking as mostly UDP is used as the transport protocol of choice and on the other hand VoIP undergoes harsh conditions in terms of delay, jitter and packet loss which makes it hard to guarantee adequate voice and interaction quality. In this paper we consider both the theoretical and practical aspects regarding different approaches for transitioning over heterogeneous IP networks. In order to evaluate the strength and weaknesses we designed a testbed architecture that enables us to investigate many transition scenarios in a very simple way. Thus we are able to conduct performance evaluation and characterization which are important issues for the Next Generation Network (NGN). 1. Introduction Apparently the industry has taken the decision; (Session Initiation Protocol) [9] will be the signaling protocol of choice for services in the Next Generation Network (NGN). The main arguments for compared to, for instance, H.323 are that it follows the basic concepts of the Internet and is a simple text-based protocol. In this paper we are only focusing on the Voice over IP (VoIP) signaling capability of, while leaving out other features like the Presence Extension. Several years ago the IETF (Internet Engineering Task Force) laid the foundation for NGN by defining the conditions and requirements for a converged all IP network. The ubiquitous term convergence stands primarily for one network accommodating traditional fixed as well as mobile telephony services. Following the new challenges the IETF developed a modern successor for the current Internet Protocol (IP), these days known as IPv6 [3]. The transition from IPv4 to IPv6 can solely happen in an incremental manner as we are confronted with a redeveloped IP protocol. This means that we require techniques during the transition, which enable co-existence and interconnection [11]. This paper is organized as follows. We consider the theoretical and practical aspects of transitioning over heterogeneous IP networks as two complementing topics. In the next section we describe the gradual transition of heterogeneous IP networks. In Section 3 we briefly introduce and the impacts of IPv6 transition. The practical aspects of transitioning are covered in Section 4. The basis for our practical research is the universal testbed architecture we developed in which almost every transition scenario for can be emulated. 2. Reflecting the heterogeneous IP-world The transition to IPv6 can definitely not be accomplished overnight. In fact, it is more an incremental process which will probably take decades and the question is whether it will be ever completed, as there are still some concerns regarding the necessity of full transition. In general, the IP transition following the five stages approach [7] can be envisioned. It includes: Stage 1 - IPv4 only networks Stage 2 - IPv6 islands connected through IPv4 network Stage 3 - Interconnection of IPv4/IPv6 networks Stage 4 - IPv4 islands connected through IPv6 network Stage 5 - Pv6 only networks Currently we are situated in Stage 2, as the core In-

2 ternet operates as IPv4 network. For some years the landscape of IPv6 islands started to scale up, especially countries in Asia, like Japan or Korea are strongly furthering IPv6. Moreover, parallel to the existing IPv4 Internet, several sites have already started to equip their infrastructure with dual-stack hosts. Today only a small number of Internet sites are effectively IPv6 enabled and reachable, but the trend points heavily towards a global IPv4/IPv6 mixed Internet Transition technologies on demand This subsection points out the field of application of different transition technologies in various use-case scenarios and transition stages. Principally, transition mechanisms are classified into three groups [12]: Dual-stack - Network nodes are equipped with both an IPv4 and an IPv6 stack to enable the maximum of flexibility and reachability. As a short term goal each Internet server should be provided dual-stack for further the spread of IPv6. Tunnelling - Currently, this is the most broadly applied techniques to connect IPv6 islands over the IPv4 core Internet. For this purpose IPv6 packets are encapsulated into IPv4 packets. Techniques like 6to4, Teredo, or static tunnels are state-of-the-art. Translation - In case when a native IPv4 and a native IPv6 domain are to be directly interconnected, one of the translation techniques, like NAT-PT (Network Address Translation - Protocol Translation) has to be deployed. The connection of two IPv6 islands will be tunnelled as long as the core Internet applies only IPv4. At the demarcation points between IPv6 islands and the IPv4 Internet translation must be deployed. Also imaginable is that mobile nodes will only support either IPv4 or IPv6 so there is also need for tunnelling or Translation. Dual-stack capability can be expected in all new networks, in the extensions of already existing networks, or network updates. The case for IPv4 islands, in particular with the local IPv4 addresses is still considered by some providers but its benefits remain to be understood. It could be assumed that as soon as an IPv4/IPv6 mixed Internet comes real, the application of tunnelling and translation will radically decrease. 3. and its IPv6 relation (Session Initiation Protocol) is an application layer protocol for signaling multimedia and multiparty sessions. In this paper we focus on for VoIP, that is, we mainly consider establishing, modifying and releasing VoIP calls. In general, VoIP requires the interworking of two layers, one intended for signaling a call and the other one used for transporting the media. For our further discussion we are assuming the Real-Time Transport Protocol (RTP) [10] for media exchange at a glance A basic scenario (as depicted in Figure 1) also known as trapezoid involves four different components: User Agent (UA) is logical entity that integrates UA server and UA client functionality, mostly referred to as client application. (Out-/Inbound) Proxy Server is used for routing the signaling messages. Each domain is at least served by one Proxy Server that commonly embeds the functionality of a Registrar (interacts with UAs and Location Server) and a Redirect Server (generates 3xx responses to redirect UAs in case of other responsibility). DNS (Domain Name System) Server resolves names into IP-addresses and vice versa. domain Location Server (LS) stores and provides location information about users, is of especial interest for Proxy and Redirect Server functionality to locate callee s. Outbound Proxy Server DNS Server User Agent Media (RTP) Location Server Figure 1. trapezoid Inbound Proxy Server User Agent The following abstract gives an overview about how the mentioned entities collaborate and how a basic call is set up. Capitalized words identify standardized methods used to describe procedures, mostly applied in the context of a

3 dialog (peer-to-peer relationship between two UAs). Normally, a UA registers at its domain serving Registrar, that stores the current location information in LS, and in this way becomes globally available (REGISTER). Direct calls without registering are imaginable but out-of-scope in terms of carrier-grade implementations. Afterwards a UA can contact another UA by exchanging signaling information through its dedicated outbound Proxy Server which carries out the routing function. Address resolution of the next routing hop is done by contacting the DNS Server. The next routing hop could be an intermediate Proxy Server or the corresponding inbound Proxy Server or a PSTN Gateway. Information related to the call session (like media codec or used RTP ports) is carried in the Session Description Protocol (SDP) [5], in the payload of the session establishment message (INVITE) and the subsequent acknowledgement (ACK). The following three methods must be essentially supported as well: ACK replies INVITE with the callee s session parameters, CANCEL used to abort a previous request, and BYE terminates a session or even the attempt and IPv4/IPv6 Transition To underline the effects of the IPv4/IPv6 Transition on the services the issues related to the network layer, signaling layer, and media layer [1] could be individually considered: Network Layer Issues - From the network view the main requirement is the IPv6 reachability: components must be accessible either per native IPv6 or via one of the transition technologies. Given that we are steering towards the IPv4/IPv6 mixed Internet as mentioned in Section 2, dual-stack capability will vitally relieve the issues of heterogeneous architecture. In other words, to provide services also in IPv6, the critical components must be IPv6 enabled or at least reachable. Signaling Layer - In this paper Signaling Layer covers both protocols substantial to signal a call session, namely and DNS (Domain Name System). - The native IPv6 scenario demands no additional adaption as compared to the native IPv4 except IPv6- enabled components. The real challenge however is the interworking of IPv4 and IPv6 domains as carries IP-addresses in its header-structure. This necessitates the introduction of Application Layer Gateways (ALG) or other facilities adapting the headers appropriately. In fact, there are two possible solutions for the interconnection of an IPv4 and an IPv6 domain: NAT- PT collaborating with a -ALG, and a Proxy Server acting as a B2BUA (Back-to-Back User Agent) for both domains. Generally, both are -aware with individual pros and cons. The most important constraint for both approaches is that during a session each signaling message must traverse the same transition point. The reason therefore lies in the signaling of the media channel as the IPv4/IPv6 translation points must be also negotiated which causes rewritting of the -headers and the SDP part of the header. To insert such an interconnection device permanently into the signaling path the Record-Route header is used. This -header enforces routing through network node, for instance NAT-PT or Proxy Server, and must be appropriately rewritten depending on the network leg (IPv4/IPv6) the message traverses. If during a dialog only domain names are applied the issue is reduced to a minimum, at least for the -headers, since SDP further mainly embeds pure IP-addresses but this is an aspect of the Media-Layer. DNS - In general, DNS is used to resolve the domain names of serving out-/inbound Proxy Servers into their corresponding IP-addresses. There are two possible ways to obtain the IP-address of a Proxy Server: by requesting the A/AAAA-record (A-record for IPv4 and AAAA-record for IPv6) or by requesting the SRVrecord (SeRVice-record for ). To support in IPv6, the IP-addresses of relevant Proxy Servers must be registered in the DNS database. This requires that DNS servers (and their associated zonefiles) are updated with new records. For the dual-stack Proxy Servers both IPv4 and IPv6 addresses should be included in the DNS-database so that both IPv4 and IPv6 User Agents can be served in the same domain. Media Layer - In the session establishment message (IN- VITE) transports an SDP payload to negotiate the attributes of the media session including codec, transport address, and protocol. Once again, the interworking of heterogeneous networks (IPv4/IPv6) is an issue. For the purpose of interworking the media relay is necessary, which listens on the negotiated ports and translates the packets between two domains. The deployed media transport protocol, mostly RTP (Real-Time Transport Protocol), is completely unaffected as it only delivers coded media data. Normally, the ports for media are negotiated between the corresponding UAs but in a scenario with the interworking node the -ALG or Proxy Server overtakes this duty. It signals a known media relay which port to use in IPv4 and in IPv6. -translator controls which media relay should be used and is therefore, able to adapt the SDP transport address/port appropriately. Hence, both UAs (IPv4/IPv6) get

4 the media relay as corresponding media endpoint communicated within the corresponding INVITE message. The last sections showed a pure theoretical point-of-view. At this stage of /IPv6 development and standardization almost all major challenges are solved but the availability of the practical implementations is still not fully given. The following sections concentrate on practical implementations. 4. Approaches/Strategies for Transition The IPv6 transition and its techniques are in general a well understood and widely elaborated topic. However, application-specific challenges are still present and the meaningful performance findings about the different approaches are still missing. In this first step of our current project on /IPv6 Transitioning we are considering the aspects as well as impacts of transition. For that purpose we investigate the techniques of dual-stack, tunnelling, and proxying (translation) Dual-stack Dual-stack hosts have two native IP-addresses, one IPv4 and one IPv6 one. A Dual-stack node communicates with every host, be it IPv4 or IPv6, with its native IP version. These hosts also have two DNS entries, one for every IP version (e.g. A and AAAA record are both specified). The big drawback to this solution is, that every node needs two IP-addresses, which is not practical, as IPv4-addresses are a sparse commodity. An additional issue is the need to manage two address spaces in your dual-stack network. In our testbed the upcoming tests IPv4-IPv4 and IPv6-IPv6 measurements will form the performance baseline, against which the other solutions will be compared to Tunnelling Tunnelling mechanisms are used to connect to isolated IPv6 islands. The tunnelling endpoints are dual-stack routers, which encapsulate IPv6 traffic destined for another IPv6 cloud. This is done by shipping the IPv6 packet over the IPv4 Network, usually by pre-pending it with an IPv4 Header. Apart form the manually configured protocol-41 tunnels, we will have a closer look at two different automatic tunnelling mechanisms. These are: 6to4 [2] tunnels use the existing IPv4 address of a router, and derive a special IPv6 addresses of it. The Format of 6to4 addresses is depicted in Figure 2. The 6to4 prefix is It is followed by the hexadecimal representation of the IPv4 address. Each IPv4 address provides an 80-bit subspace of IPv6 addresses. This space is usually partitioned into a 16-bit Subnet field and a 64-bit Host field. 128 Prefix Embedded v4 IP SubnetID IPv6 packets are encapsulated into Host Identifier 16 bits 32 bits 16 bits 64 bits 64 Figure 2. Structure of an 6to4 address IPv4 packets and sent over the IPv4 network. If a 6to4 node communicates directly to another 6to4 node, then the packets are directly exchanged between the IPv4 addresses, which are embedded in the 6to4 address. If a 6to4 node wants to contact a native IPv6 node, then it has to use the help of a 6to4 relay router, which acts as the default IPv6 gateway for all non-6to4 hosts. Teredo [6] is a transitioning mechanism, which can also be used if the host is located behind an IPv4 Network Address Translator (NAT). This is achieved by using UDPv4 packets to traverse the NAT device. Teredo involves several nodes with different duties: Teredo Clients - These nodes which located behind the NAT and are seeking IPv6 connectivity. Teredo Servers - The Servers are needed to establish a tunnel configuration. However they are stateless and do not need much bandwidth. Teredo Relays - The Relays are the instances which do the actual work. They forward packets on behalf of Teredo Clients. They usually have very high bandwidth requirements. In Figure 3 the structure of a Teredo address is shown. The Teredo Prefix has recently changed, as the IANA has 128 Prefix Teredo Server v4 Flags UDP Port 32 bits 32 bits 16 bits 16 bits 64 Public IPv4 32 bits Figure 3. Structure of an IPv6 Teredo address assigned a non-experimental prefix, which is 2001:0000. Presently only one bit of the Flags field is assigned. It is used to give a hint if the client is behind a full-cone NAT. The UDP port and the public IPv4 are fields which denote the public side of the NAT through which the Teredo Client can be reached. The last two fields are obfuscated through bitwise XOR-ing with 1. This is done, because some NAT 0 0

5 devices exchange the IP Address in the payload of an IPv4 packet, which would render the communication mechanism useless. Proxying [4] is an elegant solution for the transitioning system. The basis of this is a Proxy Gateway which is dual-stack, and is located in between the Proxy chain, that messages traverse. The Proxy Gateway acts as a Back-to-Back User Agent (B2BUA). This means that it terminates the call-leg, on one of its interfaces, processes the packets for that connection (e.g. translates the IPv4 into IPv6 and vice versa) and starts another call-leg on the other interface. Thus transactions are split up into two connections, one IPv4 connection between the IPv4 User Agent and the IPv4 address of the Proxy Gateway, and another connection between the IPv6 address of the Proxy Gateway and the native IPv6 UA. Additionally, RTP media traffic, must also be translated from IPv4 to IPv6 (and vice versa). This is done by using a Media Gateway (or Media Relay), which is controlled by the Proxy Gateway through an UDP socket (e.g. what addresses/ports to listen on, and where to forward RTP streams). An architectural overview is given in Figure 4. In the course of building up our testbed we evaluated To cover all possible approaches for transition we designed a special testbed architecture enabling all important scenario configurations. The starting point for our testbed development were two profiles of requirements, namely, regarding the architecture, also defined by the trapezoid and regarding the IPv6 transition techniques. Our major intension is to conduct performance measurements related to one-/two-way delay, jitter and packet loss. The cloud in Figure 5 identifies a virtual network back- monitor ADSL-link hub 2 Mbps-link IPv4/IPv6 Backbone networkemulaton7radon n7xenon n7argon hub NTP 2 Mbps-link ADSL-link hub Figure 5. Testbed Architecture monitor n7krypton Proxy A IPv6 User Agent A IPv6 RTP Gateway Proxy Gateway UDP Control Media Gateway RTP Proxy B IPv4 User Agent B IPv4 Figure 4. Typical Proxying Scenario two different Proxying solutions, whereas both met our expectations in terms of implementation, configuration, and functionality. The mentioned solutions are Mini Proxy (MSP) [8] developed by Fraunhofer FOKUS and the SER extension module called nathelper. 5. Introducing a universal testbed bone which represents two possible environments. First we are able to carry out a closed laboratory evaluation by directly interconnecting the components via domain-serving hub. The second approach enables us to conduct a so called real world test in which traffic is leaving the local network using the depicted links. Hence, we can obtain realistic performance results and Telekom Austria is able to further analyze and process our network load. Independent of which backbone setup is deployed each link is IPv4- and IPv6-enabled. The nodes n7radon and n7krypton are acting as User Agents. To generate traffic we use KPhone (with IPv6 support) as it is an IPv4- and IPv6-enabled client and p to introduce script-based automation. The main field of application for KPhone is the proof-of-concept.; we use the client to evaluate new transition scenarios and applications respectively. Additionally, p is used to support automatic measurement procedures and generate load (concurrent calls). Generally, n7xenon and n7argon are primarily intended to act as domain-serving Proxy Servers using SER ( Express Router) and OpenSER. Given that our testbed should provide a high level of flexibility and implement almost every IPv4/IPv6 interworking scenario, also tunnelling techniques like Miredo (Linux-based Teredo implementation) or 6to4 are setup. Additionally, both Proxy Servers can concurrently listen on IPv4 and IPv6. To emulate the impact of Wide Area Networks as well we

6 use one computer (network emulator) acting as router and running a tool called netem based on iproute2. The network emulator enables us to introduce delays or packet loss ratios according to statistical algorithms. Additionally, this tool provides packet duplication and re-ordering as well as traffic shaping. We are able to characterize intermediate networks and emulate realistic situations. The network emulator machine additionally implements essential network services like DNS, DHCP (Dynamic Host Configuration Protocol) for IPv4 as well as IPv6 router advertisements. As depicted in Figure 5, there are two monitors which are recording network traffic for further processing. For that purpose we are applying ethereal as graphical user interface and scripted tcpdump for test automation One-way delay measurement using NTP (Network Time Protocol) A well known challenge in performance evaluation is the measurement of the one-way delay. The issue lies in the fact that both endpoints must share the same time base. In other words, clock synchronization is required. As all testbed nodes are equipped with a second network interface we set up a shadow network only used for time synchronization. The network emulator acts as NTP server that maintains the reference clock. Our first approach only accesses the local computer time without external trigger but in future DCF77 and/or GPS (Global Positioning System) will be deployed. This means that, currently the synchronization is based on a relative time but with an external trigger we can provide UTC (Universal Time Coordinated). For our purpose the deployment of a relative time base is sufficient as the network-wide synchronization is the crucial requirement. The NTP clients are doing a NTP calibration every 16 seconds, thus an offset <50µs within the local network is reached which offers adequate accuracy for our performance measurements Applicability One of our project aims was to develop an all-purpose testbed, this means that native IPv4/IPv6 scenarios as well as almost every transition scenario must be configurable. As each network component is equipped with a dual-stack we have the maximum of flexibility. For Tunneling scenarios n7xenon and n7argon, the Proxy Servers, are acting additionally as tunnel endpoints. If considering the Proxying approach then the network emulator implements one of the mentioned solutions. The idea of a virtual backbone provides us to work either in a closed laboratory architecture or connected to the global Internet; dedicated links create a realistic environment. Lastly, the shadow network for synchronization enables the measurement of one-way delays. 6. Conclusions IPv6 transition in general is well covered and specified but there are still application-specific aspects which have to be considered. In terms of for instance, transition can be best handled with the Proxying solution which is enhanced application-specific approach. In the context of VoIP we are faced with strict limitations concerning delay, jitter and packet loss and so we must stress the need for performance characterization and evaluation for IPv6 transition. This is also the main motivation for the experimental approach we represented in this paper. 7. Acknowledgement The research presented in this paper is part of the project Performance of v6 Transitioning at the Telecommunications Research Center Vienna (ftw.). The work is supported by the Kplus program of the Austrian Federal Government. References [1] G. Camarillo, K. E. Malki, and V. Gurbani. Ipv6 transition in the session initiation protocol (sip). Internet-draft, IETF, February [2] B. Carpenter and K. Moore. Connection of IPv6 Domains via IPv4 Clouds. RFC 3056, Feb [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 1883, Dec [4] FhG Fokus. Report on integration of sip and ipv6. Technical report, 6NET, August [5] M. Handley and V. Jacobson. SDP: Session Description Protocol. RFC 2327, Apr [6] C. Huitema. Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). RFC 4380, Feb [7] I. Miladinovic and K. Umschaden. D1.1: General evaluation of transition scenarios. Technical report, IPv6 Task Force, December [8] P. O Hanlon, S. Varakliotis, R. Ruppelt, and J. Fiedler. Realisation of ipv4/ipv6 voip integration scenarios. Technical report, 6NET, January [9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. : Session Initiation Protocol. RFC 3261, June [10] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 3550, July [11] M. Tatipamula, P. Grossetete, and H. Esaki. Ipv6 integration and coexistence strategies for next-generation networks. IEEE Communications Magazine, 42(1):88 96, January [12] J. Wiljakka. Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks. RFC 4215, Oct