idnits 2.17.1 draft-ietf-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 on line 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 211. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 224. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No '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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 5. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [AP-ID,AR-Info], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 105 -- Looks like a reference, but probably isn't: 'AR-Info' on line 105 ** Downref: Normative reference to an Experimental draft: draft-ietf-mipshop-fast-mipv6 (ref. '1') == Outdated reference: A later version (-03) exists of draft-iesg-http-cookies-02 Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IPv6 Working Group Rajeev Koodli 2 INTERNET DRAFT Nokia Research Center 3 27 February 2006 Syam Madanapalli 4 Samsung 6 FMIPv6 Usage with DNA Protocol 7 draft-ietf-dna-fmip-00.txt 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note 16 that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is a submission of the IETF DNA WG. Comments should be 31 directed to the DNA WG mailing list, dna@eng.monash.edu.au. 33 Abstract 35 In this document, we describe how the Fast Mobile IPv6 Handovers 36 (FMIPv6) protocol can work where DNA protocol support is available, 37 but the neighborhood information, which is part of the FMIPv6 38 operation, is not available. 40 Contents 42 Abstract i 44 1. Introduction 1 46 2. FMIPv6 Operating Modes 2 48 3. FMIPv6 with DNA 2 50 4. Protocol Operation 3 52 5. IANA Considerations 4 54 6. Security Considerations 4 56 Intellectual Property Statement 4 58 Disclaimer of Validity 5 60 Copyright Statement 5 62 Acknowledgment 5 64 1. Introduction 66 The Fast Handovers for Mobile IPv6 [1] defines a protocol to 67 reduce delay and packet loss from IP protocol operations during a 68 handover. These protocol operations include movement detection, 69 IP configuration and location update with a distant mobility 70 agent such as a Home Agent. When route optimization is used, the 71 location update could be higher. The FMIPv6 protocol is designed 72 to effectively eliminate the delays due to movement detection and 73 IP configuration latencies, while disengaging the location update 74 latency from the time-critical path so that applications such as 75 Voice over IP are provided real-time mobility support. 77 The Detecting Network Attachment (DNA) WG is designing protocols to 78 quickly detect movement and establish IP connectivity as soon as 79 a mobile node is attaches to a new subnet. DNA protocols provide 80 faster and reliable mechanisms for determining the link identity 81 and router discovery on the new subnet. A DNA host uses the link 82 identifier or landmark to check for the subnet change. DNA routers 83 provide FastRA without Random Delay for hosts to discover new 84 router address and prefixes on the subnet. A host implementing DNA 85 mechanisms determines the subnet change and configures new care of 86 address significantly faster than non-DNA (unmodified) hosts on 87 networks with DNA support. 89 The purpose of this document is to illustrate how the FMIPv6 protocol 90 could make use of the DNA protocol to retain the desired handover 91 performance in certain circumstances. In order to do that, some 92 background on the two operating modes of the FMIPv6 protocol is 93 necessary. 95 2. FMIPv6 Operating Modes 97 The FMIPv6 protocol can effectively eliminate the movement detection 98 and IP configuration latencies when knowledge of the neighborhood 99 access points and their subnet affiliation is available. For 100 instance, a Mobile Node can query its access router to provide the 101 subnet prefix, IP address and MAC address of a target router attached 102 to a neighboring access point. With this information, it builds 103 a neighborhood map of Access Point Identifier to Access Router 104 Information. So, a conceptual neighborhood data structure consists 105 of [AP-ID, AR-Info] tuples, with each AR-Info structure consisting of 106 a router's IP address, MAC address and subnet prefix corresponding 107 to the interface to which the Access Point is attached to. Such a 108 neighborhood data structure serves two purposes: First, it allows 109 a MN to map an association to a new radio connection to subnet 110 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 120 on 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 130 may 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 verify roaming to a new subnet. 138 If it has moved to a new subnet, it performs DNA router discovery 139 to learn new subnet prefix and router addresses. Subsequently, it 140 runs Optimistic DAD [], and sends the FMIPv6 Fast Binding Update 141 (FBU) message to its previous access router. This special-case of 142 reactive handover is expected to be faster than having to perform 143 these operations in the absence of DNA protocol enhancements. 145 4. Protocol Operation 147 The following are the steps that take place when an MN with no 148 neighborhood information attaches to an AP. 150 1. MN (re)associates with an Access Point (AP) and gets the AP-ID 151 (BSSID) 153 2. The MN Looks for [AP-ID, AR info] Tuple and corresponding FMIPv6 154 state. If [AP-ID AR info] is available, MN proceeds with the 155 rest of the FMIPv6 protocol. If the tuple info is not available, 156 it invokes the DNA protocol (see below). 158 3. The MN sends a Router Solicitation with DNA options (if any) to 159 determine if there is a subnet change and to acquire new prefixes 160 on the subnet. 162 4. The MN receives a Fast Router Advertisement, determines change 163 in subnet, configures new care of address and makes the address 164 optimistic [2]. 166 5. The MN sends a Fast Binding Update (FBU) to the Previous Access 167 Router (PAR) directly without being encapsulated in FNA. 169 6. The PAR should send a Handover Initiate (HI) message to the New 170 Access Router (NAR). 172 7. The NAR should send a Handover Acknowledge (HAck) message to the 173 PAR. 175 8. The PAR sends a Fast Binding Acknowledgement (FBack) message to 176 the MN on the new link. 178 9. The PAR starts tunneling the packets to the MN's new CoA. 180 5. IANA Considerations 182 There are no IANA considerations introduced by this draft. 184 6. Security Considerations 186 This draft is informational. Nevertheless, the security 187 considerations of the FMIPv6 protocol and the DNA protocol must be 188 taken into account. For instance, the FBU message mentioned above 189 needs to be protected using a security association between the MN and 190 the PAR. Similar considerations apply for the DNA protocol. 192 References 194 [1] R. Koodli (Editor). Fast Handovers for Mobile IPv6 (work in 195 progress). Internet Draft, Internet Engineering Task Force. 196 draft-ietf-mipshop-fast-mipv6-03.txt, October 2005. 198 [2] N. Moore. Optimistic DAD for IPv6 (work in progress). Internet 199 Draft, Internet Engineering Task Force. 200 draft-iesg-http-cookies-02.txt, February 2005. 202 Intellectual Property Statement 204 The IETF takes no position regarding the validity or scope of any 205 Intellectual Property Rights or other rights that might be claimed to 206 pertain to the implementation or use of the technology described in 207 this document or the extent to which any license under such rights 208 might or might not be available; nor does it represent that it has 209 made any independent effort to identify any such rights. Information 210 on the procedures with respect to rights in RFC documents can be 211 found in BCP 78 and BCP 79. 213 Copies of IPR disclosures made to the IETF Secretariat and any 214 assurances of licenses to be made available, or the result of an 215 attempt made to obtain a general license or permission for the 216 use of such proprietary rights by implementers or users of this 217 specification can be obtained from the IETF on-line IPR repository at 218 http://www.ietf.org/ipr. 220 The IETF invites any interested party to bring to its attention any 221 copyrights, patents or patent applications, or other proprietary 222 rights that may cover technology that may be required to implement 223 this standard. Please address the information to the IETF at 224 ietf-ipr@ietf.org. 226 Disclaimer of Validity 228 This document and the information contained herein are provided 229 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 230 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 231 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 232 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 233 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 234 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 236 Copyright Statement 238 Copyright (C) The Internet Society (2006). This document is subject 239 to the rights, licenses and restrictions contained in BCP 78, and 240 except as set forth therein, the authors retain all their rights. 242 Acknowledgment 244 Funding for the RFC Editor function is currently provided by the 245 Internet Society.