idnits 2.17.1 draft-ietf-dna-link-information-00.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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 551. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 567), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 == Line 300 has weird spacing: '...ss, but the i...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (September 23, 2004) is 7155 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: 'DNA4' is mentioned on line 353, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'CDMA2K' -- Possible downref: Non-RFC (?) normative reference: ref. 'GPRS' -- Possible downref: Non-RFC (?) normative reference: ref. 'GPRS-LINK' == Outdated reference: A later version (-04) exists of draft-ietf-dna-goals-01 ** Downref: Normative reference to an Informational draft: draft-ietf-dna-goals (ref. 'I-D.ietf-dna-goals') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11a' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11b' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11g' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11i' ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-03) exists of draft-ietf-mipshop-fast-mipv6-02 == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-09 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Yegin, Ed. 2 Internet-Draft Samsung AIT 3 Expires: March 24, 2005 E. Njedjou 4 France Telecom 5 S. Veerepalli 6 Qualcomm 7 N. Montavont 8 T. Noel 9 LSIIT - University Louis Pasteur 10 September 23, 2004 12 Link-layer Event Notifications for Detecting Network Attachments 13 draft-ietf-dna-link-information-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 24, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 Certain network access technologies are capable of providing various 47 link-layer status information to IP. Link-layer event notifications 48 can help IP expeditiously detect configuration changes. This draft 49 provides a non-exhaustive catalogue of information available from 50 well-known access technologies. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Requirements notation . . . . . . . . . . . . . . . . . . 4 56 2. Link-Layer Event Notifications . . . . . . . . . . . . . . . . 5 57 2.1 GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.2 cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 7 59 2.3 IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 65 6.2 Informative References . . . . . . . . . . . . . . . . . . . 14 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 67 Intellectual Property and Copyright Statements . . . . . . . . 17 69 1. Introduction 71 It is not an uncommon occurrence for a node to change its point-of 72 attachment to the network. This can happen due to mobile usage 73 (e.g., a mobile phone moving among base stations) or nomadic usage 74 (e.g., road-warrior case). 76 A node changing its point-of attachment to the network may end up 77 changing its IP subnet and therefore require re-configuration of 78 IP-layer parameters, such as IP address, default gateway information, 79 and DNS server address. Detecting the subnet change can usually use 80 network-layer indications such as a change in the advertised prefixes 81 (i.e., appearance and disappearance of prefixes). But generally 82 reliance on such indications does not yield rapid detection, since 83 these indications are not readily available upon node changing its 84 point of attachment. 86 The changes on the underlying link-layer status can be relayed to IP 87 in the form of link-layer event notifications. Establishment and 88 tear down of a link-layer connection are two basic events types. 89 Additional information can be conveyed in addition to the event type, 90 such as the identifier of the network attachment point, or 91 network-layer configuration parameters obtained via the link-layer 92 attachment process. It is envisaged that such event notifications 93 can in certain circumstances be used to expedite the inter-subnet 94 movement detection and reconfiguration process. For example, the 95 notification indicating that the node has established a new 96 link-layer connection can be used for immediately probing the network 97 for a possible configuration change. In the absence of such a 98 notification from the link-layer, IP has to wait for indications that 99 are not immediately available, such as receipt of next scheduled 100 router advertisement, unreachability of the default gateway, etc. 102 It should be noted that a link-layer event notification does not 103 always translate into a subnet change. Even if the node has torn 104 down a link-layer connection with one attachment point and 105 established a new connection with another, it may still be attached 106 to the same IP subnet. For example, several IEEE 802.11 access 107 points can be attached to the same IP subnet. Moving among these 108 access points does not warrant any IP-layer configuration change. 110 In order to enable an enhanced scheme for detecting change of subnet, 111 we need to define link-layer event notifications that can be 112 realistically expected from various access technologies. The 113 objective of this draft is to provide a catalogue of link-layer 114 events and notifications in various architectures. While this 115 document mentions the utility of this information for detecting 116 change of subnet (or, detecting network attachment - DNA), the 117 detailed usage is left to other documents, namely DNA solution 118 specifications. 120 The document limits itself to the minimum set of information that is 121 necessary for solving the DNA problem [I-D.ietf-dna-goals]. A 122 broader set of information may be used for other problem spaces 123 (e.g., anticipation-based Mobile IP fast handovers 124 [I-D.ietf-mobileip-lowlatency-handoff][I-D.ietf-mipshop-fast-mipv6]). 125 Separate documents that are backward-compatible with this one can be 126 generated to discuss further enhancements. 128 These event notifications are considered with hosts in mind, although 129 they may also be available on the network side (e.g., on the access 130 points and routers). An API or protocol-based standard interface may 131 be defined between the link-layer and IP for conveying this 132 information. That activity is beyond the scope of this document. 134 1.1 Requirements notation 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 2. Link-Layer Event Notifications 142 Link-layer event notifications are considered to be one of the inputs 143 to the DNA process. A DNA process is likely to take other inputs 144 (e.g., presence of advertised prefixes, reachability of default 145 gateways) before determining whether IP-layer configuration must be 146 updated. It is expected that the DNA process can take advantage of 147 link-layer notifications when they are made available to IP. While 148 by itself a link-layer notification may not constitute all the input 149 DNA needs, it can at least be useful for prompting the DNA process to 150 collect further information (i.e., other inputs to the process). For 151 example, the node may send a router solicitation as soon as it learns 152 that a new link-layer connection is established. 154 Two basic link-layer events are considered potentially useful to DNA 155 process: link up and link down. Both of these events are 156 deterministic, and their notifications are provided to IP-layer after 157 the events successfully conclude. These events and notifications are 158 associated with a network interface on the node. The IP module may 159 receive simultaneous independent notifications from each one of the 160 network interfaces on the node. 162 Node's establishment of a link-layer connection with an attachment 163 point that signifies the availability of IP service (i.e., being able 164 to send and receive IP packets) between the two is considered a link 165 up event. The attachment point is typically an access network 166 element, such as an access point, a base station, or a wired switch 167 [TO-DO: How about ad-hoc networks? Attached neighbors may be 168 considered attachment points]. 170 The actual event is managed by the link-layer of the node through 171 execution of link-layer protocols and mechanisms. Once the event 172 successfully completes within the link-layer, its notification must 173 be delivered to the IP-layer. By the time the notification is 174 delivered, the link-layer of the node must be ready to accept IP 175 packets from the IP and the physical-layers. 177 Link down event signifies the discontinuation of the IP service 178 between the node and the attachment point. When the link-layer 179 connection is physically or logically torn down and it can no longer 180 carry IP packets, this is considered to be a link down event. 182 Among these two events the first one to take place after an interface 183 becomes enabled must be a link up event. During the time a network 184 interface is enabled, it may go through a series of link up and down 185 events. Each time the interface changes its point of attachment, a 186 link down event with the previous attachment point must be followed 187 by a link up event with the new one. Finally, when the network 188 interface is disabled, this must generate a link down event. Each 189 one of these events must generate a notification in order they occur. 191 A node may have to change its IP-layer configuration even when the 192 link-layer connection stays the same. An example scenario is the 193 IPv6 subnet renumbering [RFC2461]. Therefore, there exists cases 194 where IP-layer configuration may have to change even without the 195 IP-layer receiving a link up notification. Therefore, a link-layer 196 notification is not a mandatory indication of a subnet change. 198 In addition to the type of the event (link up, link down), a 199 link-layer notification may also optionally deliver information 200 relating to the attachment point. Such auxiliary information may 201 include identity of the attachment point (e.g., base station 202 identifier), or the IP-layer configuration parameters associated with 203 the attached subnet (e.g., subnet prefix, default gateway address, 204 etc.). While merely knowing that a new link-layer connection is 205 established may prompt DNA process to immediately seek other clues 206 for detecting network configuration change, auxiliary information may 207 constitute further clues (and even the final answers sometimes). In 208 cases where there is a one-to-one mapping between the attachment 209 point identifiers and the IP-layer configurations, learning the 210 former can reveal the latter. Furthermore, IP-layer configuration 211 parameters obtained during link-layer connection may be exactly what 212 the DNA process is trying to discover (e.g., IP address configured 213 during PPP link establishment). 215 The link-layer process leading to a link up or link down event 216 depends on the link technology. While a link-layer notification must 217 always indicate the event type, the availability and types of 218 auxiliary information on the attachment point depends on the 219 link-layer technology as well. The following subsections examine 220 three link-layer technologies and describe when a link-layer 221 notification must be generated and what information must be included 222 in it. The coverage on the link types may be expanded in the future 223 [TO-DO: Add IEEE 802.3]. 225 2.1 GPRS/3GPP 227 GPRS is an enhancement to the GSM data transmission architecture and 228 capabilities, designed to allow for packet switching in user data 229 transmission within the GPRS network as well as for higher quality of 230 service for the IP traffic of Mobile Terminals with external Packets 231 Data Networks such as the Internet or corporate LANs 232 [GPRS][GPRS-LINK]. 234 The GPRS architecture consists of a Radio Access Network and a packet 235 domain Core Network. 237 - The GPRS Radio Access Network is composed of Mobile Terminals (MT), 238 a Base Station Subsystem and Serving GPRS Support Nodes (SGSN). 240 - An IP Core Network that acts as the transport backbone of user 241 datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The 242 GGSN ensures the GPRS IP core network connectivity with external 243 networks, such as Internet or Local Area Networks. GGSN acts as the 244 default IP gateway for the MT. 246 A MT that wants to establish IP-level connections should first 247 perform a GPRS attach to the SGSN. This should be followed by a 248 request the GPRS network to settle the necessary soft state mechanism 249 (GPRS tunneling protocol) between its serving SGSN and the GGSN. The 250 soft state maintained between the MT, the SGSN and the GGSN is called 251 a PDP Context. It is used for guaranteeing a negotiated quality of 252 service for the IP flows exchanged between the GPRS MT and an 253 external Packet Data Network such as Internet . Only after the PDP 254 Context is established and tunneling mechanism takes place can the 255 MT's IP packets be forwarded to and from its remote IP peers. The 256 aim of PDP Context establishment is also to provide IP-level 257 configuration on top of the GPRS link-layer attachment. 259 Successful establishment of a PDP Context on a GPRS signifies the 260 availability of IP service to the MT. Therefore, this link-layer 261 event must generate a link up event notification sent to IP-layer. 262 The auxiliary information carried along with this notification must 263 be the IP address of the MT which is obtained as part of the PDP 264 Context. In case of IPv6, IPv6 address of the MT may be obtained by 265 alternative methods, such as DHCPv6 [RFC3315][GPRS-GSSA] or stateless 266 address autoconfiguration [RFC2462][GPRS-CN]. In that case, the IP 267 address auxiliary information must be set to null. 269 Similarly, PDP Context deactivation must generate a link down event 270 notification. 272 2.2 cdma2000/3GPP2 274 cdma2000-based 3GPP2 packet data services provide mobile users wide 275 area high-speed access to packet switched networks [CDMA2K]. Some of 276 the major components of the 3GPP2 packet network architecture consist 277 of: 279 - Mobile Station (MS), which allows mobile access to packet-switched 280 networks over a wireless connection. 282 - Radio Access Network, which consists of the Base Station 283 Transceivers, Base Station Controllers, and the Packet Control 284 Function. 286 - Network Access Server known as the Packet Data Switching Node 287 (PDSN). The PDSN also serves as default IP gateway for the IP MS. 289 3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as the 290 link-layer protocol between the MS and the PDSN. Before any IP 291 packets may be sent or received, PPP must reach the Network-Layer 292 Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP 293 [RFC2472]) reach the Opened state. When these states are reached in 294 PPP, a link up event notification must be delivered to the IP-layer. 296 When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4 297 Service, IPCP enables configuration of IPv4 address on the MS. This 298 IPv4 address must be provided as the auxiliary information along with 299 the link up notification. IPV6CP used for Simple IPv6 service does 300 not provide an IPv6 address, but the interface-identifiers for local 301 and remote end-points of the PPP link. Since there is no 302 standards-mandated correlation between the interface-identifier and 303 other IP-layer configuration parameters, this information is deemed 304 not useful for DNA (hence it is not provided as auxiliary 305 information). 307 IPCP/IPV6CP termination, or the underlying LCP or NCP reaching Closed 308 State signify the end of corresponding IP service on the PPP link. 309 This event must generate a link down notification delivered to the 310 IP-layer. 312 2.3 IEEE 802.11/WiFi 314 IEEE 802.11-based WiFi networks are the wireless extension of the 315 Local Area Networks. Currently available standards are IEEE 802.11b 316 [IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a 317 [IEEE-802.11a]. The specifications define both the MAC-layer and the 318 physical-layer. The MAC layer is the same for all these 319 technologies. 321 Two operating modes are available in the IEEE 802.11 series. In 322 ad-hoc mode, mobile station (STA) in range may directly communicate 323 with other, i.e., without any infrastructure or intermediate hop. In 324 infrastructure mode, all link-layer frames are transmitted to an 325 access point (AP) which then forwards them to the final receiver. 326 This document only considers infrastructure mode [for now... TO-DO: 327 consider ad-hoc too]. 329 A STA must establish a IEEE 802.11 link with an AP in order to send 330 and receive IP packets. In a WiFi network that supports Robust 331 Secure Network (RSN [IEEE-802.11i]), successful completion of 4-way 332 handshake between the STA and AP commences the availability of IP 333 service. The link up event notification must be generated upon this 334 event. In non-RSN-based networks, successful association or 335 re-association events on the link-layer must cause a link up 336 notification sent to the IP-layer. 338 As part of the link establishment, Basic Service Set Identification 339 (BSSID) and Service Set Identifier (SSID) associated with the AP is 340 learned by the STA. BSSID is a unique identifier of the AP. Its 341 value is set to the MAC address of the AP in infrastructure mode. 342 SSID carries the identifier of the Extended Service Set (ESS) - the 343 set composed of APs and associated STAs that share a common 344 distribution system. BSSID and SSID should be provided as auxiliary 345 information along with the link up notification. Unfortunately this 346 information does not provide a deterministic indication of whether 347 the IP-layer configuration must be changed upon movement. There is 348 no standards-mandated one-to-one relation between the BSSID/SSID 349 pairs and IP subnets. An AP with a given BSSID can connect a STA to 350 any one of more than one IP subnets. Similarly, an ESS with the 351 given SSID may span multiple IP subnets. And finally, the SSIDs are 352 not globally unique. The same SSID may be used by multiple 353 independent ESSs. See Appendix A of [DNA4] for a detailed 354 discussion. Nevertheless, BSSID/SSID information may be used in a 355 probabilistic way by the DNA process, hence it is provided with the 356 link up event notification. 358 Disassociation event in RSN-based, and de-authentication and 359 disassociation events in non-RSN-based WiFi networks must translate 360 to link down events, and generate the corresponding link-layer 361 notifications. 363 3. IANA Considerations 365 This document has no actions for IANA. 367 4. Security Considerations 369 A faked link-layer event notification can be used to launch a 370 denial-of service attack on the node and the associated network. 371 Secure generation and delivery of these notifications must be 372 ensured. This is a subject for link-layer and network stack designs 373 and therefore it is outside the scope of this document. 375 5. Acknowledgements 377 The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, 378 JinHyeock Choi, Greg Daley, Pekka Nikander, and Muhammad Mukarram bin 379 Tariq for their useful comments and suggestions. 381 6. References 383 6.1 Normative References 385 [CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", . 387 [GPRS] "Digital cellular telecommunications system (Phase 2+); 388 General Packet Radio Service (GPRS) Service description; 389 Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98. 391 [GPRS-LINK] 392 "Digital cellular telecommunications system (Phase 2+); 393 Radio subsystem link control", 3GPP GSM 03.05 version 394 7.0.0 Release 98. 396 [I-D.ietf-dna-goals] 397 Choi, J., "Detecting Network Attachment in IPv6 Goals", 398 draft-ietf-dna-goals-01 (work in progress), September 399 2004. 401 [IEEE-802.11a] 402 Institute of Electrical and Electronics Engineers, "IEEE 403 Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part 404 11: Wireless MAN Medium Access Control (MAC) and Physical 405 Layer (PHY) specifications: High-speed Physical Layer in 406 the 5 GHZ band", IEEE Standard 802.11a, September 1999. 408 [IEEE-802.11b] 409 Institute of Electrical and Electronics Engineers, "IEEE 410 Std 802 Part 11, Information technology - 411 Telecomunications and information exchange between systems 412 - Local and metropolitan area networks - Specific 413 requirements - Part 11: Wireless Lan Medium Access Control 414 (MAC) And Physical Layer (PHY) Specifications", IEEE 415 Standard 802.11b, August 1999. 417 [IEEE-802.11g] 418 Institute of Electrical and Electronics Engineers, "IEEE 419 Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 420 edition, Part 11: Wireless MAN Medium Access Control (MAC) 421 and Physical Layer (PHY) specifications. Amendment 4: 422 Further Higher Data Rate Extension in the 2.4 GHz Band", 423 IEEE Standard 802.11g, June 2003. 425 [IEEE-802.11i] 426 Institute of Electrical and Electronics Engineers, "Draft 427 Supplement to STANDARD FOR Telecommunications and 428 Information Exchange between Systems - LAN/MAN Specific 429 Requirements - Part 11: Wireless Medium Access Control 430 (MAC) and physical layer (PHY) specifications: 431 Specification for Enhanced Security", IEEE Draft 802.11I/ 432 D8, February 2004. 434 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 435 (IPCP)", RFC 1332, May 1992. 437 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 438 RFC 1661, July 1994. 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 444 Autoconfiguration", RFC 2462, December 1998. 446 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 447 2472, December 1998. 449 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 450 M. Carney, "Dynamic Host Configuration Protocol for IPv6 451 (DHCPv6)", RFC 3315, July 2003. 453 6.2 Informative References 455 [GPRS-CN] "Technical Specification Group Core Network; 456 Internetworking between the Public Land Mobile Network 457 (PLMN) supporting packet based services and Packet Data 458 Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version 459 6.1.0 2004-06. 461 [GPRS-GSSA] 462 "Technical Specification Group Services and System Aspect; 463 General Packet Radio Service (GPRS) Service description; 464 Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0 465 2004-06. 467 [I-D.ietf-mipshop-fast-mipv6] 468 Koodli, R., "Fast Handovers for Mobile IPv6", 469 draft-ietf-mipshop-fast-mipv6-02 (work in progress), July 470 2004. 472 [I-D.ietf-mobileip-lowlatency-handoff] 473 Malki, K., "Low latency Handoffs in Mobile IPv4", 474 draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in 475 progress), June 2004. 477 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 478 Discovery for IP Version 6 (IPv6)", RFC 2461, December 479 1998. 481 Authors' Addresses 483 Alper E. Yegin (editor) 484 Samsung Advanced Institute of Technology 485 75 West Plumeria Drive 486 San Jose, CA 95134 487 USA 489 Phone: +1 408 544 5656 490 EMail: alper.yegin@samsung.com 492 Eric Njedjou 493 France Telecom 494 4, Rue du Clos Courtel BP 91226 495 Cesson-SȨvignȨ, 35512 496 France 498 Phone: +33 299124202 499 EMail: eric.njedjou@france-telecom.com 501 Siva Veerepalli 502 Qualcomm 503 5775 Morehouse Drive 504 San Diego, CA 92131 505 USA 507 Phone: +1 858 658 4628 508 EMail: sivav@qualcomm.com 510 Nicolas Montavont 511 LSIIT - University Louis Pasteur 512 Pole API, bureau C428 513 Boulevard Sebastien Brant 514 Illkirch, 67400 515 France 517 Phone: +33 390 244 587 518 EMail: montavont@dpt-info.u-strasbg.fr 519 Thomas Noel 520 LSIIT - University Louis Pasteur 521 Pole API, bureau C428 522 Boulevard Sebastien Brant 523 Illkirch, 67400 524 France 526 Phone: +33 390 244 592 527 EMail: noel@dpt-info.u-strasbg.fr 529 Intellectual Property Statement 531 The IETF takes no position regarding the validity or scope of any 532 Intellectual Property Rights or other rights that might be claimed to 533 pertain to the implementation or use of the technology described in 534 this document or the extent to which any license under such rights 535 might or might not be available; nor does it represent that it has 536 made any independent effort to identify any such rights. Information 537 on the procedures with respect to rights in RFC documents can be 538 found in BCP 78 and BCP 79. 540 Copies of IPR disclosures made to the IETF Secretariat and any 541 assurances of licenses to be made available, or the result of an 542 attempt made to obtain a general license or permission for the use of 543 such proprietary rights by implementers or users of this 544 specification can be obtained from the IETF on-line IPR repository at 545 http://www.ietf.org/ipr. 547 The IETF invites any interested party to bring to its attention any 548 copyrights, patents or patent applications, or other proprietary 549 rights that may cover technology that may be required to implement 550 this standard. Please address the information to the IETF at 551 ietf-ipr@ietf.org. 553 Disclaimer of Validity 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 558 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 559 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 560 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Copyright Statement 565 Copyright (C) The Internet Society (2004). This document is subject 566 to the rights, licenses and restrictions contained in BCP 78, and 567 except as set forth therein, the authors retain all their rights. 569 Acknowledgment 571 Funding for the RFC Editor function is currently provided by the 572 Internet Society.