--- 1/draft-ietf-6man-udpzero-08.txt 2013-01-19 14:50:02.912125623 +0100 +++ 2/draft-ietf-6man-udpzero-09.txt 2013-01-19 14:50:02.972124718 +0100 @@ -1,20 +1,20 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft University of Aberdeen Intended status: Standards Track M. Westerlund -Expires: June 14, 2013 Ericsson - December 11, 2012 +Expires: July 23, 2013 Ericsson + January 19, 2013 Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums - draft-ietf-6man-udpzero-08 + draft-ietf-6man-udpzero-09 Abstract This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations and examines the role of the IPv6 UDP transport checksum. An appendix presents a summary of the trade-offs that were @@ -29,25 +29,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 14, 2013. + This Internet-Draft will expire on July 23, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -75,74 +75,75 @@ 3.1.2. Corruption of the source IP address . . . . . . . . . 13 3.1.3. Corruption of Port Information . . . . . . . . . . . . 14 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 15 3.1.5. Corruption of Fragmentation Information . . . . . . . 16 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 18 3.3. Validating the network path . . . . . . . . . . . . . . . 18 3.4. Applicability of method . . . . . . . . . . . . . . . . . 19 3.5. Impact on non-supporting devices or applications . . . . . 20 4. Constraints on implementation of IPv6 nodes supporting zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5. Requirements on the usage of zero UDP checksum . . . . . . . . 22 + 5. Requirements on usage of the zero UDP checksum . . . . . . . . 22 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Evaluation of proposal to update RFC 2460 to support zero checksum . . . . . . . . . . . . . . . . 28 A.1. Alternatives to the Standard Checksum . . . . . . . . . . 28 A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 30 A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 31 A.2.3. Ingress and Egress Performance Implications . . . . . 31 - A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 32 + A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 31 A.2.5. Corruption Detection Strength . . . . . . . . . . . . 32 - A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 33 + A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 32 Appendix B. Document Change History . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction The User Datagram Protocol (UDP) [RFC0768] transport is defined for - the Internet Protocol (IPv4) [RFC0791] and is defined in Internet + the Internet Protocol (IPv4) [RFC0791] and is defined in "Internet Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The UDP transport protocol has a minimal set of features. This limited set has enabled a wide range of applications to use UDP, but these application do need to provide many important transport functions on top of UDP. The UDP Usage Guidelines [RFC5405] provides overall guidance for application designers, including the use of UDP to support tunneling. The key difference between UDP usage with IPv4 and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum, i.e. a non-zero value, due to the lack of an IPv6 header checksum. + Algorithms for checksum computation are described in [RFC1071]. The lack of a possibility to use an IPv6 datagram with a zero UDP checksum has been observed as a real problem for certain classes of application, primarily tunnel applications. This class of application has been deployed with a zero UDP checksum using IPv4. The design of IPv6 raises different issues when considering the safety of using a UDP checksum with IPv6. These issues can significantly affect applications, both when an endpoint is the - intended user and when an innocent bystander (i.e. a packet received - by a different endpoint to that intended). + intended user and when an innocent bystander (when a packet is + received by a different endpoint to that intended). This document examines the issues and an appendix compares the strengths and weaknesses of a number of proposed solutions. This identifies a set of issues that must be considered and mitigated to be able to safely deploy IPv6 applications that use a zero UDP checksum. The provided comparison of methods is expected to also be useful when considering applications that have different goals from the ones that initiated the writing of this document, especially the use of already standardized methods. The analysis concludes that - using a zero UDP checksum is the best method of several proposed + using a zero UDP checksum is the best method of the proposed alternatives to meet the goals for certain tunnel applications. This document defines recommendations and requirements for use of IPv6 datagrams with a zero UDP checksum. This usage is expected to have initial deployment issues related to middleboxes, limiting the usability more than desired in the currently deployed internet. However, this limitation will be largest initially and will reduce as updates are provided in middleboxes that support the zero UDP checksum for IPv6. The document therefore derives a set of constraints required to ensure safe deployment of a zero UDP @@ -162,32 +163,32 @@ Section 3 discusses issues with a zero UDP checksum for IPv6. It considers the impact of corruption, the need for validation of the path and when it is suitable to use a zero UDP checksum. Section 4 is an applicability statement that defines requirements and recommendations on the implementation of IPv6 nodes that support the use of a zero UDP checksum. Section 5 provides an applicability statement that defines requirements and recommendations for protocols and tunnel - encapsulations that are transported over an IPv6 transport flow that - does not perform a UDP checksum calculation to verify the integrity - at the transport endpoints. + encapsulations that are transported over an IPv6 transport that does + not perform a UDP checksum calculation to verify the integrity at the + transport endpoints. Section 6 provides the recommendations for standardization of zero UDP checksum with a summary of the findings and notes remaining issues needing future work. Appendix A evaluates the set of proposals to update the UDP transport behaviour and other alternatives intended to improve support for tunnel protocols. It concludes by assessing the trade-offs of the - various methods identifying advantages and disadvantages for each + various methods, identifying advantages and disadvantages for each method. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Use of UDP Tunnels @@ -205,24 +206,23 @@ be used to create virtual (private) networks. 1.3.1. Motivation for new approaches A number of tunnel encapsulations deployed over IPv4 have used the UDP transport with a zero checksum. Users of these protocols expect a similar solution for IPv6. A number of tunnel protocols are also currently being defined (e.g. Automated Multicast Tunnels, AMT [I-D.ietf-mboned-auto-multicast], - and the Locator/Identifier Separation Protocol, LISP - [I-D.ietf-lisp]). These protocols motivated an update to IPv6 UDP - checksum processing to benefit from simpler checksum processing for - various reasons: + and the Locator/Identifier Separation Protocol, LISP [LISP]). These + protocols motivated an update to IPv6 UDP checksum processing to + benefit from simpler checksum processing for various reasons: o Reducing forwarding costs, motivated by redundancy present in the encapsulated packet header, since in tunnel encapsulations, payload integrity and length verification may be provided by higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, or TCP checksums). o Eliminating a need to access the entire packet when forwarding the packet by a tunnel endpoint. @@ -234,28 +234,28 @@ 1.3.2. Reducing forwarding cost It is a common requirement to terminate a large number of tunnels on a single router/host. The processing cost per tunnel includes both state (memory requirements) and per-packet processing. Automatic IP Multicast Tunneling, known as AMT [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the transport protocol for packets carrying tunneled IP multicast packets. The current specification for AMT requires that the UDP - checksum in the outer packet header should be 0 (see Section 6.6 of - [I-D.ietf-mboned-auto-multicast]). This argues that the computation - of an additional checksum is an unwarranted burden on nodes - implementing lightweight tunneling protocols when an inner packet is - already adequately protected, . The AMT protocol needs to replicate - a multicast packet to each gateway tunnel. In this case, the outer - IP addresses are different for each tunnel and therefore require a - different pseudo header to be built for each UDP replicated + checksum in the outer packet header should be zero (see Section 6.6 + of [I-D.ietf-mboned-auto-multicast]). This argues that the + computation of an additional checksum is an unwarranted burden on + nodes implementing lightweight tunneling protocols when an inner + packet is already adequately protected, . The AMT protocol needs to + replicate a multicast packet to each gateway tunnel. In this case, + the outer IP addresses are different for each tunnel and therefore + require a different pseudo header to be built for each UDP replicated encapsulation. The argument concerning redundant processing costs is valid regarding the integrity of a tunneled packet. In some architectures (e.g. PC- based routers), other mechanisms may also significantly reduce checksum processing costs: There are implementations that have optimised checksum processing algorithms, including the use of checksum-offloading. This processing is readily available for IPv4 packets at high line rates. Such processing may be anticipated for IPv6 endpoints, allowing receivers to reject corrupted packets @@ -307,24 +307,24 @@ balancing solutions for IPv4. This approach has also been leveraged for IPv6. An alternate method would be to utilise the IPv6 Flow Label as a basis for entropy for load balancing. This would have the desirable effect of releasing IPv6 load-balancing devices from the need to assume semantics for the use of the transport port field and also works for all type of transport protocols. This use of the flow-label is consistent with the intended use, although further clarity may be needed to ensure the field can be consistently used for this purpose, (e.g. the updated IPv6 Flow Label - Specification [RFC6437] and Equal-Cost Multi-Path routing, ECMP - [RFC6438]). Router vendors could be encouraged to start using the - IPv6 Flow Label as a part of the flow hash, providing support for - ECMP without requiring use of UDP. + [RFC6438] and Equal-Cost Multi-Path routing, ECMP [RFC6437]). Router + vendors could be encouraged to start using the IPv6 Flow Label as a + part of the flow hash, providing support for ECMP without requiring + use of UDP. However, the method for populating the outer IPv6 header with a value for the flow label is not trivial: If the inner packet uses IPv6, then the flow label value could be copied to the outer packet header. However, many current end-points set the flow label to a zero value (thus no entropy). The ingress of a tunnel seeking to provide good entropy in the flow label field would therefore need to create a random flow label value and keep corresponding state, so that all packets that were associated with a flow would be consistently given the same flow label. Although possible, this complexity may not be @@ -375,25 +375,26 @@ bearers). Most link-layers will cover the insensitive part with the same strong layer 2 frame CRC that covers the sensitive part. 2.2.1. Using UDP-Lite as a Tunnel Encapsulation Tunnel encapsulations can use UDP-Lite (e.g. Control And Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- Lite provides a transport-layer checksum, including an IP pseudo header checksum, in IPv6, without the need for a router/middlebox to traverse the entire packet payload. This provides most of the - verification required for delivery and still keeps the complexity of - the checksumming operation low. UDP-Lite may set the length of + verification required for delivery and still keeps a low complexity + for the checksumming operation. UDP-Lite may set the length of checksum coverage on a per packet basis. This feature could be used if a tunnel protocol is designed to only verify delivery of the - tunneled payload and uses full checksumming for control information. + tunneled payload and uses a calcuated checksum for control + information. There is currently poor support for middlebox traversal using UDP- Lite, because UDP-Lite uses a different IPv6 network-layer Next Header value to that of UDP, and few middleboxes are able to interpret UDP-Lite and take appropriate actions when forwarding the packet. This makes UDP-Lite less suited to protocols needing general Internet support, until such time that UDP-Lite has achieved better support in middleboxes and end-points. 2.3. General Tunnel Encapsulations @@ -449,40 +450,40 @@ o the payload integrity. In IPv4, the first four checks are performed using the IPv4 header checksum. In IPv6, these checks occur within the endpoint stack using the UDP checksum information. An IPv6 node also relies on the header information to determine whether to send an ICMPv6 error message [RFC4443] and to determine the node to which this is sent. Corrupted - information may lead to mis-delivery to an unintended application + information may lead to misdelivery to an unintended application socket on an unexpected host. 3.1. Effect of packet modification in the network IP packets may be corrupted as they traverse an Internet path. Evidence has been presented [Sigcomm2000] to show that this was once an issue with IPv4 routers, and occasional corruption could result from bad internal router processing in routers or hosts. These errors are not detected by the strong frame checksums employed at the link-layer [RFC3819]. There is no current evidence that such cases are rare in the modern Internet, nor that they may not be applicable to IPv6. It therefore seems prudent not to relax this constraint. The emergence of low-end IPv6 routers and the proposed use of NAT with IPv6 further motivate the need to protect from this type of error. Corruption in the network may result in: - o A datagram being mis-delivered to the wrong host/router or the + o A datagram being misdelivered to the wrong host/router or the wrong transport entity within an endpoint. Such a datagram needs to be discarded; o A datagram payload being corrupted, but still delivered to the intended host/router transport entity. Such a datagram needs to be either discarded or correctly processed by an application that provides its own integrity checks; o A datagram payload being truncated by corruption of the length field. Such a datagram needs to be discarded. @@ -528,21 +529,21 @@ address. If only the source address is corrupted, the datagram will likely be processed in the intended context, although with erroneous origin information. When using Unicast Reverse Path Forwarding [RFC2827], a change in address may result in the router discarding the packet when the route to the modified source address is different to that of the source address of the original packet. The result will depend on the application or protocol that processes the packet. Some examples are: - o An application that requires a pre-established context may + o An application that requires a per-established context may disregard the datagram as invalid, or could map this to another context (if a context for the modified source address was already activated). o A stateless application will process the datagram outside of any context, a simple example is the ECHO server, which will respond with a datagram directed to the modified source address. This would create unwanted additional processing load, and generate traffic to the modified endpoint address. @@ -551,43 +552,43 @@ in receiver processing and the creation of unnecessary transport- layer state at the receiver. For example, Real Time Protocol (RTP) [RFC3550] sessions commonly employ a source independent receiver port. State is created for each received flow. Reception of a datagram with a corrupted source address will therefore result in accumulation of unnecessary state in the RTP state machine, including collision detection and response (since the same synchronization source, SSRC, value will appear to arrive from multiple source IP addresses). - o Also, as noted above, ICMP messages relating to the corrupted - packet will be misdirected to the wrong source. + o ICMP messages relating to a corrupted packet can be misdirected to + the wrong source node. In general, the effect of corrupting the source address will depend upon the protocol that processes the packet and its robustness to this error. For the case where the packet is received by a tunnel endpoint, the tunnel application is expected to correctly handle a corrupted source address. The impact of source address modification is more difficult to quantify when the receiving application is not that originally intended and several fields have been modified in transit. 3.1.3. Corruption of Port Information This section describes what happens if one or both of the UDP port - values are corrupted in transit. This can also happen with IPv4 when + values are corrupted in transit. This can also happen with IPv4 is used with a zero UDP checksum, but not when UDP checksums are - calculated or with UDP-Lite. If the ports carried in the transport - header of an IPv6 packet were corrupted in transit, packets may be - delivered to the wrong application process (on the intended machine) - and/or responses or errors sent to the wrong application process (on - the intended machine). + calculated or when UDP-Lite is used. If the ports carried in the + transport header of an IPv6 packet were corrupted in transit, packets + may be delivered to the wrong application process (on the intended + machine) and/or responses or errors sent to the wrong application + process (on the intended machine). 3.1.4. Delivery to an unexpected port If one combines the corruption effects, such as destination address and ports, there is a number of potential outcomes when traffic arrives at an unexpected port. This section discusses these possibilities and their outcomes for a packet that does not use the UDP checksum validation: o Delivery to a port that is not in use. The packet is discarded, @@ -631,21 +632,21 @@ requiring checksums can be assumed to have their own checksums provided that the rate of corrupted packets is not significantly larger due to the tunnel encapsulation. If a tunnel transports other inner payloads that do not use IP, the assumptions of corruption detection for that particular protocol must be fulfilled, this may require an additional checksum/CRC and/or integrity protection of the payload and tunnel headers. A protocol that uses a zero UDP checksum can not assume that it is the only protocol using a zero UDP checksum. Therefore, it needs to - gracefully handle mis-delivery. It must be robust to reception of + gracefully handle misdelivery. It must be robust to reception of malformed packets received on a listening port and expect that these packets may contain corrupted data or data associated with a completely different protocol. 3.1.5. Corruption of Fragmentation Information The fragmentation information in IPv6 employs a 32-bit identity field, compared to only a 16-bit field in IPv4, a 13-bit fragment offset and a 1-bit flag, indicating if there are more fragments. Corruption of any of these field may result in one of two outcomes: @@ -664,21 +665,21 @@ is corrupted, resulting in a fragment becoming associated with another packet and taking the place of another fragment. Corruption in the offset information can cause the fragment to be misaligned in the reassembly buffer, resulting in incorrect reassembly. Corruption can cause the packet to become shorter or longer, however completion of reassembly is much less probable, since this would require consistent corruption of the IPv6 headers payload length field and the offset field. The possibility of mis-assembly requires the reassembling stack to provide strong checks that detect overlap or missing data, note however that this - is not guaranteed and has recently been clarified in "Handling of + is not guaranteed and has been clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722]. The erroneous reassembly of packets is a general concern and such packets should be discarded instead of being passed to higher layer processes. The primary detector of packet length changes is the IP payload length field, with a secondary check by the transport checksum. The Upper-Layer Packet length field included in the pseudo header assists in verifying correct reassembly, since the Internet checksum has a low probability of detecting insertion of data or overlap errors (due to misplacement of data). The checksum is also @@ -735,130 +736,133 @@ zero UDP checksum both vulnerable to undetected errors. In conclusion, fragmentation of datagrams with a zero UDP checksum does not worsen the performance compared to some other commonly used tunnel encapsulations. However, caution is needed for recursive tunneling without any additional verification at the different tunnel layers. 3.2. Where Packet Corruption Occurs - Corruption of IP packets can occur at any point in the transmission - chain, during packet generation, in the transmission link, in the - process of routing and switching, etc. Some steps have checksum or - Cyclic Redundancy Check (CRC), which reduces the probability for - erroneous packets being used, but there still exists some probability - for errors to propagate undetected. Unfortunately we lack solid - information about what the most common functions or equipment that - generate packet corruption are. However we have indications that - there are significant variations in where corruption may occur. Thus - there is a risk in applying evidence from one domain of usage onto - another. Anyone intending general Internet usage must unfortunately - assume that corruption will occur and cope with it. + Corruption of IP packets can occur at any point along a network path, + during packet generation, during transmission over the link, in the + process of routing and switching, etc. Some transmission steps + include a checksum or Cyclic Redundancy Check (CRC) that reduces the + probability for corrupted packets being forwarded, but there still + exists a probability that errors may propagate undetected. + Unfortunately the community lacks reliable information to identify + the most common functions or equipment that result in packet + corruption. However, there are indications that the place where + corruption occurs can vary significantly from one path to another. + There is therefore a risk in applying evidence from one domain of + usage to infer characteristics for another. Methods intended for + general Internet usage must therefore assume that corruption can + occur and deploy mechanisms to mitigate the effect of corruption + and/or resulting misdelivery. 3.3. Validating the network path IP transports designed for use in the general Internet should not assume specific path characteristics. Network protocols may reroute packets that change the set of routers and middleboxes along a path. Therefore transports such as TCP, SCTP and DCCP have been designed to negotiate protocol parameters, adapt to different network path characteristics, and receive feedback to verify that the current path is suited to the intended application. Applications using UDP and UDP-Lite need to provide their own mechanisms to confirm the validity of the current network path. A zero value in the UDP checksum field is explicitly disallowed in RFC2460. Thus it may be expected that any device on the path that has a reason to look beyond the IP header will consider such a packet as erroneous or illegal and may discard it, unless the device is updated to support the new behavior. A pair of end-points intending to use a new behavior will therefore not only need to ensure support at each end-point, but also that the path between them will deliver - packets with the new behavior. This may require negotiation or an - explicit mandate to use the new behavior by all nodes needed to - support the use of a new protocol. + packets with the new behavior. This may require using negotiation or + an explicit mandate to use the new behavior by all nodes that support + the new protocol. Enabling the use of a zero checksum places new requirements on equipment deployed within the network, such as middleboxes. A - middlebox (e.g. Firewalls, Network Address and Port Translation - (NAPT)) may enable zero checksum usage for a particular range of - ports. Note that checksum off-loading and operating system design - may result in all IPv6 UDP traffic being sent with a calculated - checksum. This requires middleboxes that are configured to enable a - zero UDP checksum to continue to work with bidirectional UDP flows - that use a zero UDP checksum in only one direction, and therefore - they must not maintain separate state for a UDP flow based on its - checksum usage. + middlebox (e.g. Firewalls, Network Address Translators) may enable + zero checksum usage for a particular range of ports. Note that + checksum off-loading and operating system design may result in all + IPv6 UDP traffic being sent with a calculated checksum. This + requires middleboxes that are configured to enable a zero UDP + checksum to continue to work with bidirectional UDP flows that use a + zero UDP checksum in only one direction, and therefore they must not + maintain separate state for a UDP flow based on its checksum usage. Support along the path between end points can be guaranteed in limited deployments by appropriate configuration. In general, it can be expected to take time for deployment of any updated behaviour to become ubiquitous. A sender will need to probe the path to verify the expected behavior. Path characteristics may change, and usage therefore should be robust and able to detect a failure of the path under normal usage and re- negotiate. Note that a bidirectional path does not necessarily support the same checksum usage in both the forward and return directions: Receipt of a datagram with a zero UDP checksum, does not imply that the remote endpoint can also receive a datagram with a zero UDP checksum. This will require periodic validation of the path, adding complexity to any solution using the new behavior. 3.4. Applicability of method - The IPv6 specification update defined in [I-D.ietf-6man-udpchecksums] - only modifies IPv6 nodes that implement specific protocols designed - to permit omission of a UDP checksum. This document therefore - provides an applicability statement for the updated method indicating - when the mechanism can (and can not) be used. Enabling this, and - ensuring correct interactions with the stack, implies much more than - simply disabling the checksum algorithm for specific packets at the - transport interface. + The update to the IPv6 specification defined in + [I-D.ietf-6man-udpchecksums] only modifies IPv6 nodes that implement + specific protocols designed to permit omission of a UDP checksum. + This document therefore provides an applicability statement for the + updated method indicating when the mechanism can (and can not) be + used. Enabling this, and ensuring correct interactions with the + stack, implies much more than simply disabling the checksum algorithm + for specific packets at the transport interface. When the method is widely available, it may be expected to be used by applications that are perceived to gain benefit. Any solution that uses an end-to-end transport protocol, rather than an IP-in-IP encapsulation, needs to minimise the possibility that application processes could confuse a corrupted or wrongly delivered UDP datagram with that of data addressed to the application running on their endpoint. - First of all the using protocol or application must ensure that this - doesn't significantly affect themselves. That includes receiving - packets from other protocols or contexts as an effect of the - corruption of destination or source address and port values. That - also includes considering what additional implicit protection - mechanisms that exist due to the usage the payload of the UDP packet - with a zero checksum have. + The protocol or application that uses the zero checksum method must + ensure that the lack of checksum does not affect the protocol + operation. This includes being robust to receiving a unintended + packet from another protocol or context following corruption of a + destination or source address and/or port value. It also includes + considering the need for additional implicit protection mechanisms + required when using the payload of a UDP packet received with a zero + checksum. 3.5. Impact on non-supporting devices or applications It is important to consider the potential impact of using a zero UDP checksum on end-point devices or applications that are not modified to support the new behavior or by default or preference, use the regular behavior. These applications must not be significantly impacted by the update. To illustrate why this necessary, consider the implications of a node - enabling the use of a zero UDP checksum at the interface level: This + that enables use of a zero UDP checksum at the interface level: This would result in all applications that listen to a UDP socket receiving datagrams where the checksum was not verified. This could have a significant impact on an application that was not designed with the additional robustness needed to handle received packets with corruption, creating state or destroying existing state in the application. - The use of a zero UDP checksum therefore needs to be enabled only for - individual ports by an explicit request by the application. In this - case, applications using other ports would maintain the current IPv6 + A zero UDP checksum therefore needs to be enabled only for individual + ports using an explicit request by the application. In this case, + applications using other ports would maintain the current IPv6 behavior, discarding incoming datagrams with a zero UDP checksum. These other applications would not be affected by this changed behavior. An application that allows the changed behavior should be aware of the risk of corruption and the increased level of misdirected traffic, and can be designed robustly to handle this risk. 4. Constraints on implementation of IPv6 nodes supporting zero checksum This section is an applicability statement that defines requirements @@ -868,56 +872,58 @@ All implementations that support this zero UDP checksum method MUST conform to the requirements defined below. 1. An IPv6 sending node MAY use a calculated RFC 2460 checksum for all datagrams that it sends. This explicitly permits an interface that supports checksum offloading to insert an updated UDP checksum value in all UDP datagrams that it forwards, however note that sending a calculated checksum requires the receiver to also perform the checksum calculation. Checksum offloading can normally be switched off for a particular - interface to ensure that the datagrams are sent with a zero UDP + interface to ensure that datagrams are sent with a zero UDP checksum. 2. IPv6 nodes SHOULD by default NOT allow the zero UDP checksum method for transmission. 3. IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to send datagrams - with a zero UDP checksum. This may be implemented via a socket - API call, or similar mechanism. It may also be implemented by - enabling the method for a pre-assigned static port used by a + with a zero UDP checksum. This may be implemented by enabling a + transport mode using a socket API call when the socket is + established, or a similar mechanism. It may also be implemented + by enabling the method for a pre-assigned static port used by a specific tunnel protocol. 4. IPv6 nodes MUST provide a method to allow an application/ - protocol to indicate that a particular UDP datagram requires a - UDP checksum. This needs to be allowed by the operating system - at any time (e.g. to send keep-alive datagrams), not just when a - socket is established. + protocol to indicate that a particular UDP datagram is required + to be sent with a UDP checksum. This needs to be allowed by the + operating system at any time (e.g. to send keep-alive + datagrams), not just when a socket is established in the zero + checksum mode. 5. The default IPv6 node receiver behaviour MUST discard all IPv6 packets carrying datagrams with a zero UDP checksum. 6. IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to receive datagrams with a zero UDP checksum. This may be implemented via a socket API call, or similar mechanism. It may also be implemented by enabling the method for a pre-assigned static port used by a specific tunnel protocol. - 7. IPv6 nodes supporting usage of zero UDP checksums MUST allow - reception using a calculated UDP checksum, also on ports - configured to allow zero UDP checksum usage. The sending + 7. IPv6 nodes supporting usage of zero UDP checksums MUST also + allow reception using a calculated UDP checksum on all ports + configured to allow zero UDP checksum usage. (The sending endpoint, e.g. encapsulating ingress, may choose to compute the - UDP checksum, or may calculate this by default. In either case, - the endpoint MUST use the reception method specified in RFC2460 - when the checksum field is not zero. + UDP checksum, or may calculate this by default.) The receving + endpoint MUST use the reception method specified in RFC2460 when + the checksum field is not zero. 8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams with a zero UDP checksum. This remains the case for any datagram received on a port that does not explicitly enable processing of a zero UDP checksum. A port for which the zero UDP checksum has been enabled MUST NOT log the datagram solely because the checksum value is zero. 9. IPv6 nodes MAY separately identify received UDP datagrams that are discarded with a zero UDP checksum. It SHOULD NOT add these @@ -925,177 +931,173 @@ This may be used to support other functions (such as a security policy). 10. IPv6 nodes that receive ICMPv6 messages that refer to packets with a zero UDP checksum MUST provide appropriate checks concerning the consistency of the reported packet to verify that the reported packet actually originated from the node, before acting upon the information (e.g. validating the address and port numbers in the ICMPv6 message body). -5. Requirements on the usage of zero UDP checksum +5. Requirements on usage of the zero UDP checksum This section is an applicability statement that identifies requirements and recommendations for protocols and tunnel - encapsulations that are transported over an IPv6 transport flow that - does not perform a UDP checksum calculation to verify the integrity - at the transport endpoints. - - 1. Protocols that enable the use of zero UDP checksum MUST only - enable this for a specific port or port-range. This needs to be - enabled at the sending and receiving endpoints for a UDP flow. + encapsulations that are transported over an IPv6 transport flow (e.g. + tunnel) that does not perform a UDP checksum calculation to verify + the integrity at the transport endpoints. - 2. An integrity mechanism is always RECOMMENDED at the protocol - layer to ensure that corruption rates of delivered payloads or - encapsulated packets are not increased. A mechanism that - isolates the causes of corruption (e.g. identifying mis- - delivery, IPv6 header corruption, tunnel header corruption) is - expected to also provide additional information about the status - of the tunnel (e.g. to suggest a security attack). + 1. Transported potocols that enable the use of zero UDP checksum + MUST only enable this for a specific port or port-range. This + needs to be enabled at the sending and receibing ednpoints for a + UDP flow. - 3. A protocol that encapsulates Internet Protocol (IPv4 or IPv6) - packets MAY rely on the inner packet integrity checks, provided - that the tunnel protocol will not significantly increase the - rate of corruption of the inner IP packet. If a significantly - increased corruption rate can occur, then the protocol MUST - provide an additional integrity verification mechanism. Early - detection is desirable to avoid wasting unnecessary computation/ - transmission capacity/storage for packets that will subsequently - be discarded. + 2. An integrity mechanism is always RECOMMENDED at the transported + protocol layer to ensure that corruption rates of the delivered + payload is not increased (e.g. the inner-most packet of a UDP + tunnel). A mechanism that isolates the causes of corruption + (e.g. identifying misdelivery, IPv6 header corruption, tunnel + header corruption) is expected to also provide additional + information about the status of the tunnel (e.g. to suggest a + security attack). - 4. A protocol that supports use of a zero UDP checksum MUST be - designed so that corruption of the protocol header information - does not result in accumulated state for the protocol. + 3. A transported protocol that encapsulates Internet Protocol (IPv4 + or IPv6) packets MAY rely on the inner packet integrity checks, + provided that the tunnel protocol will not significantly + increase the rate of corruption of the inner IP packet. If a + significantly increased corruption rate can occur, then the + tunnel protocol MUST provide an additional integrity + verification mechanism. Early detection is desirable to avoid + wasting unnecessary computation, transmission capacity or + storage for packets that will subsequently be discarded. - 5. A UDP based protocol with an non-tunnel payload or that - encapsulate non-IP packets MUST have a CRC or other mechanism - for checking packet integrity, unless the non-IP packet is - specifically designed for transmission over lower layers that do - not provide a packet integrity guarantee. + 4. A transported protocol that supports use of a zero UDP checksum, + MUST be designed so that corruption of this information does not + result in accumulated state for the protocol. - 6. A protocol with control feedback SHOULD be robust to changes in - the network path. The set of middleboxes on a path may vary - during the life of an association. Endpoints need to discover - paths with middleboxes that drop packets with a zero UDP - checksum. Therefore protocols SHOULD send keep-alive messages - with a zero UDP checksum. An endpoint that discovers an - appreciable loss rate for keep-alive packets MAY terminate the - tunnel. Section 3.1.3 of RFC 5405 describes requirements for - congestion control when using UDP-based transport. + 5. A transported protocol that encapsulates a payload that is not + an IP packet flow MUST verify a CRC or other mechanism to check + packet integrity, unless the payload is specifically designed + for transmission over lower layers that do not provide a packet + integrity guarantee. - 7. A protocol with control feedback that can fall-back to using UDP - with a calculated RFC 2460 checksum are expected to be more - robust to changes in the network path. Therefore keep-alive - messages SHOULD include both UDP datagrams with a checksum and - datagrams with a zero UDP checksum. This will enable the remote - endpoint to distinguish between a path failure and dropping of - datagrams with a zero UDP checksum. + 6. A transported protocol with control feedback SHOULD be robust to + changes in the network path, since the set of middleboxes on a + path may vary during the life of an association. Senders + therefore need a method to discover paths with middleboxes that + drop packets with a zero UDP checksum. Therefore keep-alive + messages SHOULD send datagrams with a zero UDP checksum. This + will enable the remote endpoint to distinguish between a path + failure and dropping of datagrams with a zero UDP checksum. - 8. Middlebox implementations MUST allow forwarding of IPv6 UDP - datagram with both a zero and standard UDP checksum. + 7. A middlebox implementation MUST allow forwarding of IPv6 UDP + datagram with both a zero and standard UDP checksum using the + same UDP port. - 9. A middlebox MAY configure a restricted set of specific port + 8. A middlebox MAY configure a restricted set of specific port ranges that forward UDP datagrams with a zero UDP checksum. The middlebox MAY drop IPv6 datagrams with a zero UDP checksum that are outside a configured range. - 10. When a middlebox forwards IPv6 UDP datagram flows containing - datagrams with both zero and standard UDP checksum, the - middlebox MUST NOT maintain separate state for the flow - depending on the value of the UDP checksum field. This - requirement is necessary to enable a sender that always - calculates a checksum to communicate via a middlebox with a - remote endpoint that uses a zero UDP checksum. + 9. When a middlebox forwards an IPv6 UDP flow containg datagrams + with both a zero and standard UDP checksum, the middlebox MUST + NOT maintain separate state for flows depending on the value of + their UDP checksum field. (This requirement is necessary to + enable a sender that always calculates a checksum to communicate + via a middlebox with a remote endpoint that uses a zero UDP + checksum.) + + 10. Section 3.1.3 of RFC 5405 describes requirements for congestion + control for apllications using UDP. 6. Summary This document examines the role of the UDP transport checksum when used with IPv6. It presents a summary of the trade-offs in evaluating the safety of updating RFC 2460 to permit an IPv6 endpoint to use a zero UDP checksum field to indicate that no checksum is present. The use of UDP with a zero UDP checksum has merits for some applications, such as tunnel encapsulation, and is widely used in IPv4. However, there are different dangers for IPv6: There is an - increased risk of corruption and mis-delivery when using zero UDP - checksum in IPv6 compared to IPv4, due to the lack of an IPv6 header - checksum. Thus, applications need to re-evaluate the risks of + increased risk of corruption and misdelivery when using zero UDP + checksum in IPv6 compared to using IPv4 due to the lack of an IPv6 + header checksum. Thus, applications need to re-evaluate the risks of enabling use of a zero UDP checksum and consider a solution that at least provides the same delivery protection as for IPv4, for example by utilizing UDP-Lite, or by enabling the UDP checksum. The use of checksum off-loading may help alleviate the checksum processing cost and permit use of a checksum using method defined in RFC 2460. Tunnel applications using UDP for encapsulation can in many cases use a zero UDP checksum without significant impact on the corruption rate. A well-designed tunnel application should include consistency checks to validate the header information encapsulated with a received packet. In most cases, tunnels encapsulating IP packets can - rely on the inner packets' own integrity protection. When correctly - implemented, such a tunnel endpoint will not be negatively impacted - by omission of the transport-layer checksum. Recursive tunneling and - fragmentation is a potential issue that can raise corruption rates - significantly, and requires careful consideration. + rely on the integrity protection provided by the transported protocol + (or tunneled inner packet). When correctly implemented, such an + endpoint will not be negatively impacted by omission of the + transport-layer checksum. Recursive tunneling and fragmentation is a + potential issue that can raise corruption rates significantly, and + requires careful consideration. Other UDP applications at the intended destination node or another node can be impacted if they are allowed to receive datagrams that have a zero UDP checksum. It is important that already deployed applications are not impacted by a change at the transport layer. If these applications execute on nodes that implement RFC 2460, they will discard (and log) all datagrams with a zero UDP checksum. This is not an issue. In general, UDP-based applications need to employ a mechanism that allows a large percentage of the corrupted packets to be removed before they reach an application, both to protect the data stream of the application and the control plane of higher layer protocols. These checks are currently performed by the UDP checksum for IPv6, or the reduced checksum for UDP-Lite when used with IPv6. - Recursive tunneling and fragmentation is a difficult issue relating - to tunnels in general. There is an increased risk of an error in the - inner-most packet when fragmentation results from several layers of - tunneling and several different reassembly processes are run without - verification of correctness. This issue requires extra thought and - careful consideration. + The transport of recursive tunneling and the use of fragmentation + pose difficult issues that need to be considered in the design of + tunnel protocols. There is an increased risk of an error in the + inner-most packet when fragmentation when several layers of tunneling + and several different reassembly processes are run without + verification of correctness. This requires extra thought and careful + consideration in the design of transported tunnels. The use of the updated method must consider the implications on firewalls, NATs and other middleboxes. It is not expected that IPv6 NATs handle IPv6 UDP datagrams in the same way that they handle IPv4 UDP datagrams. This possibly reduces the need to update the checksum. Firewalls are intended to be configured, and therefore may need to be explicitly updated to allow new services or protocols. IPv6 middlebox deployment is not yet as prolific as it is in IPv4, and therefore new devices are expected to follow the methods specified in this document. Each application should consider the implications of choosing an IPv6 transport that uses a zero UDP checksum, and consider whether other standard methods may be more appropriate, and may simplify application design. 7. Acknowledgements - Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert, - others in the TSV directorate. + Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert, + others in the TSV directorate. Barry Leiba, Ronald Bonica and + Stewart Bryant are thanked for resulting in a document with much + greater applicability. Thanks to P.F. Chimento for careful review + and editorial corrections. Thanks also to: Remi Denis-Courmont, Pekka Savola, Glen Turner, and many others who contributed comments and ideas via the 6man, behave, lisp and mboned lists. - Barry Leiba, Ronald Bonica and Stewart Bryant are thanked for - resulting in a document with much greater applicability. - - A Special thanks to P.F. Chimento for review and editorial - corrections. - 8. IANA Considerations This document does not require any actions by IANA. 9. Security Considerations Transport checksums provide the first stage of protection for the stack, although they can not be considered authentication mechanisms. These checks are also desirable to ensure packet counters correctly log actual activity, and can be used to detect unusual behaviours. @@ -1116,59 +1118,60 @@ mode) could reveal additional information to an on-path attacker to identify the type of tunnel being used. IP-in-IP or GRE tunnels offer good traversal of middleboxes that have not been designed for security, e.g. firewalls. However, firewalls may be expected to be configured to block general tunnels as they present a large attack surface. This applicability statement therefore permits this method to be enabled only for specific ranges of ports. + When enabled, nodes and middleboxes must forward received UDP + datagrams that have either a calculated checksum or a zero checksum. + 10. References 10.1. Normative References [I-D.ietf-6man-udpchecksums] - Eubanks, M., Chimento, P., and M. Westerlund, "UDP - Checksums for Tunneled Packets", - draft-ietf-6man-udpchecksums-05 (work in progress), - October 2012. + Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and + UDP Checksums for Tunneled Packets", + draft-ietf-6man-udpchecksums-07 (work in progress), + January 2013. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 10.2. Informative References [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-00 (work in progress), March 2010. - [I-D.ietf-lisp] - Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, - "Locator/ID Separation Protocol (LISP)", - draft-ietf-lisp-24 (work in progress), November 2012. - [I-D.ietf-mboned-auto-multicast] Bumgardner, G., "Automatic Multicast Tunneling", draft-ietf-mboned-auto-multicast-14 (work in progress), June 2012. + [LISP] D. Farinacci et al, "Locator/ID Separation Protocol + (LISP)", November 2012. + [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988. [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the Internet checksum", RFC 1141, January 1990. [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994. @@ -1236,41 +1239,42 @@ the UDP Checksum [RFC1071] that do not require a tunnel endpoint to inspect the entire packet when computing a checksum. These include (in decreasing order of complexity): o Delta computation of the checksum from an encapsulated checksum field. Since the checksum is a cumulative sum [RFC1624], an encapsulating header checksum can be derived from the new pseudo header, the inner checksum and the sum of the other network-layer fields not included in the pseudo header of the encapsulated packet, in a manner resembling incremental checksum update + [RFC1141]. This would not require access to the whole packet, but does require fields to be collected across the header, and arithmetic operations on each packet. The method would only work - for packets that contain a 2's complement transport checksum (i.e. - it would not be appropriate for SCTP or when IP fragmentation is - used). + for packets that contain a 2's complement transport checksum + (i.e., it would not be appropriate for SCTP or when IP + fragmentation is used). o UDP-Lite with the checksum coverage set to only the header portion of a packet. This requires a pseudo header checksum calculation only on the encapsulating packet header. The computed checksum value may be cached (before adding the Length field) for each flow/destination and subsequently combined with the Length of each packet to minimise per-packet processing. This value is combined with the UDP payload length for the pseudo header, however this length is expected to be known when performing packet forwarding. - o The proposed UDP Tunnel Transport, UDPTT [UDPTT] suggested a - method where UDP would be modified to derive the checksum only - from the encapsulating packet protocol header. This value does - not change between packets in a single flow. The value may be - cached per flow/destination to minimise per-packet processing. + o The proposed UDP Tunnel Transport [UDPTT] suggested a method where + UDP would be modified to derive the checksum only from the + encapsulating packet protocol header. This value does not change + between packets in a single flow. The value may be cached per + flow/destination to minimise per-packet processing. o There has been a proposal to simply ignore the UDP checksum value on reception at the tunnel egress, allowing a tunnel ingress to insert any value correct or false. For tunnel usage, a non standard checksum value may be used, forcing an RFC 2460 receiver to drop the packet. The main downside is that it would be impossible to identify a UDP datagram (in the network or an endpoint) that is treated in this way compared to a packet that has actually been corrupted. @@ -1311,27 +1315,28 @@ A.2.1. Middlebox Traversal Regular UDP with a standard checksum or the delta encoded optimization for creating correct checksums have the best possibilities for successful traversal of a middlebox. No new support is required. A method that ignores the UDP checksum on reception is expected to have a good probability of traversal, because most middleboxes - perform an incremental checksum update. UDPTT may also traverse a - middlebox with this behaviour. However, a middlebox on the path that - attempts to verify a standard checksum will not forward packets using - either of these methods, preventing traversal. A method that ignores - the checksum has an additional downside in that it prevents - improvement of middlebox traversal, because there is no way to - identify UDP datagrams that use the modified checksum behaviour. + perform an incremental checksum update. UDPTT would also have been + able to traverse a middlebox with this behaviour. However, a + middlebox on the path that attempts to verify a standard checksum + will not forward packets using either of these methods, preventing + traversal. A method that ignores the checksum has an additional + downside in that it prevents improvement of middlebox traversal, + because there is no way to identify UDP datagrams that use the + modified checksum behaviour. IP-in-IP or GRE tunnels offer good traversal of middleboxes that have not been designed for security, e.g. firewalls. However, firewalls may be expected to be configured to block general tunnels as they present a large attack surface. A new IPv6 Destination Options header will suffer traversal issues with middleboxes, especially Firewalls and NATs, and will likely require them to be updated before the extension header is passed. @@ -1346,21 +1351,21 @@ update would be identical to that for UDP, but different for checksum validation. A.2.2. Load Balancing The usefulness of solutions for load balancers depends on the difference in entropy in the headers for different flows that can be included in a hash function. All the proposals that use the UDP protocol number have equal behavior. UDP-Lite has the potential for equally good behavior as for UDP. However, UDP-Lite is currently - unlikely to be supported by deployed hashing mechanisms, which may + unlikely to be supported by deployed hashing mechanisms, which could cause a load balancer to not use the transport header in the computed hash. A load balancer that only uses the IP header will have low entropy, but could be improved by including the IPv6 the flow label, providing that the tunnel ingress ensures that different flow labels are assigned to different flows. However, a transition to the common use of good quality flow labels is likely to take time to deploy. A.2.3. Ingress and Egress Performance Implications IP-in-IP tunnels are often considered efficient, because they @@ -1394,31 +1399,30 @@ does not modify the protocol on the wire and only needs changes in tunnel ingress. o IP-in-IP tunnels should not require changes to the end-points, but raise issues when traversing firewalls and other security-type devices, which are expected to require updates. o Ignoring the checksum on reception will require changes at both end-points. The never ceasing risk of path failure requires additional checks to ensure this solution is robust and will - require changes or additions to the tunneling control protocol to + require changes or additions to the tunnel control protocol to negotiate support and validate the path. o The remaining solutions offer similar deployability. UDP-Lite requires support at both end-points and in middleboxes. UDPTT and the zero UDP checksum method with or without an extension header require support at both end-points and in middleboxes. UDP-Lite, UDPTT, and the zero UDP checksum method and use of extension headers may additionally require changes or additions to the - tunneling control protocol to negotiate support and path - validation. + tunnel control protocol to negotiate support and path validation. A.2.5. Corruption Detection Strength The standard UDP checksum and the delta checksum can both provide some verification at the tunnel egress. This can significantly reduce the probability that a corrupted inner packet is forwarded. UDP-Lite, UDPTT and the extension header all provide some verification against corruption, but do not verify the inner packet. They only provide a strong indication that the delivered packet was intended for the tunnel egress and was correctly delimited. The @@ -1600,48 +1604,52 @@ for noting these.Group Draft 05. Working Group Draft 06 * Resubmission to keep draft alive (spelling updated from 05). Working Group Draft 07 * Interim Version - * Resubmission after IESG Feedback + * Submission after IESG Feedback * Updates to enable the document to become a PS Applicability Statement Working Group Draft 08 - * First Version written as a PS Applicability Statement + * Submission for second WGLC as an Applicability Statement - * Changes to reflect decision to update RFC 2460, rather than - recommend decision + * Submission after second WGLC - * Updates to requirements for middleboxes + * Clarified role of API for supporting full checksum. - * Inclusion of requirements for security, API, and tunnel + * Clarified that full checksum is required in security + considerations, and therefore noting that full checksum should + not be treated as an attack - consistent with remainder of + document. - * Move of the rationale for the update to an Annex (former - section 4) + * Added mention that API can set a mode in transport stack - to + link to similar statement in RFC 2460 update. + + * Fixed typos. Authors' Addresses Godred Fairhurst University of Aberdeen School of Engineering Aberdeen, AB24 3UE Scotland, UK Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/users/gorry Magnus Westerlund Ericsson Farogatan 6 - Stockholm SE-164 80 + Stockholm, SE-164 80 Sweden Phone: +46 8 719 0000 Email: magnus.westerlund@ericsson.com