Internet DRAFT - draft-akira-v6ops-mape-experience

draft-akira-v6ops-mape-experience







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]