idnits 2.17.1 draft-moore-ipv6-optimistic-dad-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 153: '... such, the Optimistic algorithm SHOULD...' RFC 2119 keyword, line 234: '...s 6.3.7) A node MUST NOT send a Route...' RFC 2119 keyword, line 235: '... address. Router Solicitations SHOULD...' RFC 2119 keyword, line 237: '... they MAY be sent from a Tentat...' RFC 2119 keyword, line 240: '...s 7.2.2) A node MUST NOT use a Tentat...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (13 Feb 2004) is 7377 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) -- Missing reference section? 'RFC2119' on line 489 looks like a reference -- Missing reference section? 'RFC2461' on line 498 looks like a reference -- Missing reference section? 'RFC2462' on line 502 looks like a reference -- Missing reference section? 'SOTO' on line 525 looks like a reference -- Missing reference section? 'KOODLI' on line 521 looks like a reference -- Missing reference section? 'RFC2464' on line 506 looks like a reference -- Missing reference section? 'RFC1750' on line 485 looks like a reference -- Missing reference section? 'SEND-CGA' on line 533 looks like a reference -- Missing reference section? 'RFC3041' on line 510 looks like a reference -- Missing reference section? 'RFC2373' on line 494 looks like a reference -- Missing reference section? 'Note 1' on line 474 looks like a reference -- Missing reference section? 'MIPV6' on line 517 looks like a reference -- Missing reference section? 'SEND' on line 529 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group Nick 'Sharkey' Moore 2 INTERNET-DRAFT Monash University CTIE 3 13 Feb 2004 5 Optimistic Duplicate Address Detection 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/lid-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 This document is an individual submission to the IETF. Comments 29 should be directed to the author. 31 Definitions of requirements keywords are in accordance with the IETF 32 Best Current Practice - RFC2119 [RFC2119] 34 Abstract 36 Optimistic DAD is an interoperable modification of the existing IPv6 37 Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration 38 (RFC2462) process. The intention is to minimize address 39 configuration delays in the successful case without greatly 40 increasing disruption in the less likely failure case, and while 41 remaining interoperable with unmodified nodes. 43 Table of Contents 45 Status of this Memo ......................................... 1 46 Abstract .................................................... 1 47 Table of Contents ........................................... 2 48 1. Introduction ............................................. 2 49 1.1 Problem Statement ............................... 3 50 1.2 History ......................................... 3 51 1.3 Definitions ..................................... 4 52 2. Optimistic Behaviours .................................... 4 53 3. Modifications to RFC-compliant behaviour ................. 6 54 3.1 Modifications to RFC 2461 Neighbour Discovery ... 6 55 3.2 Modifications to RFC 2462 SAA ................... 7 56 3.3 Address Generation............................... 7 57 3.4 DIID vs DAD ..................................... 8 58 4. Protocol Operation ....................................... 9 59 4.1 Simple case ..................................... 9 60 4.2 Collision case .................................. 10 61 4.3 Interoperation cases ............................ 11 62 4.4 Pathological cases .............................. 11 63 5. Security Considerations .................................. 11 64 Notes / References .......................................... 12 65 Acknowledgments ............................................. 13 66 Author's Address ............................................ 13 68 1. Introduction 70 Optimistic DAD is a modification of the existing IPv6 Neighbour 71 Discovery [RFC2461] and Stateless Address Autoconfiguration [RFC2462] 72 process. The intention is to minimize address configuration delays 73 in the successful case, and to reduce disruption as far as possible 74 in the failure case. 76 Optimistic DAD is a useful optimization because DAD is far more 77 likely to succeed than fail for a well-distributed random address 78 [SOTO]. Disruption is minimized by limiting nodes' participation in 79 Neighbour Discovery while their addresses are still Tentative, 81 It is not the intention of this draft to improve the security, 82 reliability or robustness of DAD beyond that of existing standards, 83 merely to provide a method to make it faster. 85 1.1 Problem Statement 87 IPv6 ND and SAA processes provide adequate collision detection 88 mechanisms for the static hosts they were designed for. However, 89 they do not provide sufficient speed or flexibility for nodes which 90 need to maintain network access despite frequently moving network 91 attachment. 93 An optimized DAD method needs to: 95 * provide interoperability with nodes using the current standards. 97 * remove the RETRANS_TIMER delay during address configuration. 99 * ensure the probability of address collision is not increased. 101 * improve the resolution mechanisms for address collisions. 103 * minimize disruption in the case of a collision. 105 It is not sufficient to merely reduce RetransTimer in order to reduce 106 the handover delay, as values of RetransTimer large enough to 107 guarantee detection of a collision are large enough to cause 108 disruption to time-critical services. 110 1.2 History 112 There is some precedent for this work in previous drafts [KOODLI], 113 and in discussions in the MobileIP WG mailing list and at IETF-54. 114 This version of Optimistic DAD differs somewhat from previous 115 versions in that it uses no additional flags or message types beyond 116 those already defined, therefore allowing interoperation between 117 Optimistic and Standard nodes. 119 This work was presented by the author at the MobileIP WG at IETF-56. 121 Working implementations of version -02 of this draft have been made 122 by the author as a patch to Linux 2.4.18, and by Ed Remmel of Elmic 123 Systems. 125 1.3 Definitions 127 Tentative - an address for which a node has not completed DAD is 128 regarded as Tentative: a single Neighbour Advertisement 129 defending this address will cause the node to deconfigure the 130 address and cease using it. 132 Optimistic - An Optimistic node assumes that DAD will succeed, and 133 allows higher-layer communications on an address even while that 134 address is still Tentative. 136 Standard - A Standard node is one which is compliant with RFCs 2461 137 and 2462. 139 Link - A communication facility or medium over which nodes can 140 communicate at the link layer. 142 Neighbours - Nodes on the same link, which may therefore be competing 143 for the same addresses. 145 Well-Distributed Address - Address suffixes used for Optimistic DAD 146 should be well distributed, eg: there should be an equal 147 probability of any given suffix occuring. This minimizes the 148 probability of an address collision. 150 2. Optimistic Behaviours 152 Optimistic DAD is only a useful optimisation when the probability of 153 collision is very small. As such, the Optimistic algorithm SHOULD 154 NOT be used for manually assigned addresses, where the collision 155 probability is likely to be much higher than that for random 156 addresses due to human error. 158 Modifications are required only to Optimistic nodes -- Optimistic 159 nodes will interoperate with Standard nodes without significant 160 advantage or incompatibility. 162 In order to do this, it is important that an Optimistic node does 163 not, while Tentative, send any messages which will override its 164 neighbours' Neighbour Cache (NC) entries for the address it is trying 165 to configure: doing so would disrupt the rightful owner of the 166 address in the case of a collision. 168 This is achieved by: 170 * clearing the 'Override' bit in Neighbour Advertisements for 171 Tentative addresses, which prevents neighbours from overriding 172 their existing NC entries. The 'Override' bit is already defined 173 [RFC2461] and used for Proxy Neighbour Advertisement. 175 * Never sending Neighbour Solicitations from a Tentative address. 176 NSs include a Source Link Layer Address Option, which may cause 177 Neighbour Cache disruption. NSs sent as part of DAD are sent 178 from the unspecified address, without a SLLAO. 180 * Never using a Tentative address as the source address of a Router 181 Solicitation with an SLLAO. Another address, or the unspecified 182 address, may be used, or the RS may be send without an SLLAO. 183 An address collision with a router may cause neighbours' 184 IsRouter flags for that address to be cleared, however the RA 185 sent in reponse will reset the IsRouter flag. 187 It may be desirable for a Neighbour, for example the router, to 188 rapidly establish communication with the newly configured ON. To 189 do so, it must learn of the ON's arrival as soon as possible. 190 To avoid having to wait for Neighbour Discovery, the ON may wish 191 to send unsolicited Neighbour Advertisements (with Override set 192 appropriately), but for this to be effective the Neighbour must 193 either: 195 * be expecting the ON to arrive (eg: due to predictive mechanisms), 196 and thus already have a NC entry for the peer, in state 197 INCOMPLETE. 199 * be willing to cache unsolicited NAs (for a short period of time), 200 so that an entry will have been created with state STALE. 202 however, these modifications are beyond the scope of this draft. 204 The ON may choose to send unsolicited NAs to the All Nodes Multicast, 205 to the All Routers Multicast, or Unicast to the source of the RA 206 which alerted it to this new prefix. This allows flexibility with 207 regard to Layer 2 multicast transmission costs. 209 The case where the ON wants to contact its router is handled by the 210 SLLAO of the RA, where this is supplied. However, the router may 211 choose not to include the SLLAO (the example given in RFC2462 is "to 212 facilitate in-bound load balancing over replicated interfaces"). In 213 this case, the ON cannot discover its router until it is no longer 214 Tentative. Routers which do not include the SLLAO are not especially 215 suitable for use with Optimistic DAD. 217 When the MN wants to contact another neighbour, but it cannot because 218 the neighbour is not in the NC, it should instead forward the packet 219 to the router, relying on the router to forward the packet. The 220 router should then provide the MN with a ICMP redirect, which may 221 include a Target Link Layer Address Option (TLLAO). If it does, this 222 will update the ON's NC, and direct communication can begin. 224 Because Optimistic DAD allows nodes to communicate despite being 225 Tentative, RetransTimer may be left at the default 1000ms without 226 significant penalty. It is also possible to increase 227 DupAddrDetectTransmits and thus reduce the probability of an 228 undetected address collision due to packet loss. 230 3. Modifications to RFC-mandated behaviour 232 3.1 Modifications to RFC 2461 Neighbour Discovery 234 * (modifies 6.3.7) A node MUST NOT send a Router Solicitation with 235 an SLLAO from a Tentative address. Router Solicitations SHOULD 236 be sent from a non-Tentative or the Unspecified address, however 237 they MAY be sent from a Tentative address as long as the SLLAO 238 is not included. 240 * (modifies 7.2.2) A node MUST NOT use a Tentative address as the 241 source address of a Neighbour Solicitation. 243 * (modfies 7.2.2) When a node has a unicast packet to send from a 244 Tentative address to a neighbour, but does not know the 245 neighbour's link-layer address, it MUST NOT perform Neighbour 246 Discovery but instead SHOULD forward the packet to the router of 247 that network. 249 * (adds to 7.2.6) The Optimistic node MAY send an unsolicited 250 Neighbour Advertisement to All Nodes when it first configures an 251 address. The Override flag on this advertisement MUST be set to 252 0. 254 * (adds to 7.2.6) The Optimistic node SHOULD send an unsolicited NA 255 to All Nodes when it completes DAD. The Override flag on this 256 advertisement SHOULD be set to 1. 258 3.2 Modifications to RFC 2462 Stateless Address Autoconfiguration 260 * (modifies 5.5) If an initial suffix is not supplied, a new suffix 261 SHOULD be generated as per "Address Generation" below. 263 * (modifies 5.4) As soon as the initial Neighbour Solicitation (and 264 optional unsolicited Neighbour Advertisement) is sent, the 265 address is configured on the interface and available for use 266 immediately. 268 * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for 269 its address from the unspecified address with a Neighbour 270 Advertisement to the All Nodes address. If the solicitation is 271 for an address which is still Tentative, the reply MUST have the 272 Override flag set to 0. 274 * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for 275 its address from a unicast address, even while Tentative, but 276 the reply MUST have the Override flag set to 0. 278 * (modifies 5.4.5) A Tentative address that is determined to be a 279 duplicate MUST be deconfigured immediately. If the address is a 280 link-local address formed from a fixed interface identifier, the 281 interface SHOULD be disabled. Otherwise, if the address was 282 automatically configured, DAD SHOULD be restarted with a new 283 address generated as per "Address Generation" below. 285 * DupAddrDetectTransmits SHOULD be increased where there is a 286 significant probability of packet loss. 288 3.3 Address Generation 290 In order for Optimistic DAD to be a useful optimization, the 291 probability of a collision must be very small, as a collision may 292 cause temporary disruption to the collidee, and will require the 293 collidor to reconfigure. 295 Some interfaces (for example, Ethernet [RFC2464]) offer methods to 296 create an address based on a globally unique Interface Identifier, 297 however it is conceivable that due to manufacturer or user error that 298 the generated address may not in fact be unique. 300 * The Optimistic algorithm SHOULD NOT be used on manually configured 301 addresses, as the probability of collision for manually 302 configured addresses is considerably higher than for other 303 methods. 305 * If the interface offers a method to create a supposedly globally 306 unique IPv6 address, this address MAY be used for the initial 307 attempt. 309 * Otherwise, or when creating a new address in the case of a 310 collision, a well-distributed suffix MUST be chosen. 312 + The suffix MAY be chosen using a well-distributed random 313 algorithm (see [RFC1750] for more information on random 314 number generation), 316 + The suffix MAY be derived from a well-distributed hash 317 function, as in [SEND-CGA]. 319 + The algorithm used MAY be one of those documented in 320 [RFC3041]. 322 * A randomly generated address SHOULD have the Universal/Local bit 323 and the Individual/Group bit set to 0 to indicate a not globally 324 unique Unicast address (see [RFC2373]). 326 * In order to minimize the effect of DoS attacks, a delay of at least 327 RETRANS_TIMER (as used in [RFC2461]) milliseconds MUST be 328 introduced between attempts if DAD has already failed more than 329 once. An exponential backoff SHOULD be used. 331 3.4 DAD vs DIID 333 Existing standards assume that addresses are generated from 334 unchanging Interface Identifiers, and thus RFC 2462 states: 336 [5.4] Each individual unicast address SHOULD be tested for 337 uniqueness. However, when stateless address autoconfiguration 338 is used, address uniqueness is determined solely by the 339 interface identifier [...] Thus, for a set of addresses formed 340 from the same interface identifier, it is sufficient to check 341 that the link- local address generated from the identifier is 342 unique on the link. 344 However, this approach (generally referred to as 'DIID') has fallen 345 from favour in recent years, in favour of checking individual 346 addresses. In order to minimize the probability of an undetected 347 address collision, it would seem prudent to always configure and 348 check the link-local address for any given suffix as well as checking 349 the actual address being configured. 351 4. Protocol Operation 353 The following cases all consider an Optimistic Node (ON) receiving a 354 Router Advertisement containing a new prefix and deciding to 355 autoconfigure a new address on that prefix. 357 The following cases assume that the RA contains a LLAO. The router 358 "MAY omit this option in order to enable inbound load sharing" 359 [RFC2461 4.2], however, and in this case the ON will be unable to 360 contact the router until the address is no longer Tentative. 362 The ON will immediately send out a Neighbour Solicitation to 363 determine if its new address is already in use, and a Neighbour 364 Advertisement (with Override set to 0) for the address. This NA 365 allows communication with neighbours to begin immediately. 367 4.1 Simple case 369 In the non-collision case, the address being configured by the new 370 node is unused and not present in the Neighbour Caches of any of its 371 neighbours. 373 Therefore, there will be no response to its NS, and the NA with O=0 374 will be sufficient to create Neighbour Cache entries in already 375 interested neighbours. 377 The Optimistic Node already has the link-layer address of the router 378 (from the RA), and the router either already knows the link-layer 379 address of the ON from the unsolicited NA, or can determine it 380 through standard NUD. Communicatations can begin as soon as the 381 router and the ON have each others' link-layer addresses. 383 After the appropriate DAD delay, the address is marked as non- 384 Tentative, and another NA is sent, this time with O=1. This will 385 ensure that all Neighbour Caches are up-to-date. 387 4.2 Collision cases 389 In the simplest collision case, the address being configured by the 390 new node is already in use by another node, and present in the 391 Neighbour Caches (NCs) of neighbours which are communicating with 392 this node. 394 Since the Optimistic advertisement has O=0, it will not override 395 existing NC entries. An NA with O=0,S=0 and no LLAO may [Note 1], 396 however cause the NC entry to be set to STALE, causing NUD to be 397 performed on the address. 399 Nodes with no interest in communicating with the new address "SHOULD" 400 silently discard the NA [RFC2461 7.2.5], and so will likely be 401 undisturbed. 403 If a neighbour is just preparing to begin communication with the 404 address, eg: it has a NC entry for the address in state 'INCOMPLETE', 405 the optimistic advertisement may cause an incorrect NC entry to be 406 created in state 'STALE' and queued packets to be sent to an 407 incorrect destination. 409 In general, the defending NA will have Override set to 1, and so this 410 will correct the incorrect entry almost immediately. However, if the 411 defending NA has Override set to 0 (for example when the address is 412 in use by proxy) the defending advertisement will not override this 413 incorrect NC entry. In any case, the NC entry will remain in state 414 'STALE', and thus the disruption will be recoverable, albeit slowly, 415 by the standard Neighbour Unreachability Detection mechanism. 417 Of course, in the meantime the ON may have sent packets which 418 identify it as the owner of its new Tentative address (for example, 419 Binding Updates in [MIPV6]). This may incur some penalty to the ON, 420 in the form of broken connections, and some penalty to the rightful 421 owner of the address, since it will receive (and potentially reply 422 to) the misdirected packets. It is for this reason that Optimistic 423 DAD should only be used where the probability of collision is 424 exceedingly low. 426 4.3 Interoperation cases 428 Once the Optimistic Node has completed DAD, it acts exactly like a 429 Standard node, and so interoperation cases only arise while an 430 Optimistic Node is Tentative. 432 If an Optimistic Node attempts to configure an address currently 433 Tentatively assigned to a Standard Node, the Standard Node will see 434 the Neighbour Solicitation and deconfigure the address. In contrast, 435 if a node attempts to configure an address currently Tentatively 436 assigned to an Optimistic Node, the Optimistic Node will not 437 deconfigure the address, and instead defend with a Neighbour 438 Advertisement, causing the newcomer to reconfigure. This gives the 439 Optimistic Node a slight advantage over Standard nodes, however this 440 is justified since the Optimistic node may have already established 441 connections while Tentative. 443 4.4 Pathological cases 445 Optimistic DAD suffers from similar problems to Standard DAD, for 446 example duplicates are not guaranteed to be detected if packets are 447 lost, and if two nodes configure simultaneously, they may each miss 448 the other's NS. 450 These problems exist, and are not gracefully recoverable, in Standard 451 DAD. The probability of such a collision is reduced in Optimistic DAD 452 due to the pair of messages (NS, NA) sent. The probability can be 453 further reduced by increasing the RFC2462 DupAddrDetectTransmits 454 variable to greater than 1. 456 This version of Optimistic DAD is dependant on the details of the 457 router behaviour, eg: if it includes SLLAOs in RAs, and if it is 458 willing to redirect traffic for the ON. Where the router does not 459 behave in this way, the behaviour of Optimistic DAD reverts to that 460 of Standard DAD. 462 5. Security Considerations 464 There are existing security concerns with Neighbour Discovery and 465 Stateless Address Autoconfiguration, and this draft does not purport 466 to fix them. However, this draft does not significantly increase 467 security concerns either. 469 Further work will be required to integrate Optimistic DAD with Secure 470 Neighbour Discovery [SEND]. 472 Notes 474 [Note 1] RFC 2461 is unclear on this, with [RFC2461 7.2.5] specifying 475 "the advertisement prompts future Neighbour Unreachability 476 Detection [...] by changing the state in the cache entry" 477 whereas [RFC2461 Appendix C] specifies the state as "unchanged". 478 Many arguments have been made on the list (see 479 ) 480 for one interpretation or the other. For the purposes of this 481 draft, I have assumed that either behaviour is possible. 483 RFC References 485 [RFC1750] D. Eastlake, S. Crocker, J. Schiller. "Randomness 486 Recommendation for Security." Request for Comments 1750, 487 Internet Engineering Task Force, December 1994. 489 [RFC2119] S. Bradner. "Key words for use in RFCs to Indicate 490 Requirement Levels." Request for Comments (Best Current 491 Practice) 2119 (BCP 14), Internet Engineering Task Force, March 492 1997. 494 [RFC2373] R. Hinden, S. Deering. "IP Version 6 Addressing 495 Architecture." Request for Comments (Proposed Standard) 2373, 496 Internet Engineering Task Force, July 1998. 498 [RFC2461] T. Narten, E.Nordmark, W. Simpson. "Neighbor Discovery for 499 IP Version 6 (IPv6)." Request for Comments (Draft Standard) 500 2461, Internet Engineering Task Force, December 1998. 502 [RFC2462] S. Thomson, T. Narten. "IPv6 Stateless Address 503 Autoconfiguration." Request for Comments (Draft Standard) 2462, 504 Internet Engineering Task Force, December 1998. 506 [RFC2464] M. Crawford. "Transmission of IPv6 Packets over Ethernet 507 Networks." Request for Comments (Proposed Standard) 2464, 508 Internet Engineering Task Force, December 1998. 510 [RFC3041] T. Narten, R. Draves. "Privacy Extensions for Stateless 511 Address Autoconfiguration in IPv6." Request for Comments 512 (Proposed Standard) 3041, Internet Engineering Task Force, 513 January 2001. 515 Internet Draft References 517 [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6, 518 revision 24 (draft-ietf-mobileip-ipv6-24). June 2003 ... 519 Expired December 2003. 521 [KOODLI] R. Koodli, C. Perkins. Fast Handovers in Mobile IPv6, 522 revision 00 (draft-koodli-mobileip-fastv6-00). October 2000 ... 523 Expired April 2001. 525 [SOTO] M. Bagnulo, I. Soto, A. Garcia-Martinez, A. Azcorra. Random 526 generation of interface identifiers, revision 00. (draft-soto- 527 mobileip-random-iids-00). January 2002 ... Expired July 2002. 529 [SEND] J. Arkko, J. Kempf, B. Sommerfeld, B.Zill, P. Nikander. 530 SEcure Neighbor Discovery (SEND), revision 03. (draft-ietf- 531 send-ndopt-03). January 2004 ... Expires July 2004. 533 [SEND-CGA] T. Aura, Cryptographically Generated Addresses (CGA), 534 revision 01. (draft-ietf-send-cga-01). August 1, 2003. 536 Acknowledgments 538 Thanks to Greg Daley, Brett Pentland and Richard Nelson at CTIE for 539 their feedback and encouragement. More information is available at 540 . 542 Thanks to all the MobileIP and IPng WG members who contributed to the 543 debate. 545 This work has been supported by the Australian Telecommunications 546 Cooperative Research Centre (AT-CRC) 547 549 Author's Address: 551 Nick 'Sharkey' Moore 552 or 553 Centre for Telecommunications and Information Engineering 554 Monash University 3800 555 Victoria, Australia