--- 1/draft-ietf-v6ops-tunnel-loops-04.txt 2011-03-15 00:14:54.000000000 +0100 +++ 2/draft-ietf-v6ops-tunnel-loops-05.txt 2011-03-15 00:14:54.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group G. Nakibly Internet-Draft National EW Research & -Intended status: Standards Track Simulation Center -Expires: September 10, 2011 F. Templin +Intended status: Informational Simulation Center +Expires: September 15, 2011 F. Templin Boeing Research & Technology - March 09, 2011 + March 14, 2011 Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations - draft-ietf-v6ops-tunnel-loops-04.txt + draft-ietf-v6ops-tunnel-loops-05.txt Abstract This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible @@ -29,21 +29,21 @@ 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 September 10, 2011. + This Internet-Draft will expire on September 15, 2011. Copyright Notice 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 @@ -59,30 +59,30 @@ 2. A Detailed Description of the Attack . . . . . . . . . . . . . 4 3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6 3.1. Verification of end point existence . . . . . . . . . . . 6 3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 6 3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 7 3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 7 3.2.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 8 3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 8 3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9 3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 9 - 3.3. Destination and Source Address Checks . . . . . . . . . . 21 - 3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 22 - 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 23 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 + 3.3. Destination and Source Address Checks . . . . . . . . . . 15 + 3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 16 + 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction IPv6-in-IPv4 tunnels are an essential part of many migration plans for IPv6. They allow two IPv6 nodes to communicate over an IPv4-only network. Automatic tunnels that assign non-link-local IPv6 prefixes with stateless address mapping properties (hereafter called "automatic tunnels") are a category of tunnels in which a tunneled packet's egress IPv4 address is embedded within the destination IPv6 address of the packet. An automatic tunnel's router is a router that @@ -398,23 +398,22 @@ not assign non-link-local IPv6 prefixes on its tunnel interfaces there is no opportunity for it to initiate the loop. If the router further ensures that the routing state is consistent for the packets it receives on its tunnel interfaces there is no opportunity for it to propagate a loop initiated by a different router. This mitigation is available only to ISATAP routers, since the ISATAP stateless address mapping operates only on the Interface Identifier portion of the IPv6 address, and not on the IPv6 prefix. . The mitigation is also only applicable on ISATAP links on which IPv4 - source address spoofing is disabled. This section specifies new - operational procedures and mechanisms needed to implement the - mitigation; it therefore updates [RFC5214]. + source address spoofing is disabled. The following sections discuss + the operational configurations necessary to implement the mitigation. 3.2.4.1. ISATAP Router Interface Types ISATAP provides a Potential Router List (PRL) to further ensure a loop-free topology. Routers that are members of the provider network PRL configure their provider network ISATAP 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. Routers that are not members of the provider network PRL configure their provider network ISATAP interfaces as non-advertising @@ -433,511 +432,213 @@ o a forwarding table entry exists that lists the packet's IPv4 source address as the link-layer address corresponding to the inner IPv6 source address via the ISATAP interface. 3.2.4.3. ISATAP Host Behavior ISATAP hosts send Router Solicitation (RS) messages to obtain RA messages from an advertising ISATAP router. Whether or not non-link- local IPv6 prefixes are advertised, the host can acquire IPv6 addresses, e.g., through the use of DHCPv6 stateful address - autoconfiguration [RFC3315]. To acquire addresses, the host performs - standard DHCPv6 exchanges while mapping the IPv6 - "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to - the IPv4 address of the advertising router (hence, the advertising - router must configure either a DHCPv6 relay or server function). The - host should also use DHCPv6 Authentication, and the DHCPv6 server - should refuse to process requests from hosts that cannot be - authenticated. + autoconfiguration [RFC3315]. + + To acquire addresses, the host performs standard DHCPv6 exchanges + while mapping the IPv6 "All_DHCP_Relay_Agents_and_Servers" link- + scoped multicast address to the IPv4 address of the advertising + router (hence, the advertising router must configure either a DHCPv6 + relay or server function). The host should also use DHCPv6 + Authentication in environments where authentication of the DHCPv6 + exchanges is required. After the host receives IPv6 addresses, it assigns them to its ISATAP interface and forwards any of its outbound IPv6 packets via the advertising router as a default router. The advertising router in - turn maintains IPv6 forwarding table entries in the CURRENT state - that list the IPv4 address of the host as the link-layer address of - the delegated IPv6 addresses, and generates redirection messages to - inform the host of a better next hop when appropriate. + turn maintains IPv6 forwarding table entries that list the IPv4 + address of the host as the link-layer address of the delegated IPv6 + addresses. 3.2.4.4. ISATAP Router Behavior - In many use case scenarios (e.g., small enterprise networks, etc.), - advertising and non-advertising ISATAP routers can engage in a full- - or partial-topology dynamic IPv6 routing protocol, so that IPv6 - routing/forwarding tables can be populated and standard IPv6 - forwarding between ISATAP routers can be used. In other scenarios - (e.g., large ISP networks, etc.) this might be impractical dues to - scaling and security issues. + In many use case scenarios (e.g., enterprise networks, MANETs, etc.), + advertising and non-advertising ISATAP routers can engage in a + proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.) + so that IPv6 routing/forwarding tables can be populated and standard + IPv6 forwarding between ISATAP routers can be used. In other + scenarios (e.g., large ISP networks, etc.), this might be impractical + dues to scaling issues. When a proactive dynamic routing protocol + cannot be used, non-advertising ISATAP routers send RS messages to + obtain RA messages from an advertising ISATAP router, i.e., they act + as "hosts" on their non-advertising ISATAP interfaces. - When a dynamic routing protocol cannot be used, non-advertising - ISATAP routers send RS messages to obtain RA messages from an - advertising ISATAP router, i.e., they act as "hosts" on their non- - advertising ISATAP interfaces. Non-advertising routers can also - acquire IPv6 prefixes, e.g., through the use of DHCPv6 Prefix - Delegation [RFC3633] via an advertising router in the same fashion as - described above for host-based DHCPv6 stateful address - autoconfiguration. + Non-advertising routers can also acquire IPv6 prefixes, e.g., through + the use of DHCPv6 Prefix Delegation [RFC3633] via an advertising + router in the same fashion as described above for host-based DHCPv6 + stateful address autoconfiguration. The advertising router in turn + maintains IPv6 forwarding table entries that list the IPv4 address of + the non-advertising router as the link-layer address of the next hop + toward the delegated IPv6 prefixes. After the non-advertising router acquires IPv6 prefixes, it can sub- delegate them to routers and links within its attached IPv6 edge networks, then can forward any outbound IPv6 packets coming from its - edge networks via the advertising router as a default router. The - advertising router in turn maintains IPv6 forwarding table entries in - the CURRENT state that list the IPv4 address of the non-advertising - router as the link-layer address of the next hop toward the delegated - IPv6 prefixes, and generates redirection messages to inform the non- - advertising router of a better next hop when appropriate. - - This implies that the advertising router considers the delegated - prefixes as identifying the non-advertising router as an on-link - neighbor for the purpose of generating redirection messages, and that - the non-advertising router accepts redirection messages coming from - the advertising router as though its ISATAP interface were configured - as a host interface. + edge networks via other ISATAP nodes on the link. 3.2.4.5. Reference Operational Scenario Figure 3 depicts a reference ISATAP network topology for operational avoidance of on-link non-link-local IPv6 prefixes. The scenario - shows an advertising ISATAP router, a non-advertising ISATAP router, - an ISATAP host and a non-ISATAP IPv6 host in a typical deployment - configuration: + shows an advertising ISATAP router ('A'), two non-advertising ISATAP + routers ('B', 'D'), an ISATAP host ('F'), and three ordinary IPv6 + hosts ('C', 'E', 'G') in a typical deployment configuration: - .-(::::::::) - .-(::: IPv6 :::)-. - (:::: Internet ::::) - `-(::::::::::::)-' + .-(::::::::) 2001:db8:3::1 + .-(::: IPv6 :::)-. +-------------+ + (:::: Internet ::::) | IPv6 Host G | + `-(::::::::::::)-' +-------------+ `-(::::::)-' ,-. ,-----+-/-+--' \+------. / ,~~~~~~~~~~~~~~~~~, : / |companion gateway| |. ,-' '~~~~~~~~~~~~~~~~~' `. ; +--------------+ ) - : | Router A | / - : | (isatap) | ; - +- +--------------+ -+ - ; fe80::5efe:192.0.2.1 : - | ; - : IPv4 Provider Network -+-' + : | Router A | / fe80::5efe:192.0.2.4 + : | (isatap) | ; 2001:db8:2::1 + +- +--------------+ -+ +--------------+ + ; fe80::5efe:192.0.2.1 : | (isatap) | + | ; | Host F | + : IPv4 Provider Network -+-' +--------------+ `-. (PRL: 192.0.2.1) .) \ _) `-----+--------)----+'----' - fe80::5efe:192.0.2.2 fe80::5efe:192.0.2.3 - 2001:db8:0:1::1 +--------------+ - +--------------+ | (isatap) | - | (isatap) | | Router C | - | Host B | +--------------+ - +--------------+ 2001:db8:2::/48 - .-. - ,-( _)-. +------------+ - .-(_ IPv6 )-. |(non-isatap)| - (__Edge Network )--| Host D | - `-(______)-' +------------+ - 2001:db8:2:1::1 + fe80::5efe:192.0.2.2 fe80::5efe:192.0.2.3 .-. + +--------------+ +--------------+ ,-( _)-. + | (isatap) | | (isatap) | .-(_ IPv6 )-. + | Router B | | Router D |--(__Edge Network ) + +--------------+ +--------------+ `-(______)-' + 2001:db8::/48 2001:db8:1::/48 | + | 2001:db8:1::1 + .-. +-------------+ + ,-( _)-. 2001:db8::1 | IPv6 Host E | + .-(_ IPv6 )-. +-------------+ +-------------+ + (__Edge Network )--| IPv6 Host C | + `-(______)-' +-------------+ Figure 3: Reference ISATAP Network Topology - In Figure 3, router 'A' within the IPv4 provider network connects to - the IPv6 Internet, either directly or via a companion gateway. 'A' - configures a provider network IPv4 interface with address 192.0.2.1 - and arranges to add the address to the provider network PRL. 'A' - next configures an advertising ISATAP router interface with link- - local IPv6 address fe80::5efe:192.0.2.1 over the IPv4 interface. - - Host 'B' connects to the provider network via an IPv4 interface with - address 192.0.2.2, and also configures an ISATAP host interface with - link-local address fe80::5efe:192.0.2.2 over the IPv4 interface. 'B' - next configures a default IPv6 route with next-hop address fe80:: - 5efe:192.0.2.1 via the ISATAP interface, then receives the IPv6 - address 2001:db8:0:1::1 from a DHCPv6 address configuration exchange - via 'A'. When 'B' receives the IPv6 address, it assigns the address - to the ISATAP interface but does not assign a non-link-local IPv6 - prefix to the interface. - - Router 'C' connects to one or more IPv6 edge networks and also - connects to the provider network via an IPv4 interface with address - 192.0.2.3, but does not add the address to the provider network PRL. - 'C' next configures a non-advertising ISATAP router interface with - link-local address fe80::5efe:192.0.2.3 over the IPv4 interface, but - does not engage in an IPv6 routing protocol over the interface. 'C' - therefore configures a default IPv6 route with next-hop address - fe80::5efe:192.0.2.1 via the ISATAP interface, and receives the IPv6 - prefix 2001:db8:2::/48 through a DHCPv6 prefix delegation exchange - via 'A'. 'C' finally sub-delegates the prefix to its IPv6 edge - networks and configures its IPv6 edge network interfaces as - advertising router interfaces. - - In this example, when 'B' has an IPv6 packet to send to host 'D' - within an IPv6 edge network connected by 'C', it prepares the IPv6 - packet with source address 2001:db8:0:1::1 and destination address - 2001:db8:2:1::1. 'B' then uses ISATAP encapsulation to forward the - packet to 'A' as its default router. 'A' forwards the packet to 'C', - and also sends redirection messages to inform 'B' that 'C' is a - better next hop toward 'D'. Future packets sent from 'B' to 'D' - therefore go directly to 'C' without involving 'A'. An analogous - redirection exchange occurs in the reverse direction when 'D' has a - packet to send to 'B' (via 'C'). Details of the redirection - exchanges are described in Section 3.2.4.6 - -3.2.4.6. ISATAP Predirection - - With respect to the reference operational scenario depicted in - Figure 3, when ISATAP router 'A' receives an IPv6 packet on an - advertising ISATAP interface that it will forward back out the same - interface, 'A' must arrange to redirect the originating ISATAP node - 'B' to a better next hop ISATAP node 'C' that is closer to the final - destination 'D'. First, however, 'A' must direct 'C' to establish a - forwarding table entry in order to satisfy the source address - verification check specified in Section 3.2.4.2. This process is - accommodated via a unidirectional reliable exchange in which 'A' - first informs 'C', then 'C' informs 'B' via 'A' as a trusted - intermediary. 'B' therefore knows that 'C' will accept the packets - it sends as long as 'C' retains the forwarding table entry. We call - this process "predirection", which stands in contrast to ordinary - IPv6 redirection. - - Consider the alternative in which 'A' informs both 'B' and 'C' - separately via independent IPv6 Redirect messages (see: [RFC4861]). - - In that case, several conditions can occur that could result in - communications failures. First, if 'B' receives the Redirect message - but 'C' does not, subsequent packets sent by 'B' would disappear into - a black hole since 'C' would not have a forwarding table entry to - verify their source addresses. Second, if 'C' receives the Redirect - message but 'B' does not, subsequent packets sent in the reverse - direction by 'C' would be lost. Finally, timing issues surrounding - the establishment and garbage collection of forwarding table entries - at 'B' and 'C' 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. - - The following subsections discuss the predirection steps that support - the reference operational scenario: - -3.2.4.6.1. 'A' Sends Predirect Forward To 'C' - - When 'A' forwards an original IPv6 packet sent by 'B' out the same - ISATAP interface that it arrived on, it sends a "Predirect" message - forward toward 'C' instead of sending a Redirect message back to 'B'. - The Predirect message is simply an ISATAP-specific version of an - ordinary IPv6 Redirect message 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 4: - - 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 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |I|P| Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Destination Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... - +-+-+-+-+-+-+-+-+-+-+-+- - - Figure 4: ISATAP-Specific IPv6 Redirect Message Format - - Where the new bits are defined as: - - I (1) the "ISATAP" bit. Set to 1 to indicate an ISATAP-specific - Redirect message, and set to 0 to indicate an ordinary IPv6 - Redirect message. - - P (1) the "Predirect" bit. Set to 1 to indicate a Predirect - message, and set to 0 to indicate a Redirect response to a - Predirect message. (This bit is valid only when the I bit is set - to 1.) - - Using this new Predirect message format, 'A' prepares the message in - a similar fashion as for an ordinary ISATAP-encapsulated IPv6 - Redirect message as follows: - - o the outer IPv4 source address is set to 'A's IPv4 address. - - o the outer IPv4 destination address is set to 'C's IPv4 address. - - o the inner IPv6 source address is set to 'A's ISATAP link-local - address. - - o the inner IPv6 destination address is set to 'C's ISATAP link- - local address. - - o the Predirect Target and Destination Addresses are both set to - 'B's ISATAP link-local address. - - o the Predirect message includes a Route Information Option (RIO) - [RFC4191] that encodes an IPv6 prefix taken from 'B's address/ - prefix delegations that covers the IPv6 source address of the - originating IPv6 packet. - - o the Predirect message includes a Redirected Header Option (RHO) - that contains at least the header of the originating IPv6 packet. - - o the I and P bits in the Predirect message header are both set to - 1. - - 'A' then sends the Predirect message forward to 'C'. - -3.2.4.6.2. 'C' Processes the Predirect and Sends Redirect Back To 'A' - - When 'C' receives the Predirect message, it decapsulates the message - according to Section 7.3 of [RFC5214] since the outer IPv4 source - address is a member of the PRL. - - 'C' then uses the message validation checks specified in Section 8.1 - of [RFC4861], except that instead of verifying that the "IP source - address of the Redirect is the same as the current first-hop router - for the specified ICMP Destination Address" (i.e., the 6th - verification check), it accepts the message if the "outer IP source - address of the Predirect is the same as the current first-hop router - for the prefix specified in the RIO". (Note that this represents an - ISATAP-specific adaptation of the verification checks.) Finally, 'C' - only accepts the message if the destination address of the - originating IPv6 packet encapsulated in the RHO is covered by one of - its CURRENT delegated addresses/prefixes (see Section 3.2.4.9). - - 'C' then either creates or updates an IPv6 forwarding table entry - with the prefix encoded in the RIO option as the target prefix, and - the IPv6 Target Address of the Predirect message (i.e., 'B's ISATAP - link-local address) as the next hop. 'C' places the entry in the - FILTERING state, then sets/resets a filtering expiration timer value - of 40 seconds. If the filtering timer expires, the node clears the - FILTERING state and deletes the forwarding table entry if it is not - in the FORWARDING state. This suggests that 'C's ISATAP interface - should maintain a private forwarding table separate from the common - IPv6 forwarding table, since the entry must be managed by the ISATAP - interface itself. - - After processing the Predirect message and establishing the - forwarding table entry, 'C' prepares an ISATAP Redirect message in - response to the Predirect as follows: - - o the outer IPv4 source address is set to 'C's IPv4 address. - - o the outer IPv4 destination address is set to 'A's IPv4 address. - - o the inner IPv6 source address, is set to 'C's ISATAP link-local - address. - - o the inner IPv6 destination address is set to 'A's ISATAP link- - local address. - - o the Redirect Target and the Redirect Destination Addresses are - both set to 'C's ISATAP link-local address. - - o the Redirect message includes an RIO that encodes an IPv6 prefix - taken from 'C's address/prefix delegations that covers the IPv6 - destination address of the originating IPv6 packet encapsulated in - the Redirected Header option of the Predirect. - - o the Redirect message includes an RHO copied from the corresponding - Predirect message. - - o the (I, P) bits in the Redirect message header are set to (1, 0). - - 'C' then sends the Redirect message to 'A'. - -3.2.4.6.3. 'A' Processes the Redirect then Proxies it Back To 'B' - - When 'A' receives the Predirect message, it decapsulates the message - according to Section 7.3 of [RFC5214] since the inner IPv6 source - address embeds the outer IPv4 source address. - - 'A' next accepts the message only if it satisfies the same message - validation checks specified for Predirects in Section 3.2.4.6.2. - - 'A' then locates a forwarding table entry that covers the IPv6 source - address of the packet segment in the RHO (i.e., a forwarding table - entry with next hop 'B'), then proxies the Redirect message back - toward 'B'. Without decrementing the IPv6 hop limit in the Redirect - message, 'A' next changes the IPv4 source address of the Redirect - message to its own IPv4 address, changes the IPv4 destination address - to 'B's IPv4 address, changes the IPv6 source address to its own IPv6 - link-local address, and changes the IPv6 destination address to 'B's - IPv6 link-local address. 'A' then sends the proxied Redirect message - to 'B'. - -3.2.4.6.4. 'B' Processes The Redirect Message - - When 'B' receives the Redirect message, it decapsulates the message - according to Section 7.3 of [RFC5214] since the outer IPv4 source - address is a member of the PRL. - - 'B' next accepts the message only if it satisfies the same message - validation checks specified for Predirects in Section 3.2.4.6.2. - - 'B' then either creates or updates an IPv6 forwarding table entry - with the prefix encoded in the RIO option as the target prefix, and - the IPv6 Target Address of the Redirect message (i.e., 'C's ISATAP - link-local address) as the next hop. 'B' places the entry in the - FORWARDING state, then sets/resets a forwarding expiration timer - value of 30 seconds. If the forwarding timer expires, the node - clears the FORWARDING state and deletes the forwarding table entry if - it is not in the FILTERING state. Again, this suggests that 'B's - ISATAP interface should maintain a private forwarding table separate - from the common IPv6 forwarding table, since the entry must be - managed by the ISATAP interface itself. - - Now, 'B' has a forwarding table entry in the FORWARDING state, and - 'C' has a forwarding table entry in the FILTERING state. Therefore, - 'B' may send ordinary IPv6 data packets with destination addresses - covered by 'C's prefix directly to 'C' without involving 'A'. 'C' - will in turn accept the packets since they satisfy the source address - verification rule specified in Section 3.2.4.2. - - To enable packet forwarding from 'C' directly to 'B', a reverse- - predirection operation is required which is the mirror-image of the - forward-predirection operation described above. Following the - reverse predirection, both 'B' and 'C' will have forwarding table - entries in the "(FORWARDING | FILTERING)" state, and IPv6 packets can - be exchanged bidirectionally without involving 'A'. - -3.2.4.6.5. 'B' Sends Periodic Predirect Messages Forward to 'A' - - In order to keep forwarding table entries alive while data packets - are actively flowing, 'B' can periodically send additional Predirect - messages via 'A' to solicit Redirect messages from 'C'. When 'B' - forwards an IPv6 packet via 'C', and the corresponding forwarding - table entry FORWARDING state timer is nearing expiration, 'B' sends - Predirect messages (subject to rate limiting) prepared as follows: - - o the outer IPv4 source address is set to 'B's IPv4 address. - - o the outer IPv4 destination address is set to 'A's IPv4 address. - - o the inner IPv6 source address is set to 'B's ISATAP link-local - address. + In Figure 3, advertising ISATAP router 'A' within the IPv4 provider + network connects to the IPv6 Internet, either directly or via a + companion gateway. 'A' configures a provider network IPv4 interface + with address 192.0.2.1 and arranges to add the address to the + provider network PRL. 'A' next configures an advertising ISATAP + router interface with link-local IPv6 address fe80::5efe:192.0.2.1 + over the IPv4 interface. - o the inner IPv6 destination address is set to 'A's ISATAP link- - local address. + Non-advertising ISATAP router 'B' connects to one or more IPv6 edge + networks and also connects to the provider network via an IPv4 + interface with address 192.0.2.2, but it does not add the IPv4 + address to the provider network PRL. 'B' next configures a non- + advertising ISATAP router interface with link-local address fe80:: - o the Predirect Target and Destination Addresses are both set to - 'B's ISATAP link-local address. + 5efe:192.0.2.2, then receives the IPv6 prefix 2001:db8::/48 through a + DHCPv6 prefix delegation exchange via 'A'. 'B' then engages in an + IPv6 routing protocol over its ISATAP interface and announces the + delegated IPv6 prefix. 'B' finally sub-delegates the prefix to its + attached edge networks, where IPv6 host 'C' autoconfigures the + address 2001:db8::1. - o the Predirect message includes an RIO that encodes an IPv6 prefix - taken from 'B's address/prefix delegations that covers the IPv6 - source address of the originating IPv6 packet. + Non-advertising ISATAP router 'D' connects to the provider network, + configures its ISATAP interface, receives a DHCPv6 prefix delegation, + and engages in the IPv6 routing protocol the same as for router 'B'. + In particular, 'D' configures the IPv4 address 192.0.2.3, the ISATAP + link-local address fe80::5efe:192.0.2.3, and the delegated IPv6 + prefix 2001:db8:1::/48. 'D' finally sub-delegates the prefix to its + attached edge networks, where IPv6 host 'E' autoconfigures IPv6 + address 2001:db8:1::1. - o the Predirect message includes an RHO that contains at least the - header of the originating IPv6 packet. + ISATAP host 'F' connects to the provider network via an IPv4 + interface with address 192.0.2.4, and also configures an ISATAP host + interface with link-local address fe80::5efe:192.0.2.4 over the IPv4 + interface. 'F' next configures a default IPv6 route with next-hop + address fe80::5efe:192.0.2.1 via the ISATAP interface, then receives + the IPv6 address 2001:db8:2::1 from a DHCPv6 address configuration + exchange via 'A'. When 'F' receives the IPv6 address, it assigns the + address to the ISATAP interface but does not assign a non-link-local + IPv6 prefix to the interface. - o the I and P bits in the Predirect message header are both set to - 1. + Finally, IPv6 host 'G' connects to an IPv6 network outside of the + ISATAP domain. 'G' configures its IPv6 interface in a manner + specific to its attached IPv6 link, and autoconfigures the IPv6 + address 2001:db8:3::1. - When 'A' receives the Predirect message, it decapsulates the message - according to Section 7.3 of [RFC5214] since the inner IPv6 source - address embeds the outer IPv4 source address. + Following this autoconfiguration, when host 'C' has an IPv6 packet to + send to host 'E', it prepares the packet with source address 2001: + db8::1 and destination address 2001:db8:1::1, then sends the packet + into the edge network where it will eventually be forwarded to router + 'B'. 'B' then uses ISATAP encapsulation to forward the packet to + router 'D', since it has discovered a route to 2001:db8:1::/48 with + next hop 'D' via dynamic routing over the ISATAP interface. Router + 'D' finally forwards the packet to host 'E'. - 'A' next accepts the message only if it satisfies the same message - validation checks specified for Predirects in Section 3.2.4.6.2. + In a second scenario, when 'C' has a packet to send to ISATAP host + 'F', it prepares the packet with source address 2001:db8::1 and + destination address 2001:db8:2::1, then sends the packet into the + edge network where it will eventually be forwarded to router 'B' the + same as above. 'B' then uses ISATAP encapsulation to forward the + packet to router 'A' (i.e., a router that advertises "default"), + which in turn forwards the packet to 'F'. Note that this operation + entails two hops across the ISATAP link (i.e., one from 'B' to 'A', + and a second from 'A' to 'F'). If 'F' also participates in the + dynamic IPv6 routing protocol, however, 'B' could instead forward the + packet directly to 'F' without involving 'A'. - 'A' then locates a forwarding table entry that covers the IPv6 - destination address of the packet segment in the RHO (in this case, a - forwarding table entry with next hop 'C'). Without decrementing the - IPv6 hop limit in the Redirect message, 'A' next changes the IPv4 - source address of the Predirect message to its own IPv4 address, - changes the IPv4 destination address to 'C's IPv4 address, changes - the IPv6 source address to its own IPv6 link-local address, and - changes the IPv6 destination address to 'C's IPv6 link-local address. - 'A' then sends the proxied Predirect message to 'C'. When 'C' - receives the proxied message, it processes the message the same as if - it had originated from 'A' as described in Section 3.2.4.6.2. + In a final scenario, when 'C' has a packet to send to host 'G' in the + IPv6 Internet, the packet is forwarded to 'B' the same as above. 'B' + then forwards the packet to 'A', which forwards the packet into the + IPv6 Internet. -3.2.4.7. Scaling Considerations +3.2.4.6. Scaling Considerations Figure 3 depicts an ISATAP network topology with only a single advertising ISATAP router within the provider network. In order to support larger numbers of non-advertising ISATAP routers and ISATAP hosts, the provider network can deploy more advertising ISATAP routers to support load balancing and generally shortest-path routing. Such an arrangement requires that the advertising ISATAP routers participate in an IPv6 routing protocol instance so that IPv6 address/prefix delegations can be mapped to the correct router. The routing protocol instance can be configured as either a full mesh topology involving all advertising ISATAP routers, or as a partial - mesh topology with each ISATAP router associating with one or more - companion gateways and a full mesh between companion gateways. - -3.2.4.8. Proxy Chaining - - In large ISATAP deployments, there may be many advertising ISATAP - routers, each serving many ISATAP clients (i.e., both non-advertising - routers and simple hosts). The advertising ISATAP routers then - either require full topology knowledge, or a default route to a - companion gateway that does have full topology knowledge. For - example, if Client 'A' connects to advertising ISATAP router 'B', and - Client 'E' connects to advertising ISATAP router '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' sends an initial packet to 'E', 'B' generates - a Predirect message toward 'C', which proxies the message toward 'D' - which finally proxies the message toward 'E'. - - In the reverse direction, when 'E' sends a Redirect response message - to 'A', it first sends the message to 'D', which proxies the message - toward 'C', which proxies the message toward 'B', which finally - proxies the message toward 'A'. - -3.2.4.9. Mobility - - An ISATAP router 'A' can configure both a non-advertising ISATAP - interface on a provider network and an advertising ISATAP interface - on an edge network. In that case, 'A' can service ISATAP clients - (i.e. both non-advertising routers and simple hosts) within the edge - network by acting as a DHCPv6 relay. When a client 'B' in the edge - network that has obtained IPv6 addresses/prefixes moves to a - different edge network, however, 'B' can release its address/prefix - delegations via 'A' and re-establish them via a different ISATAP - router 'C' in the new edge network. + mesh topology with each advertising ISATAP router associating with + one or more companion gateways and a full mesh between companion + gateways. - When 'B' releases its address/prefix delegations via 'A', 'A' marks - the IPv6 forwarding table entries that cover the addresses/prefixes - as DEPARTED (i.e., it clears the CURRENT state). 'A' 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. +3.2.4.7. On-Demand Dynamic Routing - When 'A' receives IPv6 packets destined to an address covered by the - DEPARTED IPv6 forwarding table entries, it forwards them to the last- - known edge network link-layer address of 'B' as a means for avoiding - mobility-related packet loss during routing changes. Eventually, - correspondents will receive new Redirect messages from the network to - discover that 'B' is now associated with 'C'. + With respect to the reference operational scenario depicted in + Figure 3, there will be many use cases in which a proactive dynamic + IPv6 routing protocol cannot be used. For example, in large ISP + network deployments it would be impractical for all Customer-Edge and + Provider-Edge routers to engage in a common routing protocol instance + due to scaling considerations. - Note that this mobility management method works the same way when the - edge networks comprise native IPv6 links (i.e., and not just for - ISATAP links), however any IPv6 packets forwarded by 'A' via an IPv6 - forwarding table entry in the DEPARTED state may be lost if the - mobile node moves off-link with respect to its previous edge network - 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. + In those cases, an on-demand routing capability can be enabled in + which ISATAP nodes send initial packets via an advertising ISATAP + router and receive redirection messages back. For example, when a + non-advertising ISATAP router 'B' has a packet to send to a host + located behind non-advertising ISATAP router 'D', it can send the + initial packets via advertising router 'A' which will return + redirection messages to inform 'B' that 'D' is a better first hop. + Protocol details for this ISATAP redirection are specified in + [I-D.templin-intarea-vet]. 3.3. Destination and Source Address Checks Tunnel routers can use a source address check mitigation when they forward an IPv6 packet into a tunnel interface with an IPv6 source address that embeds one of the router's configured IPv4 addresses. Similarly, tunnel routers can use a destination address check mitigation when they receive an IPv6 packet on a tunnel interface with an IPv6 destination address that embeds one of the router's configured IPv4 addresses. These checks should correspond to both @@ -1093,23 +794,20 @@ via IPv4 Clouds", RFC 3056, February 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. - [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and - More-Specific Routes", RFC 4191, November 2005. - [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. @@ -1118,20 +816,25 @@ Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. 8.2. Informative References [I-D.gont-6man-teredo-loops] Gont, F., "Mitigating Teredo Rooting Loop Attacks", draft-gont-6man-teredo-loops-00 (work in progress), September 2010. + [I-D.templin-intarea-vet] + Templin, F., "Virtual Enterprise Traversal (VET)", + draft-templin-intarea-vet-23 (work in progress), + January 2011. + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006. [USENIX09] Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 Tunnels", USENIX WOOT, August 2009.