idnits 2.17.1 draft-ietf-dna-link-information-01.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 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 579. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 595), 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 308 has weird spacing: '...ss, but the i...' -- 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 (February 10, 2005) is 7008 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 358, 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' ** 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 (-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 (~~), 6 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: August 11, 2005 E. Njedjou 4 France Telecom 5 S. Veerepalli 6 Qualcomm 7 N. Montavont 8 T. Noel 9 LSIIT - University Louis Pasteur 10 February 10, 2005 12 Link-layer Event Notifications for Detecting Network Attachments 13 draft-ietf-dna-link-information-01.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 August 11, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 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 A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17 68 Intellectual Property and Copyright Statements . . . . . . . . 18 70 1. Introduction 72 It is not an uncommon occurrence for a node to change its point-of 73 attachment to the network. This can happen due to mobile usage 74 (e.g., a mobile phone moving among base stations) or nomadic usage 75 (e.g., road-warrior case). 77 A node changing its point-of attachment to the network may end up 78 changing its IP subnet and therefore require re-configuration of 79 IP-layer parameters, such as IP address, default gateway information, 80 and DNS server address. Detecting the subnet change can usually use 81 network-layer indications such as a change in the advertised prefixes 82 (i.e., appearance and disappearance of prefixes). But generally 83 reliance on such indications does not yield rapid detection, since 84 these indications are not readily available upon node changing its 85 point of attachment. 87 The changes on the underlying link-layer status can be relayed to IP 88 in the form of link-layer event notifications. Establishment and 89 tear down of a link-layer connection are two basic events types. 90 Additional information can be conveyed in addition to the event type, 91 such as the identifier of the network attachment point, or 92 network-layer configuration parameters obtained via the link-layer 93 attachment process. It is envisaged that such event notifications 94 can in certain circumstances be used to expedite the inter-subnet 95 movement detection and reconfiguration process. For example, the 96 notification indicating that the node has established a new 97 link-layer connection can be used for immediately probing the network 98 for a possible configuration change. In the absence of such a 99 notification from the link-layer, IP has to wait for indications that 100 are not immediately available, such as receipt of next scheduled 101 router advertisement, unreachability of the default gateway, etc. 103 It should be noted that a link-layer event notification does not 104 always translate into a subnet change. Even if the node has torn 105 down a link-layer connection with one attachment point and 106 established a new connection with another, it may still be attached 107 to the same IP subnet. For example, several IEEE 802.11 access 108 points can be attached to the same IP subnet. Moving among these 109 access points does not warrant any IP-layer configuration change. 111 In order to enable an enhanced scheme for detecting change of subnet, 112 we need to define link-layer event notifications that can be 113 realistically expected from various access technologies. The 114 objective of this draft is to provide a catalogue of link-layer 115 events and notifications in various architectures. While this 116 document mentions the utility of this information for detecting 117 change of subnet (or, detecting network attachment - DNA), the 118 detailed usage is left to other documents, namely DNA solution 119 specifications. 121 The document limits itself to the minimum set of information that is 122 necessary for solving the DNA problem [I-D.ietf-dna-goals]. A 123 broader set of information may be used for other problem spaces 124 (e.g., anticipation-based Mobile IP fast handovers 125 [I-D.ietf-mobileip-lowlatency-handoffs-v4] 126 [I-D.ietf-mipshop-fast-mipv6]). Separate documents that are 127 backward-compatible with this one can be generated to discuss further 128 enhancements. 130 These event notifications are considered with hosts in mind, although 131 they may also be available on the network side (e.g., on the access 132 points and routers). An API or protocol-based standard interface may 133 be defined between the link-layer and IP for conveying this 134 information. That activity is beyond the scope of this document. 136 1.1 Requirements notation 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Link-Layer Event Notifications 144 Link-layer event notifications are considered to be one of the inputs 145 to the DNA process. A DNA process is likely to take other inputs 146 (e.g., presence of advertised prefixes, reachability of default 147 gateways) before determining whether IP-layer configuration must be 148 updated. It is expected that the DNA process can take advantage of 149 link-layer notifications when they are made available to IP. While 150 by itself a link-layer notification may not constitute all the input 151 DNA needs, it can at least be useful for prompting the DNA process to 152 collect further information (i.e., other inputs to the process). For 153 example, the node may send a router solicitation as soon as it learns 154 that a new link-layer connection is established. 156 Two basic link-layer events are considered potentially useful to DNA 157 process: link up and link down. Both of these events are 158 deterministic, and their notifications are provided to IP-layer after 159 the events successfully conclude. These events and notifications are 160 associated with a network interface on the node. The IP module may 161 receive simultaneous independent notifications from each one of the 162 network interfaces on the node. 164 Node's establishment of a link-layer connection with an attachment 165 point that signifies the availability of IP service (i.e., being able 166 to send and receive IP packets) between the two is considered a link 167 up event. The attachment point is typically an access network 168 element, such as an access point, a base station, or a wired switch 169 [TO-DO: How about ad-hoc networks? Attached neighbors may be 170 considered attachment points]. 172 The actual event is managed by the link-layer of the node through 173 execution of link-layer protocols and mechanisms. Once the event 174 successfully completes within the link-layer, its notification must 175 be delivered to the IP-layer. By the time the notification is 176 delivered, the link-layer of the node must be ready to accept IP 177 packets from the IP and the physical-layers. 179 Link down event signifies the discontinuation of the IP service 180 between the node and the attachment point. When the link-layer 181 connection is physically or logically torn down and it can no longer 182 carry IP packets, this is considered to be a link down event. 184 Among these two events the first one to take place after an interface 185 becomes enabled must be a link up event. During the time a network 186 interface is enabled, it may go through a series of link up and down 187 events. Each time the interface changes its point of attachment, a 188 link down event with the previous attachment point must be followed 189 by a link up event with the new one. Finally, when the network 190 interface is disabled, this must generate a link down event. Each 191 one of these events must generate a notification in order they occur. 193 A node may have to change its IP-layer configuration even when the 194 link-layer connection stays the same. An example scenario is the 195 IPv6 subnet renumbering [RFC2461]. Therefore, there exists cases 196 where IP-layer configuration may have to change even without the 197 IP-layer receiving a link up notification. Therefore, a link-layer 198 notification is not a mandatory indication of a subnet change. 200 In addition to the type of the event (link up, link down), a 201 link-layer notification may also optionally deliver information 202 relating to the attachment point. Such auxiliary information may 203 include identity of the attachment point (e.g., base station 204 identifier), or the IP-layer configuration parameters associated with 205 the attached subnet (e.g., subnet prefix, default gateway address, 206 etc.). While merely knowing that a new link-layer connection is 207 established may prompt DNA process to immediately seek other clues 208 for detecting network configuration change, auxiliary information may 209 constitute further clues (and even the final answers sometimes). In 210 cases where there is a one-to-one mapping between the attachment 211 point identifiers and the IP-layer configurations, learning the 212 former can reveal the latter. Furthermore, IP-layer configuration 213 parameters obtained during link-layer connection may be exactly what 214 the DNA process is trying to discover (e.g., IP address configured 215 during PPP link establishment). 217 The link-layer process leading to a link up or link down event 218 depends on the link technology. While a link-layer notification must 219 always indicate the event type, the availability and types of 220 auxiliary information on the attachment point depends on the 221 link-layer technology as well. The following subsections examine 222 three link-layer technologies and describe when a link-layer 223 notification must be generated and what information must be included 224 in it. The coverage on the link types may be expanded in the future 225 [TO-DO: Add IEEE 802.3]. 227 2.1 GPRS/3GPP 229 GPRS is an enhancement to the GSM data transmission architecture and 230 capabilities, designed to allow for packet switching in user data 231 transmission within the GPRS network as well as for higher quality of 232 service for the IP traffic of Mobile Terminals with external Packets 233 Data Networks such as the Internet or corporate LANs 234 [GPRS][GPRS-LINK]. 236 The GPRS architecture consists of a Radio Access Network and a packet 237 domain Core Network. 239 - The GPRS Radio Access Network is composed of Mobile Terminals (MT), 240 a Base Station Subsystem and Serving GPRS Support Nodes (SGSN). 242 - An IP Core Network that acts as the transport backbone of user 243 datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The 244 GGSN ensures the GPRS IP core network connectivity with external 245 networks, such as Internet or Local Area Networks. GGSN acts as the 246 default IP gateway for the MT. 248 A GPRS MT that wants to establish IP-level connections should first 249 perform a GPRS attach to the SGSN. This should be followed by a 250 request the GPRS network to settle the necessary soft state mechanism 251 (GPRS tunneling protocol) between its serving SGSN and the GGSN. The 252 soft state maintained between the MT, the SGSN and the GGSN is called 253 a PDP Context. It is used for guaranteeing a negotiated quality of 254 service for the IP flows exchanged between the GPRS MT and an 255 external Packet Data Network such as Internet . It is only after the 256 PDP Context has been established, address autoconfiguration and 257 tunneling mechanism have taken place that the MT's IP packets can be 258 forwarded to and from its remote IP peers. The aim of PDP Context 259 establishment is also to provide IP-level configuration on top of the 260 GPRS link-layer attachment. 262 Successful establishment of a PDP Context on a GPRS signifies the 263 availability of IP service to the MT. Therefore, this link-layer 264 event must generate a link up event notification sent to IP-layer. 265 With IPv4, the auxiliary information carried along with this 266 notification MUST be the IPv4 address of the MT which is obtained as 267 part of the PDP Context. With IPv6, the PDP Context activation 268 response does not come along with a usable IPv6 address. 269 Effectively, the IPv6 address received from the GGSN in the PDP 270 address field of the message does not contain a valid prefix. The MN 271 actually only uses the interface-identifier extracted from that field 272 to form a link-local address, that it uses afterwards to obtain a 273 valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful 274 [RFC3315][GPRS-GSSA] address configuration). Therefore no 275 IPv6-related auxiliary information is provided to IP-layer. 277 Similarly, PDP Context deactivation must generate a link down event 278 notification. 280 2.2 cdma2000/3GPP2 282 cdma2000-based 3GPP2 packet data services provide mobile users wide 283 area high-speed access to packet switched networks [CDMA2K]. Some of 284 the major components of the 3GPP2 packet network architecture consist 285 of: 287 - Mobile Station (MS), which allows mobile access to packet-switched 288 networks over a wireless connection. 290 - Radio Access Network, which consists of the Base Station 291 Transceivers, Base Station Controllers, and the Packet Control 292 Function. 294 - Network Access Server known as the Packet Data Switching Node 295 (PDSN). The PDSN also serves as default IP gateway for the IP MS. 297 3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as the 298 link-layer protocol between the MS and the PDSN. Before any IP 299 packets may be sent or received, PPP must reach the Network-Layer 300 Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP 301 [RFC2472]) reach the Opened state. When these states are reached in 302 PPP, a link up event notification must be delivered to the IP-layer. 304 When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4 305 Service, IPCP enables configuration of IPv4 address on the MS. This 306 IPv4 address must be provided as the auxiliary information along with 307 the link up notification. IPV6CP used for Simple IPv6 service does 308 not provide an IPv6 address, but the interface-identifiers for local 309 and remote end-points of the PPP link. Since there is no 310 standards-mandated correlation between the interface-identifier and 311 other IP-layer configuration parameters, this information is deemed 312 not useful for DNA (hence it is not provided as auxiliary 313 information). 315 IPCP/IPV6CP termination, or the underlying LCP or NCP reaching Closed 316 State signify the end of corresponding IP service on the PPP link. 317 This event must generate a link down notification delivered to the 318 IP-layer. 320 2.3 IEEE 802.11/WiFi 322 IEEE 802.11-based WiFi networks are the wireless extension of the 323 Local Area Networks. Currently available standards are IEEE 802.11b 324 [IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a 325 [IEEE-802.11a]. The specifications define both the MAC-layer and the 326 physical-layer. The MAC layer is the same for all these 327 technologies. 329 Two operating modes are available in the IEEE 802.11 series, either 330 infrastructure mode or ad-hoc mode. In infrastructure mode, all 331 link-layer frames are transmitted to an access point (AP) which then 332 forwards them to the final receiver. A STA must establish a IEEE 333 802.11 link with an AP in order to send and receive IP packets. In a 334 WiFi network that supports Robust Secure Network (RSN 336 [IEEE-802.11i]), successful completion of 4-way handshake between the 337 STA and AP commences the availability of IP service. The link up 338 event notification must be generated upon this event. In 339 non-RSN-based networks, successful association or re-association 340 events on the link-layer must cause a link up notification sent to 341 the IP-layer. 343 As part of the link establishment, Basic Service Set Identification 344 (BSSID) and Service Set Identifier (SSID) associated with the AP is 345 learned by the STA. BSSID is a unique identifier of the AP. Its 346 value is set to the MAC address of the AP. SSID carries the 347 identifier of the Extended Service Set (ESS) - the set composed of 348 APs and associated STAs that share a common distribution system. 349 BSSID and SSID should be provided as auxiliary information along with 350 the link up notification. Unfortunately this information does not 351 provide a deterministic indication of whether the IP-layer 352 configuration must be changed upon movement. There is no 353 standards-mandated one-to-one relation between the BSSID/SSID pairs 354 and IP subnets. An AP with a given BSSID can connect a STA to any 355 one of more than one IP subnets. Similarly, an ESS with the given 356 SSID may span multiple IP subnets. And finally, the SSIDs are not 357 globally unique. The same SSID may be used by multiple independent 358 ESSs. See Appendix A of [DNA4] for a detailed discussion. 359 Nevertheless, BSSID/SSID information may be used in a probabilistic 360 way by the DNA process, hence it is provided with the link up event 361 notification. 363 Disassociation event in RSN-based, and de-authentication and 364 disassociation events in non-RSN-based WiFi networks must translate 365 to link down events, and generate the corresponding link-layer 366 notifications. 368 In ad-hoc mode, mobile station (STA) in range may directly 369 communicate with others, i.e., without any infrastructure or 370 intermediate hop. The set of communicating STAs is called IBSS for 371 Indepedant Basic Service Set. In an IBSS, only station services are 372 available, i.e. authentication, deauthentication, privacy and MSDU 373 delivery. STAs do not associate with each other, and therefore may 374 exchange data frames in state 2 (authenticated and not associated) or 375 even in state 1 (unauthenticated and unassociated) if authentication 376 is not used. Although a link up indication can be generated upon 377 authentication, one may not be present per latter usage. If 378 authentication is performed, a deauthentication event is used for 379 generating the link down indication. Concerning the link layer 380 identification, both the BSSID (which is a random MAC address chosen 381 by a STA of the IBSS) and SSID may be used to identify a link, but 382 not to make any assumptions on the IP network configuration. 384 3. IANA Considerations 386 This document has no actions for IANA. 388 4. Security Considerations 390 A faked link-layer event notification can be used to launch a 391 denial-of service attack on the node and the associated network. 392 Secure generation and delivery of these notifications must be 393 ensured. This is a subject for link-layer and network stack designs 394 and therefore it is outside the scope of this document. 396 5. Acknowledgements 398 The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, 399 JinHyeock Choi, Greg Daley, Pekka Nikander, and Muhammad Mukarram bin 400 Tariq for their useful comments and suggestions. 402 6. References 404 6.1 Normative References 406 [CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", . 408 [GPRS] "Digital cellular telecommunications system (Phase 2+); 409 General Packet Radio Service (GPRS) Service description; 410 Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98. 412 [GPRS-LINK] 413 "Digital cellular telecommunications system (Phase 2+); 414 Radio subsystem link control", 3GPP GSM 03.05 version 415 7.0.0 Release 98. 417 [I-D.ietf-dna-goals] 418 Choi, J., "Detecting Network Attachment in IPv6 Goals", 419 draft-ietf-dna-goals-04 (work in progress), December 2004. 421 [IEEE-802.11a] 422 Institute of Electrical and Electronics Engineers, "IEEE 423 Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part 424 11: Wireless MAN Medium Access Control (MAC) and Physical 425 Layer (PHY) specifications: High-speed Physical Layer in 426 the 5 GHZ band", IEEE Standard 802.11a, September 1999. 428 [IEEE-802.11b] 429 Institute of Electrical and Electronics Engineers, "IEEE 430 Std 802 Part 11, Information technology - 431 Telecomunications and information exchange between systems 432 - Local and metropolitan area networks - Specific 433 requirements - Part 11: Wireless Lan Medium Access Control 434 (MAC) And Physical Layer (PHY) Specifications", IEEE 435 Standard 802.11b, August 1999. 437 [IEEE-802.11g] 438 Institute of Electrical and Electronics Engineers, "IEEE 439 Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 440 edition, Part 11: Wireless MAN Medium Access Control (MAC) 441 and Physical Layer (PHY) specifications. Amendment 4: 442 Further Higher Data Rate Extension in the 2.4 GHz Band", 443 IEEE Standard 802.11g, June 2003. 445 [IEEE-802.11i] 446 Institute of Electrical and Electronics Engineers, "Draft 447 Supplement to STANDARD FOR Telecommunications and 448 Information Exchange between Systems - LAN/MAN Specific 449 Requirements - Part 11: Wireless Medium Access Control 450 (MAC) and physical layer (PHY) specifications: 451 Specification for Enhanced Security", IEEE Draft 802.11I/ 452 D8, February 2004. 454 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 455 (IPCP)", RFC 1332, May 1992. 457 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 458 RFC 1661, July 1994. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 464 Autoconfiguration", RFC 2462, December 1998. 466 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 467 2472, December 1998. 469 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 470 M. Carney, "Dynamic Host Configuration Protocol for IPv6 471 (DHCPv6)", RFC 3315, July 2003. 473 6.2 Informative References 475 [GPRS-CN] "Technical Specification Group Core Network; 476 Internetworking between the Public Land Mobile Network 477 (PLMN) supporting packet based services and Packet Data 478 Networks (PDN) (Release 6)", 3GPP 3GPP TS 29.061 version 479 6.1.0 2004-06. 481 [GPRS-GSSA] 482 "Technical Specification Group Services and System Aspect; 483 General Packet Radio Service (GPRS) Service description; 484 Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0 485 2004-06. 487 [I-D.ietf-mipshop-fast-mipv6] 488 Koodli, R., "Fast Handovers for Mobile IPv6", 489 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 490 October 2004. 492 [I-D.ietf-mobileip-lowlatency-handoffs-v4] 493 Malki, K., "Low latency Handoffs in Mobile IPv4", 494 draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in 495 progress), June 2004. 497 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 498 Discovery for IP Version 6 (IPv6)", RFC 2461, December 499 1998. 501 Authors' Addresses 503 Alper E. Yegin (editor) 504 Samsung Advanced Institute of Technology 505 75 West Plumeria Drive 506 San Jose, CA 95134 507 USA 509 Phone: +1 408 544 5656 510 EMail: alper.yegin@samsung.com 512 Eric Njedjou 513 France Telecom 514 4, Rue du Clos Courtel BP 91226 515 Cesson-SȨvignȨ, 35512 516 France 518 Phone: +33 299124202 519 EMail: eric.njedjou@france-telecom.com 521 Siva Veerepalli 522 Qualcomm 523 5775 Morehouse Drive 524 San Diego, CA 92131 525 USA 527 Phone: +1 858 658 4628 528 EMail: sivav@qualcomm.com 530 Nicolas Montavont 531 LSIIT - University Louis Pasteur 532 Pole API, bureau C428 533 Boulevard Sebastien Brant 534 Illkirch, 67400 535 France 537 Phone: +33 390 244 587 538 EMail: montavont@dpt-info.u-strasbg.fr 539 Thomas Noel 540 LSIIT - University Louis Pasteur 541 Pole API, bureau C428 542 Boulevard Sebastien Brant 543 Illkirch, 67400 544 France 546 Phone: +33 390 244 592 547 EMail: noel@dpt-info.u-strasbg.fr 549 Appendix A. Change History 551 The following changes were made on draft version 00: 553 - IEEE 802.11 ad-hoc mode discussion added. 555 - IPv6 address configuration over 3GPP networks clarified. 557 Intellectual Property Statement 559 The IETF takes no position regarding the validity or scope of any 560 Intellectual Property Rights or other rights that might be claimed to 561 pertain to the implementation or use of the technology described in 562 this document or the extent to which any license under such rights 563 might or might not be available; nor does it represent that it has 564 made any independent effort to identify any such rights. Information 565 on the procedures with respect to rights in RFC documents can be 566 found in BCP 78 and BCP 79. 568 Copies of IPR disclosures made to the IETF Secretariat and any 569 assurances of licenses to be made available, or the result of an 570 attempt made to obtain a general license or permission for the use of 571 such proprietary rights by implementers or users of this 572 specification can be obtained from the IETF on-line IPR repository at 573 http://www.ietf.org/ipr. 575 The IETF invites any interested party to bring to its attention any 576 copyrights, patents or patent applications, or other proprietary 577 rights that may cover technology that may be required to implement 578 this standard. Please address the information to the IETF at 579 ietf-ipr@ietf.org. 581 Disclaimer of Validity 583 This document and the information contained herein are provided on an 584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 587 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 588 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 591 Copyright Statement 593 Copyright (C) The Internet Society (2005). This document is subject 594 to the rights, licenses and restrictions contained in BCP 78, and 595 except as set forth therein, the authors retain all their rights. 597 Acknowledgment 599 Funding for the RFC Editor function is currently provided by the 600 Internet Society.