sip, fcp and the transition to ipv6 · sip, fcp and the transition to ipv6 gustav rydmark master of...

SIP, FCP and the transition to IPv6

G U S T A V R Y D M A R K

Master of Science Thesis Stockholm, Sweden 2011


G U S T A V R Y D M A R K

Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2011 Supervisor at CSC was Örjan Ekeberg Examiner was Stefan Arnborg TRITA-CSC-E 2011:074 ISRN-KTH/CSC/E--11/074--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.kth.se/csc


AbstractThe world is transitioning to a new IP protocol, IP version 6 (IPv6), forever changing how networks and the Internet functions. The transition brings with it great promise but also many issues that need solving, particularly for protocols that build upon the IP infrastructure. One such protocol is the Session Initiation Protocol (SIP), used for initiating communication sessions between two or more parties on a network. This report investigates how the transition and its suggested solutions impact SIP. In addition, it uses this investigation to analyze the needed additions to the Firewall Control Protocol (FCP), used to allow SIP to flow unobstructed through firewalls. The report starts by explaining fundamental technologies, then identifies different transition scenarios between the new and old IP protocol. Following this several transition technologies such as dual-stack, tunneling and proxy solutions are explored and investigated, with proxy solution being a favorite. Afterwards, this investigation is used to examine needed additions to a FCP, concluding that extension to the protocol is not all that difficult, but accounting for transition technology that translates between the two protocols is complex. Finally the report discusses how fractured the current state of the industry is and leaves a recommendation for networks who wish to implement IPv6 to acquire a solid proxy solution until the transition has passed.

SIP,FCP och övergången till IPv6

SammanfattningVärlden är just nu påväg att byta till ett nytt IP protokoll, IP version 6 (IPv6). Detta byte kommer för alltid att ändra hur nätverk och internet fungerar och för med sig både förväntningar och komplikationer. Session Initiation Protocol (SIP), ett protokoll som använder sig av IP infrastrukturen för att starta kommunikation mellan två eller flera parter, behöver således ny teknologi för att anpassa sig till den nya IP versionen. Den här rapporten utreder vilken sådan teknik som finns och hur önskvärda de är för SIP.Dual-stack,tunnlar och proxy lösningar är några av teknikerna som undersöks och en proxy lösning blir en favorit. Den använder sedan denna utredning för att undersöka hur Firewall Control Protocol (FCP) kan utökas. FCP används för att låta SIP kommunikation fungera även genom brandväggar. Slutsatsen av denna undersökning är att utökning av FCP för att klara det nya IP- protokollet är inte speciellt komplicerat men för lösningar som skall översätta mellan det gamla och nya IP protokollet blir omgivningen komplex.Slutligen diskuteras branchens vitt skilda åsikter på området och en rekommendation för nätverk som vill börja med IPv6 är att implementera en utförlig proxy lösning under övergångsfasen.

Table of ContentsIntroduction..........................................................................................................................................1

Background......................................................................................................................................1Problem............................................................................................................................................1Goal..................................................................................................................................................1The company....................................................................................................................................2

Abbreviations and technical terms.......................................................................................................3Theory...................................................................................................................................................4

IPv4 and IPv6...................................................................................................................................4SIP....................................................................................................................................................7

SDP ............................................................................................................................................8NAT..................................................................................................................................................9

SIP, NAT and firewalls..............................................................................................................10Firewall Control Protocol..............................................................................................................11

Ingate/Intertex FCP...................................................................................................................11Analysis..............................................................................................................................................12

Identifying IPv4 and IPv6 network scenarios................................................................................12Examining IPv4/IPv6 transition solutions and SIP........................................................................16

Dual-stack.................................................................................................................................16Tunneling..................................................................................................................................19Translation.................................................................................................................................23DNS...........................................................................................................................................26Streaming media complications and solutions..........................................................................27

NAT in IPv6...................................................................................................................................30FCP and IPv6.................................................................................................................................32

Final Discussion.................................................................................................................................34Thoughts regarding masters project..........................................................................................35

References..........................................................................................................................................36

SIP and IPv6 masters project

Introduction

BackgroundAs the internet as well as local networks gradually increase the usage of IPv6, the newest version of the IP protocol, a complex environment arises where parts of the network consist of IPv6 and other parts still use IPv4. This heterogeneous environment is predicted to last for several years and creates the need for transition-compatible technology.

ProblemFor the Session Initiation Protocol (SIP) this creates several complications, particularly in NAT:s and firewalls where SIP has already been problematic due to its use of application layer information-storage and multiple protocol usage. One solution to these firewall related complications in an IPv4 homogenous environment has been introducing a firewall control SIP proxy, which facilitates the firewall's interactions with SIP. For this proxy to dynamically control the NAT and firewall, a Firewall Control Protocol(FCP) has been used. Which are the SIP interoperability and NAT/firewall traversal scenarios in today's IPv4/IPv6 networks, how will these be handled, what changes to the Firewall Control Protocol are needed to let it serve a similar role and what are the complications that relate to these changes?

GoalIdentifying the necessary and beneficial steps for altering and extending a Firewall Control Protocol and SIP proxy's functionality to address SIP-related problems in an IPv4/IPv6 environment. Thus the masters project also requires a thorough mapping of different IPv4/IPv6 traffic scenarios and their impact on SIP interoperability, as well as investigations regarding the continued usage of NAT in IPv6 since this was one of the primary complications of SIP traversing firewalls in IPv4. With these scenarios and investigations concluded, an analysis of the needed changes and additions to the Firewall Control Protocol will be discussed as well as suggestions for an implementation in a prototype version.

To summarize:• Identify and map the different IPv4/IPv6 traffic scenarios and their impact on

SIP interoperability as well as the current solutions for these scenarios.• Investigate the usage of NAT in an IPv6-natural and IPv4/IPv6 environment.• Study how SIP traverses NAT/Firewall in an IPv4 SIP proxy solution and find

suitable changes to extend that solution for an IPv6 and IPv4/IPv6 environment.

• Proposal and analysis of needed and beneficial changes to the Firewall Control Protocol based on the research described above.

• Suggestions for a prototype version of this new Firewall Control Protocol.

1


The companyIngate and its sister company Intertex produce and sell fully SIP compatible IP firewalls. They take great pride in their high quality combination of firewall technology and SIP functionality to create devices with both security and smooth communication options, even from within a secure LAN. Intertex Data AB was founded in 1982 and has since been a successful provider of security and communications technology to the European market. In 2001, a joint venture with another company called Cendio Systems AB lead to the creation of Ingate Systems AB with the goal of developing SIP firewalls for the enterprise market.

Both Ingate and Intertex have long been dedicated to being at the forefront of new technology and it's a position they wish to keep even as the world transitions to the new IP protocol. In keeping with this they decided a masters project investigating the subject of IPv6 and SIP transition would bring valuable research towards the development of future versions of their SIP-enabled firewall.

Initial questions formulated by Ingate/Intertex were divided between two separate masters projects to improve the scope for each project and make them distinct. These questions were later modified to obtain a more cohesive investigation but in large part they set the framework for each project. One project is described within this report. The second project was conducted by another KTH student by the name of Ludvig Lind (source still in production at time of writing). Lind's report focuses more on the practicalities and particularities of a SIP proxy solution and the different implementations used in available open-source products in the industry.

Ingate/Intertex has offices in Hallonbergen, Stockholm, Sweden. An office was made available to provide a workplace for the student for the duration of the masters project. The office has been very beneficial in providing a solid base of operations with expert help made available from the co-workers. Everyone has been optimistic and friendly and have listened with enthusiasm to the presentations made during the course of the investigation.

Supervisor for the masters project on Ingate/Intertex side was Karl Erik Ståhl, the current owner and CEO of Intertex. Like the rest of the co-workers he has been instrumental in providing advice and resources for the project. Ingate/Intertex also arranged for a meeting with SIP veteran and owner of Edvina AB (founders of the Open Unified Communications European Alliance) Olle E. Johansson. He provided helpful advice and clarity into the current state of SIP technology and what hardships he feels are associated with an IPv6 transition.

2


Abbreviations and technical termsIPv4 Internet protocol version 4IPv6 Internet protocol version 6SIP Session Initiation ProtocolUA User AgentURI Uniform resource identifierSDP Session Description ProtocolNAT Network Address TranslationSBC Session Border ControllerFCP Firewall Control ProtocolHomogenous network A network with a uniform protocolHeterogeneous network A network with differing protocolsDual-stack A device with both an IPv4 and IPv6

address and interfaceTunneling Transporting one protocol through

another.6to4 A specific tunneling technique.

Transport IPv6 packet inside IPv4 payload.

Teredo A specific tunneling technique. Transport IPv6 packet inside IPv4 and UDP packet.

Translation Modifying packet format in-transit.NAT-PT Network address translation/Protocol

TranslationProxy An external intermediary device that

handles translation for SIP packetsANAT Alternate network address typesSTUN Session traversal utilities for NATICE Interactive connectivity establishmentTURN Traversal using relay around NATHappy Eardrums IPv6media without connectivity checksALTC Alternate Connectivity Attribute

3


TheoryThis chapter consists of a theoretical overview of the technologies that constitute a basis for the topics presented in later chapters of the report. For more in-depth information on these technologies, relevant source material is referenced.

IPv4 and IPv6In the beginning of the 1980's the Internet Protocol version 4 became the first Internet Protocol to be publicly used and it is still the most commonly used one today. However a new version of the Internet Protocol was defined in 1998 by the internet engineering task force (IETF) when they released RFC 2460 describing IP version 6 [1]. IPv6 has been gaining in popularity since then and today the internet is in a state of transition where IPv4 is gradually being replaced by its successor.

Since IPv4 came into operation the usage and size of the internet has vastly increased. With each increase the number of available addresses for new networks dwindled and it is currently estimated that the IPv4 address space will be depleted entirely by 2011 [2], likely causing new services established in 2012 to only be reachable through IPv6. This depletion is called IPv4 address exhaustion. The long-term solution to this exhaustion is widely believed to be the transition to IPv6.

4


IPv6 was developed with many of IPv4's flaws in mind, particularly the address space formatting which is no longer suitable for the global usage of the internet we're seeing today. The differences in the two versions packets can be seen in figure 1 on the following page.

Some of the key differences are as follows:• Header size: An IPv4 packet's header is 20 bytes plus options. An IPv6 header

is 40 bytes without additional optional headers. The optional headers in IPv6 are the segments from Hop-by-hop Options down to Destination Options in fig 1.

• Address length: As mentioned earlier IPv6 addresses are longer than IPv4 addresses. An IPv4 address is 4 bytes while an IPv6 address is 16 bytes. This means that IPv4's address space consists of roughly 4x109 addresses and IPv6's has 3.4x1038.

• Lifetime of packets: In IPv4 the lifetime of packets has been covered by the traditional time to live field (TTL). In IPv6 this field is called a hop limit, which decreases by one with every hop. Other than that the functionality remains the same.

• Quality of Service: Fields that handle quality of service(QoS) have been greatly increased in size in IPv6. QoS in IPv4 is handled by the Type of Service(ToS)/Differentiated Services(DSCP) field at a size of between 3 to 8 bits. In IPv6 this is handled by two fields called Class and Flow Label. These fields are 8 and 20 bits respectively.

• Security: Internet security has become a much more pressing matter in today's world. When discussing security in the network layer, IPSec is usually the technology discussed. IPSec works with IPv4 but is essentially an add-on that requires specific considerations when implemented in an IPv4 environment. IPv6 was designed with IPSec in mind and as such includes two fields intended for its use, the Authentication header (AH) and Encapsulating security Payload (ESP).

5


Figure 1: An IPv4- and an IPv6 packet respectively.

6


SIPThe Session Initiation Protocol(SIP) is a signaling protocol that was first invented in 1996. Today its specifications can be found in RFC 3261 as defined by the IETF [3].SIP, as its name implies, is used to initiate sessions. Specifically, it is used to initiate, control and end multimedia sessions between one or several parties over an IP network. It is a protocol based in the application layer and can therefore be transported by several different protocols such as UDP or TCP without it interfering with the SIP message.In today's networks SIP is one of the most commonly used protocols for handling multimedia communications with audio or video, such as voice over IP (VOIP) or video conferencing.The endpoints in a SIP communication are called User Agents(UA) which communicate by a series of text messages. These User Agents are identified by their Uniform Resource Identifier(URI) which is of a similar syntax to mail addresses.

Example: sip:username:password@host:port

Apart from the user agents SIP infrastructure also has several server elements which act as intermediary devices. Although it is quite possible for User Agents to communicate directly, in most situations this is impractical. These three server elements are the Registrars, the Proxy servers and the Redirect servers.

Registrars receive the messages from User Agents known as REGISTER requests. It then stores the information received from this request in a registry for its domain, typically mapping IP addresses to SIP URI:s.

Proxy servers stand in between communication of two User Agents and acts as both a server and a client. It inspects and interprets messages and often change parts of them before passing them on to the original receiver. Most of the time this is done for routing reasons (getting packets to other network entities closer to the target) but could also be to regulate the amount of traffic or for security reasons.

Redirect servers generate redirect answers to messages that it receives, telling the sender that it needs to contact a different URI (for example it may redirect messages to different URI:s depending on the time of day).

7


SDP It is difficult to discuss SIP without bringing up the Session Description Protocol(SDP). SDP is used to describe parameters when initializing streamed media sessions. As SIP sessions often use streamed media in different forms (for example streamed video and sound during a video conference call) it relies on SDP to describe the streaming parameters (such as video codecs, speeds, versions etc). SDP is built up by a series of text-lines where each line is a field of information. It contains some core parameters but can be easily extended to contain new attributes, which is why it can be used to describe parameters for a wide variety of streamed media.

Note that SDP does not deliver the media itself but rather just helps in negotiating the parameters for the streaming session. For the delivery itself other protocols are used, primarily the Realtime Transport Protocol(RTP).

SDP was originally proposed by the IETF in 1998, but a revised RFC was published in 2006, RFC 4566 [4].

8


NATNetwork Address Translation (NAT) is a central part of network usage today and refers to changing the address information in IP packets while they are being routed from sender to receiver.

In its most basic form, this means that a device in the packet's path exchanges one IP address for another – effectively hiding one address behind another. This type of usage, referred to as a one-to-one NAT [5], has limited areas of usefulness and is usually not what is referred to when NAT is mentioned.

What it usually refers to is one-to-many NAT. This is when several IP addresses are hidden behind a single address. Most often the hidden addresses are part of a special type of IP address space referred to as private IP addresses. These are not allowed outside of internal networks and so do not need to be unique to the world. Since they are not unique they cannot be used to identify a device on the internet. This is where NAT is used. By hiding the private addresses behind a regular IP address using a NAT, several computers can access the internet through the same address.

Example: Most home networks use the 192.168.0.0/16 private address space to identify the different computers in a single household. They are all connected to a router with an actual IP address that it uses to connect to the internet. When traffic is sent through the computers out to the internet the router changes the source address of each IP packet to that of its own global IP address. When the packets return the router keeps a translation table on hand to identify which of the home computers the returning packet is intended for. The exact mechanics on how a NAT handles returning packets is different from NAT to NAT but most do not allow external packets from sources that the home computers have not previously send packets to.

NAT usage takes careful planning and methodical execution during implementation and even when done correct it poses a problem for both the quality and functionality of many other technologies. More on how this reflects on SIP in the chapter “SIP, NAT and firewalls” below.

As IPv4 address exhaustion became more and more pressing the usage of NAT grew in tandem with that pressure, effectively giving the world more time to adapt to IPv6 at the cost of increased network complexity and reduction of end-to-end connectivity on the internet.

9


SIP, NAT and firewallsThe relation between SIP, NAT and most firewalls is in most cases in need of extra attention. When SIP attempts to communicate to a host in another network it will quickly be confronted with two complexities.

• Firewalls are in almost all cases configured to not allow unknown external communication attempting to access the network behind it, so without the firewall supporting SIP it will dismiss the inbound traffic even if it is legitimate.

• NAT devices obfuscate the addresses of the hosts on the LAN behind the firewall and aggregates them into a single public address (typically the router or firewall) that is shown to the outside world. This makes inbound communication impossible without extra attention because of the unknown destination.

To counter this there are several solutions and which one to choose is based mostly on two parameters [6]:

1. How much security and control do I need?2. How much configuration and flexibility do I need?

These dictate the choice between four types of technology:1. Universal Plug and Play – a software that takes control of the firewall to allow

communication to pass through. This of course a big risk in security and can really only be used when it's certain that the LAN will never contain malevolent elements.

2. STUN, TURN and ICE – These are several technologies invented by the IETF that set up additional devices to pass through the NAT and firewall. They are complex in their setup and ultimately they still allow the client to take control of what the firewall lets through, limiting their use when security needs are high.

3. Session Border Controllers (SBC) at the Service Provider – This approach lets SIP technology at the services providers side handle how the SIP client receives its communication by rewriting relaying. This requires the client to open certain ports in its firewall and so gives the service provider control of security configuration.

4. SIP capable proxy based firewall / Enterprise SBC – This introduces a firewall and SIP proxy built to fully handle SIP in unison. This stops SIP packets, parses them to verify their content and lets them through the firewall. This is the most secure approach out of the four and in many cases also easier to setup.

The order that the technologies have been listed indicate their respective security, from least secure to most secure. Flexibility is a little different and largely depend on specific implementation but generally the fourth option is preferable in this aspect as well.

10


Firewall Control ProtocolBack in January 2000, a new working group within the IETF was formed to investigate the prospect of allowing applications to communicate with NAT devices and firewalls and transmit authoritative requests to them. This working group was named MIDCOM (middlebox communication).

This investigation ended in an internet draft written by Jiri Kuthan and Jonathan Rosenberg, specifying their researched frameworks and requirements for a controller protocol for IP and transport layer data flows. This protocol would transmit the control data to external controllers and intermediary processing devices [7].

With this new protocol, it would be possible to remove application-awareness and application logic from the intermediary device (handling SIP packet inspection inside a firewall for example is costly for performance). An external device would take over this awareness and logic and send trusted or non-trusted requests back to the intermediary device. If the external device was set to being trusted the request would be obeyed without authentication and if it's untrusted additional policies may be introduced to provide authentication.

After this investigation was complete the working group was concluded and no RFC was developed afterwards to create a standard.

Ingate/Intertex FCPIngate / Intertex saw the potential for the FCP technology and developed their own implementation, an interface between the SIP parts and the dynamically controllable firewall. This interface was named the IXFCP, the Intertex firewall control protocol. This enabled them to successfully construct devices with separate application awareness for SIP, greatly increasing their performance. It also enabled them to market “SIParators” - products that would work in tandem with non SIP-enabled firewalls, dynamically controlling them while containing a SIP proxy and registrar themselves.

11


AnalysisThis chapter will analyze a range of topics related to IPv4 to IPv6 transition, starting with a mapping of the different scenarios where IPv4 and IPv6 interoperability have an impact on SIP. Following this will be an investigation of some of the widely used transition solutions for these scenarios in place today. Their advantages and disadvantages will be discussed and their impact on SIP will be explained. Other sections of this chapter will discuss the usage of NAT in IPv6 and how it relates to the future of SIP. Finally, the chapter will see how these different topics relate to the continued usage of FCP.

Identifying IPv4 and IPv6 network scenariosTo be able to properly discuss IPv4 and IPv6 transition and its impact on SIP it is beneficial to identify a series of scenarios or networking situations where the difference in protocol comes into play. These scenarios in networking are usually explained through maps or graphs known as network topologies, although for identifying interoperability scenarios certain documentation can be omitted, such as specific addresses.

IPv4 to IPv4The first scenario is where both ends of a SIP communication use IPv4. This is known as a homogenous networking scenario and before IPv6 was introduced this scenario was the only one that needed to be considered when handling SIP technology. Because of this many installations involving SIP that are in place today are only adapted to this scenario and their sturdiness to withstand introduction of other scenarios may vary substantially depending on implementation. This has given birth to the aim that new solutions pertaining to IPv4/IPv6 interoperability should attempt to impact these existing installations as little as possible. Supporters of this aim argue that placing the burden of IPv4/IPv6 transition on new technologies is a lot easier than hoping to reliably alter existing installations and this philosophy shines through in a lot of technologies discussed in later chapters. In short, the IPv4-IPv4 scenario is relevant for this analysis because altering the technologies involved in it would require vast (and often undesired) changes to a lot of networks in the world. A visualization of this scenario can be seen in figure 2 below.

Figure 2: IPv4 to IPv4 communication.

12


IPv6 to IPv6The second scenario is the other homogenous networking scenario, where both ends of SIP communication use IPv6. This is still somewhat unusual but will occur more and more as networks adapt to the new protocol before finally replacing the IPv4-IPv4 scenario as the scenario present in most networks. As such any new technology which wants to handle interaction between the two protocols also needs to handle this scenario to allow for development towards the future.

This scenario is both very different from the IPv4-IPv4 scenario and at the same time perhaps the most closely related one. Because of their different protocols several fields and parameters such as the address format is different but at the same time they are both homogenous networking scenarios where communication is sent and received in the same protocol. A visualization of this scenario can be seen in figure 3 below.

Figure 3: IPv6 to IPv6 communication.

IPv4/6 to IPv4 or IPv6When the protocol capacities at both ends of communication are different a heterogeneous networking scenario occurs. In this particular scenario it is were one end is capable of communicating with either IPv4 or IPv6 while the other one is limited to using only one of them. End-points that can communicate using either of the protocols are usually equipped with a feature called a dual-stack, which is a transition technology discussed at length in the later chapters. Respectively, an end-point that can only handle one type of protocol is referred to as single-stack.This scenario mainly creates problems for the dual-stack end-point since it is the only one with the capability to adapt. A visualization of this scenario can be seen in figure 4 below.

Figure 4: Ipv4/6 to IPv4 or IPv6 communication.

13


IPv4/6 to IPv4/6A scenario closely related to the “dual-stack to single-stack scenario” is the one where both ends of a communication have the capacity for dual-stacking. The problem with this scenario is also similar to the earlier scenario but with an additional complexity, since the decision on which protocol to use is no longer dictated by one end-point having limited capacity. A visualization of this scenario can be seen in figure 5 below.

Figure 5: IPv4/6 to IPv4/6 communication.

IPv4 islandThe term 'island' is used when a network of a certain protocol is only able to reach the rest of the world through a network of a different protocol. The analogy being that the network is an island upon which the protocol is stranded, surrounded by a sea consisting of a different protocol.Specifically, an IPv4 island is a network with only IPv4 capability where all of its external access is gained from a network with only IPv6 capability. Although the scenario is usually not found in today’s networks since IPv4 is so widely spread it can become more of a situation in the future as IPv4 connectivity grows more and more scarce.This scenario creates the need for technologies referred to as tunneling and will be discussed amongst the solutions presented in later chapters. A visualization of this scenario can be seen in figure 6 below.

Figure 6: IPv4 island communication.

14


IPv6 islandAn IPv6 island scenario is simply an IPv4 island scenario where the protocols have been reversed. An IPv6 network is stranded behind a network that can only handle IPv4. Unlike its more unusual counterpart this scenario has the potential to occur in a lot of places around the world today, as individual networks get their IPv6 capability up and running. As with IPv4 islands the suggested solution is most often tunneling but as will be explained in later chapters it is worth noting that there are differences between tunneling IPv6 and IPv4 respectively. A visualization of this scenario can be seen in figure 7 below.

Figure 7: IPv6 island communication.

In summaryThe different scenarios can be summarized as:

• Homogenous scenarios – where the protocol capabilities are the same and which protocol to use is dictated.

• Heterogeneous scenarios – where the protocol capabilities are different and which protocol to use must be determined.

• Island scenarios – where the protocol capabilities are limited and need to be circumvented.

15


Examining IPv4/IPv6 transition solutions and SIPWith the different scenarios identified, it is time to look into what technologies and solutions for IPv4/IPv6 transition have been developed thus far. The field of IPv4/IPv6 transition is extensive and so only those with relevance to SIP communication will be investigated. In 2005, RFC 4215 presented an analysis on IPv6 transition [8] and classified three principal categories of transition solutions: Dual-stack, Tunneling and Translation. These three categories make up the first three sections of this chapter, followed by a section dedicated to DNS in IPv6 and finally a section regarding media stream problems related to the transition.

Dual-stackOne way to allow a device to access both IPv4 and IPv6 is to simply connect it to both of them. A dual-stack device is essentially a device with both an IPv4 and an IPv6 address and the ability to function with both.

The practice of dual-stacking has been used in earlier times. Before TCP/IP became dominant protocols for the transport layer and network layer respectively, they existed in tandem with two other protocols called SPX and IPX. This was during the 1980's and 90's when SPX and IPX saw most of their usage in local networks between then very popular Novell NetWare operating systems. Because of their popularity, many PC's were fitted with dual-stack technology to accommodate both TCP/IP and SPX/IPX [9].

Dual-stacking as a term can be used with varying specifics. In this investigation we will use the definition in RFC 4213 [10], with an addition regarding DNS. Thus, a device can be called dual-stack if:

• It has an IPv4 address assigned.• It has an IPv6 address assigned.• When either of the stacks is inactive, the device will function as a normal node

of the active stack (I.E when the IPv6 stack is inactive, it will function as a normal IPv4 node).

• It communicates with native IPv4 and IPv6 devices with their native protocol.• The dual-stack device should have both an A and an AAAA record for DNS.

More on DNS and IPv6 in a later chapter.Dual-stacking is in most cases used on end-hosts in a network but any device which wants to be accessible through both protocols will need the same technology.

With the basic definition of dual-stack explored, benefits and problems with the particular solution can be discussed.

16


One advantage dual-stack has over other technologies is its relative speed and simplicity. It does not require additional intermediary devices and puts the required changes on the end-hosts.

For networks that already have public IPv4 addresses available this can be an attractive option.

The complications raised have been pointed out by several sources. The most glaring flaw in dual-stack technology is of course that it requires end-systems to both have IPv4 and IPv6 address space available, something that will get harder and harder to achieve as public IPv4 addresses dry out.[10,11]

Following the dual address situation, the additional management required to delegate an address of each protocol to all devices is also an extra frustration to take into consideration.[10,11]

Despite the drawbacks, dual-stack often acts as a first step when already established networks wish to introduce IPv6 availability, because of the relatively low implementation costs.

For SIP, dual-stacking causes a few issues on the application layer, primarily in the “dual-stack to dual-stack” scenario. In this situation, the preferred protocol of each UA needs to be announced and negotiated. The default way to test IPv6 connectivity [13] is to wait for DNS-lookup timeout and then use IPv4 afterwards. The default timeout for SIP is 32 seconds. As has been pointed out by several sources [9,14] this is a quite unacceptable time frame. A standardized solution for this problem is yet to be announced, although several suggestions have been proposed [14].

With regards to dual-stack behavior and use of other SIP technologies, Yasuro Kawarasaki, Takahiro Shibata and Tom Takahashi of NTT Network Systems Laboratories, Japan, conducted a series of experiments with different SIP inter-working methods in dual-stack networks in 2003. Their conclusions were two-fold [15]:

• What they call the “IP-version-dependent routing method” was generally the best with regards to all aspects tested.

• Given that some connection delay can be allowed, the so-called “RE-INVITE method” may also be worth investigating.

The “IP-version-dependent routing method” uses a SIP Application Layer Gateway (ALG) in addition to a SIP proxy. The SIP proxy sends communications between differing protocols to a special SIP ALG that handles IP translation. This is similar to the Proxy translation solution in later chapters.

17


The “RE-INVITE method” lets the SIP proxy send a SIP re-invite message when communicating between dual-stack and IPv4 hosts. This re-invitation however causes connection delay in this type of communication.

The IETF recently released an RFC [16] regarding SIP and IPv4/IPv6 transition. In this, it is recommended and in some cases indeed assumed that IPv6 user agents use dual-stacking to allow communication with IPv4. Because of this, additional research and standardization of dual-stack implementations will soon be required by the industry.

From this, in addition to the investigations described above, it seems fair to assume that dual-stack solutions will be a prevalent practice for a significant time period, albeit often in conjunction with other solutions.

18


TunnelingTunneling is the practice of connecting islands of a particular network across networks of a differing protocol. In particular, connecting IPv6 islands across the sea of IPv4-only networks that constitutes today's internet makes up the primary scenario for this type of solution. Two tunneling technologies, 6to4 and Teredo, will be discussed in this section. Following this will be an analysis regarding the future of tunneling and its impact on SIP.

6To4The 6to4 tunneling protocol is designed to allow networks using IPv6 to communicate over networks that only route IPv4 packets. This is especially relevant in the early phases of IPv6 deployment. A common analogy when explaining this protocol is that it allow IPv6 islands to communicate over an IPv4 sea. As the world grows more and more IPv6 aware, 6to4 will begin to lose its relevance but at time of writing it is still essential in many networks. Additionally, 6to4 is one of the few tunneling mechanisms that do not need manually configured tunnels to function, something that greatly increases its usefulness.

6to4 is described thoroughly in RFC 3056 - “Connection of IPv6 domains via IPv4 clouds”[17].

6to4 behaves slightly different depending on its destination. The destination could be either another 6to4 address connected to the same neighboring IPv4 network or it could be a native IPv6 address connected to the global IPv6 WAN. Both scenarios will be described below.

6to4 address to 6to4 address• Hosts on an IPv6 network create an IPv6 packet whose source address begin

with the prefix 2002::/16. The following 32 bits are filled by a global IPv4 address. This address could be the hosts own if they have one assigned or it could be the IPv4 address of the 6to4 border router on their network. The remaining bits of the source address can be used to to allocate sub-net and unique host address in the network.

• When the intended destination is another 6to4 address, the destination address of the packet also starts with the 2002::/16 prefix. The IPv4 address that follows the prefix is then the IPv4 address of the 6to4 router on the receiving network (or it could be the address of receiving host if it has a global IPv4 address of its own).

19


• When the packet is sent, it first arrives via IPv6 traffic to the senders 6to4 router. The 6to4 router notices that the prefix for the destination is 2002::/16. It then puts the IPv6 packet in the payload of an IPv4 packet. The source address of this IPv4 packet is extracted from the 32bits of the 6to4 source address in the IPv6 packet and the IPv4 destination address is extracted from the 6to4 destination address in a similar manner. The IPv4 packet is then given protocol type 41 to indicate that it carries an IPv6 packet as payload and is sent on the IPv4 network as regular traffic.

6to4 address to native IPv6 address• When the destination address is a native IPv6 address a special type of 6to4

router is used. These are called 6to4 relay routers and are located between an IPv4 network and an IPv6 wide area network. If a 6to4 host wishes to communicate with a native IPv6 address, its default IPv6 gateway needs to be a 6to4 address with the IPv4 address of a 6to4 relay router inside it. To simplify this process, the IPv4 anycast address of 192.88.99.1/32 has been reserved. 6To4 relay routers announce this address to attract 6to4 traffic.

• IPv4 packets with protocol type 41 that arrive on the 6to4 relay routers IPv4 interface are unwrapped and the IPv6 packet that was in the payload is routed as regular IPv6 traffic.

• IPv6 packets with the prefix 2002::/16 that arrive on the 6to4 relay routers IPv6 interface are wrapped in an IPv4 packet and sent over the IPv4 network.

Reverse DNS• 6to4 addresses that are constructed from global IPv4 addresses can be reserved

for reverse DNS lookup like any other IPv6 address. Allocation is then done on the 2.0.0.2.ip6.arpa DNS zone.

As can be noted by the steps above, a device that wishes to become an endpoint of a 6to4 tunnel needs to have a global IPv4 address. Nowadays however most hosts are behind at least one NAT-device due to IPv4 address scarcity and so the NAT-device needs to act as the 6to4 endpoint in those cases. 6To4 functionality is however not very common in NAT:s and end-network filters are particular about the protocols they allow to pass – protocol 41 often being amongst those blocked.

Another issue with 6to4 usage is that 6to4 relay routers are uncommon in today's internet. As has been pointed out by Geoff Huston, chief scientist at the Regional Internet Registry for the Asia Pacific Region, this can cause sub-optimal packet paths and additional connection failure.[18]

When it is employed however, 6to4 can be very useful as long as there are still many networks without IPv6 routing capacity. As can be seen from the explanation above the tunneling mechanism is a matter for the IP layer and as such has little direct impact on SIP itself. It is however highly beneficial for IPv6-enabled SIP endpoints that only have an outside connection via an IPv4 network.

20


Teredo6to4 tunneling requires the endpoint of its tunnel to have a public IPv4 address. As such, either the endpoint needs to be the host using the tunnel, or the NAT device of its network. Teredo tunneling attempts to circumvent this problem using a combination of UDP and IPv4.

Teredo was developed by Christian Huitema at Microsoft. In 2006 his RFC on the technology was approved, RFC 4380 [19]. A useful and complete explanation of the technology has also been published as a Microsoft technical note [20].

Teredo uses both a tunneling mechanism and an addressing structure, similarly to 6to4. Teredo however has a larger number of different devices in its infrastructure:

• Teredo clients – A dual-stack host behind a NAT and connected to the IPv4 internet. It also has a teredo tunneling interface to tunnel packets to either teredo relays or other teredo clients. It initially communicates with a teredo server to setup its IPv6 connection.

• Teredo servers – A dual-stack node connected to both the IPv4 internet and the IPv6 internet. It receives tunneling packets and sets up communication between teredo clients or between teredo clients and IPv6 destinations.

• Teredo relays – An IPv4/IPv6 router that forwards traffic from IPv4 teredo clients to IPv6 hosts. It's also used by the teredo server in some cases of initial communication setup. Relaying is bandwidth intensive and thus is often limited to a specific range of IPv6 hosts, such as a campus or office.

• Teredo host-specific relays – Similar to a regular relay, but its range is limited to a single host, normally the one the relay is located on.

Teredo IPv6 addresses are constructed in a specific manner, much like 6to4 addresses. Just like 6to4 addresses, they are public IPv6 addresses that makes a teredo client globally unique.

• The first 32 bits consist of a Teredo prefix – 2001:0::/32• The following 32 bits are the colon-hexadecimal version of the teredo servers

IPv4 address.• The next 16 bits consists of flags, primarily for determining the type of NAT the

client is behind.• The 16 bits after this consist of the UDP port number written in hexadecimal

and inverted.• And the last 32 bits consist of the public IPv4 address of the teredo clients NAT,

in colon-hexadecimal form and inverted.

21


Example address: 2001::CE49:7601:2CAD:DFFF:7C94:FFFE.Where CE49:7601 =206.73.118.1

2CAD = Flag fieldDFFF = 8192 (UDP port)7C94:FFFE = 131.107.0.1 (NAT IPv4 address)

Teredo tunneling is mentioned as a solution technology in many reports regarding SIP and IPv4/IPv6 transition but it is never given much space in the final conclusions. It is also never mentioned in the RFC on SIP and IPv6 transition by the IETF.

Data suggests that Teredo is not as widely used as it could be in networks today [18]. Unlike 6to4 which has a somewhat natural cause of failure in most cases, namely that of network filters blocking protocol 41, Teredo failure rates are often a lot more obscure.

This potential failure obscurity makes increasing the usage of Teredo risky as added failure complexity becomes even worse when introduced on a large scale.

Tunneling and SIP

Now that the two popular tunneling techniques have been introduced and analyzed, what future can these see in relation to SIP? From the material gathered by this investigation, tunneling is often mentioned as part of a solution but is never given much room in final discussions. This may have several causes.

First it is valuable to note that tunneling as a technology is very transitional by its nature. It is designed to function purely in the age just between the two different protocols and quickly becomes redundant or needlessly complex when usage of IPv6 becomes more commonplace.

Second, other technologies such as different type of translation are often considered more attractive in SIP situations. These are often considered to have a longer life-span or be less complicated to setup for large installations (a large number of tunnels can quickly become complex to manage).

It is however useful for those who wish to quickly expand their IPv6 usage for a few specific networks and find themselves “trapped” behind networks administered by slower moving organizations without IPv6 connectivity.

22


TranslationAnther technique used in IPv4/IPv6 transition is translation. This means that addresses of one format are mapped to an address of the other format, similar to how network address translation works for global and private IPv4 addresses today. There are several solutions based on translation that are discussed today and they all present different beneficial effects and problems. Two specific solutions will be explored in the following sections.

NAT-PT

Network address translation / Protocol translation was one of the first attempts to create a standard technology to allow IPv4-only nodes to communicate with IPv6-only nodes. It attempted to combine traditional network address translation, already made popular in an IPv4 world with protocol translation, as defined in an earlier document on stateless IP/ICMP Translation [21].The intended scheme would not need dual-stacked hosts or specific routing in the form of tunnels and endpoints, only the use of specific IPv4 global addresses, that would be dynamically allocated to IPv6 locations upon session initiation.

It was originally defined in RFC 2766 in February 2000[22].

As the technology began to spread, a series of issues quickly emerged however and after a few years a new RFC was released [23], demanding that NAT-PT was to be moved to historic status. Today NAT-PT is a deprecated technology and other transition solutions have taken over responsibility for moving IPv4/IPv6 transition forward.

NAT-PT is present in this report primarily because of its frequent mention in older reports on SIP and IPv4/IPv6 transition, albeit even in those reports its competitors (primarily different types of proxy solutions) are often suggested as more attractive options [11,12]. It serves as an example of the importance of checking up on the state-of-the-art and constitutes an early attempt by industry to handle transition issues.

23


Proxy

The term “proxy” has long been in use in networking. In regular IPv4 networks proxy servers are common and have several uses, for example allowing a host to access a website from a different world region than their own. The basic principle is the same as the proxies that will be discussed in this section – proxies act as intermediary devices that alter packet information to place itself between the end-points of a communication.

In IPv4/IPv6 transition an intermediary proxy alters packets between end-points of differing protocols to allow communication. Implementation specifics are diverse but in most cases this involves terminating the SIP connection when it reaches the proxy, altering the information to translate between protocols and then opening a new connection to reach the receiver.

Since these intermediary proxy devices (often referred to as SIP proxy gateways) need to place themselves between an IPv4 and an IPv6 network to perform translation, they require dual-stack technology as discussed in a previous chapter of this report.

Proxy solutions are frequently seen in research on SIP and IPv6 transition and often with positive results, as can be seen by these next reports. The naming of these solutions are somewhat unfortunate since they can easily be confused with the SIP-proxies that are part of regular SIP infrastructure.

In Lambros Lambrinos and Peter Kirsteins report “Integrating Voice over IP services in IPv4 and IPv6 networks” [24] they setup a test network to investigate voice over IP (VOIP) quality in a heterogeneous networking situation similar to the scenario described in this report. To facilitate IPv4/IPv6 transition they implement a Proxy Gateway solution in addition to a server with the open source SIP Express Router (SER) platform to seamlessly translate between the two protocols.

Their tests included call initiation from both IPv4 and IPv6 phone's to both IPv4 and IPv6 receivers, calls from IPv6 to PSTN (regular telephone network) and multi-party conferencing. Their results indicated that both their Proxy Gateway and the SER platform had performed their function without any problems.

The Proxy Gateway and SER platform are also mentioned in “SIP and IPv6: Why and How?” by Dorgham Sisalem, Jens Fiedler and Reinhard Ruppelt of Fraunhofer Institute [11]. Here they are described in additional detail.

The SER platform supports both IPv4 and IPv6 and has three modes for acting as all three parts of SIP server infrastructure - a SIP redirect,proxy and registry.

The Gateway is what handles actual translation during communication, using three parts:

• A mini-SIP-Proxy• UDP-forwarding-daemon• Control Protocol

24


The mini-SIP-proxy modifies received SIP messages and sends mapping requests to the UDP-forwarding-daemon to allow media traffic (sent with RTP) to function as well. Received SIP messages are sent to a SIP-proxy on either the IPv4- or IPv6-network to be routed after they've been altered to match the new protocol.

The UDP-forwarding-daemon receives mapping requests from the mini-SIP-proxy and keeps them all in check, performing the same function as a NAT. It also uses the stored mappings to send media traffic between user agents.

The Control Protocol is composed of UDP messages, sent between the mini-SIP-proxy and the UDP-forwarding-daemon. Thanks to this protocol, they can both be on separate devices. This middlebox control protocol similar in function to the Firewall Control Protocol discussed in earlier chapters of this report.

In the conclusions of their report Sisalem, Fiedler and Ruppelt suggest that moving the modification of the IP packets to the kernel domain rather than the user one could improve performance. They also suggest that moving the SIP-proxies from the IPv4 and IPv6 networks into the Gateway itself would decrease the amount of overhead involved with installing their current solution.

In an article [25] by Tomás Robles, Ramiro Ortiz and Joaquín Salvachúa of Madrid Technical University in 2003, they detail their work on creating a proxy solution with the use of Java Libraries. While the article provided little additional insight it proves that a functioning proxy solution can be constructed even with a high-level programming language. The trade-off for the clearer code is that all translation is done in the application layer, which lowers the performance of the solution.

As mentioned in the dual-stack chapter, Kawarasaki, Shibata and Takahashi [15] concluded in their report that a translation Gateway with dual-stack functionality was the best candidate for a transition solution with regards to connection delay, propagation delay, operational cost and required additional function for the end-point.

One final endorsement of a proxy solution comes from Thoma Hoeher, Slobodanka Tomic and Richard Menedetter and their report “SIP collides with IPv6” [12] published in 2006. In this report they discuss dual-stacking, tunneling and translation using a proxy and their conclusion is that SIP transition issues can best be handled using a proxy solution.

25


DNSWhat other technologies are affected by the transition from IPv4 to IPv6 and how does it affect SIP? One aspect of networking that has come up a few times already in the investigation is Domain Name Service, DNS.

DNS keeps track of IP addresses in different records. The most commonly known of these is an A-record, which connects an IPv4 address to a domain name. A domain name is the text-string that a user can type into a browser to access a site without having to remember its IP address.

In addition to A-records, there are two more records a DNS server can store that are of interest.

• AAAA-records that store an IPv6 address and a domain name.• SRV-records, Service records[26], specify domain name,ports and priority of

service providing servers for a specific technology. SIP architecture uses SRV records to prioritize which SIP proxy server a SIP client should contact to make a call.

SIP proxies in most cases have both an A-record and an SRV-record. To allow transition to IPv6, those proxies that wish to connect to IPv6 user agents or both protocols with dual-stack functionality will need an additional AAAA-record to allow IPv6 clients to look-up their IP address in the SIP domain.

Olle Johansson in his SIP action plan [9] suggests using SRV records to indicate which of the two IP protocols a specific server prefers. For those with good IPv6 connectivity,assigning an SRV record with high priority to your IPv6 SIP proxy will tell the world that you prefer that protocol and respectively a low priority will indicate the opposite. He also suggests that both servers and clients should support functionality that lets clients only find servers that fit with their protocol preferences in the list of SRV records.

RFC 3264 by the IETF on SIP and IPv6 transition[16] supports Johanssons suggestions to some degree but instead of introducing functionality to only present the relevant servers from the SRV list, the IETF suggests implementing the decision algorithms defined in RFC 3484 “Default Address Selection for Internet Protocol version 6 (IPv6)” [13] in IPv6 hosts. These algorithms construct a list, where IPv4 destinations will be at the bottom of preference.

26


Streaming media complications and solutionsWhen SIP makes changes to accommodate IPv4/IPv6 transition, the protocol that handles media initiation, SDP, will need to change as well. The suggested solutions to facilitate these changes to SDP and media handling have been the source of some contention and several different technologies have been presented. Two of these will be presented here.

ANATANAT stands for Alternate Network Address Translation. Potentially confusing, it has little to do with traditional NAT. Its RFC “The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework” [28] by Camarillo and Rosenberg was released in 2005. The ANAT semantic introduces a grouping within the parameters of an SDP packet to show that it has both IPv4 and IPv6 settings. This grouping is achieved by adding additional “m”-lines (the “m” stands for media name and transport addresses). An example SDP of this from the RFC is shown below. v=0

o=bob 280744730 28977631 IN IP4 host.example.com s= t=0 0 a=group:ANAT 1 2 m=audio 25000 RTP/AVP 0 c=IN IP6 2001:DB8::1 a= <ICE-encoded additional IPv6 addresses (and ports)> a=mid:1 m=audio 22334 RTP/AVP 0 c=IN IP4 192.0.2.1 a= <ICE-encoded additional IPv4 addresses (and ports)> a=mid:2

From the fifth line and down the grouping begins. The two addresses are 2001:DB8::1 for IPv6 and 192.0.2.1 for IPv4.

ANAT has the advantage of leaving SDP packets similar to their earlier appearance but the additional grouping functionality has received criticism for not being compatible with those that have not implemented it. ANAT has since been obsoleted by RFC 5245 written by one of ANATs creators himself, Rosenberg. The RFC defines ICE [18], another technology that will be discussed in the next section.ANAT is also criticized in the Happy Eardrums draft, an internet draft that also concerns IPv4/IPv6 media connectivity [14], as well as Mohamed Boucadair et. al. In their report “Migrating SIP-based Conversational Services to IPv6: Complications and interworking with Ipv4” [29] from 2007.

A revised version of ANAT, named Alternate Connectivity Attribute (ALTC) is currently in a draft state. It claims to solve the problem with backward compatibility that ANAT syntax had [30].

27


ICE

Interactive Connectivity Establishment, or ICE, was submitted as a draft in 2003 and has since undergone several changes as issues were resolved and functionality altered. In April 2010 it was finally published as an RFC, “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols”[31].

ICE is meant to solve a broader problem than ANAT (its objective being IPv4/IPv6 transition), the traversal of NAT:s for UDP-based media streams that have been established by an offer/answer protocol, such as the Session Description Protocol used by SIP. ICE can however achieve the objective of ANAT during its execution and because of this its RFC was set to deprecate the RFC for ANAT.

In addition to ICE:s own functionality it makes use of two other technologies, Session Traversal Utilities for NAT (STUN) [27] and Traversal Using Relays Around NAT (TURN) [33].

STUN is a protocol that is designed to do three things. 1. It can help an endpoint investigate what IP addresses and ports a NAT device

has given it. 2. Do connectivity checks between two endpoints and can 3. Keep NAT-bindings alive.

TURN is a protocol that allows an endpoint stuck behind a NAT that doesn't allow direct communication with outsiders to control a relay node outside the NAT. The relay node accepts and sends communication on the endpoints behalf and relays it back to endpoint.

With the two additional protocols briefly explained, a functional overview of ICE can be described as:

• Two endpoints(agents) in an SDP exchange each identify “candidate transport addresses” (a combination of an IP address and a port) they can use to stream media to the other endpoint.

• These identifications typically come in three types.• An address from a directly connected(local) interface, referred to as a HOST

candidate.• An address on the public side of a NAT, referred to as a SERVER

REFLEXIVE candidate. Usually discovered by STUN.• An address of a relay node supplied by TURN, referred to as a RELAY

candidate. Both agents prioritize their respective candidates into a list and send that list to the other agent.

• Both agents create candidate pairs by combining their own list with the received one.

• Both agents perform connectivity checks using STUN to check if their candidate pairs work.

28


• One of the agents, assigned by ICE as the CONTROLLING agent, decides which pair to use for media, either by picking the first (and highest priority) or letting all connectivity checks conclude before choosing one.

As the candidate pairs can differ in IP address format and port, dual-stack hosts can use this to connect to hosts of different protocol (the protocol not supported by the receiver will have a low priority). This is the reason that ICE deprecates the use of ANAT.

Camarillo et al. dictate in the “IPv6 Transition in the Session Initiation Protocol (SIP)” RFC [14] that ICE, along with its allied technologies STUN and TURN should be used in the media negotiation. Specifically, ICE should be used in all networks except a few strictly managed enterprise networks.

As can be seen from even the brief overview above, ICE, STUN and TURN require a substantial amount of implementation to function properly in a network. Introducing a STUN server, a TURN server and ICE functionality is in some cases considered overkill and networks managers can be reluctant to go through with such a substantial implementation.

For example,Wing and Yourtchenko express this opinion in their internet draft “Happy Eardrums” [16] and suggest an alternate method to establish media streams – without the connectivity checks that play a large part in ICE. Put simply, they instead suggest sending a few milliseconds (defined by a new SDP attribute 'T' in their document) of RTP traffic over both IPv6 and IPv4. If no traffic from IPv6 comes back, the node reverts to using IPv4. This approach to media initiation is similar to what Johansson suggests in his SIP Operation plan [9].

29


NAT in IPv6Network Address Translation has played a vital role in IPv4, particularly in later years as available addresses started to dwindle and the world was still far from an IPv6 transition. NAT extended the life-span of the IPv4 era by several years but now even that additional time has run out.

So now that IPv6 is on the worlds doorstep, what will be its new fate? This is currently still a matter of hot debate within the internet community. This is primarily due to one effect that NAT has had on internet infrastructure up until now – it works against the End-to-End principle.

The End-To-End principle was first introduced in the beginning of the 1980's as a design incentive to create smarter end-points in a network, rather than making a network additionally complex. The design document [33] was written by Saltzer, Reed and Clark who were all intricately connected with the birth of the global internet several years later.

The principle suggests that endpoints should be the only actors in a communication and they should be the only ones that impact if communication will crash, provided that the networks can send packets properly. This is known as “fate-sharing”. Intermediary devices that increase the number of participants (and so increase the number of parties involved in the “fate-sharing”) are not desired. NAT works against the end-to-end principle by translating addresses mid-communication, obscuring the end-points from each other. The end-to-end principle and its future was discussed in RFC 3724 in the year 2004 [34]. Its conclusion was that the additional principles that spawned from the end-to-end principle were still highly desirable and services that work against the principle should be analyzed thoroughly.

It was only with some reluctance that NAT was defined by the IETF and the idea was that with the introduction of IPv6, the by now wide-spread NAT usage would see its end. As the transition drew closer discussions became more frequent about the need for an IPv6 NAT.

The Internet Architecture Board ( IAB ) released an RFC on the subject in July 2010 [35] by the title “IAB Thoughts on IPv6 Network Address Translation”. The IAB concluded that NAT for IPv6 was primarily desired in the industry for five reasons:

• Avoid renumbering – This is mainly an issue within managed networks. Renumbering the IP addresses of several hosts, devices and servers (for example when changing Internet Service Provider) is a complex and exhausting task that most companies would rather avoid. This is usually solved by acquiring Provider Independent addresses but for those that cannot, NAT:ed networks can be built without fear of future renumbering.

30


• Facilitate multihoming – Multihoming a site increases reliability by advertising its own addresses through multiple Internet Service Providers. Unfortunately this increases the size of the global routing table linearly with the amount of multihomed sites and they are becoming more and more popular. NAT prevents this table increase by having the addresses from different service providers behind a single exit router with NAT functionality. This is currently the only deployed solution against this routing table increase and as such many find it natural that an IPv6 NAT should be used to facilitate multihoming in IPv6 in the same manner.

• Hiding internal network details – This may be the most highly desired aspect of NAT today. Administrators want to obfuscate the address and functionality of hosts inside their network. Operators may also want to hide the topology and interconnection of their network infrastructure. This obfuscation is increased by increased complexity.

• Making configurations homogenous – For support call purposes, it is useful if all network configuration that customers come in contact with have the same addresses, to save time having to look up the IP address of each individual customers router, network card etc.

• Provide simple security – A NAT device is believed by a lot of people to provide a first layer of security since malevolent external sources cannot communicate directly with internal hosts. A NAT does however not improve security in this manner, this is actually the function of a firewall with packet inspection functionality. A possible source of this confusion between a NAT and firewall may be that they are often located on the same device.

The IAB concedes that renumbering,multihoming and homogenous configuration are valid situations where IPv6 NAT may be a solution. Hiding internal network details is possible but the additional complexity required for this to be successful causes substantial trouble for application protocols (SIP and SCTP, Stream Control Transmission Protocol, are examples mentioned) as well as network reachability.

They do however stress the importance of observing the big picture when discussing IPv6 NAT. IPv6 NAT may solve some issues for an individual actor but what needs to be considered is if translation should become a permanent part of the internet infrastructure. If so, transparency will be moved from endpoint to endpoint, to transparency between obfuscated network clusters. This, the IAB argues, would cause severe additional struggle for application developers (who can no longer work with the end-to-end transparency policy) with the possible outcome of even more NAT-application management devices and increased costs for debugging.

It is their opinion that the community should seek transparent solutions and then decide between those which are desirable with regard to scalability, ease of deployment etc.

31


FCP and IPv6A Firewall Control Protocol has been useful for letting aspects of SIP communication function properly through firewalls and NAT:s in an IPv4 world. After mapping and investigating transition scenarios and the suggested technologies for IPv4/IPv6 transition, how does IPv6 impact a firewall control protocol? What complications and additions may be necessary for FCP to continue to be useful? This will be discussed in the sections below.

Complications with IPv6When identifying complications between an IPv4 enabled FCP and the IPv6 protocol, there are three important areas to investigate:

• Extensions to support IPv6 native communication.• Transition communication and devices.• Maintaining IPv4 functionality.

The first thing to observe is the differing address format between IPv4 and IPv6. IPv6 address size is 16 bytes as opposed to the IPv4 4 byte address size. This may seem a trivial observation but it does mean that traffic size for the FCP will increase. Since the usefulness of an FCP transaction is dependent on not affecting the speed and quality of the SIP communication it is facilitating, any additional size of the FCP transaction may become a complication.

Many complications may arise during transition communication. This is especially true in networking today when having IPv6 capability is desired but native IPv6 infrastructure is still limited. As can be seen by the earlier chapters of this report, transition mechanisms are varied and numerous and thus can have differing effects on the use of FCP. Unfortunately, a lot of these effects are out of the developer of an FCP:s control. Given the lack of commonly accepted solutions for IPv4/IPv6 transition, the precise implementation of a transition solution in a network may be not be known to the developer of the FCP.

For example, if a SIP Application Layer Gateway and a firewall are connected via a Firewall Control Protocol and the SIP ALG is trying to facilitate communication between an external IPv4 host and an internal IPv6 host, how is translation handled in the network? Is the translation device located before or after the firewall? Is tunneling employed? Or is either of the hosts dual-stacked? The answers to these questions change the message that FCP sends to the firewall from the SIP ALG when asking the firewall to let certain messages through.

Finally, before the desire to solve transition issues goes too far it's also important to remember that the original IPv4 functionality will still need to be preserved until IPv4 use drops to historic status.

32


Needed additionsSo what additions are necessary when extending a Firewall Control Protocol? Some additions are listed below.

• Accommodate new address format (syntax and size).• Accommodate new/different fields (traffic class and checksum for example).• Make decisions regarding FCP robustness.

• How intelligent should FCP and its users (ALG:s and firewalls for example) be in regards to IPv4/IPv6 transition?

• If the ALG that sends FCP messages also handles translation (perhaps in a proxy solution described earlier in this report) it may contain all information it needs to send correct FCP messages.

• Alternatively, if the firewall/NAT device is in control of translation and the ALG is simply there to handle SIP traffic, the FCP receiver in the firewall/NAT device needs to have the necessary intelligence to translate FCP requests from the ALG. FCP could also be extended to allow for requests with different protocols on entering/exiting the firewall/NAT device.

As can be seen from the above additions, the majority of work comes from transition issues. The native IPv6 communication scenario is not all that different from the native IPv4 communication that FCP is used for today once the new syntax has been implemented.

Suggestions for constructing a protoypeAfter analyzing SIP IPv4/IPv6 transition mechanisms and seeing what complications can arise when combining IPv6 and FCP one observation becomes apparent: The protocol itself needs relatively little to be operational with IPv6 communication but to have it function properly with transition technology requires consideration. For this reason, constructing a prototype of an extended FCP protocol becomes difficult while the industry is still debating what technologies are desired for IPv4/IPv6 transition.

However, FCP usage could be useful in conjunction with a SIP proxy solution. The presence of a SIP ALG that handles translation is ideally suited for instructing a firewall on what packets to allow through via an FCP with IPv4/IPv6 capability.

For designing an initial prototype a first step is to introduce the new address format and size. This will allow FCP to make requests for the new protocol, but otherwise be oblivious to transition mechanisms. From there, a transition mechanism should be determined and the FCP modified altered accordingly. Again, a SIP proxy solution appears ideal for creating a device with the necessary intelligence to send correct FCP requests to the firewall.

33


Final DiscussionWith all analysis and investigation concluded, it is time for a final discussion. First, mythoughts on the state of the industry.

With IPv6 having had a longer introduction phase than anticipated, the last IPv4 addresses have been distributed to regional providers. This is somewhat of a historic event and has shaken many people out of their apathy towards IPv6 implementation. The European Union has been trying to get IPv6 awareness among authorities and in Sweden the eGoverment Delegation is providing an IPv6 guide for authorities who wish to make the transition [36]. I am also personally exited about World IPv6 day, on the 8th of June 2011. On this day several large organizations (like Google, Yahoo! and Facebook) will conduct a 24 hour test of IPv6 connectivity to their services [37]. Here in Sweden, world IPv6 day will be spent with a full day seminar about IPv6 status and discussion [38].

With regards to SIP and IPv6 transition, the state of the industry seems confused. As may be expected when regular IPv4 to IPv6 transition is still in progress, additional protocols that depend on these will find themselves adapting to a world that is still busy reorganizing. The IETF has done their best to solidify a possible future and best practice when implementing SIP and transition mechanisms but contention to their decisions has been widespread, particularly their reliance on ICE and TURN which has a stigma of creating large network overhead.

To let the industry conform to a standardized solution, a demand from consumers needs to appear. As can be seen from two analysis reports by Roman Yasinovskyy et. al. in 2009, “Comparison of VoIP Performance on IPv6 and IPv4” [39] and “Impact of Isec and 6to4 on VoIP Quality over IPv6” [40] the VOIP quality is pretty much the same for both protocols which can make that consumer need harder to achieve. It will however increase naturally, as more and more new networks are introduced and IPv4 addresses are no longer available.

Recommendation regarding SIP,FCP and IPv6So what is my recommendation after this analysis is concluded? After investigating several suggestions for IPv4/IPv6 transition, it is clear that all of them have advantages and disadvantages. With regards to SIP though, a SIP proxy solution seems the most desirable, with a forwarding daemon to forward media streams.

Media streams are a complex situation when discussing transition and SDP modification in the form of ANAT has been abandoned. I do place some hope in the ALTC draft though, which seems like a more lightweight implementation than introducing ICE. To allow all this to function through a firewall/NAT an extended FCP seems ideal in this proxy solution since the proxy knows the translations and can make accurate FCP requests to the firewall.

34


Thoughts regarding masters projectFinally, a few words regarding the masters project, masters project report and future work.

The masters project has been an opportunity to delve deep into an area that I have a real personal interest in. This investigation has also created an insight into how a transitional phase can look when technologies change, something that is generally not observed when learning about them through traditional education.

Much gratitude must be extended to Ingate/Intertex for suggesting the project goal and providing me with both a friendly workplace and a chance to discuss my thoughts with people with extensive experience on SIP and networking!

As can be said about any analysis report there are of course limitations to be considered. Because of the fractured nature of the industry that I am currently investigating it is possible that a technology or solution has escaped my notice. I have however made a point of thoroughly investigating each area to get a thorough mapping of the different options.

For future work, implementing and testing a recommended solution is a natural development, particularly to test FCP capabilities with IPv6. Due to the altering state of the industry such future work may however change priority relatively quickly as the industry comes to a consensus on what constitutes best practice.

35


References[1]S. Deering, Cisco. R. Hinden, Nokia. RFC 2460 Internet Protocol, Version 6 (IPv6) Specification. December 1998.

[2]Daily address report by Geoff Huston, Chief scientist at APNIC. http://www.potaroo.net/tools/IPv4/index.html (4 Jan 2011)

[3]H. Schulzrinne, Columbia University. G. Camarillo, Ericsson. A. Johnston, WorldCom. J. Peterson, Neustar. R. Sparks and J. Rosenberg, Dynamicsoft. M. Handley, ICIR. E. Schooler, AT&T. RFC 3261 SIP: Session Initiation Protocol. June 2002.

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

[5]P. Srisuresh, M. Holdrege, Lucent Technologies. RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations, August 1999.

[6] Ingate Systems, Solving the Firewall/NAT Traversal Issue of SIP: Who Should Control Your Security Infrastructure? http://www.ingate.com/files/Solving_Firewall-NAT_Traversal.pdf (16 maj 2011)

[7]Jiri Kuthan, Jonathan Rosenberg, Internet Draft Middlebox Communication: Framework and Requirements, November 2000

[8]J. Wiljakka, Ed., RFC 4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks, October 2005.

[9]Olle E. Johansson, SIP & IPv6: The action plan. http://edvina.net/blog/2011/03/sip-IPv6-action-plan/ (16 maj 2011).

[10]E. Nordmark, R. Gilligan, RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers, October 2005

[11]Dorgham Sisalem, Jens Fiedler, Reinhard Ruppelt. Fraunhofer Institute FOKUS.Kaiserin-Augusta-Allee 31. 10589 Berlin, Germany. SIP and IPv6: Why and How?

36


[12]Thomas Hoeher and Slobodanka Tomic, ftw. (Telecommunications Research Center Vienna),Vienna, Austria. Richard Menedetter, Institute of Broadband Communications, Technical University Vienna, Vienna, Austria. SIP collides with IPv6. ISBN 0-7695-2622-5

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

[14]Wing & Yourtchenko, Internet-Draft Happy Eardrums: SIP Media IPv6 Migration, August 2010

[15]Yasuro Kawarasaki, Takahiro Shibata, Tom takahashi. NTT Network Systems Laboratories, NTT Corporation,Tokyo, Japan. IPv4/IPv6 SIP interworking methods in dual-stack network.ISBN 0-7803-8114-9.

[16]G. Camarillo, Ericsson, K. El Malki, Athonet, V. Gurbani, RFC 6157 IPv6 Transition in the Session Initiation Protocol (SIP), April 2011, ISSN: 2070-1721

[17]B. Carpenter, K. Moore, RFC 3056 Connection of IPv6 Domains via IPv4 Clouds, February 2001.

[18]C. Huitema, RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs), February 2006

[19]Microsoft Teredo technical note http://technet.microsoft.com/en-us/library/bb457011.aspx (17 maj 2011)

[20]Geoff Huston on Teredo and IPv6http://www.potaroo.net/ispcol/2011-04/teredo.html (16 maj 2011)

[21]E.,Nordmark, RFC 2765 Stateless IP/ICMP Translator (SIIT), February 2000.

[22]G. Tsirtsis, P. Srisuresh, RFC 2766 Network Address Translation - Protocol Translation (NAT-PT), February 2000

[23]C. Aoun, Energize Urnet. E. Davies, Folly Consulting. RFC 4966 Reasons to Move the Network Address Translator - Protocol Translator(NAT-PT) to Historic Status. July 2007,

37


[24]Lambros Lambrinos, Dept. of Communication and Internet Studies, Cyprus University of Technology, Limassol 3603, Cyprus. Peter Kirstein, Dept. of Computer Science, University College London, London WC1E 6BT, UK. Integrating Voice over IP services in IPv4 and IPv6 networks. Proceedings of the International Multi-Conference on Computing in the Global Information Technology (ICCGI'07)ISBN 0-7695-2798-1.

[25]Tomás Robles, Ramiro Ortiz and Joaquín Salvachúa. Technical University of Madrid. Porting the Session Initiation Protocol to IPv6. IEEE Internet Computing 1089-7801, Page 43-50.

[26]A. Gulbrandsen, P. Vixie, L. Esibov, RFC 2782 A DNS RR for specifying the location of services (DNS SRV), February 2000.

[27]J. Rosenberg, R. Mahy, P. Matthews, D. Wing, RFC 5389 Session Traversal Utilities for NAT (STUN), October 2008.

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

[29]Mohamed Boucadair, Yoann Noisette. France Telecom R&D, 42 Rue des coutures,14062 Caen Cedex, France. Migrating SIP-based Conversational Services to IPv6: Complications and interworking with IPv4. Second International Conference on Digital Telecommunications (ICDT'07), ISBN 0-7695-2910-0.

[30]M. Boucadair, H. Kaplan, R. Gilman, S. Veikkolainen, Internet-Draft Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute, March 2011

[31]J. Rosenberg. RFC 5245 (obsoletes 4091) Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols, April 2010. ISSN: 2070-1721.

[32]R. Mahy, P. Matthews, J. Rosenberg, RFC 5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN), April 2010, ISSN: 2070-1721

[33] Saltzer, J.H., Reed, D.P., and Clark, D.D., "End-to-End Arguments in System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.

38


[34]J. Kempf, Ed., R. Austein, Ed., RFC 3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture, March 2004

[35]D. Thaler, L. Zhang, G. Lebovitz, RFC 5902 IAB Thoughts on IPv6 Network Address Translation, July 2010, ISSN: 2070-1721

[36]Swedish eGoverment Delegation.http://www.edelegationen.se/sida/vagledning-for-inforande-av-IPv6 (29 maj 2011)

[37]World IPv6 dayhttp://isoc.org/wp/worldIPv6day/ (29 maj 2011)

[38]IPv6 i praktikenhttp://www.iis.se/evenemang/IPv6-i-praktiken (29 maj 2011)

[39]Roman Yasinovskyy, Alexander L. Wijesinha, Ramesh K. Karne, and Gholam Khaksari.Towson University. A Comparison of VoIP Performance on IPv6 and IPv4 Networks. Proceedings of the 2009 International Conference on Computer Systems and Applications (AICCSA’2009). Page 603-609. ISBN 978-1-4244-3806-8.

[40]R. Yasinovskyy, A. L. Wijesinha, and R. Karne.Towson University, Maryland, USA. Impact of IPsec and 6to4 on VoIP Quality over IPv6.

39

TRITA-CSC-E 2011:074 ISRN-KTH/CSC/E--11/074-SE

ISSN-1653-5715

www.kth.se

sip, fcp and the transition to ipv6 · sip, fcp and the transition to ipv6 gustav rydmark master of...

Documents