idnits 2.17.1 draft-templin-aerolink-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 19, 2013) is 3781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0768' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 912, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 926, but no explicit reference was found in the text == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-65 ** Downref: Normative reference to an Experimental draft: draft-templin-intarea-seal (ref. 'I-D.templin-intarea-seal') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Obsoletes: rfc6706 (if approved) December 19, 2013 5 Intended status: Standards Track 6 Expires: June 22, 2014 8 Transmission of IPv6 Packets over Asymmetric Extended Route Optimization 9 (AERO) Links 10 draft-templin-aerolink-00.txt 12 Abstract 14 This document specifies the operation of IPv6 over tunnel virtual 15 Non-Broadcast, Multiple Access (NBMA) links using Asymmetric Extended 16 Route Optimization (AERO). Nodes attached to AERO links can exchange 17 packets via trusted intermediate routers on the link that provide 18 forwarding services to reach off-link destinations and/or redirection 19 services to inform the node of an on-link neighbor that is closer to 20 the final destination. Operation of the IPv6 Neighbor Discovery (ND) 21 over AERO links is based on an IPv6 link local address format known 22 as the AERO address. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 22, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 5 61 3.1. AERO Interface Characteristics . . . . . . . . . . . . . . 5 62 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 7 63 3.3. AERO Addresses . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4. AERO Reference Operational Scenario . . . . . . . . . . . 8 65 3.5. AERO Prefix Delegation and Router Discovery . . . . . . . 9 66 3.5.1. AERO Client Behavior . . . . . . . . . . . . . . . . . 9 67 3.5.2. AERO Server Behavior . . . . . . . . . . . . . . . . . 10 68 3.6. AERO Neighbor Unreachability Detection . . . . . . . . . . 10 69 3.7. AERO Redirection . . . . . . . . . . . . . . . . . . . . . 11 70 3.7.1. Classical Redirection Approaches . . . . . . . . . . . 11 71 3.7.2. AERO Redirection Concept of Operations . . . . . . . . 12 72 3.7.3. AERO Redirection Message Format . . . . . . . . . . . 13 73 3.7.4. Sending Predirects . . . . . . . . . . . . . . . . . . 14 74 3.7.5. Processing Predirects and Sending Redirects . . . . . 15 75 3.7.6. Forwarding Redirects . . . . . . . . . . . . . . . . . 16 76 3.7.7. Processing Redirects . . . . . . . . . . . . . . . . . 17 77 3.7.8. Neighbor Reachability Considerations . . . . . . . . . 18 78 3.7.9. Neighbor Cache Entry Mainenance . . . . . . . . . . . 18 79 3.7.10. Mobility and Link-Layer Address Change 80 Considerations . . . . . . . . . . . . . . . . . . . . 19 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 87 Appendix A. AERO Server and Relay Interworking . . . . . . . . . 21 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 This document specifies the operation of IPv6 over tunnel virtual 93 Non-Broadcast, Multiple Access (NBMA) links using Asymmetric Extended 94 Route Optimization (AERO). Nodes attached to AERO links can exchange 95 packets via trusted intermediate routers on the link that provide 96 forwarding services to reach off-link destinations and/or redirection 97 services to inform the node of an on-link neighbor that is closer to 98 the final destination. 100 AERO uses an IPv6 link-local address format known as the AERO 101 Address. This address type has properties that statelessly link IPv6 102 Neighbor Discovery (ND) to IPv6 routing. The AERO link can be used 103 for tunneling to neighboring nodes on either IPv6 or IPv4 networks, 104 i.e., AERO views the IPv6 and IPv4 networks as equivalent links for 105 tunneling. The remainder of this document presents the AERO 106 specification. 108 2. Terminology 110 The terminology in the normative references applies; the following 111 terms are defined within the scope of this document: 113 AERO link 114 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 115 configured over a node's attached IPv6 and/or IPv4 networks. All 116 nodes on the AERO link appear as single-hop neighbors from the 117 perspective of IPv6. 119 AERO interface 120 a node's attachment to an AERO link. 122 AERO address 123 an IPv6 link-local address assigned to an AERO interface and 124 constructed as specified in Section 3.3. 126 AERO node 127 a node that is connected to an AERO link and that participates in 128 IPv6 Neighbor Discovery over the link. 130 AERO Server ("server") 131 a node that configures an advertising router interface on an AERO 132 link over which it can provide default forwarding and redirection 133 services for other AERO nodes. 135 AERO Client ("client") 136 a node that configures a non-advertising router interface on an 137 AERO link over which it can connect End User Networks (EUNs) to 138 the AERO link. 140 AERO Relay ("relay") 141 a node that relays IPv6 packets between Servers on the same AERO 142 link, and/or that forwards IPv6 packets between the AERO link and 143 the IPv6 Internet. An AERO Relay may or may not also be 144 configured as an AERO Server. 146 ingress tunnel endpoint (ITE) 147 a node that injects tunneled packets into an AERO link. 149 egress tunnel endpoint (ETE) 150 a node that receives tunneled packets from an AERO link. 152 underlying network 153 a connected IPv6 or IPv4 network routing region over which AERO 154 links tunnel IPv6 packets. 156 underlying interface 157 a node's interface point of attachment to an underlying network. 159 underlying address 160 an IPv6 or IPv4 address assigned to a node's underlying interface. 161 When UDP encapsulation is used, the UDP port number is also 162 considered as part of the link-layer address. Link-layer 163 addresses are used as the source and destination addresses of the 164 AERO encapsulation header. 166 link-layer address 167 the same as defined for "underlying address" above. 169 network layer address 170 an IPv6 address used as the source or destination address of the 171 inner IPv6 packet header. 173 end user network (EUN) 174 an IPv6 network attached to a downstream interface of an AERO 175 Client (where the AERO interface is seen as the upstream 176 interface). 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 3. Asymmetric Extended Route Optimization (AERO) 184 The following sections specify the operation of IPv6 over Asymmetric 185 Extended Route Optimization (AERO) links: 187 3.1. AERO Interface Characteristics 189 All nodes connected to an AERO link configure their AERO interfaces 190 as router interfaces (not host interfaces). End system applications 191 therefore do not bind directly to the AERO interface, but rather bind 192 to end user network (EUN) interfaces beyond which their packets may 193 be forwarded over an AERO interface. 195 AERO interfaces use IPv6-in-IPv6 encapsulation [RFC2473] to exchange 196 tunneled packets with AERO neighbors attached to an underlying IPv6 197 network and use IPv6-in-IPv4 encapsulation [RFC4213] to exchange 198 tunneled packets with AERO neighbors attached to an underlying IPv4 199 network. AERO interfaces can also use IPsec encapsulation [RFC4301] 200 (either IPv6-in-IPv6 or IPv6-in-IPv4) in environments where strong 201 authentication and confidentiality are required. 203 AERO interfaces further use the Subnetwork Encapsulation and 204 Adaptation Layer (SEAL)[I-D.templin-intarea-seal] and can therefore 205 configure an unlimited Maximum Transmission Unit (MTU). This entails 206 the insertion of a SEAL header (i.e., an IPv6 fragment header with 207 the S bit set to 1) above the outer IP encapsulation header. When 208 NAT traversal and/or filtering middlebox traversal is necessary, a 209 UDP header is further inserted between the outer IP encapsulation 210 header and the SEAL header. 212 AERO interfaces maintain a neighbor cache and use an adaptation of 213 standard unicast IPv6 ND messaging in which Router Solicitation (RS), 214 Router Advertisement (RA), Neighbor Solicitation (NS) and Neighbor 215 Advertisement (NA) messages do not include Source/Target Link Layer 216 Address Options (S/TLLAO). Instead, AERO nodes discover the link- 217 layer addresses of neighbors by examining the encapsulation source 218 address of any RS/RA/NS/NA messages they receive and ignore any 219 S/TLLAOs included in these messages. This is vital to the operation 220 of AERO in environments in which AERO neighbors are separated by 221 Network Address Translators (NATs) - either IPv4 or IPv6. 223 AERO Redirect messages include a TLLAO the same as for any IPv6 link. 224 The TLLAO includes the link-layer address of the target node, 225 including both the IP address and the UDP source port number used by 226 the target when it sends UDP-encapsulated packets over the AERO 227 interface (the TLLAO instead encodes the value 0 when the target does 228 not use UDP encapsulation). TLLAOs for target nodes that use an IPv6 229 underlying address include the full 16 bytes of the IPv6 address as 230 shown in Figure 1, while TLLAOs for target nodes that use an IPv4 231 underlying address include only the 4 bytes of the IPv4 address as 232 shown in Figure 2. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type = 2 | Length = 3 | UDP Source Port (or 0) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Reserved | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 +-- --+ 243 | | 244 +-- IPv6 Address --+ 245 | | 246 +-- --+ 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 1: AERO TLLAO Format for IPv6 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Type = 2 | Length = 1 | UDP Source Port (or 0) | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | IPv4 Address | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 2: AERO TLLAO Format for IPv4 262 Finally, nodes on AERO interfaces use a simple data origin 263 authentication for encapsulated packets they receive from other 264 nodes. In particular, AERO Clients accept encapsulated packets with 265 a link-layer source address belonging to their current AERO Server. 266 AERO nodes also accept encapsulated packets with a link-layer source 267 address that is correct for the network-layer source address. The 268 AERO node considers the link-layer source address correct for the 269 network-layer source address if there is an IPv6 route that matches 270 the network-layer source address as well as a neighbor cache entry 271 corresponding to the next hop that includes the link-layer address. 273 3.2. AERO Node Types 275 AERO Servers configure their AERO link interfaces as advertising 276 router interfaces (see [RFC4861], Section 6.2.2) and may therefore 277 send Router Advertisement (RA) messages that include non-zero Router 278 Lifetimes. 280 AERO Clients configure their AERO link interfaces as non-advertising 281 router interfaces, i.e., even if the AERO Client otherwise displays 282 the outward characteristics of an ordinary host (for example, the 283 Client may internally configure both an AERO interface and (virtual) 284 EUN interfaces). AERO Clients are provisioned with IPv6 Prefix 285 Delegations either through a DHCPv6 Prefix Delegation exchange with 286 an AERO Server over the AERO link or via a static delegation obtained 287 through an out-of-band exchange with an AERO link prefix delegation 288 authority. 290 AERO Relays relay packets between Servers connected to the same AERO 291 link and also forward packets between the AERO link and the native 292 IPv6 network. The relaying process entails re-encapsulation of IPv6 293 packets that were received from a first AERO Server and are to be 294 forwarded without modification to a second AERO Server. This 295 relaying process can best be understood as a form of bridging. 297 3.3. AERO Addresses 299 An AERO address is an IPv6 link-local address assigned to an AERO 300 interface and with an IPv6 prefix embedded within the 64-bit 301 interface identifier. 303 Each AERO Client configures an AERO address based on the delegated 304 prefix it has received from the AERO link prefix delegation 305 authority. The address begins with the prefix fe80::/64 and includes 306 in its interface identifier the base /64 prefix from the Client's 307 delegated IPv6 prefix. For example, if an AERO Client has received 308 the prefix delegation 2001:db8:1000:2000::/56 it would construct its 309 AERO address as fe80::2001:db8:1000:2000. An AERO Client may receive 310 multiple IPv6 prefix delegations, in which case it would configure 311 multiple AERO addresses - one for each delegated prefix. 313 Each AERO Server configures the special AERO address fe80::1 to 314 support the operation of IPv6 Neighbor Discovery over the AERO link; 315 the address therefore has the properties of an IPv6 Anycast address. 316 While all Servers configure the same AERO address and therefore 317 cannot be distinguished from one another at the network layer, 318 Clients can still distinguish Servers at the link layer by examining 319 the Servers' link-layer addresses. 321 Nodes that are configured as pure AERO Relays (i.e., and that do not 322 also act as Servers) do not configure an IPv6 address of any kind on 323 their AERO interfaces. The Relay's AERO interface is therefore used 324 purely for transit and does not participate in IPv6 ND message 325 exchanges. 327 3.4. AERO Reference Operational Scenario 329 Figure 3 depicts the AERO reference operational scenario. The figure 330 shows an AERO Server('A'), two AERO Clients ('B', 'D') and three 331 ordinary IPv6 hosts ('C', 'E', 'F'): 332 .-(::::::::) 333 .-(::: IPv6 :::)-. +-------------+ 334 (:::: Internet ::::)--| Host F | 335 `-(::::::::::::)-' +-------------+ 336 `-(::::::)-' 2001:db8:3::1 337 | 338 +--------------+ 339 | AERO Server A| 340 | (C->B; E->D) | 341 +--------------+ 342 fe80::1 343 L2(A) 344 | 345 X-----+-----------+-----------+--------X 346 | AERO Link | 347 L2(B) L2(D) 348 fe80::2001:db8:0:0 fe80::2001:db8:1:0 .-. 349 +--------------+ +--------------+ ,-( _)-. 350 | AERO Client B| | AERO Client D| .-(_ IPv6 )-. 351 | (default->A) | | (default->A) |--(__ EUN ) 352 +--------------+ +--------------+ `-(______)-' 353 2001:DB8:0::/48 2001:DB8:1::/48 | 354 | 2001:db8:1::1 355 .-. +-------------+ 356 ,-( _)-. 2001:db8:0::1 | Host E | 357 .-(_ IPv6 )-. +-------------+ +-------------+ 358 (__ EUN )--| Host C | 359 `-(______)-' +-------------+ 361 Figure 3: AERO Reference Operational Scenario 363 In Figure 3, AERO Server ('A') connects to the AERO link and connects 364 to the IPv6 Internet, either directly or via other IPv6 routers (not 365 shown). Server ('A') assigns the address fe80::1 to its AERO 366 interface with link-layer address L2(A). Server ('A') next arranges 367 to add L2(A) to a published list of valid Servers for the AERO link. 369 AERO Client ('B') assigns the address fe80::2001:db8:0:0 to its AERO 370 interface with link-layer address L2(B). Client ('B') configures a 371 default route via the AERO interface with next-hop network-layer 372 address fe80::1 and link-layer address L2(A), then sub-delegates the 373 prefix 2001:db8:0::/48 to its attached EUNs. IPv6 host ('C') 374 connects to the EUN, and configures the network-layer address 2001: 375 db8:0::1. 377 AERO Client ('D') assigns the address fe80::2001:db8:1:0 to its AERO 378 interface with link-layer address L2(D). Client ('D') configures a 379 default route via the AERO interface with next-hop network-layer 380 address fe80::1 and link-layer address L2(A), then sub-delegates the 381 network-layer prefix 2001:db8:1::/48 to its attached EUNs. IPv6 host 382 ('E') connects to the EUN, and configures the network-layer address 383 2001:db8:1::1. 385 Finally, IPv6 host ('F') connects to an IPv6 network outside of the 386 AERO link domain. Host ('F') configures its IPv6 interface in a 387 manner specific to its attached IPv6 link, and assigns the network- 388 layer address 2001:db8:3::1 to its IPv6 link interface. 390 3.5. AERO Prefix Delegation and Router Discovery 392 3.5.1. AERO Client Behavior 394 AERO Clients observe the IPv6 router requirements defined in 395 [RFC6434] except that they act as "hosts" on their AERO interfaces 396 for the purpose of prefix delegation and router discovery in the same 397 fashion as for IPv6 Customer Premises Equipment (CPE) routers 398 [RFC6204]. AERO Clients first discover the link-layer address of an 399 AERO Server via static configuration, or through an automated means 400 such as DNS name resolution. After discovering the link-layer 401 address, the Client then acts as a requesting router to obtain IPv6 402 prefixes through DHCPv6 Prefix Delegation [RFC3633] via the Server. 403 (The Client can also obtain prefixes through out-of-band means such 404 as static administrative configuration, etc.). After the Client 405 acquires prefixes, it sub-delegates them to nodes and links within 406 its attached EUNs. It also assigns the link-local AERO address(es) 407 taken from its delegated prefix(es) to the AERO interface (see: 408 Section 3.3). 410 After acquiring prefixes, the Client next prepares a unicast IPv6 411 Router Solicitation (RS) message using its AERO address as the 412 network-layer source address and fe80::1 as the network-layer 413 destination address. The Client then tunnels the packet to the 414 Server using one of its underlying addresses as the link-layer source 415 address and using an underlying address of the Server as the link- 416 layer destination address. The Server in turn returns a unicast 417 Router Advertisement (RA) message, which the Client uses to create an 418 IPv6 neighbor cache entry for the Server on the AERO interface per 419 [RFC4861]. The link-layer address for the neighbor cache entry is 420 taken from the link-layer source address of the RA message. 422 After obtaining prefixes and performing an initial RS/RA exchange 423 with a Server, the Client continues to send periodic RS messages to 424 the server to obtain new RAs in order to keep neighbor cache entries 425 alive. The Client can also forward IPv6 packets destined to networks 426 beyond its local EUNs via the Server as an IPv6 default router. The 427 Server may in turn return a Redirect message informing the Client of 428 a neighbor on the AERO link that is topologically closer to the final 429 destination as specified in Section 3.7. 431 3.5.2. AERO Server Behavior 433 AERO Servers observe the IPv6 router requirements defined in 434 [RFC6434]. They further configure a DHCPv6 relay/server function on 435 their AERO links and/or provide an administrative interface for 436 delegation of network-layer addresses and prefixes. When the Server 437 delegates prefixes, it also establishes forwarding table entries that 438 list the AERO address of the Client as the next hop toward the 439 delegated IPv6 prefixes (where the AERO address is constructed as 440 specified in Section 3.3). 442 Servers respond to RS messages from Clients on their advertising AERO 443 interfaces by returning an RA message. When the Server receives an 444 RS message, it creates or updates a neighbor cache entry using the 445 network layer source address as the neighbor's network layer address 446 and using the link-layer source address of the RS message as the 447 neighbor's link-layer address. 449 When the Server forwards a packet via the same AERO interface on 450 which it arrived, it initiates an AERO route optimization procedure 451 as specified in Section 3.7. 453 3.6. AERO Neighbor Unreachability Detection 455 When an AERO Client forwards a packet originating from one of its 456 EUNs via an IPv6 route for which the next hop is reached via the AERO 457 interface, it first consults its neighbor cache to determine the 458 link-layer address of the next hop. The Client then encapsulates the 459 packet and uses its link-layer address as the link-layer source 460 address and the link-layer address of the neighbor as the link-layer 461 destination address. If the IPv6 route is more-specific than 462 "default", the Client also follows the Neighbor Unreachability 463 Detection (NUD) procedures in Section 7.3 of [RFC4861] to keep 464 neighbor cache entries alive. In particular, the Client sends NS 465 messages including its AERO address as the network-layer source 466 address, the next hop's AERO address as the network-layer destination 467 address, and the same link-layer addresses used to forward the 468 packet. If the Client receives a solicited NA message response from 469 the next hop, it updates its neighbor cache entry state for the next 470 hop to REACHABLE, and records the link-layer source address of the NA 471 as the neighbor's link layer address. 473 When an AERO Client receives an NS message used for NUD on an AERO 474 interface, it either creates or updates a neighbor cache entry for 475 the neighbor that sent the NS including recording the link-layer 476 source address of the NS as the link layer address. If the Client 477 creates a new neighbor cache entry it sets the neighbor's state to 478 STALE. The Client then sends a solicited NA message back to the 479 source including the Client's AERO address as the network-layer 480 source address, the network-layer source address of the NS message as 481 the network-layer destination address, its own link-layer address as 482 the link-layer source address, and the link-layer source address of 483 the NS message as the link-layer destination address. 485 AERO Servers process NS/NA messages in the same way as AERO Clients. 486 However, they need not actively perform NUD if they have other means 487 of determining Client reachability (e.g., through RS/RA exchanges, 488 through reachability confirmation from the prefix delegation service, 489 through link-layer probing, etc.). 491 3.7. AERO Redirection 493 Section 3.4 describes the AERO reference operational scenario. We 494 now discuss the operation and protocol details of AERO Redirection 495 with respect to this reference scenario. 497 3.7.1. Classical Redirection Approaches 499 With reference to Figure 3, when the IPv6 source host ('C') sends a 500 packet to an IPv6 destination host ('E'), the packet is first 501 forwarded via the EUN to AERO Client ('B'). Client ('B') then 502 forwards the packet over its AERO interface to AERO Server ('A'), 503 which then forwards the packet to AERO Client ('D'), where the packet 504 is finally forwarded to the IPv6 destination host ('E'). When Server 505 ('A') forwards the packet back out on its advertising AERO interface, 506 it must arrange to redirect Client ('B') toward Client ('D') as a 507 better next-hop node on the AERO link that is closer to the final 508 destination. However, this redirection process should only occur if 509 there is assurance that both Client nodes are willing participants. 511 Consider a first alternative in which Server ('A') informs Client 512 ('B') only and does not inform Client ('D') (i.e., "classical 513 redirection"). In that case, Client ('D') has no way of knowing that 514 Client ('B') is authorized to forward packets from their claimed 515 network-layer source addresses, and it may simply elect to drop the 516 packets. Also, Client ('B') has no way of knowing whether Client 517 ('D') is performing some form of source address filtering that would 518 reject packets arriving from a node other than a trusted default 519 router, nor whether Client ('D') is even reachable via a direct path 520 that does not involve Server ('A'). Finally, Client ('B') has no way 521 of knowing whether the final destination ('E') has moved away from 522 Client ('D'). 524 Consider a second alternative in which Server ('A') informs both 525 Client ('B') and Client ('D') separately, via independent redirection 526 control messages (i.e., "augmented redirection"). In that case, 527 several conditions can occur that could result in communication 528 failures. First, if Client ('B') receives the redirection control 529 message but Client ('D') does not, subsequent packets sent by Client 530 ('B') could be dropped due to filtering since Client ('D') would not 531 have cached state to verify their source network-layer addresses. 532 Second, if Client ('D') receives the redirection control message but 533 Client ('B') does not, subsequent packets sent in the reverse 534 direction by Client ('D') would be lost. Finally, timing issues 535 surrounding the establishment and garbage collection of neighbor 536 state at the two Client nodes could yield unpredictable behavior. 537 For example, unless the timing were carefully coordinated through 538 some form of synchronization loop, there would invariably be 539 instances in which one node has the correct neighbor state and the 540 other node does not resulting in non-deterministic packet loss. 542 Since both of these alternatives have shortcomings, a new redirection 543 technique (i.e., "AERO redirection") is needed. 545 3.7.2. AERO Redirection Concept of Operations 547 Again, with reference to Figure 3, when source host ('C') sends a 548 packet to destination host ('E'), the packet is first forwarded over 549 the source host's attached EUN to Client ('B'), which then forwards 550 the packet via its AERO interface to Server ('A'). 552 Using AERO redirection, Server ('A') then forwards the packet out the 553 same AERO interface toward Client ('D') and also sends an AERO 554 "Predirect" message forward to Client ('D') as specified in 555 Section 3.7.4. The Predirect message includes Client ('B')'s 556 network- and link-layer addresses as well as information that Client 557 ('D') can use to determine the IPv6 prefix used by Client ('B') . 558 After Client ('D') receives the Predirect message, it process the 559 message and returns an AERO Redirect message to Server ('A') as 560 specified in Section 3.7.5. During the process, Client ('D') also 561 creates or updates a neighbor cache entry for Client ('B'), and 562 creates an IPv6 route to be used as ingress filtering information to 563 accept future packets using addresses matched by Client ('B')'s 564 prefix. 566 When Server ('A') receives the Redirect message, it processes the 567 message and forwards it on to Client ('B') as specified in 568 Section 3.7.6. The message includes Client ('D')'s network- and 569 link-layer addresses as well as information that Client ('B') can use 570 to determine the IPv6 prefix used by Client ('D'). After Client 571 ('B') receives the Redirect message, it processes the message as 572 specified in Section 3.7.7. During the process, Client ('B') also 573 creates or updates a neighbor cache entry for Client ('D'), and 574 creates an IPv6 route for forwarding future packets using addresses 575 matched by the prefixes to Client ('D'). 577 Following the above Predirect/Redirect message exchange, forwarding 578 of packets from Client ('B') to Client ('D') without involving Server 579 ('A) as an intermediary is enabled. The mechanisms that support this 580 exchange are specified in the following sections. 582 3.7.3. AERO Redirection Message Format 584 AERO Redirect/Predirect messages use the same format as for ICMPv6 585 Redirect messages depicted in Section 4.5 of [RFC4861], but also 586 include a new field (the "Prefix Length" field) taken from the 587 Redirect message Reserved field. The Redirect/Prediect messages are 588 formatted as shown in Figure 4: 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type (=137) | Code (=0/1) | Checksum | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Prefix Length | Reserved | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | | 598 + + 599 | | 600 + Target Address + 601 | | 602 + + 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | | 606 + + 607 | | 608 + Destination Address + 609 | | 610 + + 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Options ... 614 +-+-+-+-+-+-+-+-+-+-+-+- 616 Figure 4: AERO Redirect/Predirect Message Format 618 3.7.4. Sending Predirects 620 When an AERO Server forwards a packet out the same AERO interface 621 that it arrived on, the Server sends a Predirect message forward 622 toward the AERO Client nearest the destination instead of sending a 623 Redirect message back to AERO Client nearest the source. 625 In the reference operational scenario, when Server ('A') forwards a 626 packet sent by Client ('B') toward Client ('D'), it also sends a 627 Predirect message forward toward Client ('D'), subject to rate 628 limiting (see Section 8.2 of [RFC4861]). Server ('A') prepares the 629 Predirect message as follows: 631 o the link-layer source address is set to 'L2(A)' (i.e., the 632 underlying address of Server ('A')). 634 o the link-layer destination address is set to 'L2(D)' (i.e., the 635 underlying address of Client ('D')). 637 o the network-layer source address is set to fe80::1 (i.e., the AERO 638 address of Server ('A')). 640 o the network-layer destination address is set to fe80::2001:db8:1:0 641 (i.e., the AERO address of Client ('D')). 643 o the Type is set to 137. 645 o the Code is set to 1 to indicate "Predirect". 647 o the Prefix Length is set to the length of the prefix to be applied 648 to Target address. 650 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 651 address of Client ('B')). 653 o the Destination Address is set to the IPv6 source address of the 654 packet that triggered the Predirection event. 656 o the message includes a TLLAO set to 'L2(B)' (i.e., the underlying 657 address of Client ('B')). 659 o the message includes a Redirected Header Option (RHO) that 660 contains the originating packet truncated to ensure that at least 661 the network-layer header is included but the size of the message 662 does not exceed 1280 bytes. 664 Server ('A') then sends the message forward to Client ('D'). 666 3.7.5. Processing Predirects and Sending Redirects 668 When Client ('D') receives a Predirect message, it accepts the 669 message only if it has a link-layer source address of the Server, 670 i.e. 'L2(A)'. Client ('D') further accepts the message only if it 671 is willing to serve as a redirection target. Next, Client ('D') 672 validates the message according to the ICMPv6 Redirect message 673 validation rules in Section 8.1 of [RFC4861]. 675 In the reference operational scenario, when the Client ('D') receives 676 a valid Predirect message, it either creates or updates a neighbor 677 cache entry that stores the Target Address of the message as the 678 network-layer address of Client ('B') and stores the link-layer 679 address found in the TLLAO as the link-layer address of Client ('B'). 680 Client ('D') then applies the Preflx Length to the Interface 681 Identifier portion of the Target Address and records the resulting 682 IPv6 prefix in its IPv6 forwarding table. Client ('D') then marks 683 the forwarding table entry as "FILTERING", i.e., the entry is to be 684 used by the network layer for ingress filtering purposes only and not 685 for forwarding purposes. 687 After processing the message, Client ('D') prepares a Redirect 688 message response as follows: 690 o the link-layer source address is set to 'L2(D)' (i.e., the link- 691 layer address of Client ('D')). 693 o the link-layer destination address is set to 'L2(A)' (i.e., the 694 link-layer address of Server ('A')). 696 o the network-layer source address is set to 'L3(D)' (i.e., the AERO 697 address of Client ('D')). 699 o the network-layer destination address is set to 'L3(B)' (i.e., the 700 AERO address of Client ('B')). 702 o the Type is set to 137. 704 o the Code is set to 0 to indicate "Redirect". 706 o the Prefix Length is set to the length of the prefix to be applied 707 to the Target and Destination address. 709 o the Target Address is set to fe80::2001:db8:1:1 (i.e., the AERO 710 address of Client ('D')). 712 o the Destination Address is set to the IPv6 destination address of 713 the packet that triggered the Redirection event. 715 o the message includes a TLLAO set to 'L2(D)' (i.e., the underlying 716 address of Client ('D')). 718 o the message includes as much of the RHO copied from the 719 corresponding AERO Predirect message as possible such that at 720 least the network-layer header is included but the size of the 721 message does not exceed 1280 bytes. 723 After Client ('D') prepares the Redirect message, it sends the 724 message to Server ('A'). 726 3.7.6. Forwarding Redirects 728 When Server ('A') receives a Redirect message, it accepts the message 729 only if it has a neighbor cache entry that associates the message's 730 link-layer source address with the network-layer source address. 731 Next, Server ('A') validates the message according to the ICMPv6 732 Redirect message validation rules in Section 8.1 of [RFC4861]. 734 Following validation, Server ('A') processes the Redirect, and then 735 forwards a corresponding Redirect on to Client ('B') as follows. 737 In the reference operational scenario, Server ('A') receives the 738 Redirect message from Client ('D') and prepares to forward a 739 corresponding Redirect message to Client ('B'). Server ('A') then 740 verifies that Client ('D" is authorized to use the Prefix Length in 741 the Redirect message when applied to the AERO address in the network- 742 layer source of the Redirect message, and it discards the message if 743 verification fails. Otherwise, Server ('A') changes the link-layer 744 source address of the message to 'L2(A)', changes the network-layer 745 source address of the message to fe80::1, and changes the link-layer 746 destination address to 'L2(B)' . Server ('A') finally forwards the 747 message to the ingress node ('B') without decrementing the network- 748 layer IPv6 header Hop Limit field. 750 While not shown in Figure 3, AERO Relays forward Redirect and 751 Predirect messages in exactly this same fashion described above. See 752 Figure 5 in Appendix A for an extension of the reference operational 753 scenario that includes Relays. 755 3.7.7. Processing Redirects 757 When Client ('B') receives the Redirect message, it accepts the 758 message only if it has a link-layer source address of the Server, 759 i.e. 'L2(A)'. Next, Client ('B') validates the message according to 760 the ICMPv6 Redirect message validation rules in Section 8.1 of 761 [RFC4861]. Following validation, Client ('B') then processes the 762 message as follows. 764 In the reference operational scenario, when Client ('B') receives the 765 Redirect message, it either creates or updates a neighbor cache entry 766 that stores the Target Address of the message as the network-layer 767 address of Client ('D') and stores the link-layer address found in 768 the TLLAO as the link-layer address of Client ('D'). Client ('B') 769 then applies the Preflx Length to the Interface Identifier portion of 770 the Target Address and records the resulting IPv6 prefix in its IPv6 771 forwarding table. Client ('B') then marks the forwarding table entry 772 as "FORWARDING", i.e., the entry is to be used by the network layer 773 for forwarding purposes only and not for ingress filtering purposes.. 775 Now, Client ('B') has an IPv6 forwarding table entry for 776 Client('D')'s prefix in the "FORWARDING" state, and Client ('D') has 777 an IPv6 forwarding table entry for Client ('B')'s prefix in the 778 "FILTERING" state. Therefore, Client ('B') may forward ordinary 779 network-layer data packets directly to the egress node ('D') without 780 forwarding through Server ('A'). 782 To enable packet forwarding in the reverse direction, a separate AERO 783 redirection operation is required that is the mirror-image of the 784 forward operation described above but the link segments traversed in 785 the forward and reverse directions may be different, i.e., the 786 operations are asymmetric. 788 3.7.8. Neighbor Reachability Considerations 790 When Client ('B') receives a Redirect message informing it of a 791 direct path to Client ('D'), there is a question in point as to 792 whether Client ('D') can be reached directly without forwarding 793 through Server ('A'). On some AERO links, it may be reasonable for 794 Client ('B') to (optimistically) assume that reachability is 795 transitive, and to immediately begin forwarding data packets to 796 Client ('D') without testing reachability. 798 On AERO links in which an optimistic assumption of transitive 799 reachability may be unreasonable, however, Client ('B') can defer the 800 redirection until it tests the direct path to the egress node ('D'), 801 e.g., by sending an initial NS message to elicit an NA response. If 802 Client ('B') is unable to elicit a response after MAX_RETRY attempts, 803 it should consider the direct path to Client ('D') to be unusable. 805 In still other instances, Client ('B') may connect only to an IPvX 806 underlying network, while Client ('D') connects only to an IPvY 807 underlying network. In that case, Client ('B') has no means for 808 reaching Client ('D') directly (since they connect to underlying 809 networks of different IP protocol versions) and so must ignore any 810 Redirects and continue to send packets via Server ('A'). 812 If a direct path between Client ('B') and Client ('D') can be 813 established, the clients can thereafter process any link-layer errors 814 as a hint that the direct path has either failed or has become 815 intermittent. 817 3.7.9. Neighbor Cache Entry Mainenance 819 While Client ('B') is actively sending packets to Client ('D'), it 820 should also send NS messages (subject to rate limiting) to keep 821 neighbor cache entries alive and to keep link-layer addresses up to 822 date. If Client ('B') ceases to send packets to Client ('D') for 823 longer than the standard neighbor discover reachability timer, it 824 considers Client ('D') as "unreachable". It then deletes the 825 neighbor cache and IPv6 routing table entries, and allows future 826 packets destined to Client (D')'s EUNs to once again flow through 827 Server ('A') (after which it may eventually receive additional 828 Redirects). 830 3.7.10. Mobility and Link-Layer Address Change Considerations 832 When Client ('B') needs to change its link-layer address (e.g., due 833 to a mobility event, due to a change in underlying network interface, 834 etc.), it sends an immediate NS message forward to Client ('D'), 835 which then discovers a new link-layer address. 837 If both Client ('B') and Client ('D') change their link-layer 838 addresses simultaneously, the NS/NA exchanges between the two 839 neighbors may fail. In that case, the Clients follow the same 840 neighbor unreachability procedures specified in Section 3.7.9. 842 4. IANA Considerations 844 There are no IANA actions required for this document. 846 5. Security Considerations 848 AERO link security considerations are the same as for standard IPv6 849 Neighbor Discovery [RFC4861] except that AERO improves on some 850 aspects. In particular, AERO is dependent on a trust basis between 851 AERO Clients and Servers, where the Clients must only engage in the 852 AERO mechanism when it is facilitated by a trusted Server. 854 AERO links must be protected against link-layer address spoofing 855 attacks in which an attacker on the link pretends to be a trusted 856 neighbor. Links that provide link-layer securing mechanisms (e.g., 857 WiFi networks) and links that provide physical security (e.g., 858 enterprise network LANs) provide a first line of defense that is 859 often sufficient. In other instances, securing mechanisms such as 860 Secure Neighbor Discovery (SeND) [RFC3971] or IPsec [RFC4301] must be 861 used. 863 6. Acknowledgements 865 Discussions both on the v6ops list and in private exchanges helped 866 shape some of the concepts in this work. Individuals who contributed 867 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 868 Brian Carpenter, Brian Haberman, Joel Halpern, and Lee Howard. 869 Members of the IESG also provided valuable input during their review 870 process that greatly improved the document. Special thanks go to 871 Stewart Bryant, Joel Halpern and Brian Haberman for their shepherding 872 guidance. 874 Earlier works on NBMA tunneling approaches are found in 876 [RFC2529][RFC5214][RFC5569]. 878 7. References 880 7.1. Normative References 882 [I-D.templin-intarea-seal] 883 Templin, F., "The Subnetwork Encapsulation and Adaptation 884 Layer (SEAL)", draft-templin-intarea-seal-65 (work in 885 progress), October 2013. 887 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 888 August 1980. 890 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 891 September 1981. 893 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 894 RFC 792, September 1981. 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, March 1997. 899 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 900 (IPv6) Specification", RFC 2460, December 1998. 902 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 903 IPv6 Specification", RFC 2473, December 1998. 905 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 906 for IPv6 Hosts and Routers", RFC 4213, October 2005. 908 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 909 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 910 September 2007. 912 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 913 Address Autoconfiguration", RFC 4862, September 2007. 915 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 916 Requirements", RFC 6434, December 2011. 918 7.2. Informative References 920 [IRON] Templin, F., "The Internet Routing Overlay Network 921 (IRON)", Work in Progress, June 2012. 923 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 924 Domains without Explicit Tunnels", RFC 2529, March 1999. 926 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 927 and M. Carney, "Dynamic Host Configuration Protocol for 928 IPv6 (DHCPv6)", RFC 3315, July 2003. 930 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 931 Host Configuration Protocol (DHCP) version 6", RFC 3633, 932 December 2003. 934 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 935 Neighbor Discovery (SEND)", RFC 3971, March 2005. 937 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 938 Internet Protocol", RFC 4301, December 2005. 940 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 941 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 942 March 2008. 944 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 945 Infrastructures (6rd)", RFC 5569, January 2010. 947 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 948 Troan, "Basic Requirements for IPv6 Customer Edge 949 Routers", RFC 6204, April 2011. 951 Appendix A. AERO Server and Relay Interworking 953 Figure 3 depicts a reference AERO operational scenario with a single 954 Server on the AERO link. In order to support scaling to larger 955 numbers of nodes, the AERO link can deploy multiple Servers and 956 Relays, e.g., as shown in Figure 5. 958 .-(::::::::) 959 .-(::: IPv6 :::)-. 960 (:: Internetwork ::) 961 `-(::::::::::::)-' 962 `-(::::::)-' 963 | 964 +--------------+ +------+-------+ +--------------+ 965 |AERO Server C | | AERO Relay D | |AERO Server E | 966 | (default->D) | | (A->C; G->E) | | (default->D) | 967 | (A->B) | +-------+------+ | (G->F) | 968 +-------+------+ | +------+-------+ 969 | | | 970 X---+---+-------------------+------------------+---+---X 971 | AERO Link | 972 +-----+--------+ +--------+-----+ 973 |AERO Client B | |AERO Client F | 974 | (default->C) | | (default->E) | 975 +--------------+ +--------------+ 976 .-. .-. 977 ,-( _)-. ,-( _)-. 978 .-(_ IPv6 )-. .-(_ IPv6 )-. 979 (__ EUN ) (__ EUN ) 980 `-(______)-' `-(______)-' 981 | | 982 +--------+ +--------+ 983 | Host A | | Host G | 984 +--------+ +--------+ 986 Figure 5: AERO Server/Relay Interworking 988 In this example, AERO Client ('B') associates with AERO Server ('C'), 989 while AERO Client ('F') associates with AERO Server ('E'). 990 Furthermore, AERO Servers ('C') and ('E') do not associate with each 991 other directly, but rather have an association with AERO Relay ('D') 992 (i.e., a router that has full topology information concerning its 993 associated Servers and their Clients). Relay ('D') connects to the 994 AERO link, and also connects to the native IPv6 Internetwork. 996 When host ('A') sends a packet toward destination host ('G'), IPv6 997 forwarding directs the packet through the EUN to Client ('B'), which 998 forwards the packet to Server ('C') in absence of more-specific 999 forwarding information. Server ('C') forwards the packet, and it 1000 also generates an AERO Predirect message that is then forwarded 1001 through Relay ('D') to Server ('E'). When Server ('E') receives the 1002 message, it forwards the message to Client ('F'). 1004 After processing the AERO Predirect message, Client ('F') sends an 1005 AERO Redirect message to Server ('E'). Server ('E'), in turn, 1006 forwards the message through Relay ('D') to Server ('C'). When 1007 Server ('C') receives the message, it forwards the message to Client 1008 ('B') informing it that host 'G's EUN can be reached via Client 1009 ('F'), thus completing the AERO redirection. 1011 The network layer routing information shared between Servers and 1012 Relays must be carefully coordinated in a manner outside the scope of 1013 this document. In particular, Relays require full topology 1014 information, while individual Servers only require partial topology 1015 information (i.e., they only need to know the EUN prefixes associated 1016 with their current set of Clients). See [IRON] for an architectural 1017 discussion of routing coordination between Relays and Servers.. 1019 Author's Address 1021 Fred L. Templin (editor) 1022 Boeing Research & Technology 1023 P.O. Box 3707 1024 Seattle, WA 98124 1025 USA 1027 Email: fltemplin@acm.org