idnits 2.17.1 draft-templin-autoconf-dhcp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 566. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2006) is 6335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.thaler-autoconf-multisubnet-manets' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'I-D.thaler-intarea-multilink-subnet-issues' is defined on line 410, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-03 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft S. Russert 4 Intended status: Informational I. Chakeres 5 Expires: June 18, 2007 S. Yi 6 Boeing Phantom Works 7 December 15, 2006 9 MANET Autoconfiguration 10 draft-templin-autoconf-dhcp-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 18, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Mobile Ad-hoc Networks (MANETs) comprise asymmetric reachability link 44 types that connect MANET routers, and connect to the global Internet 45 via zero or more MANET gateways. MANET routers with nodes on 46 downstream-attached links that require global Internet access must 47 have a way to automatically provision globally routable and unique IP 48 addresses/prefixes. This document specifies mechanisms for MANET 49 autoconfiguration (AUTOCONF). Solutions for both IPv4 and IPv6 are 50 given. 52 1. Introduction 54 Mobile Ad-hoc Networks (MANETs) comprise asymmetric reachability link 55 types ([RFC2461], Section 2.2) that connect MANET Routers (MRs). MRs 56 participate in a routing protocol such that packets can be forwarded 57 via multiple hops across the MANET if necessary. MANETs attach to 58 provider networks (and/or the global Internet) via zero or more MANET 59 Gateways (MGs), and MRs may be multiple IP hops away from their 60 nearest MG in some scenarios. MRs with nodes on downstream-attached 61 links that require global Internet access must have a means to 62 delegate global IP addresses/prefixes and/or other configuration 63 information. 65 MRs comprise a router entity and a host entity that are connected via 66 a virtual point-to-point VLAN configured over an imaginary shared 67 link for the MANET (e.g., via a loopback interface). The imaginary 68 shared link provides the appearance of a fully-connected link to 69 which all MRs attach, and has an associated "landmark" prefix that 70 MRs can use to identify the MANET(s) to which they attach. An MR 71 (and its downstream-attached links) is a "site" unto itself, and a 72 MANET is therefore a "site-of-sites". 74 MANETs that comprise homogeneous link types can configure the routing 75 protocol to operate as a Layer-2 mechanism such that Layer-3 (i.e., 76 IP) sees the MANET as a non-broadcast, multiple access (NBMA) link. 77 When a Layer-2 broadcast/multicast flooding mechanism is also used, 78 IP sees the MANET as an ordinary shared link, i.e., the same as for a 79 (bridged) campus LAN. In that case, a single IP hop is sufficient to 80 traverse the MANET. 82 MANETs that comprise heterogeneous link types must configure the 83 routing protocol to operate as a Layer-3 mechanism such that routing 84 protocol operation and packet forwarding are based on Layer-3 MANET- 85 Local Addresses (MLAs) to avoid issues associated with bridging media 86 types with dissimilar Layer-2 address formats and maximum 87 transmission units (MTUs). In that case, multiple IP hops may be 88 necessary to traverse the MANET. 90 This document specifies DHCP and neighbor discovery operation for 91 MANET autoconfiguration as well as details of operation for multiple 92 MGs. Operation using standard BOOTP/DHCP 93 [RFC0951][RFC2131][RFC3315][RFC3633] and neighbor discovery 94 [RFC0826][RFC1256][RFC2461][RFC2462] mechanisms is assumed unless 95 otherwise specified. Solutions for both IPv4 [RFC0791] and IPv6 97 [RFC2460] are given. 99 2. Terminology 101 The terminology in the normative references apply; the following 102 terms are defined within the scope of this document: 104 Mobile Ad-hoc Network (MANET) 105 a connected network region that comprises MANET routers that 106 maintain a routing structure among themselves in a relatively 107 arbitrary fashion over asymmetric reachability link types 108 ([RFC2461], Section 2.2). Further information on the 109 characteristics of MANETs can be found in [RFC2501]. 111 MANET Interface 112 a MANET router's attachment to a link within the MANET. 114 MANET Router (MR) 115 a node that participates in a routing protocol over its MANET 116 interface(s), connects its downstream-attached links to the MANET 117 and forwards packets on behalf of other MRs. An MR comprises a 118 router entity and a host entity that communicate via a virtual 119 point-to-point VLAN configured over an imaginary shared link for 120 the MANET (e.g., via a loopback interface). An MR (and its 121 downstream-attached links) is a "site" unto itself, and a MANET is 122 therefore a "site-of-sites". For the purpose of this 123 specification, an MR's host entity configures a DHCP client and 124 its router entity configures a DHCP relay. 126 landmark prefix 127 an IP prefix associated with the imaginary shared link that 128 connects MRs in a MANET; used by MRs to identify their current 129 MANET point(s) of attachment and as an identifier for the virtual 130 interface(s) configured over the imaginary link. 132 MANET Gateway (MG) 133 an MR that also provides gateway service to a provider network 134 and/or the global Internet. For the purpose of this 135 specification, MGs configure a DHCP relay and/or a DHCP server. 137 MANET Local Address (MLA) 138 a Layer-3 unicast address/prefix configured by an MR that is used 139 for intra-MANET communications, i.e., routable only within the 140 scope of the MANET. For IPv6, Unique Local Addresses (ULAs) 141 [RFC4193][I-D.jelger-autoconf-mla] provide a natural MLA 142 mechanism. 144 Extended Router Advertisement/Solicitation (ERA/ERS) 145 an IP Router Advertisement/Solicitation (RA/RS) message [RFC1256] 146 [RFC2461] with an MLA source address and with destination address 147 set to an MLA or a site-scoped multicast address that spans the 148 MANET via a broadcast/multicast flooding mechanism (see: 149 Section 3.5). Unlike ordinary RA/RS messages, ERA/ERS messages 150 may travel multiple IP hops. 152 3. MANET Autoconfiguration 154 The following sections specify autoconfiguration operation for 155 MANETs. In-scope for this specification are "stub" MANETs with zero 156 or more gateways that connect either to the same provider network or 157 to the public Internet using provider-independent addressing. The 158 mechanisms in this specification are also necessary (but may not be 159 sufficient) for supporting multihomed MANETs, MANETs configured as 160 transit networks, default MG selection, etc. 162 3.1. MANET Router (MR) Operation 164 Each MR configures one or more MLAs on each of its MANET interfaces. 165 For IPv6, MLAs are generated using [RFC4193][I-D.jelger-autoconf-mla] 166 with interface identifiers that are either managed for uniqueness 167 ([RFC4291], Appendix A) or self-generated using a suitable random 168 interface identifier generation mechanism that is compatible with 169 EUI-64 format, e.g., Cryptographically Generated Addresses (CGAs) 170 [RFC3972]. For IPv4, MLAs are generated using a corresponding unique 171 local address configuration mechanism. 173 Each MR next engages in the routing protocol then discovers the MLAs 174 of MGs and a landmark prefix for the MANET's imaginary shared link by 175 either receiving ERAs or through a means outside the scope of this 176 specification, e.g., via an out-of-band service discovery protocol, 177 via information conveyed in the routing protocol itself, etc. MRs 178 can also send a small number of ERSs to elicit immediate ERAs if no 179 unsolicited ERAs are received. 181 After a MR discovers the MLAs of MGs, it selects one or more MGs as 182 default MGs. The MR's DHCP client function then sends a DHCP 183 DISCOVER (DHCPv4) or Solicit (DHCPv6) request to its DHCP relay 184 function across the virtual interface that connects its host and 185 router functions. The relay function then forwards the request to 186 the MLA(s) for one or more MG, to the MLAs of other known DHCP 187 servers within the MANET, or to a site-scoped "All-DHCP-Servers" 188 multicast address. 190 For DHCPv4, the relay writes an MLA from the outgoing MANET interface 191 (i.e., the relay's upstream-attached interface) in the 'giaddr' field 192 and also includes the MLA in a DHCPv4 MLA option (see: Section 3.4). 193 If necessary to identify the downstream-attached virtual interface, 194 the relay also includes a link selection sub-option [RFC3527] with an 195 address from the landmark prefix for the MANET's imaginary shared 196 link. 198 For DHCPv6, the relay writes an MLA from the outgoing MANET interface 199 in the "peer-address" field and also writes an address from the 200 landmark prefix for the MANET's imaginary shared link in the "link- 201 address" field. The MR can also use DHCP prefix delegation [RFC3633] 202 to obtain prefixes for further sub-delegation to nodes on its 203 downstream-attached links. 205 The DHCP request will elicit a DHCP reply from a server with IP 206 address/prefix delegations. When addresses are delegated, the MR 207 assigns the resulting addresses to the virtual interface that 208 connects its host and router functions, i.e., the addresses are *not* 209 assigned on a MANET interface. When prefixes are delegated, the MR 210 can further sub-delegate the prefixes to its downstream-attached 211 links, including physical links and virtual links of the MR itself. 213 After the MR configures global IP addresses/prefixes, it can send IP 214 packets with global IP source addresses to off-MANET destinations 215 using any of the MGs in its default MG list as egress gateways. For 216 MANETs in which MGs can inject a 'default' route that propagates 217 throughout the MANET, the MR can send the IP packets without 218 encapsulation at the expense of extra TTL (IPv4) or Hop Limit (IPv6) 219 decrementation. For MANETs in which MGs cannot propagate a default 220 route, the MR either: a) encapsulates IP packets with an MLA for an 221 MG as the destination address in the outer header (i.e., tunnels the 222 packets to the MG), or b) inserts an IPv4 source routing header 223 (likewise IPv6 routing header) to ensure that the packets will be 224 forwarded through an MG. 226 3.2. MANET Gateway Operation 228 MGs send periodic and/or solicited ERAs on their attached MANET 229 links. For IPv6, MGs advertise prefixes in ERAs that are to be used 230 as landmark prefixes for the MANET (e.g., by setting the 'A', 'L' 231 bits in Prefix Information Options to 0). 233 MGs act as BOOTP/DHCP relays for the DHCP requests/replies exchanged 234 between MRs and DHCP servers. (When the DHCP server function resides 235 on the MG itself, the MG acts as a DHCP server.) For DHCPv4, when a 236 MG acting as a relay forwards a MR's DHCP request that includes an 237 MLA option, it writes its own address in the 'giaddr' field, i.e., it 238 overwrites the value that was written into 'giaddr' by the MR's relay 239 function. 241 For each DHCP reply message it processes pertaining to address/prefix 242 delegation, the MG creates a tunnel (if necessary) with the tunnel's 243 destination address set to the MLA for the MR encoded in the DHCPv4 244 MLA option or the DHCPv6 "peer-address" field (see: Section 3.4). 245 The MG then creates entries in its IP forwarding table that point to 246 the tunnel for each delegated IP address/prefix and relays the reply 247 to the MLA for the MR. For MANETs in which MRs will inject delegated 248 addresses/prefixes into the routing protocol, tunneling from the MG 249 is not necessary since standard IP routing within the MANET will 250 direct packets to the correct MR. 252 3.3. DHCP Server Deployments and Extensions 254 DHCP servers can reside on provider networks, the Internet or on the 255 MGs themselves; they can also reside on some non-MG node within the 256 MANET. 258 DHCPv4 servers examine DHCPv4 requests for a DHCPv4 MLA option (see: 259 Section 3.4). If a DHCPv4 MLA option is present, the DHCPv4 server 260 copies the option into the corresponding DHCPv4 reply message(s). 262 No MANET-specific extensions are required for DHCPv6 servers. 264 3.4. MLA Encapsulation 266 For DHCPv6, the MLA is encoded directly in the "peer-address" field 267 of DHCPv6 requests/replies. 269 For DHCPv4, a new DHCPv4 option [RFC2132] called the 'MLA option' is 270 required to encode an MLA for DHCP transactions that will traverse a 271 MG, i.e., so that the MG has a MANET-relevant address to direct 272 DHCPv4 replies to the correct MR, which may be multiple Layer-3 hops 273 away. The format of the DHCPv4 MLA option is given below: 275 Code Len Ether Type MLA 276 +-----+-----+-----+-----+-----+-----+--- 277 | TBD | n | type | a1 | a2 | ... 278 +-----+-----+-----+-----+-----+-----+--- 280 Code 281 a one-octet field that identifies the option type (see: 282 Section 5). 284 Len 285 a one-octet field that encodes the remaining option length. 287 Ether Type 288 a type value from the IANA "ethernet-numbers" registry. 290 MLA 291 a variable-length MANET Local Address (MLA). 293 3.5. MANET Flooding 295 MRs and MGs in Layer-3 MANETs that implement this specification 296 require a MANET flooding mechanism (e.g., Simplified Multicast 297 Forwarding (SMF) [I-D.ietf-manet-smf]) so that site-scoped multicast 298 messages can be propagated across multiple Layer-3 hops. 300 4. Operation with Multiple MGs 302 MGs are associated with landmark prefixes that identify the MANET's 303 point of attachment to a provider network. For a set of MGs that 304 attach to the same provider network, MRs can retain their global IP 305 address/prefix delegations as they move between different MGs if the 306 landmark prefix stays the same and if the network participates with 307 the MGs and MRs in a localized mobility management scheme, e.g., see: 308 [I-D.templin-autoconf-netlmm-dhcp]. 310 For a set of MGs that attach to different provider networks and/or 311 serve different global IP prefixes from within the same provider 312 network, MRs must configure new global IP addresses/prefixes as they 313 change between different MGs unless inter-MG tunnels and routing 314 protocol exchanges are supported, e.g., see: 315 [I-D.templin-autoconf-netlmm-dhcp], Appendix A. 317 Global mobility management mechanisms for MRs that configure new 318 global IP addresses/prefixes as they move between different MGs are 319 beyond the scope of this document. 321 5. IANA Considerations 323 A new DHCP option code is requested for the DHCP MLA Option in the 324 IANA "bootp-dhcp-parameters" registry. 326 6. Security Considerations 328 Threats relating to MANET routing protocols also apply to this 329 document. 331 7. Related Work 333 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 334 program. Various proposals targeted for the IETF AUTOCONF working 335 group have suggested stateless mechanisms for address configuration. 337 8. Acknowledgements 339 The Naval Research Lab (NRL) Information Technology Division uses 340 DHCP in their MANET research testbeds. Many of the ideas on this 341 document originated from IETF Autoconf working group discussions on 342 various aspects of autoconfiguration for MANETs. 344 The following individuals (in chronological order) have provided 345 valuable input: Thomas Henderson. 347 9. References 349 9.1. Normative References 351 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 352 September 1981. 354 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 355 converting network protocol addresses to 48.bit Ethernet 356 address for transmission on Ethernet hardware", STD 37, 357 RFC 826, November 1982. 359 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 360 September 1985. 362 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 363 September 1991. 365 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 366 RFC 2131, March 1997. 368 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 369 Extensions", RFC 2132, March 1997. 371 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 372 (IPv6) Specification", RFC 2460, December 1998. 374 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 375 Discovery for IP Version 6 (IPv6)", RFC 2461, 376 December 1998. 378 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 379 Autoconfiguration", RFC 2462, December 1998. 381 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 382 and M. Carney, "Dynamic Host Configuration Protocol for 383 IPv6 (DHCPv6)", RFC 3315, July 2003. 385 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 386 Host Configuration Protocol (DHCP) version 6", RFC 3633, 387 December 2003. 389 9.2. Informative References 391 [I-D.ietf-manet-smf] 392 Macker, J., "Simplified Multicast Forwarding for MANET", 393 draft-ietf-manet-smf-03 (work in progress), October 2006. 395 [I-D.jelger-autoconf-mla] 396 Jelger, C., "MANET Local IPv6 Addresses", 397 draft-jelger-autoconf-mla-01 (work in progress), 398 October 2006. 400 [I-D.templin-autoconf-netlmm-dhcp] 401 Templin, F., "Network Localized Mobility Management using 402 DHCP", draft-templin-autoconf-netlmm-dhcp-04 (work in 403 progress), October 2006. 405 [I-D.thaler-autoconf-multisubnet-manets] 406 Thaler, D., "Multi-Subnet MANETs", 407 draft-thaler-autoconf-multisubnet-manets-00 (work in 408 progress), February 2006. 410 [I-D.thaler-intarea-multilink-subnet-issues] 411 Thaler, D., "Issues With Protocols Proposing Multilink 412 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 413 (work in progress), March 2006. 415 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 416 (MANET): Routing Protocol Performance Issues and 417 Evaluation Considerations", RFC 2501, January 1999. 419 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 420 "Link Selection sub-option for the Relay Agent Information 421 Option for DHCPv4", RFC 3527, April 2003. 423 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 424 RFC 3972, March 2005. 426 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 427 Addresses", RFC 4193, October 2005. 429 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 430 Architecture", RFC 4291, February 2006. 432 Appendix A. IPv6 Neighbor Discovery and Duplicate Address Detection 434 IPv6 Neighbor Discovery (ND) and Duplicate Address Detection (DAD) 435 for MANETs is for further study. In terms of ND, [RFC2461][RFC4291] 436 require that a node configure a link-local address on each of its 437 IPv6-enabled interfaces, but the primary use for link-locals seems to 438 be for the purpose of uniquely identifying routers on the link. 439 Also, it is an open question as to whether MRs should send RAs on 440 MANET links at all, since the MANET is a peering point between 441 distinct sites and not the link of a single site with a clear set of 442 serving routers and dependent end-hosts. In particular, since MANET 443 interfaces configure MLAs which already provide a statistically- 444 unique identifier, link-local addresses may be of little/no value on 445 MANET interfaces and hence strict enforcement of link-local address 446 uniqueness may not be necessary. 448 In terms of DAD, in-service DAD upon link change is problematic, 449 since MANET links are constantly changing due to node mobility. 450 Also, pre-service DAD on a MANET link would require either flooding 451 the entire MANET or somehow discovering a targeted region of the 452 MANET on which a node that configures a duplicate address resides and 453 sending a directed DAD message toward that region. In both 454 instances, the overhead for performing DAD is substantial and prone 455 to false-negatives due to packet loss. Note also that link-local 456 addresses using Cryptographically Generated Addresses (CGAs) 457 [RFC3972] provide random generation only in 59 bits of the lower 64 458 bits of the IPv6 address, while MLAs using CGAs also use 40/56 bits 459 of random generation in the upper 64 bits of the IPv6 address. Since 460 such MLAs are highly unlikely to collide, pre-service DAD and in- 461 service DAD based on link change can be avoided and a passive DAD, 462 e.g., one that monitors routing protocol messages, can be used 463 instead. 465 Note also that no DAD is required for the global addresses/prefixes 466 delegated to MRs as long as the addresses are configured on the MR's 467 downstream-attached links (and not the MANET link) and as long as 468 standard DAD procedures are observed on the downstream-attached links 469 themselves. 471 Appendix B. Change Log 473 Changes from -02 to -03: 475 o updated terminology based on RFC2461 "asymmetric reachability" 476 link type; IETF67 MANET Autoconf wg discussions. 478 o added new appendix on IPv6 Neighbor Discovery and Duplicate 479 Address Detection 481 o relaxed DHCP server deployment considerations allow DHCP servers 482 within the MANET itself 484 Changes from -01 to -02: 486 o minor updates for consistency with recent developments 488 Changes from -00 to -01: 490 o new text on DHCPv6 prefix delegation and multilink subnet 491 considerations. 493 o various editorial changes 495 Authors' Addresses 497 Fred L. Templin 498 Boeing Phantom Works 499 P.O. Box 3707 MC 7L-49 500 Seattle, WA 98124 501 USA 503 Email: fred.l.templin@boeing.com 505 Steven W. Russert 506 Boeing Phantom Works 507 P.O. Box 3707 MC 7L-49 508 Seattle, WA 98124 509 USA 511 Email: steven.w.russert@boeing.com 512 Ian D. Chakeres 513 Boeing Phantom Works 514 P.O. Box 3707 MC 7L-49 515 Seattle, WA 98124 516 USA 518 Email: ian.chakeres@gmail.com 520 Seung Yi 521 Boeing Phantom Works 522 P.O. Box 3707 MC 7L-49 523 Seattle, WA 98124 524 USA 526 Email: seung.yi@boeing.com 528 Full Copyright Statement 530 Copyright (C) The Internet Society (2006). 532 This document is subject to the rights, licenses and restrictions 533 contained in BCP 78, and except as set forth therein, the authors 534 retain all their rights. 536 This document and the information contained herein are provided on an 537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 539 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 540 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 541 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 Intellectual Property 546 The IETF takes no position regarding the validity or scope of any 547 Intellectual Property Rights or other rights that might be claimed to 548 pertain to the implementation or use of the technology described in 549 this document or the extent to which any license under such rights 550 might or might not be available; nor does it represent that it has 551 made any independent effort to identify any such rights. Information 552 on the procedures with respect to rights in RFC documents can be 553 found in BCP 78 and BCP 79. 555 Copies of IPR disclosures made to the IETF Secretariat and any 556 assurances of licenses to be made available, or the result of an 557 attempt made to obtain a general license or permission for the use of 558 such proprietary rights by implementers or users of this 559 specification can be obtained from the IETF on-line IPR repository at 560 http://www.ietf.org/ipr. 562 The IETF invites any interested party to bring to its attention any 563 copyrights, patents or patent applications, or other proprietary 564 rights that may cover technology that may be required to implement 565 this standard. Please address the information to the IETF at 566 ietf-ipr@ietf.org. 568 Acknowledgment 570 Funding for the RFC Editor function is provided by the IETF 571 Administrative Support Activity (IASA).