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]