| Network Working Group | F. Templin, Ed. |
| Internet-Draft | Boeing Research & Technology |
| Intended status: Standards Track | October 19, 2011 |
| Expires: April 21, 2012 |
Asymmetric Extended Route Optimization (AERO)
draft-templin-aero-04.txt
Nodes attached to link types such as multicast-capable, shared media and non-broadcast multiple access (NBMA), etc. can exchange packets as neighbors on the link. Each node should therefore be able to discover a trusted neighboring gateway that can provide default routing services to reach off-link destinations, and should also accept redirection messages from the gateway informing it of a different neighbor that is closer to the final destination. This redirect function can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the gateway, and finally to the egress link neighbor may be considerably longer than the direct path between the neighbors. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues.
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 21, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Nodes attached to link types such as multicast-capable, shared media, non-broadcast multiple access (NBMA), etc. can exchange packets with each other as neighbors on the link. Each node should therefore be able to discover a trusted neighboring gateway that can provide default routing services to reach off-link destinations, and should also accept redirection messages from the gateway informing it of a different neighbor that is closer to the final destination. This redirect function can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the gateway, and finally to the egress link neighbor may be considerably longer than the direct path between the neighbors. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios.
For example, when an ingress link neighbor accepts an ordinary redirect message from a gateway, it has no way of knowing whether the egress link neighbor is ready and willing to accept packets directly without involving the gateway. In particular, without involvement from the gateway, the egress would have no way of knowing that the ingress is authorized to forward packets from a given source address. (This is especially important for very large links, since any node on the link can spoof the network-layer source address with low probability of detection even if the link-layer source address cannot be spoofed.) Additionally, the ingress would have no way of knowing whether the direct path to the egress has failed, nor whether the final destination has moved away from the egress to some other network attachment point.
Therefore, a new redirection approach is required that can enable a reliable one-way handshake from the egress to the ingress link node under the mediation of trusted gateways. The mechanism is asymmetric (since only the forward direction from the ingress to the egress is optimized) and extended (since the redirection extends forward to the egress before reaching back to the ingress). This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues.
While the AERO mechanisms were initially designed for the specific purpose of NBMA tunnel virtual interfaces (e.g., see: [RFC2529][RFC5214][RFC5569][I-D.templin-ironbis]) they can also be applied to any link types that support redirection [RFC0792][RFC4861]. The rest of this document refers to this class of links collectively as "AERO links".
The AERO techniques apply to both the IPv4 [RFC0791] and IPv6 [RFC2460] protocols, as well as any other network layer protocol that includes link models that can support redirection.
The terminology in the normative references apply; the following terms are defined within the scope of this document:
[RFC2119]. When used in lower case (e.g., must, must not, etc.), these words MUST NOT be interpreted as described in [RFC2119], but are rather interpreted as they would be in common English.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
The route optimization mechanism must satisfy the following requirements:
The following sections specify an Asymmetric Extended Route Optimization (AERO) capability that fulfills the requirements specified in Section 3.
In many AERO link use case scenarios (e.g., small enterprise networks, small and stable MANETs, etc.), AERO gateways and routers can engage in a proactive dynamic routing protocol (e.g., OSPF, RIP, IS-IS, etc.) so that routing/forwarding tables can be populated and standard forwarding between routers can be used. In other scenarios (e.g., large enterprise/ISP networks, cellular service provider networks, dynamic MANETs, etc.), this might be impractical due to routing protocol control message scaling issues.
When a proactive dynamic routing protocol cannot be used, the mechanisms specified in this section can provide a useful on-demand dynamic routing capability.
The following sections discuss characteristics of nodes attached to links over which AERO can be used:
AERO gateways configure their AERO link interfaces as advertising router interfaces (see: [RFC4861], Section 6.2.2), and therefore may send Router Advertisement (RA) messages that include non-zero Router Lifetimes.
AERO routers configure their AERO link interfaces as non-advertising router interfaces.
AERO hosts configure their AERO link interfaces as simple host interfaces.
AERO nodes must employ a source address verification check for the packets they receive on an AERO interface in a manner that is consistent with the Source Address Validation Improvement (SAVI) Framework [I-D.ietf-savi-framework]. In order to perform source address verification, the node considers the network-layer source address correct for the link-layer source address if:
The latter of these checks can be established through static configuration, via a proactive dynamic routing protocol, or through the AERO mechanisms specified in
AERO hosts send Router Solicitation (RS) messages to obtain RA messages from an AERO gateway. When the RA contains Prefix Information Options with non-link-local prefixes, the host autoconfigures addresses from the prefixes using Stateless Address Autoconfiguration (SLAAC) [RFC4861][RFC4862]. When managed address delegation services are available, the host can also (or instead) acquire addresses taken from prefixes aggregated by the gateway through the use of stateful mechanisms, e.g., DHCP [RFC2131][RFC3315], manual configuration, etc.
After the host receives addresses, it assigns them to its AERO interface and forwards any of its outbound packets via the gateway as a default router. The host may subsequently receive redirection messages from the gateway listing a better next hop.
AERO routers send RS messages to obtain RA messages from an AERO gateway, i.e., they act as "hosts" on their non-advertising AERO link router interfaces for the purpose of default router discovery.
The router can then acquire managed prefix delegations aggregated by the gateway through the use of, e.g., DHCPv6 Prefix Delegation [RFC3633], manual configuration, etc. in the same fashion as described above for host-based autoconfiguration.
After the router acquires prefixes, it can sub-delegate them to nodes and links within its attached End User Networks (EUNs), then can forward any outbound packets coming from its EUNs via the gateway. The router may subsequently receive redirection messages from the gateway listing a better next hop.
AERO gateways respond to RS messages from hosts and routers on the AERO link by returning an RA message. Gateways may further configure a DHCP relay or server function on their AERO links and/or provide an administrative interface for manual configuration of address/prefix-to-client forwarding table entries.
When the gateway completes a stateful address or prefix delegation transaction (e.g., as a DHCP relay/server, etc.), it establishes forwarding table entries that list the link-layer address of client as the link-layer address of the next hop toward the delegated addresses/prefixes.
When the gateway forwards a packet out the same AERO interface it arrived on, it initiates an AERO route optimization procedure as specified in Section 4.4.
Figure 1 depicts an example AERO network topology. IPv6 is used only as an example network layer protocol, and the same fundamental AERO techniques can be applied for other network layer protocols. The figure shows an AERO gateway ('A'), two non-advertising AERO routers ('B', 'D'), an AERO host ('F'), and three ordinary IPv6 hosts ('C', 'E', 'G') in a typical operational scenario:
.-(::::::::) 2001:db8:3::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host G |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,.................,
|companion gateway|
'.................' +---------------+
+--------------+ | Host F |
| Gateway A | +---------------+
+--------------+ 2001:db8:2:1
L3(A) L3(F)
L2(A) L2(F)
| AERO Link |
X-----+--+-----------------+--+---X
| |
L2(B) L2(D) .-.
L3(B) L3(D) ,-( _)-.
+--------------+ +--------------+ .-(_ IPv6 )-.
| Router B | | Router D |--(__ EUN )
+--------------+ +--------------+ `-(______)-'
2001:db8:0::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8:0::1 | IPv6 Host E |
.-(_ IPv6 )-. +-------------+ +-------------+
(__ EUN )--| IPv6 Host C |
`-(______)-' +-------------+
In Figure 1, Gateway 'A' connects to the AERO link and also connects to the IPv6 Internet, either directly or via a companion gateway. 'A' configures an AERO link interface with a link-local network-layer address L3(A) and with link-layer address L2(A). 'A' next arranges to add the link-layer address L2(A) to the list of valid gateways for the link.
Router 'B' connects to one or more IPv6 EUNs and also connects to the AERO link via an interface with a link-local network-layer address L3(B) and with link-layer address L2(B). 'B' next configures a default IPv6 route with next-hop address L3(A) via the AERO interface, then receives the IPv6 prefix 2001:db8:0::/48 through a stateful prefix delegation exchange via 'A'. 'B' finally sub-delegates the prefix to its attached EUNs, where IPv6 host 'C' autoconfigures the address 2001:db8:0::1.
Router 'D' connects to the AERO link via an interface with addresses L3(D)/L2(D), configures a default IPv6 route with next-hop address L3(A) via the AERO interface, and receives a stateful prefix delegation of 2001:db8:1::/48 in the same fashion as for router 'B'. 'D' finally sub-delegates the prefix to its attached EUNs, where IPv6 host 'E' autoconfigures IPv6 address 2001:db8:1::1.
Host 'F' connects to the AERO link via an interface with addresses L3(F)/L2(F). 'F' next configures a default IPv6 route with next-hop address L3(A) via the AERO interface, then receives the IPv6 address 2001:db8:2::1 from a stateful address configuration exchange via 'A'. When 'F' receives the IPv6 address, it assigns the address to the AERO interface but does not assign a non-link-local IPv6 prefix to the interface.
Finally, IPv6 host 'G' connects to an IPv6 network outside of the AERO link domain. 'G' configures its IPv6 interface in a manner specific to its attached IPv6 link, and autoconfigures the IPv6 address 2001:db8:3::1.
In these arrangements, 'A' must maintain routes that associate the delegated IPv6 addresses/prefixes with the correct routers and/or hosts on the AERO link. The routers and hosts must maintain at least a default route that points to gateway 'A', and can discover more-specific routes either via a proactive dynamic routing protocol or via the AERO mechanisms specified in Section 4.4.
Figure 1 depicts a reference operational scenario including an AERO link. The figure shows an AERO gateway ('A'), two AERO routers ('B', 'D'), an AERO host ('F') and three ordinary IPv6 hosts ('C', 'E', 'G') in a typical deployment configuration. We now discuss the operation of AERO with respect to this reference scenario.
With reference to Figure 1, when host 'C' sends a packet with source address 'C' and destination address 'E', the packet is first forwarded over 'C's attached EUN to router 'B'. 'B' then forwards the packet over the AERO interface to gateway 'A', which then forwards the packet to router 'D', where the packet is finally forwarded to host 'E' over 'E's attached EUN. When 'A' forwards the packet back out on its advertising AERO interface, it must arrange to redirect 'B' toward 'D' as a better next hop node on the AERO link that is closer to the final destination 'E'. However, this redirection process should only take place if there is assurance that both 'B' and 'D' are willing participants.
Consider a first alternative in which 'A' informs 'B' only and does not inform 'D' (i.e., "classic redirection"). In that case, 'D' has no way of knowing that 'B' is authorized to forward packets from a given source address. Also, 'B' has no way of knowing whether 'D' is willing to accept its packets, nor whether 'D' is even reachable via a direct path that does not involve 'A'. Finally, 'B' has no way of knowing whether the final destination has moved away from 'D'.
Consider also a second alternative in which 'A' informs both 'B' and 'D' separately via independent redirection messages (i.e., "augmented redirection"). In that case, several conditions can occur that could result in communications failures. First, if 'B' receives the redirection message but 'D' does not, subsequent packets sent by 'B' would be dropped due to filtering since 'D' would not have a forwarding table entry to verify their source addresses. Second, if 'D' receives the redirection message but 'B' does not, subsequent packets sent in the reverse direction by 'D' would be lost. Finally, timing issues surrounding the establishment and garbage collection of forwarding table entries at 'B' and 'D' could yield unpredictable behavior. For example, unless the timing were carefully coordinated through some form of synchronization loop, there would invariably be instances in which one node has the correct forwarding table state and the other node does not resulting in non-deterministic packet loss.
Since neither of these alternatives can satisfy the requirements listed in Section 3, a new redirection technique is needed. In this new method (i.e., "AERO redirection"), when 'A' forwards a packet from 'B' out the same AERO interface toward 'D', 'A' must first send a "predirect" message forward to 'D' to inform it that 'B' is authorized to produce packets using source address 'C'. After 'D' receives the predirect, it sends a Redirect message back to 'B' via 'A' as a trusted intermediary. When 'B' receives the Redirect, it knows that 'D' will accept the packets it sends with source address 'C' as long as 'D' retains the forwarding table entry. This process stands in contrast to the classical and augmented redirection approaches; the following subsections therefore specify the AERO redirection steps necessary to support the reference operational scenario.
When a gateway forwards a packet out the same AERO interface that it arrived on, the gateway sends a predirect message forward to the egress AERO node instead of sending a Redirect message back to the ingress node. If there is some way of marking the data packet itself as a predirect, then the data packet itself serves as a "predirect" without the need for a separate message (e.g., see: [I-D.templin-ironbis]).
If there is no means for signaling a predirect in the data plane, the gateway instead sends an explicit Predirect message which is simply an AERO-specific version of an ordinary Redirect message. In the case of IPv6 as the network layer protocol, the Predirect format is the same as depicted in Section 4.5 of [RFC4861], and is identified by two new backward-compatible bits taken from the Reserved field as shown in Figure 2:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (=137) | Code (=0) | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-
Where the new bits are defined as:
In the reference operational scenario, when gateway 'A' forwards a packet sent by 'B' toward 'D', it marks the packet as a "predirect" if possible. Otherwise, it also sends an explicit Predirect message forward toward 'D', subject to rate limiting (see Section 8.2 of [RFC4861]). 'A' prepares the Predirect message in a similar fashion as for an ordinary IPv6 Redirect message as follows:
'A' then sends the Predirect message forward to 'D'.
When an AERO router or host receives a either a data packet marked as a predirect or an explicit Predirect message, it validates the message according to the appropriate redirect message validation rules (e.g., Section 8.1 of [RFC4861] for IPv6). The node further accepts the message only if it came from the link-layer address of a trusted gateway. Finally, the node only processes the message if the destination address of the originating packet encapsulated in the RHO is covered by one of its CURRENT delegated addresses/prefixes (see Section 4.5).
In the reference operational scenario, when router 'D' receives the predirect it creates forwarding table entries with the prefixes encoded in RIO options as the target prefixes, and associates the forwarding table entries with a node structure (e.g., in a neighbor cache) that stores the source address of the Predirect message (i.e., 'L3(B)'). 'D' places the node structure in the FILTERING state, then sets/resets a filtering expiration timer value of 40 seconds. If the filtering timer later expires, 'D' clears the FILTERING state. If the node structure is not in the FORWARDING state, 'D' then deletes the node structure and all of its associated forwarding table entries. (This suggests that 'D's AERO interface should maintain a private forwarding table separate from the primary forwarding table, since the node structure and forwarding table entries must be managed by the AERO interface itself.)
After processing the Predirect message and establishing the forwarding table entry, 'D' prepares a Redirect message in response to the Predirect as follows:
After 'D' prepares the Redirect message, it sends the message to 'A'. (Note that the Redirect message does not include RIOs, since the gateway is the only authoritative source of routing information and will supply RIOs when it proxies the message.)
When an AERO gateway receives a Redirect message, it accepts the message only if it satisfies the redirect message validation rules. The gateway further accepts the message only if it came from the link-layer address of the current next hop toward the destination address of the originating packet encapsulated in the RHO. The gateway then "proxies" the Redirect message back to the original ingress AERO node as described below.
In the reference operational scenario, 'A' receives the Redirect message from 'D' and adds RIOs to the message that encode 'D's address/prefix delegations. Without decrementing the hopcount in the Redirect message, 'A' next changes the link-layer source address of the message to 'L2(A)' and changes the link-layer destination address to 'L2(B)'. 'A' then sends this proxied Redirect message to 'B'.
When an AERO router or host receives a Redirect message, it validates the message according to the appropriate redirect message validation rules. The node further accepts the message only if it came from the link-layer address of either a trusted gateway or the current next hop on the AERO link for the destination address of the originating packet encapsulated in the RHO.
In the reference operational scenario, 'B' receives the (proxied) Redirect message then creates forwarding table entries with the prefixes encoded in RIO options as the target prefixes. 'B' further associates the forwarding table entries with a node structure (e.g., in a neighbor cache) that stores the source address of the Predirect message (i.e., 'L3(D)'). 'B' places the node structure in the FORWARDING state, then sets/resets a filtering expiration timer value of 30 seconds. If the filtering timer later expires, 'B' clears the FORWARDING state. If the node structure is not in the FILTERING state, 'B' then deletes the node structure and all of its associated forwarding table entries.
Now, 'B' has a node structure for 'D' in the FORWARDING state, and 'D' has a node structure for 'B' in the FILTERING state. Therefore, 'B' may forward ordinary network-layer data packets with destination addresses covered by 'D's prefixes directly to 'D' without involving 'A'. 'D' will in turn accept the packets since it has a forwarding table entry authorizing 'B' to forward packets with source addresses covered by 'B's prefixes.
To enable packet forwarding in the reverse direction, a separate AERO operation is required which is the mirror-image of the forward AERO operation described above, i.e., the forward and reverse AERO operations are asymmetric. Following the reverse operation, packets can be exchanged bidirectionally without involving 'A'.
In order to prevent forwarding table entries from expiring while data packets are actively flowing, the ingress node can periodically send Predirect messages directly to the egress node (subject to rate limiting) to solicit Redirect messages. In the reference operational scenario, when 'B' forwards a packet to 'D' and wishes to update the corresponding FORWARDING state timer, 'B' can also send a Predirect message directly to 'D' prepared as follows:
When 'D' receives the Predirect message, it accepts the message only if it satisfies the redirect message validation rules. The node further accepts the message only if it came from the current previous hop on the AERO link for the source address of the originating packet encapsulated in the RHO. 'D' then resets its FILTERING expiration timer for node 'B' to 40 seconds, and sends a Redirect message directly to 'B' prepared as follows:
When 'B' receives the Redirect message, it accepts the message only if it satisfies the redirect message validation rules. The node further accepts the message only if it came from the current next hop on the AERO link for the source address of the originating packet encapsulated in the RHO. 'B' then resets its FORWARDING expiration timer for node 'D' to 30 seconds.
Note that in these direct neighbor to neighbor exchanges, neither the Predirect nor Redirect message contain RIOs, since gateways are the only authoritative source of routing information. Therefore, AERO routers and hosts should not include RIOs in the Predirects/Redirects they send, and they must ignore any RIOs included in received Predirect/Redirect messages that did not come from a trusted gateway.
When an ingress node receives a Redirect message informing it of a direct path to a new egress, there is a question in point as to whether the new egress can be reached directly without involving the gateway as an intermediary. On some AERO links, it may be reasonable for the ingress to (optimistically) assume that the new egress is reachable, and to immediately begin forwarding data packets to the egress without testing reachability.
On AERO links in which an optimistic assumption of reachability may be inappropriate, however, the ingress can defer the redirection until it tests the direct path to the egress by sending a direct Predirect message to elicit a Redirect as specified in Section 4.4.5. If the ingress is unable to elicit a Redirect message after a small number of attempts, it should consider the direct path to the egress as unusable.
In either case, the ingress can process any link errors corresponding to the data packets sent directly to the egress as a hint that the direct path has either failed or has become intermittent.
An AERO link egress router 'D' can configure both a non-advertising router interface on a provider AERO link and advertising router interfaces on EUN links to provide gateway services to nodes in EUNs. When node 'E' in an EUN that has obtained addresses/prefixes moves to a different network point of attachment, however, 'E' can release its address/prefix delegations via 'D' and re-establish them via a different gateway.
When 'E' releases its address/prefix delegations via 'D', 'D' marks the forwarding table entries that cover the addresses/prefixes as DEPARTED (i.e., it clears the CURRENT state). 'D' therefore ceases to respond to Predirect messages correlated with the DEPARTED entries, and also schedules a garbage-collection timer of 60 seconds, after which it deletes the DEPARTED entries.
When 'D' receives packets destined to an address covered by the DEPARTED forwarding table entries, it forwards them to the last-known EUN link-layer address of 'E' as a means for avoiding mobility-related packet loss during routing changes. 'D' also returns a NULL Redirect message to inform the correspondent 'B' of the departure. The Redirect message is prepared as follows:
Eventually, any correspondents will receive such a NULL Redirect message and will cease to use 'D' as a next hop. They will then revert to sending packets destined to 'E' via their gateways and may subsequently receive new Redirect messages to discover that 'E' is now associated with a new egress router. Note that any packets forwarded by 'D' via a forwarding table entry in the DEPARTED state may be lost if the mobile node moves off-link with respect to its previous EUN point of attachment. This should not be a problem for large links (e.g., large cellular network deployments, large ISP networks, etc.) in which all/most mobility events are intra-link.
Figure 1 depicts a reference network topology with only a single gateway on the AERO link. In order to support larger numbers of AERO routers and hosts, the AERO link can deploy more gateways to support load balancing and generally shortest-path routing.
Such an arrangement requires that the gateways participate in a routing protocol instance (e.g., an eBGP instance with each gateway configuring a private Autonomous System Number (ASN)) so that address/prefix delegations can be mapped to the correct gateway. The routing protocol instance can be configured as either a full mesh topology involving all gateways, or as a partial mesh topology with each AERO link gateway associating with one or more backhaul network companion gateways and a full mesh between companion gateways.
In large AERO link deployments, there may be many gateways - each serving many AERO routers and hosts. The gateways then either require full topology knowledge, or a default route to a companion gateway that does have full topology knowledge. For example, if AERO node 'A' connects to gateway 'B', and AERO node 'E' connects to gateway 'D', then 'B' and 'D' must either have full topology knowledge or have a default route to a companion gateway (e.g., 'C') that does.
In that case, when 'A' forwards an initial packet destined to an end system behind 'E', it forwards the packet to 'B'. Next, 'B' forwards the packet toward 'C', which both forwards the packet generates a Predirect message toward 'D'. 'D' then either processes the Predirect message locally or proxies it toward 'E'.
In the reverse direction, when 'E'/'D' sends a Redirect response message back to 'A', it first sends the message to 'D'/'C', which proxies the message toward 'B', which finally proxies the message toward 'A'.
If a legacy host or router receives an AERO Redirect or Predirect message, it will process the message as if it were an ordinary Redirect. This will cause no harmful effects, since the legacy system will ignore the 'A' and P' bits in the Reserved field, and will also ignore any RIOs that are included. The values encoded in the Redirect message target and destination addresses will also not cause the legacy node to create incorrect routing state. The mechanism therefore causes no harm to legacy systems, and supports natural incremental deployment.
On some AERO links, each packet can include a signature that the link egress nodes can use to authenticate the link ingress node (e.g., see: [I-D.templin-ironbis]). On those links, the procedures for maintaining ingress filtering entries described above are not necessary.
There are no IANA considerations for this document.
This document enables ingress filtering, and therefore improves the security of AERO links.
Discussions both on the v6ops list and in private exchanges helped shape some of the concepts in this work. Individuals who contributed insights include Mikael Abrahamsson, Fred Baker, Brian Carpenter, Joel Halpern, Lee Howard,
| [RFC0791] | Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. |
| [RFC0792] | Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2460] | Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. |
| [RFC4861] | Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. |
| [RFC4862] | Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. |
| [RFC4191] | Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. |