IPv6 Operations A. Nakagawa, Ed. Internet-Draft Japan Network Enabler (JPNE) Intended status: Experimental July 6, 2015 Expires: January 7, 2016 Operational Experience of MAP-E draft-akira-v6ops-mape-experience-00 Abstract This document describes operational experience of "Mapping of Address and Port with Encapsulation (MAP-E)". Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 January 7, 2016. Copyright Notice Copyright (c) 2015 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 described in the Simplified BSD License. Nakagawa Expires January 7, 2016 [Page 1] Internet-Draft MAP-E Experience July 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. General / Overview . . . . . . . . . . . . . . . . . . . . . 2 2.1. Motivation to choose MAP-E . . . . . . . . . . . . . . . 2 2.2. Requirement to the user . . . . . . . . . . . . . . . . . 3 3. Architecture and methodology . . . . . . . . . . . . . . . . 3 3.1. Redundant and Scaling consideration . . . . . . . . . . . 3 3.2. Logging Issue . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Roles of IPv4 and IPv6 Networks . . . . . . . . . . . . . 4 3.4. Encouragement or mechanism move traffic to IPv6 . . . . . 4 4. Operational Considerations . . . . . . . . . . . . . . . . . 5 4.1. Protocols supported and not supported by MAP-E . . . . . 5 4.2. ping . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Applications supported by MAP-E . . . . . . . . . . . . . 5 5. Observations and Experiences . . . . . . . . . . . . . . . . 6 5.1. Effects on End-Users affected by IPv4 address sharing . . 6 5.2. Effects on People affected by IPv4 address sharing . . . 6 5.3. Timer management . . . . . . . . . . . . . . . . . . . . 6 5.4. x.x.x.0 x.x.x.255 IPv4 address . . . . . . . . . . . . . 6 5.5. Spikes of support calls when launched MAP-E . . . . . . . 7 5.6. Internal Staff Issue . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Four years have passed since IPv4 address of IANA pool exhausted. Since then, IPv6 transition technologies have been discussed in IETF. On the other hand, Network operators have been continuing their business by getting transferred IPv4 address from other organizations, by harvesting their IPv4 address from their own networks and so on. Nowadays, some network operators have been installing not only IPv6 but also IPv6 transition technologies, and it is time to share operational information among IETF community. This document describes operational experience of MAP-E that could be used as a reference by network operators who are trying to introduce transition technologies or already introduced. 2. General / Overview 2.1. Motivation to choose MAP-E There are some possible motivations for network providers to choose MAP-E as follows. For example in one of Japanese operators' case, the upper, the much important. Nakagawa Expires January 7, 2016 [Page 2] Internet-Draft MAP-E Experience July 2015 o IPv6 based transition technology is suitable for going to IPv6-only Internet as final goal. o No setup operation by users depending on the implementation. o No daily provisioning operation by network providers. o Not have to have logging function of Border Relay and no storage system of logging in order to identify the packet senders from source IPv4 address, source port and timestamp. o Border Relays scales according to only traffic, not number of user, not number of session. o No session management, such as session expiration timer. o Enables to send packets directly between MAP-E users without going through Border Relay. It reduces the load of Border Relay and the traffic of backbone network. 2.2. Requirement to the user There is nothing to require to users. But operators have to inform users in advance that there are some restrictions caused by MAP-E or IPv4 address sharing. 3. Architecture and methodology 3.1. Redundant and Scaling consideration Network operators are supposed to design the redundant network by choosing combination of topology and technology. There are variety of topologies, for example, one active node with one backup node, plural active nodes with one backup node. There are variety of redundancy technologies, for example, redundancy protocols, routing protocols, and so on. In one of Japanese operators' case, it installs additional active Border Relay(s) in its network. Traffic of each Border Relay balances equally and traffic of each Border Relay is kept less than its capacity. If one of them fails, other Border Relays undertake the rerouted traffic equally. A backbone router that is directly connected to the Border Relays sends packets to anycast address of each Border Relay equally by Equal Cost Multi Path (ECMP). So all Border Relays must equip the same map rule. When traffic of each Border Relay increases much than a certain criteria, operators install additional Border Relays. From daily operation's view, this system absorbs the unexpected spike traffic, because redundant Border Relays are used as active nodes. Nakagawa Expires January 7, 2016 [Page 3] Internet-Draft MAP-E Experience July 2015 3.2. Logging Issue MAP-E does not need logging function just because MAP-E is stateless. Network Operators are required to identify a user from source IPv4 address, source port and timestamp of the packets. Operators of MAP-E can do this by having map rule and the record of IPv6 prefix assignment to users. 3.3. Roles of IPv4 and IPv6 Networks The protocol of entire network of MAP-E must be IPv6. If operators are required to use IPv4 for their operation, backbone network could be dual stack. IPv4 tunnel between MAP CE in homenet and Border Relay in backbone is overlaid on IPv6 network. Protocol of queries of DNS cache server could be IPv6, IPv4 or dual stack. If network operator's goal is IPv6-only, it should be IPv6. If it is operated by IPv6, it can save the consumption of port at MAP CE. 3.4. Encouragement or mechanism move traffic to IPv6 Users are not supposed to consider IPv4 and IPv6. They do not have to do anything, just buying devices such as PCs, smart phones. Most of them are capable of IPv6 function. Network operators have been introducing dual stack of IPv6 and address shared IPv4. The motivation to do this is to continue and expand their business after the IPv4 address exhaustion. Their motivation to move IPv4 traffic to IPv6 could be to keep the good quality of Internet connectivity and to reduce the IPv4 traffic in order to reduce the additional investment in the transition systems. Product makers such as IoT product makers may start producing IPv6-only products. They may have some motivations. They are reluctant to test and support IPv4 function on variety of IPv4 address transition technologies like NAT444, MAP-E, MAP-T, DS-Lite, 464XLAT, and so on. In addition to that, each operator's tuned parameters are different, for example, the number of port assigned to each user, session expiration timer and so on. If the destinations of the packets from such devices are only their own servers, they could produce their product by IPv6-only. Each content provider may have different motivations to move traffic to IPv6 depending upon their business. Nakagawa Expires January 7, 2016 [Page 4] Internet-Draft MAP-E Experience July 2015 o To avoid the limitation of number of port by transition technologies. o To avoid increasing delay by transition technologies. o To avoid testing on variety of transition technologies. o To avoid the network topology in which users are hidden by address sharing systems. 4. Operational Considerations 4.1. Protocols supported and not supported by MAP-E Protocols without port number are not supported by MAP-E because MAP-E needs a function to distinguish users by port number. In IPSec's case, it has a workaround. If client is NAT traversal mode, it functions. FTP has different issue. If client is passive mode, FTP works. On the other hand, if it is active mode, Application Level Gateway is required on MAP CE. 4.2. ping o IPv4 ping available : * from device in homenet to Internet through Border Relay * from MAP CE to Internet * from Internet to WAN interface of MAP CE if operator sets IPv4 address together with ICMP identifier number as destination. o IPv4 not available : * from any place to any place under Border Relay. o It is not perfect but good enough from user's point of view, because users can send ping from their homenet to Internet. Most users do not send ping from Internet to their MAP CE or from their homenet to other user's MAP CE. On the other hand, network operators can send ping to MAP CE. 4.3. Applications supported by MAP-E All applications on supported protocol is available so far, as far as one of Japanese network operators' observation. Nakagawa Expires January 7, 2016 [Page 5] Internet-Draft MAP-E Experience July 2015 Servers in homenet is available if users reassign the port numbers of each service from well known port to the port assigned by network operator. But it is impossible to set up DNS authoritative servers in homenet, because port number 53 is unconfigurable. 5. Observations and Experiences 5.1. Effects on End-Users affected by IPv4 address sharing MAP-E is one of IPv4 address sharing technologies. There are some effects caused by MAP-E and some effects caused by IPv4 address sharing. The following is effects caused by IPv4 address sharing.([RFC6269]s) Most users may not be affected practically, so far. But applications those are not aware of address sharing does not function on MAP-E properly. For example, a very few OLD games do not function on MAP- E. The protocols which require incoming access and the destination port number is unconfigurable does not function. An example is IP conference system that uses H.323 protocol. 5.2. Effects on People affected by IPv4 address sharing People regardless of whether using Internet also affected by IPv4 address sharing. It is becoming complicated to solve the criminal cases, civil litigation, abuse issue, and so on. If packet receivers report source port number in addition to source IPv4 address and timestamp to network operators, network operators can identify the packet sender. Many of server operators do not seem to record port number as an item of access log. On the other hand, some major server operators are recording it. 5.3. Timer management NAT mapping timer is one of the parameters of MAP CE. The shorter interval of NAT mapping timer is, the less it consumes ports of each user. If interval of keepalive of an application is longer than the timer, this application does not function. For example, in case of IP Phone, if the interval of SIP keepalive is longer than the UDP timer, IP phone does not function as a service specification. It does not mean SIP does not function on MAP-E as a technical specification. 5.4. x.x.x.0 x.x.x.255 IPv4 address Map-Rule automatically produces "x.x.x.0" or "x.x.x.255" IPv4 address from IPv6 prefix that is assigned to each user. So the source IPv4 address of packets from user could be "x.x.x.0" or "x.x.x.255". Nakagawa Expires January 7, 2016 [Page 6] Internet-Draft MAP-E Experience July 2015 There are very few sites where they reject these packets. It is not the issue of MAP-E or address sharing, but network operators may know it. 5.5. Spikes of support calls when launched MAP-E Support calls about MAP-E have been quiet since the beginning. 5.6. Internal Staff Issue MAP-E is dual stack, so it is not as simple as IPv4-only network. Even the experts cannot convert IPv6 address to IPv4 address and port without tool. So it is important to have operational tools with easy User Interface for internal staff. For example, trouble shooting tool that sends IPv6 and IPv4 ping to many nodes simultaneously is very useful. It can detect where and what protocol the failure is. 6. Security Considerations There are no new security considerations pertaining to this document. 7. IANA Considerations This specification does not require any IANA actions. 8. Informative References [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. Author's Address Akira Nakagawa (editor) Japan Network Enabler (JPNE) 1-8-1 Otemachi, Chiyoda-ku Tokyo Japan Phone: +81 90 9242 2717 EMail: a-nakagawa@jpne.co.jp Nakagawa Expires January 7, 2016 [Page 7]