idnits 2.17.1 draft-koodli-dna-fmip-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 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 247. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2005) is 6867 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) -- Looks like a reference, but probably isn't: 'AP-ID' on line 104 -- Looks like a reference, but probably isn't: 'AR-Info' on line 104 ** Downref: Normative reference to an Experimental draft: draft-ietf-mipshop-fast-mipv6 (ref. '1') == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-optimistic-dad-05 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA Working Group R. Koodli 3 Internet-Draft Nokia Research Center 4 Expires: January 9, 2006 S. Madanapalli 5 Samsung ISO 6 July 8, 2005 8 FMIPv6 Usage with DNA Protocol 9 draft-koodli-dna-fmip-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she becomes aware will be disclosed, in accordance with 18 Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 9, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 In this document, we describe how the Fast Mobile IPv6 Handovers 45 (FMIPv6) protocol can work where DNA protocol support is available, 46 but the neighborhood information, which is part of the FMIPv6 47 operation, is not available. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. FMIPv6 Operating Modes . . . . . . . . . . . . . . . . . . . . 3 53 3. FMIPv6 with DNA . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 60 Intellectual Property and Copyright Statements . . . . . . . . 7 62 1. Introduction 64 The Fast Handovers for Mobile IPv6 [1] defines a protocol to reduce 65 delay and packet loss from IP protocol operations during a handover 66 between cells or points of attachment. These protocol operations 67 include movement detection, IP configuration and location update with 68 a distant mobility agent such as a Home Agent. The FMIPv6 protocol 69 is designed to effectively eliminate the delays due to movement 70 detection and IP configuration latencies, while disengaging the 71 location update latency from the time-critical path so that 72 applications such as Voice over IP are provided real-time mobility 73 support. 75 The Detecting Network Attachment (DNA) WG is designing protocols to 76 quickly detect link changes and enable establishment of IP 77 connectivity as soon as a mobile node is attached to a new subnet. 78 Compared to existing IPv6 router discovery mechanisms, DNA protocols 79 provide faster and reliable mechanisms for determining the link 80 identity and router discovery on the new subnet. DNA routers send 81 augmented Router Advertisement information which uniquely identifies 82 a link. These RAs are sent without delay providing rapid 83 notification of link change. A host implementing DNA mechanisms 84 determines the subnet change and configures new care of address 85 significantly faster than non-DNA (unmodified) hosts on networks with 86 DNA support, if post arrival link change detection is required. 88 The purpose of this document is to illustrate how the FMIPv6 protocol 89 could make use of the DNA protocol to retain the desired handover 90 performance in certain circumstances. In order to do that, some 91 background on the two operating modes of the FMIPv6 protocol is 92 necessary. 94 2. FMIPv6 Operating Modes 96 The FMIPv6 protocol can effectively eliminate the movement detection 97 and IP configuration latencies when knowledge of the neighborhood 98 access points and their subnet affiliation is available. For 99 instance, a Mobile Node can query its access router to provide the 100 subnet prefix, IP address and MAC address of a target router attached 101 to a neighboring access point. With this information, it builds a 102 neighborhood map of Access Point Identifier to Access Router 103 Information. So, a conceptual neighborhood data structure consists 104 of [AP-ID, AR-Info] tuples, with each AR-Info structure consisting of 105 a router's IP address, MAC address and subnet prefix corresponding to 106 the interface to which the Access Point is attached to. Such a 107 neighborhood data structure serves two purposes: First, it allows a 108 MN to map an association to a new radio connection to subnet 109 information immediately, which allows it to bypass router discovery. 111 Second, it allows a MN to use a new IP address on the new subnet link 112 immediately, which allows it to send data packets immediately. 114 There are two modes of operation assuming neighborhood information. 115 In the "predictive mode", a MN is able to effect a local route update 116 before departing from its current link. That is, a MN updates its 117 access router's route table to forward packets to the new IP address 118 before the MN departs the current link. In the "reactive" mode, the 119 MN effects such a route update after it regains radio connectivity on 120 the new link. In both the cases, the latencies due to movement 121 detection and IP configuration are eliminated. In some cases 122 however, neighborhood information may not be available. We discuss 123 this in the following section. 125 3. FMIPv6 with DNA 127 There are scenarios where DNA protocol operation could be beneficial 128 for FMIPv6. For instance, an access network may not be able to 129 provide neighborhood information for whatever reasons, or a MN may 130 end up on an unanticipated Access Point for which it has no 131 neighborhood information available. In another scenario, the 132 neighborhood information maintained could be marked as stale using 133 some measure. Under these scenarios, if DNA protocol is available, 134 it can expedite FMIPv6 handover. 136 When a MN with no neighborhood information regains link connectivity, 137 it performs DNA movement detection to check if it has changed IP 138 subnet. DNA performs router discovery, and in the process learns new 139 subnet prefixes and router addresses. Subsequently, it runs address 140 configuration, and uses Optimistic DAD [2], and sends the FMIPv6 Fast 141 Binding Update (FBU) message to its previous access router (PAR). 142 This special-case of reactive handover is expected to be faster than 143 having to perform these operations in the absence of DNA protocol 144 enhancements. 146 4. Protocol Operation 148 The following are the steps that take place when an MN with no 149 neighborhood information attaches to an AP. 150 1. MN (re)associates with an Access Point (AP) and gets the AP-ID 151 (BSSID) 152 2. The MN searches for the [AP-ID, AR info] Tuple in its 153 neighborhood data structure corresponding to the AP-ID of the 154 Access Point it just (re)associated. If [AP-ID AR info] is 155 available, MN proceeds with the rest of the FMIPv6 protocol. If 156 the tuple info is not available, it invokes the DNA protocol (see 157 below). 159 3. The MN sends a Router Solicitation with DNA options (if any) to 160 determine if there is a subnet change and to acquire new prefixes 161 on the subnet. 162 4. The MN receives a DNA Router Advertisement, determines change in 163 subnet, configures new care of address and makes the address 164 optimistic [2]. 165 5. The MN sends a Fast Binding Update (FBU) to the Previous Access 166 Router (PAR) directly without being encapsulated in FNA. 167 6. The PAR should send a Handover Initiate (HI) message to the New 168 Access Router (NAR). 169 7. The NAR should send a Handover Acknowledge (HAck) message to the 170 PAR. 171 8. The PAR sends a Fast Binding Acknowledgement (FBack) message to 172 the MN on the new link. 173 9. The PAR starts tunneling the packets to the MN's new CoA. 175 5. IANA Considerations 177 There are no IANA considerations introduced by this draft. 179 6. Security Considerations 181 This draft is informational. Nevertheless, the security 182 considerations of the FMIPv6 protocol and the DNA protocol must be 183 taken into account. For instance, the FBU message mentioned above 184 needs to be protected using a security association between the MN and 185 the PAR. Similar considerations apply for the DNA protocols which 186 may be able to take advantage of SEND for Router Discovery, if 187 available [3]. 189 7. Acknowledgements 191 The authors would like to thank Greg Daley for his initiative, and 192 suggestions to improve this draft. 194 8. References 196 [1] Koodli, R., "Fast Handovers for Mobile IPv6, 197 draft-ietf-mipshop-fast-mipv6-03.txt (work in progress)", 198 October 2004. 200 [2] Moore, N., "Optimistic Duplicate Address Detection for IPv6, 201 draft-ietf-ipv6-optimistic-dad-05.txt (work in progress)", 202 February 2005. 204 [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 205 Neighbor Discovery (SEND)", RFC 3971, March 2005. 207 Authors' Addresses 209 Rajeev Koodli 210 Nokia Research Center 211 313 Fairchild Drive 212 Mountain View, CA 94043 USA 214 Phone: +1 650 625 2359 215 Email: Rajeev.Koodli@nokia.com 217 Syam Madanapalli 218 Samsung ISO 219 No. 3/1 Millers Road 220 Bangalore-560 052, India 222 Phone: +91 80 51197777 223 Email: syam@samsung.com 225 Intellectual Property Statement 227 The IETF takes no position regarding the validity or scope of any 228 Intellectual Property Rights or other rights that might be claimed to 229 pertain to the implementation or use of the technology described in 230 this document or the extent to which any license under such rights 231 might or might not be available; nor does it represent that it has 232 made any independent effort to identify any such rights. Information 233 on the procedures with respect to rights in RFC documents can be 234 found in BCP 78 and BCP 79. 236 Copies of IPR disclosures made to the IETF Secretariat and any 237 assurances of licenses to be made available, or the result of an 238 attempt made to obtain a general license or permission for the use of 239 such proprietary rights by implementers or users of this 240 specification can be obtained from the IETF on-line IPR repository at 241 http://www.ietf.org/ipr. 243 The IETF invites any interested party to bring to its attention any 244 copyrights, patents or patent applications, or other proprietary 245 rights that may cover technology that may be required to implement 246 this standard. Please address the information to the IETF at 247 ietf-ipr@ietf.org. 249 Disclaimer of Validity 251 This document and the information contained herein are provided on an 252 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 253 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 254 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 255 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 256 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 257 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 259 Copyright Statement 261 Copyright (C) The Internet Society (2005). This document is subject 262 to the rights, licenses and restrictions contained in BCP 78, and 263 except as set forth therein, the authors retain all their rights. 265 Acknowledgment 267 Funding for the RFC Editor function is currently provided by the 268 Internet Society.