NAT64 Operational Experiences
draft-ietf-v6ops-nat64-experience-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7269.
|
|
|---|---|---|---|
| Authors | Gang Chen , Zhen Cao , Chongfeng Xie , David Binet | ||
| Last updated | 2013-10-13 | ||
| Replaces | draft-chen-v6ops-nat64-experience | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7269 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-v6ops-nat64-experience-04
Internet Engineering Task Force G. Chen
Internet-Draft Z. Cao
Intended status: Informational China Mobile
Expires: April 17, 2014 C. Xie
China Telecom
D. Binet
France Telecom-Orange
October 14, 2013
NAT64 Operational Experiences
draft-ietf-v6ops-nat64-experience-04
Abstract
This document summarizes NAT64 function deployment scenarios and
operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and
NAT64 server Front End (NAT64-FE) are considered in this document.
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 April 17, 2014.
Copyright Notice
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
Chen, et al. Expires April 17, 2014 [Page 1]
Internet-Draft NAT64 Experiences October 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NAT64 Networking Experiences . . . . . . . . . . . . . . . . 4
3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4
3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4
3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4
3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 4
3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5
3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 8
5. Source Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 10
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
12. Additional Author List . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Testing Results of Application Behavior . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
IPv6 is the only sustainable solution for numbering nodes on Internet
due to the IPv4 depletion. Network operators have to deploy
IPv6-only networks in order to meet the needs of the expanding
internet without available IPv4 addresses.
Single stack IPv6 network deployment can simplify network's
provisioning. Some justifications have been described in 464xlat
[RFC6877]. As an example, IPv6-only connectivity confers some
benefits to mobile operators. In such mobile context, it enables the
use of a single IPv6 Packet Data Protocol(PDP) context or Evolved
Packet System (EPS) bearer if Long Term Evolution (LTE) network is
Chen, et al. Expires April 17, 2014 [Page 2]
Internet-Draft NAT64 Experiences October 2013
considered, which eliminates significant network costs caused by
doubling the number of PDP contexts in some cases and the need of
IPv4 addresses to be assigned to customers. In broadband networks
overall, it can allow for the scaling of edge-network growth
decoupled from IPv4 numbering limitations.
In a transition scenario, some existing networks are likely to be
IPv4-only configured for quite a long time. IPv6 networks and hosts
will need to coexist with IPv4 numbered resources. Widespread dual-
stack deployments have not materialized at the anticipated rate over
the last 10 years, one possible conclusion being that legacy networks
will not make the jump quickly. The Internet will include nodes that
are dual-stack, nodes that remain IPv4-only, and nodes that can be
deployed as IPv6-only nodes. A translation mechanism based on a
NAT64[RFC6146] [RFC6145]function is likely to be a key element of the
Internet for IPv6-IPv4 interoperability.
[RFC6036] reports at least 30% of operators plan to run some kind of
translator (presumably NAT64/DNS64). Advice on NAT64 deployment and
operations are therefore of some importance. [RFC6586] documents the
implications for IPv6 only networks. This document intends to be
specific to NAT64 network planning.
2. Terminology
In regards to IPv4/IPv6 translation, [RFC6144] has described a
framework of enabling networks to make interworking possible between
IPv4 and IPv6 networks. This document has further categorized
different NAT64 function locations and use cases. The principle
distinction of location is if the NAT64 is located in a Carrier Grade
NAT or server Front End. The terms of NAT-CGN/FE are understood to be
a topological distinction indicating different features employed in a
NAT64 deployment.
NAT64-CGN: A NAT64-CGN is placed in an ISP network. IPv6
subscribers leverage the NAT64-CGN to access existing IPv4
internet services. The ISP as an administrative entity takes full
control on the IPv6 side, but has limited or no control on the
IPv4 side. NAT64-CGN may have to consider the IPv4 Internet
environment and services to make appropriate configurations.
NAT64-FE: A NAT64-FE is generally a device with NAT64 functionality
in a content provider or data center network. It could be for
example a traffic load balancer or a firewall. The operator of
the NAT64-FE has full control over the IPv4 network within the
data center, but only limited influence or control over the
external IPv6 network.
Chen, et al. Expires April 17, 2014 [Page 3]
Internet-Draft NAT64 Experiences October 2013
3. NAT64 Networking Experiences
3.1. NAT64-CGN Consideration
3.1.1. NAT64-CGN Usages
Fixed network operators and mobile operators may locate NAT64 in
access networks or in mobile core networks. It can be built into
various devices, including routers, gateways or firewalls in order to
connect IPv6 users to the IPv4 Internet. With regard to the numbers
of users and the shortage of public IPv4 addresses, stateful
NAT64[RFC6146] is more adapted to perform some maximal sharing of
public IPv4 addresses. The usage of stateless NAT64 can be seen with
better transparency features
[I-D.ietf-softwire-stateless-4v6-motivation], while it has to be
coordinated with A+P[RFC6346] processes as specified in
[I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope
with IPv4 shortage.
3.1.2. DNS64 Deployment
DNS64[RFC6147] is recommended for use in combination with stateful
NAT64, and will likely be an essential part of an IPv6 single-stack
network that couples to the IPv4 Internet. 464xlat[RFC6877] is
proposed to enable access of IPv4 only applications or applications
that call IPv4 literal addresses. Using DNS64 will help 464xlat to
automatically discover NAT64 prefix through
[I-D.ietf-behave-nat64-discovery-heuristic]. Berkeley Internet Name
Daemon (BIND) software supports the function. It&Perkins, et al. Expires September 25, 2015 [Page 27]
Internet-Draft AODVv2 March 2015
length shorter than the number of bits of the address family
for OrigAddr.
OrigSeqNum
OrigSeqNum is REQUIRED and carries the destination sequence
number associated with OrigNode.
TargSeqNum
TargSeqNum is optional and carries a destination sequence
number associated with TargNode.
MetricList
The MetricList data element is REQUIRED, and carries the route
metric information associated with OrigAddr.
MetricType
The MetricType element defines the type of Metric associated
with the entries in the MetricList.
ValidityTimeList
The ValidityTimeList is optional and carries the length of time
that the sender is willing to offer a route towards OrigAddr.
RREQ messages carry information about OrigAddr and TargAddr, as
identified in the context of the RREQ_Gen. The OrigSeqNum MUST
appear. Both MAY appear in the same RREQ when SeqNum is available
for both OrigAddr and TargAddr.
The OrigSeqNum data element in a RteMsg MUST apply only to OrigAddr.
The other address in the AddressList is TargAddr.
If the TargSeqNum data element appears, then it MUST apply only to
TargAddr. The other address in the AddressList is OrigAddr.
9.1.1. RREQ Generation
Upon receiving an IP packet from one of its Router Clients, it often
happens that an AODVv2 router has no valid route to the destination.
In this case the AODVv2 router is responsible for generating a RREQ
and associated data elements on behalf of its client OrigNode. The
router is referred to as RREQ_Gen. Before creating a RREQ, RREQ_Gen
should check if an RREQ has recently been sent for this destination
and a response is awaited, or if the limit of AODVv2 RREQ retries has
been reached.
In constructing the RREQ, RREQ_Gen uses AddressList, OrigSeqNum,
MetricList, and optionally PrefixLengthList, TargSeqNum, MetricType,
and ValidityTime.
Perkins, et al. Expires September 25, 2015 [Page 28]
Internet-Draft AODVv2 March 2015
RREQ_Gen follows the steps in this section. OrigAddr MUST be a
unicast address. The order of data elements is illustrated
schematically in Figure 1. RREQ_Gen SHOULD include TargSeqNum, if a
previous value of the TargAddr's SeqNum is known (e.g. from an
invalid route table entry using longest-prefix matching). If
TargSeqNum is not included, AODVv2 routers handling the RREQ assume
that RREQ_Gen does not have that information.
1. Set msg_hop_limit to MAX_HOPCOUNT.
2. Set msg_hop_count to zero, if including it.
3. Set AddressList := {OrigAddr, TargAddr}.
4. For the PrefixLengthList:
* If OrigAddr resides on a subnet of Router Clients, set
PrefixLengthList := { OrigAddr subnet's prefix, null }.
* Otherwise, the PrefixLengthList is omitted.
5. For the Sequence Number List:
* Increment the SeqNum as specified in Section 6.4.
* Set OrigSeqNum to the new value of SeqNum.
* If an Invalid route exists matching TargAddr using longest
prefix matching, include TargSeqNum and set it to the sequence
number on the Invalid route. Otherwise omit TargSeqNum.
6. Set MetricList := { Route[OrigAddr].Metric, null }.
7. Include the MetricType data element if requesting a route for a
non-default metric type.
8. If the RREQ_Gen wishes to limit the time that the route to
OrigAddr may be used, include the ValidityTime data element.
9.1.2. RREQ Reception
Upon receiving an RREQ, an AODVv2 router performs the following
steps.
1. A router MUST handle RREQs only from neighbors. RREQs from nodes
that are not neighbors MUST be disregarded.
Perkins, et al. Expires September 25, 2015 [Page 29]
Internet-Draft AODVv2 March 2015
2. Check whether the sender is on the blacklist of AODVv2 routers
(see Section 6.2). If not, continue processing. Otherwise,
check the Blacklist Remove Time.
* If Current_Time < Remove Time, ignore this RREQ for further
processing.
* If Current_Time >= Remove Time, remove the Blacklist entry and
continue processing.
3. Verify that the message contains the required data elements:
msg_hop_limit, OrigAddr, TargAddr, OrigSeqNum, OrigAddrMetric,
and verify that OrigAddr and TargAddr are valid addresses
(routable and unicast). If not, ignore this message for further
processing.
4. If the MetricType data element is present, check that the
MetricType is known.
* If not, ignore this RREQ for further processing.
* Otherwise continue processing .
5. Verify that OrigAddrMetric <= {MAX_METRIC[MetricType] -
Cost(Link)}.
* If not, ignore this RREQ for further processing.
* Otherwise continue processing .
6. Process the route to OrigAddr as specified in Section 8.1.
7. Check if the message is a duplicate or redundant by comparing to
entries in the RteMsg table as described in Section 8.6.
* If duplicate or redundant, ignore this RREQ for further
processing.
* Otherwise save the information in the RteMsg table to identify
future duplicates and continue processing.
8. Check if the TargAddr belongs to one of the Router Clients.
* If so, generate a RREP as specified in Section 9.2.1.
* Otherwise, continue to RREQ regeneration.
Perkins, et al. Expires September 25, 2015 [Page 30]
Internet-Draft AODVv2 March 2015
9.1.3. RREQ Regeneration
Unless the router is prepared to advertise the new route, it halts
processing. By sending a RREQ, a router advertises that it will
forward packets to the OrigAddr contained in the RREQ according to
the information enclosed. The router MAY choose not to regenerate
the RREQ, though this could decrease connectivity in the network or
result in non-optimal paths.
The circumstances under which a router MAY choose not to regenerate a
RREQ are not specified in this document. Some examples may include
the router being heavily loaded and not advertising routing for more
traffic, or being low on energy and having to reduce energy expended
for sending AODVv2 messages or packet forwarding.
The procedure for RREQ regeneration is as follows:
1. Check the msg_hop_limit.
* If it is zero, do not regenerate.
* Otherwise, decrement the value by one.
2. Check if msg_hop_count is present and greater than or equal to
MAX_HOPCOUNT
* If so, do not regenerate.
* Otherwise, increment msg_hop_count by one.
3. Change OrigAddrMetric to match the route table entry for
OrigAddr, which should match the advertised value in the received
RREQ plus the cost of the link to the router which forwarded the
RREQ.
4. If the incoming RREQ contains a ValidityTimeList, it MUST be
copied into the regenerated RREQ. If not present, and the
regenerating router wishes to limit the time that its route to
OrigAddr may be used, set ValidityTimeList := {ValidityTime for
OrigAddr, null}.
If the received RREQ was unicast, the regenerated RREQ can be unicast
to the next hop address of the route towards TargAddr, if known.
Otherwise, the RREQ SHOULD be multicast to the LL-MANET-Routers IP
and MAC address [RFC5498], [RFC4291].
Perkins, et al. Expires September 25, 2015 [Page 31]
Internet-Draft AODVv2 March 2015
9.2. RREP Messages
RREP messages are used to offer a route to a target address, and are
sent in response to a RREQ message. RREP messages have the following
general structure:
+-----------------------------------------------------------------+
| msg_hop_limit, msg_hop_count |
+-----------------------------------------------------------------+
| AckReq (optional) |
+-----------------------------------------------------------------+
| AddressList := {OrigAddr,TargAddr} |
+-----------------------------------------------------------------+
| PrefixLengthList := {null, PrefixLength for TargAddr(optional)} |
+-----------------------------------------------------------------+
| TargSeqNum |
+-----------------------------------------------------------------+
| MetricList := {null, metric for TargAddr} |
+-----------------------------------------------------------------+
| MetricType (optional) |
+-----------------------------------------------------------------+
| ValidityTimeList := {null, ValidityTime for TargAddr}(optional) |
+-----------------------------------------------------------------+
Figure 2: RREP message structure
RREP Data Elements
msg_hop_limit
The remaining number of hops allowed for dissemination of the
RREP message.
msg_hop_count
The number of hops already traversed during dissemination of
the RREP message.
AckReq
Acknowledgement Requested by sender (optional).
AddressList
AddressList contains OrigAddr and TargAddr.
PrefixLengthList
PrefixLengthList contains the length of the prefix for
TargAddr, if TargAddr resides on a Client Network with a prefix
length shorter than the number of bits of the address family
for TargAddr.
Perkins, et al. Expires September 25, 2015 [Page 32]
Internet-Draft AODVv2 March 2015
TargSeqNum
TargSeqNum is REQUIRED and carries the destination sequence
number associated with TargNode.
MetricList
The MetricList data element is REQUIRED, and carries the route
metric information associated with TargAddr.
MetricType
The MetricType element defines the type of Metric associated
with the entries in the MetricList.
ValidityTimeList
The ValidityTimeList is optional and carries the length of time
that the sender is willing to offer a route towards TargAddr.
RREP messages carry information about OrigAddr and TargAddr, as known
in the context of the RREP_Gen. The TargSeqNum MUST appear. It MUST
apply only to TargAddr. The other address in the AddressList is
OrigAddr.
9.2.1. RREP Generation
This section specifies the generation of an RREP by an AODVv2 router
(RREP_Gen) that provides connectivity for TargAddr, thus enabling the
establishment of a route between OrigAddr and TargAddr. In
constructing the RREP, AODVv2 uses AddressList, TargSeqNumber List,
MetricList, and optionally AckReq, PrefixLengthList and/or
ValidityTimeList. These elements are then used to create a RFC5444
message; see Section 10 for details.
The AckReq data element indicates that an acknowledgement to the RREP
has been requested. If no corresponding RREP_Ack is received within
the RREP_Ack_SENT_TIMEOUT, the next hop is added to the blacklist as
discussed in Section 6.2.
The procedure for RREP generation is as follows:
1. Set msg_hop_limit to the msg_hop_count from the received RREQ
message.
2. Set msg_hop_count, if including it, to zero.
3. Include the AckReq data element if RREP_Ack is requested from the
next hop (as described in Section 6.2).
4. Include the MetricType data element and set the type accordingly.
Perkins, et al. Expires September 25, 2015 [Page 33]
Internet-Draft AODVv2 March 2015
5. Set the Address List := {OrigAddr, TargAddr}.
6. For the PrefixLengthList:
* If TargAddr resides on a subnet of Router Clients, set
PrefixLengthList := {null, TargAddr subnet's prefix}.
* Otherwise, no PrefixLengthList is needed.
7. For the TargSeqNum:
* RREP_Gen increments its SeqNum as specified in Section 6.4.
* Set TargSeqNum := the new value of SeqNum.
8. Set MetricList := { null, Route[TargAddr].Metric }.
9. If the RREP_Gen wishes to limit the time that the route to
TargAddr may be used, set ValidityTimeList := {null, TargAddr
ValidityTime}.
By default, the RREP is sent by unicast to the IP address of the next
hop of the RREP_Gen's route to OrigAddr.
9.2.2. RREP Reception
Upon receiving an RREP, an AODVv2 router performs the following
steps.
1. Verify that the RREP message contains the required data elements:
msg_hop_limit, OrigAddr, TargAddr, TargAddrMetric, TargSeqNum,
and verify that OrigAddr and TargAddr are valid addresses
(routable and unicast). If not, ignore this RREP message for
further processing.
2. Check that the MetricType is known.
* If not, ignore this RREP for further processing.
* Otherwise continue processing .
3. Verify that TargAddrMetric <= {MAX_METRIC[MetricType] -
Cost(Link)}.
* If not, ignore this RREP for further processing.
* Otherwise continue processing .
Perkins, et al. Expires September 25, 2015 [Page 34]
Internet-Draft AODVv2 March 2015
4. Process the route to TargAddr as specified in Section 8.1.
5. If the AckReq data element is present, send a RREP_Ack as
specified in Section 9.4.
6. Check if the message is a duplicate or redundant by comparing to
entries in the RREP table as described in Section 8.6.
* If duplicate or redundant, ignore this RREP for further
processing.
* Otherwise save the information in the RREP table to identify
future duplicates and continue processing.
7. Check if the OrigAddr belongs to one of the Router Clients.
* If so, the RREP satisfies a previously sent RREQ. Processing
is complete and data can now be forwarded along the route.
Any packets from OrigAddr that were buffered for later
delivery SHOULD be transmitted.
* Otherwise, continue to RREP regeneration.
9.2.3. RREP Regeneration
Similar to rules for RREQ regeneration, unless the router is prepared
to advertise the route to TargAddr, it halts processing. By
forwarding a RREP, a router advertises that it will forward packets
to the TargAddr contained in the RREP according to the information
enclosed. The router MAY choose not to regenerate the RREP, for the
same reasons as mentioned under RREQ regeneration Section 9.1.3,
though this could decrease connectivity in the network or result in
non-optimal paths.
If no valid route exists to OrigAddr, a RERR SHOULD be transmitted to
TargAddr as specified in Section 9.3.1 and the RREP should not be
regenerated.
The procedure for RREP regeneration is as follows:
1. Check the msg_hop_limit.
* If it is zero, do not regenerate.
* Otherwise, decrement the value by one.
2. If msg_hop_count is present, then:
Perkins, et al. Expires September 25, 2015 [Page 35]
Internet-Draft AODVv2 March 2015
* If msg_hop_count >= MAX_HOPCOUNT, do not regenerate.
* Otherwise, increment msg_hop_count by one.
3. The RREP SHOULD be unicast to the next hop on the route to
OrigAddr. If no valid route exists to OrigAddr, a RERR SHOULD be
transmitted to TargAddr as specified in Section 9.3.1.
4. Change TargAddrMetric to match the route table entry for
TargAddr, which should match the advertised value in the received
RREP plus the cost of the link to the router which forwarded the
RREP.
5. Include the AckReq data element if this device requires
acknowledgement of the RREP message.
6. If the incoming RREP contains a ValidityTimeList, it MUST be
copied into the regenerated RREP. If not present, and the
regenerating router wishes to limit the time that its route to
TargAddr may be used, set ValidityTimeList := {null, ValidityTime
for TargAddr}.
The RREP SHOULD be unicast to the next hop on the route to OrigAddr.
9.3. RERR Messages
An RERR message is generated by a AODVv2 router (i.e., RERR_Gen) in
order to notify upstream routers that packets cannot be delivered to
one or more destinations. An RERR message has the following general
structure:
+-----------------------------------------------------------------+
| msg_hop_limit |
+-----------------------------------------------------------------+
| PktSource (optional) |
+-----------------------------------------------------------------+
| RERR AddressList |
+-----------------------------------------------------------------+
| PrefixLengthList for UnreachableAddresses (optional) |
+-----------------------------------------------------------------+
| SeqNumList (one entry per address) |
+-----------------------------------------------------------------+
| MetricType (optional) |
+-----------------------------------------------------------------+
Figure 3: RERR message structure
RERR Data Elements
Perkins, et al. Expires September 25, 2015 [Page 36]
Internet-Draft AODVv2 March 2015
msg_hop_limit
The remaining number of hops allowed for dissemination of the
RERR message.
PktSource
The IP address of the unreachable destination triggering RERR
generation. If this RERR message was triggered by a broken
link, the PktSource data element is not required.
RERR AddressList
A list of IP addresses not reachable by the AODVv2 router
transmitting the RERR.
PrefixLengthList
PrefixLengthList contains the prefix lengths associated with
the addresses in the RERR AddressList, if any of them reside on
a Client Network with a prefix length shorter than the number
of bits of their address family.
MetricType
If MetricType != DEFAULT_METRIC_TYPE, the MetricType associated
with routes affected by a broken link.
SeqNumList
The list of sequence numbers associated with the
UnreachableAddresses in the RERR AddressList.
9.3.1. RERR Generation
There are two types of events which trigger generation of a RERR
message. The first is the arrival of a packet for which there is no
route to the destination address. This can be a packet forwarded by
the routing process, or a RREP when there is no route to OrigAddr.
In this case, exactly one UnreachableAddress will be included in
RERR's AddressList (either the Destination Address of the IP header
from a data packet, or the OrigAddr found in the AddressList of an
RREP message). RERR_Gen MUST discard the packet or message that
triggered generation of the RERR.
The second type of event happens when a link breaks. All routes
(whether valid or not) that use the broken link MUST be marked as
Invalid. If the broken link was not used by any Active route, no
RERR message is generated. Every Invalid route reported in the RERR
MUST have the same MetricType. If the broken link affects routes to
destinations that have different MetricTypes, multiple RERR messages
must be generated.
Perkins, et al. Expires September 25, 2015 [Page 37]
Internet-Draft AODVv2 March 2015
If an AODVv2 router receives an ICMP packet to or from the address of
one of its client nodes, it simply forwards the ICMP packet, and does
not generate any RERR message.
In constructing the RERR, AODVv2 uses MetricType, AddressList,
SeqNumList, and in some cases PktSource and PrefixLengthList. These
elements are then used to create a RFC5444 message; see Section 10
for details.
The procedure for RERR generation is as follows:
1. Set msg_hop_limit to MAX_HOPCOUNT.
2. If the RERR was triggered by an Undeliverable Packet, the
PktSource data element MUST be included, containing the source IP
address of the Undeliverable Packet.
3. Include the MetricType data element if reporting a Invalid route
for a non-default metric type.
4. For the RERR AddressList:
* If the RERR was triggered by an undeliverable packet, insert
the destination IP address of the undeliverable packet, or if
the packet was a RREP, insert the OrigAddr.
* If the RERR was triggered by a broken link, include the
addresses of all previously Active routes which are now
Invalid, up to the limit imposed by the MTU (interface
"Maximum Transfer Unit") of the physical medium. If there are
too many such previously Active routes, additional RERR
messages should be constructed and transmitted to contain the
remaining addresses. If the configuration option
ENABLE_IDLE_IN_RERR is enabled, include any previously Idle
routes which are now Invalid, as long as the packet size of
the RERR does not exceed the MTU.
5. If there are destinations reported in the RERR AddressList that
have associated subnet prefixes in the route table, insert those
prefixes in the PrefixLengthList; otherwise, omit the
PrefixLengthList.
6. If known, the sequence numbers associated with the routes to the
addresses in the RERR AddressList SHOULD be included in the
SeqNumList; otherwise, omit the SeqNumList.
If the RERR is sent in response to an Undeliverable Packet:
Perkins, et al. Expires September 25, 2015 [Page 38]
Internet-Draft AODVv2 March 2015
o It SHOULD be sent unicast to the next hop towards the source IP
address of the packet which triggered the RERR.
o Otherwise the RERR MUST be sent to the multicast IP and MAC
address for LL-MANET-Routers.
If the RERR is sent in response to a broken link:
o If precursor lists are maintained for the addresses in the RERR
AddressList (see Section 12.2), the RERR SHOULD be unicast to the
precursors.
o Otherwise the RERR MUST be sent to the multicast IP and MAC
address for LL-MANET-Routers.
9.3.2. RERR Reception
Upon receiving an RERR, the following steps are performed.
1. If the message does not contain the msg_hop_limit and at least
one UnreachableAddress, do not process the RERR.
2. If the MetricType data element is present, check that the
MetricType is known.
* If not, ignore this RERR for further processing.
* Otherwise continue processing .
3. For each UnreachableAddress,
* Check that the address is valid (routable and unicast).
* Check that there is a valid route with the same MetricType
matching the address using longest prefix matching.
* Check that the route's next hop is the sender of the RERR.
* Check that the route's next hop interface is the interface on
which the RERR was received.
* Check that the Unreachable Address SeqNum is either unknown,
or is greater than the route's SeqNum.
* If any of the above are false, the UnreachableAddress does not
need to be advertised in a regenerated RERR.
* If all of the above are true:
Perkins, et al. Expires September 25, 2015 [Page 39]
Internet-Draft AODVv2 March 2015
+ If the route's prefix length is the same as the
UnreachableAddress's prefix length, set the route state to
Invalid.
+ If the prefix length is shorter than the original route,
the route MUST be expunged from the routing table, since it
is a sub-route of the larger route which is reported to be
Invalid.
+ If the prefix length is different, create a new route with
the UnreachableAddress and its prefix, and set the state to
Invalid.
If there are no UnreachableAddresses which need to be advertised in a
regenerated RERR, take no further action.
Otherwise regenerate the RERR as specified in Section 9.3.3.
9.3.3. RERR Regeneration
The procedure for RERR regeneration is as follows:
1. Check the msg_hop_limit.
* If it is zero, do not regenerate.
* Otherwise, decrement the value by one.
2. If the PktSource data element was included in the original RERR,
copy it into the regenerated RERR.
3. For the RERR AddressList, include all UnreachableAddresses which
have been determined to need regeneration.
4. For the PrefixLengthList, insert the prefix lengths associated
with the addresses in the RERR AddressList.
5. For the SeqNumList, include the sequence numbers corresponding to
the addresses in the RERR AddressList.
If the original RERR contained the PktSource data element, and a
route exists to the source address, the regenerated RERR MUST be sent
unicast to the next hop of the route towards PktSource.
Otherwise, if precursor lists are maintained, the regenerated RERR
SHOULD be sent to the active precursors of the Invalid routes as
specified in Section 12.2.
Perkins, et al. Expires September 25, 2015 [Page 40]
Internet-Draft AODVv2 March 2015
Otherwise the regenerated RERR MUST be sent to the multicast IP and
MAC address for LL-MANET-Routers.
9.4. RREP_Ack Messages
RREP_Ack is modeled on the RREP_Ack message type from AODV [RFC3561].
RREP_Ack messages have the following general structure:
+-----------------------------------------------------------------+
| msg_hop_limit := 1 |
+-----------------------------------------------------------------+
Figure 4: RREP_Ack message structure
RREP_Ack Data Elements
msg_hop_limit
The remaining number of hops allowed for dissemination of the
RREP_Ack message.
9.4.1. RREP_Ack Generation
This section specifies the generation of an RREP_Ack by an AODVv2
router. The procedure is as follows:
1. Set msg_hop_limit := 1.
The RREP_Ack is sent by unicast to the IP address of router that
inserted a AckReq data element into a RREP message.
9.4.2. RREP_Ack Reception
Upon receiving an RREP_Ack, an AODVv2 router performs the following
steps.
1. The router checks whether the sender's IP address is in the
blacklist. If so, the IP address is deleted from the blacklist.
2. The router checks whether an RREP_Ack message was expected from
the sending IP address, in response to an AckReq data element
that the router included in a preceding RREP message as specified
in Section 9.2.1. If so, the router records that the required
RREP_Ack has been received and cancels the associated timeout.
Perkins, et al. Expires September 25, 2015 [Page 41]
Internet-Draft AODVv2 March 2015
10. Representing AODVv2 data elements using RFC 5444
AODVv2 specifies that all control plane messages between Routers
SHOULD use the Generalised Mobile Ad-hoc Network Packet and Message
Format [RFC5444], which provides a multiplexed transport for multiple
protocols. AODVv2 therefore specifies Route Messages comprising data
elements that map to message elements in RFC5444 but, in line with
the concept of use, does not specify which order the messages should
be arranged in an RFC5444 packet. An implementation of an RFC5444
multiplexer may choose to optimise the content of certain message
elements to reduce control plane overhead. For handling of messages
that contain unknown TLV types, the multiplexer SHOULD ignore the
information for processing, but preserve it unmodified for
forwarding.
Here is a brief summary of the RFC 5444 format.
1. A packet formatted according to RFC 5444 contains zero or more
messages.
2. A message contains a message header, message TLV block, and zero
or more address blocks.
3. Each address block MAY also have one TLV blocks; each TLV block
MAY encode any number of TLVs (including zero). Each TLV value
in an Address TLV block is associated with exactly one of the
addresses in the address block.
The following table shows how AODVv2 data elements are represented in
RFC 5444 messages.
Perkins, et al. Expires September 25, 2015 [Page 42]
Internet-Draft AODVv2 March 2015
+------------------------+------------------------------------------+
| Data Element | RFC 5444 Message Representation |
+------------------------+------------------------------------------+
| msg_hop_limit | RFC 5444 Message Header <msg-hop-limit> |
| msg_hop_count | RFC 5444 Message Header <msg-hop-count> |
| AckReq | Acknowledgement Request Message TLV |
| PktSource | The Packet Source Message TLV |
| RteMsg AddressList | RFC 5444 Address Block |
| - OrigAddr | |
| - TargAddr | |
| - PrefixLengthList | |
| RERR AddressList | RFC 5444 Address Block |
| - UnreachableAddress | |
| - PrefixLengthList | |
| SeqNumList | Sequence Number Address Block TLV |
| - SeqNum | |
| OrigSeqNum | Originating Node Sequence Number Address |
| | Block TLV |
| TargSeqNum | Target Node Sequence Number Address |
| | Block TLV |
| MetricType | Extension byte of Metric Address Block |
| | TLV |
| MetricList | Metric Address Block TLV |
| - OrigAddrMetric | - corresponds to OrigAddr |
| - TargAddrMetric | - corresponds to TargAddr |
| ValidityTimeList | VALIDITY_TIME Address Block TLV |
| - ValidityTime | |
+------------------------+------------------------------------------+
Table 3
AODVv2 neither requires any inclusion nor uses any information from
the packet header. The length of an address (32 bits for IPv4 and
128 bits for IPv6) inside an AODVv2 message is indicated by the msg-
addr-length (MAL) in the msg-header. Although the addresses in an
Address Block may appear in any order, each TLV value in a TLV Block
is associated with exactly one Address in the Address Block. So, for
instance, the ordering of the OrigAddrMetric and TargAddrMetric
values in the MetricList is determined by the order of OrigAddr and
TargAddr in the preceding RteMsg Address List. See Section 14.2 for
more information about AODVv2 Message TLVs. See Section 14.3 for
more information about AODVv2 Address Block TLVs.
11. Simple Internet Attachment
Simple Internet attachment means attachment of a stub (i.e., non-
transit) network of AODVv2 routers to the Internet via a single
Internet AODVv2 router (called IAR).
Perkins, et al. Expires September 25, 2015 [Page 43]
Internet-Draft AODVv2 March 2015
As in any Internet-attached network, AODVv2 routers, and their
clients, wishing to be reachable from hosts on the Internet MUST have
IP addresses within the IAR's important to note
that DNS64 generates the synthetic AAAA reply when services only
register A records. Operators should not expect to access IPv4 parts
of a dual-stack server using NAT64/DNS64. The traffic is forwarded
on IPv6 paths if dual-stack servers are targeted. IPv6 traffic may
be routed not going through NAT64. Only the traffic going to
IPv4-only service would traverse NAT64. In some sense, it encourages
IPv6 transmission and restrains NAT uses compared to NAT44(if used),
on which all traffic flows have to be traversed and translated. In
some cases, NAT64-CGN may serve double roles, i.e. a translator and
IPv6 forwarder. Some failure cases may be occurred once NAT64 serves
a IPv6 gateway while is configured only with IPv4 on WAN links. We
tested on Top100 websites (referring to [Alexa] statistics) in such
condition. 43% of websites are failed to be connected since those
websites have both AAAA and A records. Therefore, it's recommended
to enable NAT64 WAN links with dual-stack connections in such case.
3.1.3. NAT64 Placement
Chen, et al. Expires April 17, 2014 [Page 4]
Internet-Draft NAT64 Experiences October 2013
All connections to IPv4 services from IPv6-only clients must traverse
the NAT64-CGN. It can be advantageous from the vantage-point of
troubleshooting and traffic engineering to carry the IPv6 traffic
natively for as long as possible within an access network and
translate packets only at or near the network egress. NAT64 can be
considered as a feature of the Autonomous System (AS) border in fixed
networks. And, it is likely to be deployed in an IP node beyond the
Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway
(PDN-GW) in mobile networks or directly in the gateway itself in some
situations. This allows consistent attribution and traceability
within the service provider network. It has been observed that the
process of correlating log information is problematic from multiple-
vendor's equipment due to inconsistent formats of log records.
Placing NAT64 in a centralized location may reduce diversity of log
format and simplify the network provisioning. Moreover, since NAT64
is only targeted at serving traffic flows from IPv6 to IPv4-only
services, the user traffic volume should not be as high as in a NAT44
scenario, and therefore, the gateway's capacity in such location may
not be as much of a concern or a hurdle to deployment. On the other
hand, the placement in a centralized way would require more strict
high availability (HA) design. It would also make geo-location based
on IPv4 addresses rather inaccurate as it is currently the case for
NAT44 CGN already deployed in ISP networks. More considerations or
workarounds on HA and traceability could be found at Section 4 and
Section 5.
3.1.4. Co-existence of NAT64 and NAT44
NAT64 could likely co-exist with NAT44 in a dual-stack network mostly
because IPv4 private addresses are allocated to customers. The
coexistence has already appeared in mobile networks, in which dual
stack mobile phones normally initiate some dual-stack PDN/PDP
Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated
addresses are very often private ones. [RFC6724] always prioritizes
IPv6 connections regardless of whether the end-to-end path is native
IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy
Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The
selection of IPv4/IPv6 paths may depend on particular implementation
choices or settings on a host-by-host basis, and may differ from an
operator's deterministic scheme. Our tests verified that hosts may
find themselves switching between IPv4 and IPv6 paths as they access
identical service, but at different times
[I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each
path is different, it may cause unstable user experiences and some
degradation of Quality of Experience (QoE) when fallback to the other
protocol is not powerful enough for example. It's also difficult for
operators to debug the issue and make optimal resource usages on both
NAT44 and NAT64. It's desirable to find the solutions that will
Chen, et al. Expires April 17, 2014 [Page 5]
Internet-Draft NAT64 Experiences October 2013
allow introducing IPv6/IPv4 translation service to IPv6-only hosts
while keeping dual-stack hosts unaffected and IPv4 service unchanged.
3.2. NAT64-FE Consideration
Some Internet Content Providers (ICPs) may locate NAT64 in front of
an Internet Data Center (IDC), for example co-located with load
balancing function. Load balancers are employed to connect different
IP family domains, meanwhile distribute workloads across multiple
domains or internal servers actually. In some cases, IPv4 addresses
exhaustion may not be a problem in some IDC's networks. IPv6 support
for some applications may require some investments and workloads so
IPv6 support may not be a priority. The use of NAT64 may be served
to support widespread IPv6 adoption on the Internet while maintaining
IPv4-only applications access.
Different strategy has been described in [RFC6883]referred to as
"inside out" and "outside in". An IDC operator may implement the
following practices in the NAT64-FE networking.
o Some ICPs who already have satisfactory operational experiences
would adopt single stack IPv6 operations to build up their data
center network, servers and applications since it allows new
services delivery without having to integrate consideration of
IPv4 NAT and address limitations of IPv4 networks. Stateless
NAT64[RFC6145]is used to provide services for IPv4-only
subscribers. [I-D.anderson-siit-dc]has provided further
descriptions and guidelines.
o ICPs who attempt to offer customers IPv6 support in their
application farms at an early stage may likely run some proxies,
which are configured to handle incoming IPv6 flows and proxy them
to IPv4 back-end systems. Many load balancers have already
integrated some proxy functionality. IPv4 addresses configured in
the proxy can be multiplexed like a stateful NAT64 performs. A
similar challenge exists once increasingly numerous users in IPv6
Internet access an IPv4 network. High loads on load-balancers may
be apt to cause additional latency, IPv4 pool exhaustion, etc.
Therefore, this approach is only reasonable at an early stage.
ICPs may learn from the experiences and move on to dual-stack or
IPv6 single stack in a further stage, since the native IPv6 is
always more desirable than transition solutions.
[RFC6144] recommends that AAAA records of load-balancers or
application servers can be directly registered in the authoritative
DNS servers requiring to populate these servers with corresponding
AAAA records. In this case, there is no need to deploy DNS64
servers. Those AAAA records can be some native IPv6 addresses or
Chen, et al. Expires April 17, 2014 [Page 6]
Internet-Draft NAT64 Experiences October 2013
some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6
address does not give the possibility to nodes to get any information
about NAT64 presence on communication path and the possibility to
prefer IPv4 path or the IPv6 path in dual-stack networks. Using an
independent sub domain e.g. ipv6exp.xxx.xxx may help to identify
experimental ipv6 services to users. How to design the FQDN for the
IPv6 service is out-of-scope of this document.
4. High Availability
4.1. Redundancy Design
High Availability (HA) is a major requirement for every service and
network services. The deployment of redundancy mechanism is an
essential approach to avoid single-point failure and significantly
increase the network reliability. It's not only useful to stateful
NAT64 cases, but also to stateless NAT64 gateways.
Three redundancy modes are mainly used hereafter: cold standby, warm
standby and hot standby.
o Cold standby can't replicate the NAT64 states from the primary
equipment to the backup. Administrators switch on the backup
NAT64 only if the primary NAT64 fails. As the results, all the
existing established sessions will be disconnected. The internal
hosts are required to re-establish sessions to the external hosts.
Since the backup NAT64 is manually configured to switch over to
active NAT64, it may have unpredictable impacts to the ongoing
services. Normally, the handover would take several minutes so as
to wait for the whole process of NAT64 bootstrap loader.
o Warm standby is a flavor of the cold standby mode. Backup NAT64
would keep running once the primary NAT64 is working. This makes
warm standby less time consuming during the traffic failover.
Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a
solution to enable automatic handover in the warm standby. It was
tested that the handover takes as maximum as 1 minute if the
backup NAT64 needs to take over routing and re-construct the
Binding Information Bases (BIBs) for 30 million sessions. In
deployment phase, operators could balance loads on distinct NAT64s
devices. Those NAT64s make a warm backup of each other.
o Hot standby must synchronize the BIBs between the primary NAT64
and backup. When the primary NAT64 fails, backup NAT64 would take
over and maintain the state of all existing sessions. The
internal hosts don't have to re-connect the external hosts. The
handover time has been extremely reduced. Thanks to Bidirectional
Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay
Chen, et al. Expires April 17, 2014 [Page 7]
Internet-Draft NAT64 Experiences October 2013
of only 35ms for 30 million sessions handover was observed during
testing. In some sense, it could guarantee the session continuity
for every service. In order to timely transmit states
information, operators may have to deploy extra transport links
between primary NAT64 and distant backup.
In general, cold-standby and warm-standby is simpler and less
resource intensive, but it requires clients to re-establish sessions
when a fail-over occurs. Hot standby doubles resource's consumption
to synchronize the states, but it achieve seamless handover. The
consideration of redundancy mode for stateless NAT64 is simple,
because it doesn't have to consider time consuming for states
maintenance. The warm standby is sufficient for stateless NAT64. In
regards to stateful NAT64, it maybe useful to investigate performance
tolerance of applications and the traffic characteristics in a
particular network. Some testing results are shown in the
Appendix A.
Our statistics in a mobile network shown that almost 91.21% of amount
of traffic is accounted by browsing services. Those services don't
require session continuity. The handover time of warm standby is
qualified to the delay tolerance. Hot-standby does not offer much
benefit for those sessions on this point. In a fixed network, HTTP
streaming, p2p and online games would be the major
traffic[Cisco-VNI]. Consideration should be given to the importance
of maintaining bindings for those sessions across failover.
Operators may also consider the Average Revenue Per User (ARPU)
factors to deploy suitable redundancy mode. Warm standby may still
be adopted to cover most services while hot standby could be used to
upgrade Quality of Experience (QoE) using DNS64 with different
synthetic responses for limited traffic. Further considerations are
discussed at Section 6.
4.2. Load Balancing
Load balancing is used to accompany redundancy design so that better
scalability and resiliency could be achieved. Stateless NAT64s allow
asymmetric routing while anycast-based solutions are recommended in
[I-D.ietf-softwire-map-deployment]. The deployment of load balancing
may make more sense to stateful NAT64s for the sake of single-point
failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct
facilities, the following lists the considerations for each case.
o NAT64-CGN equipment doesn't implement load balancer functions on a
board card. Therefore, the gateways have to resort to DNS64 or
internal host's behavior. Once DNS64 is deployed, the load
balancing can be performed by synthesizing AAAA response with
different IPv6 prefixes. For the applications not requiring DNS
Chen, et al. Expires April 17, 2014 [Page 8]
Internet-Draft NAT64 Experiences October 2013
resolver, internal hosts could learn multiple IPv6 prefixes
through the approaches defined
in[I-D.ietf-behave-nat64-discovery-heuristic] and then select one
based on a given prefix selection policy.
o A dedicated Load Balancer could be deployed at front of a NAT64-FE
farm. Load Balancer uses proxy mode to redirect the flows to the
appropriate NAT64 instance. Stateful NAT64s require a
deterministic pattern to arrange the traffic in order to ensure
outbound/inbound flows traverse the identical NAT64. Therefore,
static scheduling algorithms, for example source-address based
policy, is preferred. A dynamic algorithm, for example Round-
Robin, may have impacts on applications seeking session
continuity, which described in the Table 1.
5. Source Address Transparency
5.1. Traceability
Traceability is required in many cases such as identifying malicious
attacks sources and accounting requirements. Operators are asked to
record the NAT64 log information for specific periods of time. In
our lab testing, the log information from 200,000 subscribers have
been collected from a stateful NAT64 gateway for 60 days.
Syslog[RFC5424] has been adopted to transmit log message from NAT64
to a log station. Each log message contains transport protocol,
source IPv6 address:port, translated IPv4 address: port and
timestamp. It takes almost 125 bytes long in ASCII format. It has
been verified that the volume of recorded information reach up to
42.5 terabytes in the raw format and 29.07 terabytes in a compact
format. Operators have to build up dedicated transport links,
storage system and servers for the purpose. There are also several
implementations to mitigate the issue. For example, stateful NAT64
could configure with bulk port allocation method. Once a subscriber
creates the first session, a number of ports are pre-allocated. A
bulk allocation message is logged indicating this allocation.
Subsequent session creations will use one of the pre-allocated port
and hence does not require logging. The log volume in this case may
be only one thousandth of dynamic port allocation. Some
implementations may adopt static port-range allocations
[I-D.donley-behave-deterministic-cgn] which eliminates the need for
per-subscriber logging. As a side effect, the IPv4 multiplexing
efficiency is decreased regarding to those methods. For example, the
utilization ratio of public IPv4 address is dropped approximately to
75% when NAT64 gateway is configured with bulk port allocation (The
lab testing allocates each subscriber with 400 ports). In addition,
port-range based allocation should also consider port randomization
described in [RFC6056] . A trade-off among address multiplexing
Chen, et al. Expires April 17, 2014 [Page 9]
Internet-Draft NAT64 Experiences October 2013
efficiency, logging storage compression and port allocation
complexity should be considered. More discussions could be found in
[I-D.chen-sunset4-cgn-port-allocation].Basically, the decision
depends on usable IPv4 resource and investments of log systems.
5.2. Geo-location
IP addresses are usually used as inputs to geo-location services.
The use of address sharing will prevent these systems from resolving
the location of a host based on IP address alone. Applications that
assume such geographic information may not work as intended. The
possible solutions listed in [RFC6967] are intended to bridge the
gap. However, those solutions can only provide a sub-optimal
substitution to solve the problem of host identification, in
particular it may not today solve problems with source identification
through translation. The following lists current practices to
mitigate the issue.
o Operators who adopt NAT64-FE may leverage the application layer
proxies, e.g. X-Forwarded-For (XFF)
[I-D.ietf-appsawg-http-forwarded], to convey the IPv6 source
address in HTTP headers. Those messages would be passed on to
web-servers. The queried server can lookup Radius servers for the
target subscribers based on IPv6 addresses included in XFF HTTP
headers. XFF is the de facto standard which has been integrated
in most Load Balancers. Therefore, it may be superior to use in a
NAT-FE environment. In the downsides, XFF is specific to HTTP.
It restricts the usages so that the solution can't be applied to
requests made over HTTPs. This makes geo-location problematic for
HTTPs based services.
o The NAT64-CGN equipment may not implement XFF. Geo-location based
on shared IPv4 address is rather inaccurate in that case.
Operators could subdivide the outside IPv4 address pool so an IPv6
address can be translated depending on their geographical
locations. As consequence, location information can be identified
from a certain IPv4 address range. [RFC6967] also enumerates
several options to reveal the host identifier. Each solution
likely has their-own specific usage. For the geo-location systems
relying on a Radius database[RFC5580], we have investigated to
deliver NAT64 BIBs and Session Table Entrys (STEs) to a Radius
server[I-D.chen-behave-nat64-radius-extension]. This method could
provide geo-location system with an internal IPv6 address to
identify each user. It can get along with [RFC5580] to convey
original source address through same message bus.
6. Quality of Experience
Chen, et al. Expires April 17, 2014 [Page 10]
Internet-Draft NAT64 Experiences October 2013
6.1. Service Reachability
NAT64 is providing a translation capability between IPv6 and IPv4
end-nodes. In order to provide the reachability between two IP
address families, NAT64-CGN has to implement appropriate application
aware functions, i.e. Application Layer Gateway (ALG), where address
translation is not itself sufficient and security mechanisms do not
render it infeasible. Most NAT64-CGNs mainly provide FTP-
ALG[RFC6384]. NAT64-FEs may have functional richness on Load
Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have
been supported. It should be noted that ALGs may impact the
performance on a NAT64 box to some extent. ISPs as well as content
providers might choose to avoid situations where the imposition of an
ALG might be required. At the same time, it is also important to
remind customers and application developers that IPv6 end-to-end
usage does not require ALG imposition and therefore results in a
better overall user experience.
6.2. Resource Reservation
Session status normally is managed by a static timer. For example,
the value of the "established connection idle-timeout" for TCP
sessions must not be less than 2 hours 4 minutes[RFC5382] and 5
minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe
significantly consumed by largely inactive users. The NAT translator
and other customers would suffer from service degradation due to port
consummation by other subscribers using the same NAT64 device. A
flexible NAT session control is desirable to resolve the issues.
PCP[RFC6887] could be a candidate to provide such capability. A
NAT64-CGN should integrate with a PCP server, to allocate available
IPv4 address/port resources. Resources could be assigned to PCP
clients through PCP MAP/PEER mode. Such ability can be considered to
upgrade user experiences, for example assigning different sizes of
port ranges for different subscribers. Those mechanisms are also
helpful to minimize terminal battery consumption and reduce the
number of keep-alive messages to be sent by mobile terminal devices.
Subscribers can also benefit from network reliability. It has been
discussed that hot-standby offers satisfactory experience once outage
of primary NAT64 is occurred. Operators may rightly be concerned
about the considerable investment required for NAT64 equipment
relative to low ARPU income. For example, transport links may cost
much, because primary NAT64 and backup are normally located at
different locations, separated by a relatively large distance.
Additional maintenance has to be spent to ensure the connectivity
quality. However, that may be necessary to some applications, which
are delay-sensitive and seek session continuity, for example on-line
games and live-streaming. Operators may be able to get added-values
Chen, et al. Expires April 17, 2014 [Page 11]
Internet-Draft NAT64 Experiences October 2013
from those services by offering first-class services. It can be pre-
configured on the gateway to hot-standby modes depending on
subscriber's profile. The rest of other sessions can be covered by
cold/warm standby.
7. MTU Considerations
IPv6 requires that every link in the internet have an Maximum
Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. However,
in case of NAT64 translation deployment, some IPv4 MTU constrained
link will be used in some communication path and originating IPv6
nodes may therefore receive an ICMP Packet Too Big (PTB) message,
reporting a Next-Hop MTU less than 1280 bytes. The result would be
that IPv6 allows packets to contain a fragmentation header, without
the packet being fragmented into multiple pieces. A NAT64 would
receive IPv6 packets with fragmentation header in which "M" flag
equal to 0 and "Fragment Offset" equal to 0. Those packets likely
impact other fragments already queued with the same set of {IPv6
Source Address, IPv6 Destination Address, Fragment Identification}.
If the NAT64 box is compliant with [RFC5722], there is risk that all
the fragments have to be dropped.
[RFC6946] discusses how this situation could be exploited by an
attacker to perform fragmentation-based attacks, and also proposes an
improved handling of such packets. It required enhancements on NAT64
gateway implementations to isolate packet's processing. NAT64 should
follow the recommendation and take steps to prevent the risks of
fragmentation.
Another approach that potentially avoids this issue is to configure
IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB
smaller than 1280 bytes. Such an operational consideration is hard
to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged.
However, it's a feasible approach in NAT64-FE cases, since a IPv4
network NAT64-FE connected is rather well-organized and operated by a
IDC operator or content provider. Therefore, the MTU of IPv4 network
in NAT64-FE case are strongly recommended to set to more than 1260
bytes.
8. ULA Usages
Chen, et al. Expires April 17, 2014 [Page 12]
Internet-Draft NAT64 Experiences October 2013
Unique Local Addresses (ULAs) are defined in [RFC4193] to be
renumbered within a network site for local communications. Operators
may use ULAs as NAT64 prefixes to provide site-local IPv6
connectivity. Those ULA prefixes are stripped when the packets going
to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site.
The use of ULAs could help in identifying the translation
traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided
further guidance for the ULAs usages.
We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is
only assigned with an IPv6 address and connected to NAT64-CGN, when
connect to an IPv4 service, it would receive AAAA record generated by
the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will
be selected as the source address to the ULA destination address.
When the host has both IPv4 and IPv6 address, it would initiate both
A and AAAA record lookup, then both original A record and
DNS64-generated AAAA record would be received. A host, which is
compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4
path will be always selected. It may be undesirable because the
NAT64-CGN will never be used. Operators may consider to add
additional site-specific rows to the default table to steer traffic
flows going through NAT64-CGN. However, it involves significant
costs to change terminal's behavior. Therefore, operators are not
suggested to configure ULAs on a NAT64-CGN.
ULAs can't work when hosts transit the Internet to connect with
NAT64. Therefore, ULAs are inapplicable to the case of NAT64-FE.
9. Security Considerations
his document presents the deployment experiences of NAT64 in CGN and
FE scenarios. In general, RFC 6146[RFC6146] provides TCP-tracking,
address-dependent filtering mechanisms to protect NAT64 from
Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators
also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and
black/white-list to enhance the security by specifying access
policies. For example, NAT64-CGN should forbid establish NAT64 BIB
for incoming IPv6 packets if uRPF in Strict or Loose mode check does
not pass or whose source IPv6 address is associated to black-lists.
The stateful NAT64-FE creates state and maps that connection to an
internally-facing IPv4 address and port. An attacker can consume the
resources of the NAT64-FE device by sending an excessive number of
connection attempts. Without a DDoS limitation mechanism, the
NAT64-FE is exposed to attacks. Load Balancer is recommended to
enable the capabilities of line rate DDOS defense, such as the
employment of SYN PROXY-COOKIE. Security domain division is
necessary as well in this case. Therefore, Load Balancers could not
Chen, et al. Expires April 17, 2014 [Page 13]
Internet-Draft NAT64 Experiences October 2013
only serve for optimization of traffic distribution, but also prevent
service from quality deterioration due to security attacks.
10. IANA Considerations
This memo includes no request to IANA.
11. Acknowledgements
The authors would like to thank Jari Arkko, Dan Wing, Remi Despres,
Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum, Philip
Matthews, Randy Bush, Mikael Abrahamsson, Lorenzo Colitti and Sheng
Jiang for their helpful comments.
Many thanks to Wesley George and Satoru Matsushima for their detailed
reviews.
The authors especially thank Joel Jaeggli and Ray Hunter for his
efforts and contributions on editing which substantially improves the
legibility of the document.
Thanks to Cameron Byrne who was an active co-author of some earlier
versions of this draft.
12. Additional Author List
The following are extended authors who contributed to the effort:
Qiong Sun
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn
QiBo Niu
ZTE
50,RuanJian Road.
YuHua District,
Nan Jing 210012
P.R.China
Email: niu.qibo@zte.com.cn
13. References
Chen, et al. Expires April 17, 2014 [Page 14]
Internet-Draft NAT64 Experiences October 2013
13.1. Normative References
[I-D.ietf-appsawg-http-forwarded]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 2012.
[I-D.ietf-behave-nat64-discovery-heuristic]
Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", draft-
ietf-behave-nat64-discovery-heuristic-17 (work in
progress), April 2013.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
Aboba, "Carrying Location Objects in RADIUS and Diameter",
RFC 5580, August 2009.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
Chen, et al. Expires April 17, 2014 [Page 15]
Internet-Draft NAT64 Experiences October 2013
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG)
for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
6946, May 2013.
13.2. Informative References
[Alexa] Alexa, "http://www.alexa.com/topsites", April 2013.
[Cisco-VNI]
Cisco, "Cisco Visual Networking Index: Forecast and
Methodology, 2012-2017,
http://ciscovni.com/forecast-widget/index.html", May 2013.
[I-D.anderson-siit-dc]
Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data
Centre Environments", draft-anderson-siit-dc-00 (work in
progress), November 2012.
[I-D.chen-behave-nat64-radius-extension]
Chen, G. and D. Binet, "Radius Attributes for Stateful
NAT64", draft-chen-behave-nat64-radius-extension-00 (work
in progress), July 2013.
Chen, et al. Expires April 17, 2014 [Page 16]
Internet-Draft NAT64 Experiences October 2013
[I-D.chen-sunset4-cgn-port-allocation]
Chen, G., "Analysis of NAT64 Port Allocation Method",
draft-chen-sunset4-cgn-port-allocation-02 (work in
progress), July 2013.
[I-D.donley-behave-deterministic-cgn]
Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments", draft-donley-
behave-deterministic-cgn-06 (work in progress), July 2013.
[I-D.ietf-softwire-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", draft-ietf-softwire-4rd-07 (work in
progress), October 2013.
[I-D.ietf-softwire-map-deployment]
Sun, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault,
"Mapping of Address and Port (MAP) - Deployment
Considerations", draft-ietf-softwire-map-deployment-02
(work in progress), July 2013.
[I-D.ietf-softwire-map-t]
Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work
in progress), September 2013.
[I-D.ietf-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Carrier-side
Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-
softwire-stateless-4v6-motivation-05 (work in progress),
November 2012.
[I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B., Jiang, S., and C. Byrne, "Recommendations of
Using Unique Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-00 (work in progress), May 2013.
[I-D.kaliwoda-sunset4-dual-ipv6-coexist]
Kaliwoda, A. and D. Binet, "Co-existence of both dual-
stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual-
ipv6-coexist-01 (work in progress), October 2012.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
Chen, et al. Expires April 17, 2014 [Page 17]
Internet-Draft NAT64 Experiences October 2013
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider
Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization's routable and topologically correct
prefix (e.g. 191.0.2.0/24).
/-------------------------\
/ +----------------+ \
/ | AODVv2 Router | \
| | 191.0.2.2/32 | |
| +----------------+ | Routable
| +-----+--------+ Prefix
| | Internet | /191.0.2/24
| | AODVv2 Router| /
| | 191.0.2.1 |/ /---------------\
| | serving net +------+ Internet \
| | 191.0.2/24 | \ /
| +-----+--------+ \---------------/
| +----------------+ |
| | AODVv2 Router | |
| | 191.0.2.3/32 | |
\ +----------------+ /
\ /
\-------------------------/
Figure 5: Simple Internet Attachment Example
When an AODVv2 router within the AODVv2 MANET wants to discover a
route toward a node on the Internet, it uses the normal AODVv2 route
discovery for that IP Destination Address. The IAR MUST respond to
RREQ on behalf of all Internet destinations.
When a packet from a node on the Internet destined for a node in the
AODVv2 MANET reaches the IAR, if the IAR does not have a route toward
that destination it will perform normal AODVv2 route discovery for
that destination.
12. Optional Features
Some optional features of AODVv2, associated with AODV, are not
required by minimal implementations. These features are expected to
apply in networks with greater mobility, or larger node populations,
or requiring reduced latency for application launches. The optional
features are as follows:
o Expanding Rings Multicast
o Precursor lists.
Perkins, et al. Expires September 25, 2015 [Page 44]
Internet-Draft AODVv2 March 2015
o Multicast RREP Response to RREQ
o Intermediate RREPs (iRREPs): Without iRREP, only the destination
can respond to a RREQ.
o Message Aggregation Delay.
12.1. Expanding Rings Multicast
For multicast RREQ, msg_hop_limit MAY be set in accordance with an
expanding ring search as described in [RFC3561] to limit the RREQ
propagation to a subset of the local network and possibly reduce
route discovery overhead.
12.2. Precursor Lists and Notifications
This section specifies an interoperable enhancement to AODVv2 (and
possibly other reactive routing protocols) enabling more economical
RERR notifications to traffic sources upon determination that a route
needed to forward such traffic to its destination has become Invalid.
12.2.1. Overview
In many circumstances, there can be several sources of traffic for a
certain destination. Each such source of traffic is known as a
"precursor" for the destination, as well as all upstream routers
between the forwarding AODVv2 router and the traffic source. There
is no need to keep track of upstream routers any farther away than
the next hop. For each destination, an AODVv2 router MAY choose to
keep track of the upstream neighbors that have provided traffic for
that destination.
Moreover, any particular link to an adjacent AODVv2 router may be a
path component of multiple routes towards various destinations. The
precursors for all destinations using the next hop across any link
are collectively known as the precursors for that next hop.
When an AODVv2 router marks a route as Invalid, the precursors of the
Invalid route should be notified (using RERR) about the change in
status of their route to the destination of that Invalid route.
12.2.2. Precursor Notification Details
During normal operation, each AODVv2 router wishing to maintain
precursor lists as described above, maintains a precursor table and
updates the table whenever the node forwards traffic to one of the
destinations in its route table. For each precursor in the precursor
list, a record must be maintained to indicate whether the precursor
Perkins, et al. Expires September 25, 2015 [Page 45]
Internet-Draft AODVv2 March 2015
has been used for recent traffic (in other words, whether the
precursor is an Active precursor). So, when traffic arrives from a
precursor, the Current_Time is used to mark the time of last use for
the precursor list element associated with that precursor.
When an AODVv2 router detects that a link is broken, then for each
Active precursor using that next hop, the node MAY notify the
precursor using either unicast or multicast RERR:
unicast RERR to each Active precursor
This option is applicable when there are few Active precursors
compared to the number of neighboring AODVv2 routers.
multicast RERR to RERR_PRECURSORS
RERR_PRECURSORS is, by default, LL-MANET-Routers [RFC5498]. This
option is typically preferable when there are many precursors,
since fewer packet transmissions are required.
Each neighbor receiving the RERR MAY then execute the same procedure
until all upstream routers have received the RERR notification.
12.3. Multicast RREP Response to RREQ
The RREQ Target Router (RREP_Gen) MAY, as an alternative to
unicasting a RREP, be configured to use multicast to distribute
routing information about the route toward TargAddr. RREP_Gen does
this as described in Section 9.2.1, but multicasting the RREP to LL-
MANET-Routers [RFC5498]. Routers receiving the multicast RREP must
perform RteMsg suppression (see Section 8.6).
Broadcast RREP response to incoming RREQ was originally specified to
handle unidirectional links, but it is expensive. Due to the
significant overhead, AODVv2 routers MUST NOT use multicast RREP
unless configured to do so by setting the administrative parameter
USE_MULTICAST_RREP. This technique can be used to find the best
return path rather than follow the same path as the RREQ took.
12.4. Intermediate RREP
This specification has been published as a separate Internet Draft
[I-D.perkins-irrep].
12.5. Message Aggregation Delay
The aggregation of multiple messages into a packet is specified in
RFC 5444 [RFC5444].
Perkins, et al. Expires September 25, 2015 [Page 46]
Internet-Draft AODVv2 March 2015
Implementations MAY choose to briefly delay transmission of messages
for the purpose of aggregation (into a single packet) or to improve
performance by using jitter [RFC5148].
13. Administratively Configurable Parameters and Timer Values
AODVv2 uses various configurable parameters of various types:
o Timers
o Protocol constants
o Administrative (functional) controls
o Other administrative parameters and lists
The tables in the following sections show the parameters along their
definitions and default values (if any).
Note: several fields have limited size (bits or bytes). These sizes
and their encoding may place specific limitations on the values that
can be set. For example, <msg-hop-count> is a 8-bit field and
therefore MAX_HOPCOUNT cannot be larger than 255.
13.1. Timers
AODVv2 requires certain timing information to be associated with
route table entries. The default values are as follows:
+------------------------+---------------+
| Name | Default Value |
+------------------------+---------------+
| ACTIVE_INTERVAL | 5 second |
| MAX_IDLETIME | 200 seconds |
| MAX_BLACKLIST_TIME | 200 seconds |
| MAX_SEQNUM_LIFETIME | 300 seconds |
| RteMsg_ENTRY_TIME | 12 seconds |
| RREQ_WAIT_TIME | 2 seconds |
| RREP_Ack_SENT_TIMEOUT | 1 second |
| RREQ_HOLDDOWN_TIME | 10 seconds |
+------------------------+---------------+
Table 4: Timing Parameter Values
The above timing parameter values have worked well for small and
medium well-connected networks with moderate topology changes. The
timing parameters SHOULD be administratively configurable for the
network where AODVv2 is used. Ideally, for networks with frequent
Perkins, et al. Expires September 25, 2015 [Page 47]
Internet-Draft AODVv2 March 2015
topology changes the AODVv2 parameters should be adjusted using
either experimentally determined values or dynamic adaptation. For
example, in networks with infrequent topology changes MAX_IDLETIME
may be set to a much larger value.
13.2. Protocol Constants
AODVv2 protocol constants typically do not require changes. The
following table lists these constants, along with their values and a
reference to the specification describing their use.
+------------------------+-----------------+------------------------+
| Name | Default Value | Description |
+------------------------+-----------------+------------------------+
| DISCOVERY_ATTEMPTS_MAX | 3 | Section 8.5 |
| MAX_HOPCOUNT | 20 hops | Section 7 |
| MAX_METRIC[i] | Specified only | Section 7 |
| | for HopCount | |
| MAXTIME | [TBD] | Maximum expressible |
| | | clock time Section 8.4 |
+------------------------+-----------------+------------------------+
Table 5: Parameter Values
These values MUST have the same values for all AODVv2 routers in the
ad hoc network. If the configured values are different, the
following consequences may be observed:
o DISCOVERY_ATTEMPTS_MAX: some nodes are likely to be more
successful at finding routes, but at the cost of additional
control traffic for unsuccessful attempts.
o MAX_HOPCOUNT: If some nodes use a value that is too small, they
would not be able to discover routes to distant addresses.
o MAX_METRIC[DEFAULT_METRIC_TYPE]: MUST always be the maximum
expressible metric of type DEFAULT_METRIC_TYPE. No
interoperability problems due to variations on different nodes,
but if a lesser value is used, route comparisons may exhibit
overly restrictive behavior.
o MAXTIME: Variations on different nodes would not cause problems
for interoperability. If a lesser value is used, route state
management may exhibit overly restrictive behavior.
Perkins, et al. Expires September 25, 2015 [Page 48]
Internet-Draft AODVv2 March 2015
13.3. Administrative (functional) controls
The following administrative controls may be used to change the
operation of the network, by enabling optional behaviors. These
options are not required for correct routing behavior, although they
may potentially reduce AODVv2 protocol messaging in certain
situations. The default behavior is typically to NOT enable the
options. Inconsistent settings at different nodes in the network
will not result in protocol errors. In the case of inconsistent
settings for DEFAULT_METRIC_TYPE, inconsistent setting might result
in messages specifying metric types unknown to some nodes and
consequent poor performance.
+------------------------+------------------------------------+
| Name | Description |
+------------------------+------------------------------------+
| DEFAULT_METRIC_TYPE | 3 (i.e, Hop Count (see [RFC6551])) |
| ENABLE_IDLE_IN_RERR | Section 9.3.1 |
| ENABLE_IRREP | Section 9.1.1 |
| USE_MULTICAST_RREP | Section 12.3 |
+------------------------+------------------------------------+
Table 6: Administratively Configured Controls
13.4. Other administrative parameters and lists
The following table lists contains AODVv2 parameters which should be
administratively configured for each node.
+-----------------------+-----------------------+-----------------+
| Name | Default Value | Cross Reference |
+-----------------------+-----------------------+-----------------+
| AODVv2_INTERFACES | | Section 4 |
| BUFFER_SIZE_PACKETS | 2 | Section 8.5 |
| BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 8.5 |
| CLIENT_ADDRESSES | AODVv2_INTERFACES | Section 6.3 |
| CONTROL_TRAFFIC_LIMIT | TBD [50 packets/sec?] | Section 9 |
+-----------------------+-----------------------+-----------------+
Table 7: Other Administrative Parameters
14. IANA Considerations
This section specifies several RFC 5444 message types, message tlv-
types, and address tlv-types. Also, a new registry of 16-bit
alternate metric types is specified.
Perkins, et al. Expires September 25, 2015 [Page 49]
Internet-Draft AODVv2 March 2015
14.1. AODVv2 Message Types Specification
+----------------------------------------+----------+
| Name of AODVv2 Message | Type |
+----------------------------------------+----------+
| Route Request (RREQ) | 10 (TBD) |
| Route Reply (RREP) | 11 (TBD) |
| Route Error (RERR) | 12 (TBD) |
| Route Reply Acknowledgement (RREP_Ack) | 13 (TBD) |
+----------------------------------------+----------+
Table 8: AODVv2 Message Types
14.2. Message TLV Type Specification
+-----------------------------+----------+----------+---------------+
| Name of Message TLV | Type | Length | Cross |
| | | (octets) | Reference |
+-----------------------------+----------+----------+---------------+
| AckReq (Acknowledgment | 10 (TBD) | 0 | Section 6.2 |
| Request) | | | |
| PktSource (Packet Source) | 11 (TBD) | 4 or 16 | Section 9.3.1 |
+-----------------------------+----------+----------+---------------+
Table 9: Message TLV Types
14.3. Address Block TLV Specification
+----------------------------+-----------+------------+-------------+
| Name of Address Block TLV | Type | Length | Value |
+----------------------------+-----------+------------+-------------+
| Metric | 10 (TBD) | depends on | Section 9.1 |
| | | MetricType | |
| Sequence Number (SeqNum) | 11 (TBD) | 2 octets | Section 9.1 |
| Originating Node Sequence | 12 (TBD) | 2 octets | Section 9.1 |
| Number (OrigSeqNum) | | | |
| Target Node Sequence | 13 (TBD) | 2 octets | Section 9.1 |
| Number (TargSeqNum) | | | |
| VALIDITY_TIME | 1 | 1 octet | [RFC5497] |
+----------------------------+-----------+------------+-------------+
Table 10: Address Block TLV (AddrTLV) Types
14.4. MetricType Number Allocation
Metric types are identified according to the assignments as specified
in [RFC6551]. The metric type of the Hop Count metric is assigned to
Perkins, et al. Expires September 25, 2015 [Page 50]
Internet-Draft AODVv2 March 2015
be 3, in order to maintain compatibility with that existing table of
values from RFC 6551.
+-----------------------+----------+-------------+
| Name of MetricType | Type | Metric Size |
+-----------------------+----------+-------------+
| Unallocated | 0 -- 2 | TBD |
| Hop Count | 3 - TBD | 1 octet |
| Unallocated | 4 -- 254 | TBD |
| Reserved | 255 | Undefined |
+-----------------------+----------+-------------+
Table 11: Metric Types
15. Security Considerations
The objective of the AODVv2 protocol is for each router to
communicate reachability information about addresses for which it is
responsible. Positive routing information (i.e. a route exists) is
distributed via RREQ and RREP messages. Negative routing information
(i.e. a route does not exist) is distributed via RERRs. AODVv2
routers store the information contained in these messages in order to
properly forward data packets, and they generally provide this
information to other AODVv2 routers.
This section describes various security considerations and potential
avenues to secure AODVv2 routing. Security for authentication of
AODVv2 routers, and/or encryption of traffic is dealt with by the
underlying transport mechanism (e.g., by using the techniques for
Authentication, Integrity, and Confidentiality documented in
[RFC5444]). The most important security mechanism for AODVv2 routing
is integrity/authentication.
In situations where routing information are suspect, integrity and
authentication techniques SHOULD be applied to AODVv2 messages. In
these situations, routing information that is distributed over
multiple hops SHOULD also verify the integrity of information based
on originator of the routing information.
In situations where confidentiality of AODVv2 messages is important,
cryptographic techniques can be applied.
In certain situations, for example sending a RREP or RERR, an AODVv2
router could include proof that it has previously received valid
routing information to reach the destination, at one point of time in
the past. In situations where routers are suspected of transmitting
maliciously erroneous information, the original routing information
along with its security credentials SHOULD be included.
Perkins, et al. Expires September 25, 2015 [Page 51]
Internet-Draft AODVv2 March 2015
Note that if multicast is used, any confidentiality and integrity
algorithms used MUST permit multiple receivers to handle the message
[RFC7182].
Routing protocols, however, are prime targets for impersonation
attacks. In networks where the node membership is not known, it is
difficult to determine the occurrence of impersonation attacks, and
security prevention techniques are difficult at best. However, when
the network membership is known and there is a danger of such
attacks, AODVv2 messages must be protected by the use of
authentication techniques, such as those involving generation of
unforgeable and cryptographically strong message digests or digital
signatures.
Most AODVv2 messages are transmitted to the multicast address LL-
MANET-Routers [RFC5498]. It is therefore required for security that
AODVv2 neighbors exchange security information that can be used to
insert an ICV [RFC7182] into the AODVv2 message block [RFC5444].
This enables hop-by-hop security. For destination-only RREP
discovery procedures, AODVv2 routers that share a security
association SHOULD use the appropriate mechanisms as specified in
[RFC7182]. The establishment of these security associations is out
of scope for this document.
16. Acknowledgments
AODVv2 is a descendant of the design of previous MANET on-demand
protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to
previous MANET on-demand protocols stem from research and
implementation experiences. Thanks to Elizabeth Belding and Ian
Chakeres for their long time authorship of AODV. Additional thanks
to Derek Atkins, Emmanuel Baccelli, Abdussalam Baryun, Ramon Caceres,
Thomas Clausen, Christopher Dearlove, Ulrich Herberg, Henner Jakob,
Luke Klein-Berndt, Lars Kristensen, Tronje Krop, Koojana Kuladinithi,
Kedar Namjoshi, Alexandru Petrescu, Henning Rogge, Fransisco Ros,
Pedro Ruiz, Christoph Sommer, Lotte Steenbrink, Romain Thouvenin,
Richard Trefler, Jiazi Yi, Seung Yi, and Cong Yuan, for their reviews
AODVv2 and DYMO, as well as numerous specification suggestions.
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Perkins, et al. Expires September 25, 2015 [Page 52]
Internet-Draft AODVv2 March 2015
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March
2009.
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
(MANET) Protocols", RFC 5498, March 2009.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in
Low-Power and Lossy Networks", RFC 6551, March 2012.
17.2. Informative References
[I-D.perkins-irrep]
Perkins, C. and I. Chakeres, "Intermediate RREP for
dynamic MANET On-demand (AODVv2) Routing", draft-perkins-
irrep-02 (work in progress), November 2012.
[Perkins94]
Perkins, C. and P. Bhagwat, "Highly Dynamic Destination-
Sequenced Distance-Vector Routing (DSDV) for Mobile
Computers", Proceedings of the ACM SIGCOMM '94 Conference
on Communications Architectures, Protocols and
Applications, London, UK, pp. 234-244, August 1994.
[Perkins99]
Perkins, C. and E. Royer, "Ad hoc On-Demand Distance
Vector (AODV) Routing", Proceedings of the 2nd IEEE
Workshop on Mobile Computing Systems and Applications, New
Orleans, LA, pp. 90-100, February 1999.
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561, July
2003.
Perkins, et al. Expires September 25, 2015 [Page 53]
Internet-Draft AODVv2 March 2015
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source
Routing Protocol (DSR) for Mobile Ad Hoc Networks for
IPv4", RFC 4728, February 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)", RFC
5148, February 2008.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.
[RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621,
May 2012.
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", RFC 7182, April 2014.
Appendix A. Example Algorithms for AODVv2 Protocol Operations
The following subsections show example algorithms for protocol
operations required by AODVv2, including RREQ, RREP, RERR, and
RREP_Ack.
Processing for RREQ, RREP, and RERR messages follows the following
general outline:
1. Receive incoming message.
2. Update route table as appropriate.
3. Respond as needed, often regenerating the incoming message with
updated information.
Once the route table has been updated, the information contained
there is known to be the most recent available information for any
fields in the outgoing message. For this reason, the algorithms are
written as if outgoing message field values are assigned from the
route table information, even though it is often equally appropriate
to use fields from the incoming message.
Perkins, et al. Expires September 25, 2015 [Page 54]
Internet-Draft AODVv2 March 2015
AODVv2_algorithms:
o Process_Routing_Info
o Fetch_Route_Table_Entry
o Update_Route_Table_Entry
o Create_Route_Table_Entry
o LoopFree
o
o Update_Rte_Msg_Table
o
o Generate_RREQ
o Receive_RREQ
o Regenerate_RREQ
o
o Generate_RREP
o Receive_RREP
o Regenerate_RREP
o
o Generate_RERR
o Receive_RERR
o Regenerate_RERR
o
o Generate_RREP_Ack
o Receive_RREP_Ack
o Timeout RREP_Ack
Perkins, et al. Expires September 25, 2015 [Page 55]
Internet-Draft AODVv2 March 2015
The following lists indicate the meaning of the field names used in
subsequent sections to describe message processing for the above
algorithms.
RteMsg parameters, where rteMsg can be inRREQ, outRREQ, inRREP or
outRREP:
rteMsg.hopLimit
rteMsg.hopCount
rteMsg.ackReq (RREP only, optional)
rteMsg.metricType (optional)
rteMsg.origAddr
rteMsg.targAddr
rteMsg.origPrefixLen (optional)
rteMsg.targPrefixLen (optional)
rteMsg.origSeqNum (RREQ only)
rteMsg.targSeqNum (optional in RREQ)
rteMsg.origAddrMetric (RREQ only)
rteMsg.targAddrMetric (RREP only)
rteMsg.validityTime
rteMsg.nbrIP
AdvRte has the following properties as described in Section 8.1:
AdvRte.Address = OrigAddr (in a RREQ) or TargAddr (in a RREP)
AdvRte.PrefixLength = PrefixLength for OrigAddr (in a RREQ) or
TargAddr (in a RREP), or if not present, the maximum address
length for the address family of AdvRte.Address
AdvRte.SeqNum = SeqNum for OrigAddr (in a RREQ) or for TargAddr
(in a RREP)
AdvRte.MetricType = RteMsg.MetricType
Perkins, et al. Expires September 25, 2015 [Page 56]
Internet-Draft AODVv2 March 2015
AdvRte.Metric = RteMsg.Metric
AdvRte.Cost = AdvRte.Metric + Cost(L) according to the indicated
MetricType, where L is the link from the advertising router
AdvRte.ValidityTime = ValidityTime in the RteMsg, if present
AdvRte.NextHopIP = IP source of the RteMsg
AdvRte.NextHopIntf = interface the RteMsg was received on
AdvRte.HopCount = value from RteMsg header
AdvRte.HopLimit = value from RteMsg header
AdvRte.AckReq = true/false whether present in RteMsg (optional in
RREP)
A route table entry has properties as described in Section 6.1:
Route.Address
Route.PrefixLength
Route.SeqNum
Route.NextHop
Route.NextHopInterface
Route.LastUsed
Route.LastSeqNum
Route.ExpirationTime
Route.MetricType
Route.Metric
Route.State
Route.Timed
Route.Precursors (optional)
Perkins, et al. Expires September 25, 2015 [Page 57]
Internet-Draft AODVv2 March 2015
A.1. Subroutines for AODVv2 Operations
A.1.1. Process_Routing_Info
/* Compare incoming route information to stored route, maybe use
linkMetric: either Cost(inRREQ.netif) or (inRREP.netif) */
Process_Routing_Info (advRte)
{
rte := Fetch_Route_Table_Entry (advRte);
if (!rte exists)
{
rte := Create_Route_Table_Entry(advRte);
return rte;
}
/* rule from 8.1 */
if (
(AdvRte.SeqNum > Route.SeqNum) /* stored route is stale */
OR
((AdvRte.SeqNum == Route.SeqNum) /* same SeqNum */
AND
[( (Route.State == Invalid)
AND
(LoopFree(advRte, rte))) /* advRte can repair stored */
OR
(AdvRte.Cost < Route.Metric)])) /* advRte is better */
{
Update_Route_Table_Entry (rte, advRte);
}
return rte;
}
Perkins, et al. Expires September 25, 2015 [Page 58]
Internet-Draft AODVv2 March 2015
A.1.2. Fetch_Route_Table_Entry
/* lookup a route table entry matching an advertised route */
Fetch_Route_Table_Entry (advRte)
{
foreach (rteTableEntry in rteTable)
{
if (rteTableEntry.Address == advRte.Address AND
rteTableEntry.MetricType == advRte.MetricType)
return rteTableEntry;
}
return null;
}
/* lookup a route table entry matching address and metric type */
Fetch_Route_Table_Entry (destination, metricType)
{
foreach (rteTableEntry in rteTable)
{
if (rteTableEntry.Address == destination AND
rteTableEntry.MetricType == metricType)
return rteTableEntry;
}
return null;
}
Perkins, et al. Expires September 25, 2015 [Page 59]
Internet-Draft AODVv2 March 2015
A.1.3. Update_Route_Table_Entry
/* update a route table entry using AdvRte in received RteMsg */
Update_Route_Table_Entry (rte, advRte);
{
rte.SeqNum := advRte.SeqNum;
rte.NextHop := advRte.NextHopIp;
rte.NextHopInterface := advRte.NextHopIntf;
rte.LastUsed := Current_Time;
rte.LastSeqNum := Current_Time;
if (validityTime)
{
rte.ExpirationTime := Current_Time + advRte.validityTime;
rte.Timed := true;
}
else
{
rte.Timed := false;
rte.ExpirationTime := MAXTIME;
}
rte.Metric := advRte.Cost;
if (rte.State == Invalid)
rte.State := Idle;
}
A.1.4. Create_Route_Table_Entry
/* Create a route table entry from address and prefix length */
Create_Route_Table_Entry (address, prefixLength,
seqNum, metricType)
{
rte := allocate_memory();
rte.Address := address;
rte.PrefixLength := prefixLength;
rte.SeqNum := seqNum;
rte.MetricType := metricType;
}
Perkins, et al. Expires September 25, 2015 [Page 60]
Internet-Draft AODVv2 March 2015
/* Create a route table entry from the advertised route */
Create_Route_Table_Entry(advRte)
{
rte := allocate_memory();
rte.Address := advRte.Address;
if (advRte.PrefixLength)
rte.PrefixLength := advRte.PrefixLength;
else
rte.PrefixLength := maxPrefixLenForAddressFamily;
rte.SeqNum := advRte.SeqNum;
rte.NextHop := advRte.NextHopIp;
rte.NextHopInterface := advRte.NextHopIntf;
rte.LastUsed := Current_Time
rte.LastSeqnum := Current_Time
if (validityTime)
{
rte.ExpirationTime := Current_Time + advRte.ValidityTime;
rte.Timed := true;
}
else
{
rte.Timed := false;
rte.ExpirationTime := MAXTIME;
}
rte.MetricType := advRte.MetricType;
rte.Metric := advRte.Metric;
rte.State := Idle;
}
A.1.5. LoopFree
/* return TRUE if the route advRte is LoopFree compared to rte */
LoopFree(advRte, rte)
{
if (advRte.Cost <= rte.Cost)
return true;
else
return false;
}
Perkins, et al. Expires September 25, 2015 [Page 61]
Internet-Draft AODVv2 March 2015
A.1.6. Fetch_Rte_Msg_Table_Entry
/* Find an entry in the RteMsg table matching the given
message's msg-type, OrigAddr, TargAddr, MetricType */
Fetch_Rte_Msg_Table_Entry (rteMsg)
{
foreach (entry in RteMsgTable)
{
if (entry.msg-type == rteMsg.msg-type AND
entry.OrigAddr == rteMsg.OrigAddr AND
entry.TargAddr == rteMsg.TargAddr AND
entry.MetricType == rteMsg.MetricType)
{
return entry;
}
}
return NULL;
}
A.1.7. Update_Rte_Msg_Table
/* update the multicast route message suppression table based
on the received RteMsg, return true if it was created or
the SeqNum was updated (i.e. it needs to be regenerated) */
Update_Rte_Msg_Table(rteMsg)
{
/* search for a comparable entry */
entry := Fetch_Rte_Msg_Table_Entry(rteMsg)
/* if there is none, create one (see 6.5 and 8.6) */
if (entry does not exist)
{
entry.MessageType := rteMsg.msg_type
entry.OrigAddr := rteMsg.OrigAddr
entry.TargAddr := rteMsg.TargAddr
entry.OrigSeqNum := rteMsg.origSeqNum (if present)
entry.TargSeqNum := rteMsg.targSeqNum (if present)
entry.MetricType := rteMsg.MetricType
entry.Metric := rteMsg.origAddrMetric(for RREQ)
or rteMsg.targAddrMetric(for RREP)
entry.Timestamp := Current_Time
return true;
}
Perkins, et al. Expires September 25, 2015 [Page 62]
Internet-Draft AODVv2 March 2015
/* if current entry is stale */
if ( (rteMsg.msg-type == RREQ AND
entry.OrigSeqNum < rteMsg.OrigSeqNum)
OR
(rteMsg.msg-type == RREP AND
entry.TargSeqNum < rteMsg.TargSeqNum))
{
entry.OrigSeqNum := rteMsg.OrigSeqNum (if present)
entry.TargSeqNum := rteMsg.TargSeqNum (if present)
entry.Timestamp := Current_Time
return true;
}
/* if received rteMsg is stale */
if ( (rteMsg.msg-type == RREQ AND
entry.OrigSeqNum > rteMsg.OrigSeqNum)
OR
(rteMsg.msg-type == RREP AND
entry.TargSeqNum > rteMsg.TargSeqNum))
{
entry.Timestamp := Current_Time
return false;
}
/* if same SeqNum but rteMsg has lower metric */
if (entry.Metric > rteMsg.Metric)
entry.Metric := rteMsg.Metric
entry.Timestamp := Current_Time
return false;
}
Perkins, et al. Expires September 25, 2015 [Page 63]
Internet-Draft AODVv2 March 2015
A.1.8. Build_RFC_5444_message_header
/* This pseudocode shows possible RFC 5444 actions, and
would not be performed by the AODVv2 implementation.
It is shown only to provide more understanding about
the AODVv2 message that will be constructed by RFC 5444 */
Build_RFC_5444_message_header (msgType, Flags,
AddrFamily, Size, hopLimit, hopCount, tlvLength)
{
/* Build RFC 5444 message header fields */
msg-type := msgType
MF (Message Flags) := Flags
MAL (Message Address Length) := 3 for IPv4, 15 for IPv6
msg-size := Size (octets - counting MsgHdr, AddrBlk, AddrTLVs)
msg-hop-limit := hopLimit
if (hopCount != 0) /* hopCount == 0 means do not include */
msg-hop-count := hopCount
msg.tlvs-length := tlvLength
}
A.2. Example Algorithms for AODVv2 RREQ Operations
A.2.1. Generate_RREQ
Generate_RREQ
{
/* Increment sequence number */
mySeqNum := (1 + mySeqNum) /* from nonvolatile storage */
/* Marshall parameters */
outRREQ.hopLimit := MAX_HOPCOUNT /* RFC 5444 */
outRREQ.hopCount := (if included) 0
outRREQ.metricType := if not DEFAULT_METRIC_TYPE,
metric type needed by application
outRREQ.origAddr := IP address of Router Client which generated
the packet to be forwarded
outRREQ.targAddr := destination IP address in
the packet to be forwarded
outRREQ.origPrefixLen := if included, the prefix length
associated with the Router Client
outRREQ.origSeqNum := mySeqNum
outRREQ.targSeqNum := if known from route table,
target sequence number
outRREQ.origAddrMetric := 0 (default) or
MIN_METRIC(outRREQ.metricType)
outRREQ.validityTime := if included, the validity time
for route to OrigAddr
Perkins, et al. Expires September 25, 2015 [Page 64]
Internet-Draft AODVv2 March 2015
/* Build Address Blk */
AddrBlk := outRREQ.origAddr and outRREQ.targAddr addresses
/* using prefix length information from
outRREQ.origPrefixLen if necessary */
/* Include each available Sequence Number in appropriate
Address Block TLV */
/* OrigSeqNum Address Block TLV */
origSeqNumAddrBlkTlv.value := outRREQ.origSeqNum
/* TargSeqNum Address Block TLV */
if (outRREQ.targSeqNum is known)
{
targSeqNumAddrBlkTlv.value := outRREQ.targSeqNum
}
/* Build Metric Address Block TLV */
metricAddrBlkTlv.value := outRREQ.origAddrMetric
if (outRREQ.metricType != DEFAULT_METRIC_TYPE)
{ /* include Metric AddrBlkTlv Extension byte */
metricAddrBlkTlv.typeExtension := outRREQ.MetricType
}
if (outRREQ.validityTime is required)
{
/* Build VALIDITY_TIME Address Block TLV */
VALIDITY_TIMEAddrBlkTlv.value := outRREQ.validityTime
}
/* multicast RFC 5444 message to LL-MANET-Routers */
}
A.2.2. Receive_RREQ
Receive_RREQ (inRREQ)
{
if (inRREQ.nbrIP present in blacklist) {
if (blacklist_expiration_time < current_time)
return; /* don't process or regenerate RREQ... */
else
remove nbrIP from blacklist;
}
if (inRREQ does not contain msg_hop_limit, OrigAddr,
TargAddr, OrigSeqNum, OrigAddrMetric)
return;
if (inRREQ.origAddr and inRREQ.targAddr are not valid
routable and unicast addresses)
Perkins, et al. Expires September 25, 2015 [Page 65]
Internet-Draft AODVv2 March 2015
quot;, BCP 156, RFC 6056, January
2011.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, June
2011.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012.
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers", RFC
6883, March 2013.
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Potential Solutions for Revealing a Host
Identifier (HOST_ID) in Shared Address Deployments", RFC
6967, June 2013.
Appendix A. Testing Results of Application Behavior
We test several application behaviors in a lab environment to
evaluate the impact when a primary NAT64 is out of service. In this
testing, participants are asked to connect a IPv6-only WiFi network
using laptops, tablets or mobile phones. NAT64 is deployed as the
gateway to connect Internet service. The tested applications are
shown in the below table. Cold standby, warm standby and hot standby
are taken truns to be tested. The partipants may experience service
interruption due to the NAT64 handover. Different interruption
Chen, et al. Expires April 17, 2014 [Page 18]
Internet-Draft NAT64 Experiences October 2013
intervals are tested to gauge application behaviors. The results are
illuminated as below.
Table 1: The acceptable delay of applications
+----------------+------------------------+-------------------------+
| APPs | Acceptable Interrupt | Session Continuity |
| | Recovery | |
+----------------+------------------------+-------------------------+
| Web Browse |As maximum as 6s | No |
+----------------+------------------------+-------------------------+
|Http streaming |As maximum as 10s(cache)| Yes |
+----------------+------------------------+-------------------------+
| Gaming | 200ms~400ms | Yes |
+----------------+------------------------+-------------------------+
| P2P | 10~16s | Yes |
+----------------+------------------------+-------------------------+
|Instant Message |1 minute | Yes |
+----------------+------------------------+-------------------------+
|Mail |30 seconds | No |
+----------------+------------------------+-------------------------+
|Downloading |1 minutes | No |
+----------------+------------------------+-------------------------+
Authors' Addresses
Gang Chen
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: phdgang@gmail.com
Zhen Cao
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: caozhen@chinamobile.com
Chen, et al. Expires April 17, 2014 [Page 19]
Internet-Draft NAT64 Experiences October 2013
Chongfeng Xie
China Telecom
Room 708 No.118, Xizhimenneidajie
Beijing 100035
P.R.China
Email: xiechf@ctbri.com.cn
David Binet
France Telecom-Orange
Rennes
35000
France
Email: david.binet@orange.com
Chen, et al. Expires April 17, 2014 [Page 20]