idnits 2.17.00 (12 Aug 2021) /tmp/idnits40019/draft-cho-nemo-hmra-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 211: '...t unused field. It MUST be initialized...' RFC 2119 keyword, line 212: '...y the sender and MUST be ignored by th...' RFC 2119 keyword, line 220: '...fault router and SHOULD NOT appear on ...' 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 (January 13, 2004) is 6703 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) == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2463 (ref. '4') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2462 (ref. '5') (Obsoleted by RFC 4862) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group H. Cho 3 Internet-Draft E. K. Paik 4 Expires: July 13, 2004 Seoul National University 5 January 13, 2004 7 Hierarchical Mobile Router Advertisement for nested mobile networks 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes needs for hierarchical mobile router 39 advertisement for nested mobile networks. When ingress and egress 40 interfaces of a Mobile Router are both wireless, the MR cannot 41 distinguish the Router Advertisement of the parent MR from the RA 42 of the child MR. To maintain hierarchical information of wireless 43 nested mobile networks, RA message needs to be extended to deliver 44 additional information for hierarchy. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terms and Abbreviations. . . . . . . . . . . . . . . . . . . 3 52 3. Router Advertisement (RA) Confliction problem .br 53 in nested mobile networks. . . . . . . . . . . . . . . . . 3 55 4. Hierarchical Mobile Router Advertisement (HMRA). . . . . . . 4 56 4.1. Router Advertisement Message Format. . . . . . . . . . . . 4 57 4.2. Hierarchy management . . . . . . . . . . . . . . . . . . . 5 59 5. Security Considerations. . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 This document proposes the Router Advertisement mechanism called 70 Hierarchical Mobile Router Advertisement (HMRA) for nested mobile 71 networks. Mobile network is a network that the entire network 72 moves as a single unit and includes one or more mobile routers 73 (MRs) that connect it to the global Internet [1]. Mobile routers 74 use Mobile IPv6 protocol to broadcast Router Advertisement message. 75 Mobile Network Nodes (MNNs) under an MR can configure their address 76 and know the connectivity to the MR by listening the RA. Personal 77 Area Network (PAN) and Vehicle Area Network (VAN) connected to the 78 Internet are examples of mobile network. Furthermore, PANs in a 79 vehicle are also possible and this situation is referred to as a 80 nested mobile network. 82 Nested mobile networks contain MRs that are not directly attached 83 to the Internet (i.e. connected to the Internet via another MR). In 84 the case of nested mobile network, MRs also use Mobile IPv6 RA 85 mechanism. MRs have ingress and egress interfaces, and each 86 interface can be wired or wireless. If an MR uses wired ingress 87 interface, the RA of the MR is delivered to only nodes connected by 88 wire. But if an MR uses wireless ingress interfaces, all nodes in 89 its coverage receive the RA of the MR. So when a parent MR has 90 wireless egress interface and a child MR has wireless egress 91 interface, the parent MR can listen to the RA of the child MR. This 92 situation is called "RA Confliction". 94 2. Terms and Abbreviations 96 Age 97 Age is defined as decreasing value by the distance from AR. 99 Visiting Mobile Node (VMN) 100 A mobile node (MN), either a host or a router who can move 101 topologically with respect to the MR and whose home link 102 doesn't belong to the mobile network. A VMN that gets 103 attached to a foreign link within the mobile network 104 obtains an address on that link. [2] 106 3. Router Advertisement (RA) Confliction problem 108 When egress and ingress interfaces of an MR are both wireless, 109 nested mobile networks have Router Advertisement (RA) confliction 110 problem. When MRs form nested mobile networks, an MR receives RA 111 of the child MR as well as the parent MR for the open 112 characteristics of wireless interface. But the MR cannot 113 distinguish which MR is its parent. Figure 1 shows the RA 114 confliction problem. With existing RA scheme [3], MR2 receives both 115 RAs of MR1 and MR3. So MR2 may think it is under MR3. And in this 116 situation if MR2 wants to send data to the outside of mobile 117 network, the packets cannot be routed correctly. 119 +-----+ 120 | AR | Age = max_age max_age max_age max_age 121 +-----+ 122 | 123 +-----+ 124 | MR1 | Age = 0 max_age-1 max_age-1 max_age-1 125 +-----+ 126 | 127 +-----+ 128 | MR2 | Age = 0 0 max_age-2 max_age-2 129 +-----+ 130 | 131 +-----+ 132 | MR3 | Age = 0 0 0 max_age-3 133 +-----+ 135 Figure 1. RA Confliction problem 137 RA confliction problem occurs since MRs and ARs broadcast RA 138 messages simultaneously. Thus, additional information is needed in 139 RA message for the management of hierarchy between MRs. 141 4. Hierarchical Mobile Router Advertisement (HMRA) 143 To solve the RA confliction problem of nested mobile networks this 144 document proposes hierarchical architecture of RA, HMRA. HMRA is 145 based on the information of hierarchy. For the purpose of 146 hierarchical management, we employ a field for age in the RA 147 message. Initially Access Router (AR) has age of maximum value and 148 MRs have age of zero. The maximum value of age means the maximum 149 depth of hierarchy. 151 When an MR receives an RA with an age value, the MR compares 152 received age with its own age. So if the received age is less than 153 or equal to its own age, the MR just ignores the RA. And if 154 received age is bigger than its own age, the MR sets its own age to 155 smaller age than the received age by one. So each MR can construct 156 the parent-child relationship by using this age information. When 157 an MR moved to other network, we can know the movement by the 158 change of Care-of Address (CoA). So whenever an MR changes its 159 point of attachment, the MR re-initializes its age to zero and re- 160 calculates its age again using new RA. 162 4.1. Router Advertisement Message Format 164 Figure 2 shows the RA message format with age field. 166 0 1 2 3 167 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Type | Code | Checksum | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Cur Hop Limit |M|O| Age |Rsvd | Router Lifetime | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Reachable Time | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Retrans Timer | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Options ... 178 +-+-+-+-+-+-+-+-+-+-+-+- 180 Figure 2. Router Advertisement message with "Age" field 182 ICMP Fields: 184 Type 134 186 Code 0 188 Checksum The ICMP checksum. See [4]. 190 Cur Hop Limit 8-bit unsigned integer. The default value that 191 should be placed in the Hop Count field of the IP 192 header for outgoing IP packets. A value of zero 193 means unspecified (by this router). 195 M 1-bit "Managed address configuration" flag. When 196 set, hosts use the administered (stateful) protocol 197 for address autoconfiguration in addition to any 198 addresses autoconfigured using stateless address 199 autoconfiguration. The use of this flag is 200 described in [5]. 202 O 1-bit "Other stateful configuration" flag. When 203 set, hosts use the administered (stateful) protocol 204 for autoconfiguration of other (non-address) 205 information. The use of this flag is described in 206 [5]. 208 Age 3-bit "Age" field for HMRA. Initially Access Router 209 has age of maximum value and MRs have age of zero. 211 Rsvd A 3-bit unused field. It MUST be initialized 212 to zero by the sender and MUST be ignored by the 213 receiver. 215 Router Lifetime 216 16-bit unsigned integer. The lifetime associated 217 with the default router in units of seconds. The 218 maximum value corresponds to 18.2 hours. A 219 Lifetime of 0 indicates that the router is not a 220 default router and SHOULD NOT appear on the default 221 router list. 223 Reachable Time 32-bit unsigned integer. The time, in 224 milliseconds, that a node assumes a neighbor is 225 reachable after having received a reachability 226 confirmation. A value of zero means unspecified 227 (by this router). 229 Retrans Timer 32-bit unsigned integer. The time, in 230 milliseconds, between retransmitted Neighbor 231 Solicitation messages. A value of zero means 232 unspecified (by this router). 234 4.2. Hierarchy management 236 When an MR moves to the same level of other nested mobile network, 237 the MR sets its age to zero and listens RA from neighbor MRs. If 238 the MR receives RA from the child MR before it receives from the 239 parent MR, the MR thinks that the child MR is the parent. But after 240 the MR receives RA of the parent MR, the MR corrects its age. When 241 an N-level MR moves to an (N-1)-level mobile network, the MR 242 receives bigger or the same age of RA from neighbor MRs. In this 243 case re-initializing of age is not necessary. The MR just ignores 244 the RA of the same age and accepts the RA of bigger age and set its 245 age to smaller age than received age by one. When an N-level MR 246 moves to an (N+1)-level mobile network, the MR sets its age to zero 247 and listens to RA from the neighbor MRs. The next procedures are 248 the same as the two cases above. 250 5. Security Considerations 252 When a malicious MR broadcast RA with the maximum age, hierarchy of 253 nested mobile network can be confused. 255 6. Acknowledgements 257 This work was supported in part by the Brain Korea 21 project of 258 the Ministry of Education, and in part by the National Research 259 Laboratory project of the Ministry of Science and Technology, 260 Korea. 262 The authors would like to thank people who have given valuable 263 comments on various nested mobile network issues on the mailing 264 list. 266 References 268 [1] Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, 269 and Pascal Thubert, "Nemo Basic Support Protocol", 270 draft-ietf-nemo-basic-support-01.txt, September 2003, 271 work in progress. 273 [2] Thierry Ernst, and Hong-Yon Lach, 274 "Network Mobility Support Terminology", 275 draft-ietf-nemo-terminology-00.txt, May 2003, 276 work in progress. 278 [3] T. Narten, E. Nordmark, and W. Simpson, 279 "Neighbor Discovery for IP Version 6", RFC2461, 280 December 1998. 282 [4] Conta, A. and S. Deering, 283 "Internet Control Message Protocol (ICMPv6) 284 for the Internet Protocol Version 6 (IPv6) Specification", 285 RFC 2463, December 1998. 287 [5] Thomson, S. and T. Narten, "IPv6 Address Autoconfiguration", 288 RFC 2462, December 1998. 290 Authors' Addresses 292 Hosik Cho 293 Multimedia and Computer Communications Lab. 294 Seoul National University 295 ENG4190, School of Electronic Engineering and Computer Science 296 Seoul National University 297 Seoul 151-744, Korea 299 Phone: +82 2 880 1832 300 Fax: +82 2 872 2045 301 EMail: hscho@mmlab.snu.ac.kr 303 Eun Kyoung Paik 304 Multimedia and Computer Communications Lab. 305 Seoul National University 306 ENG4190, School of Electronic Engineering and Computer Science 307 Seoul National University 308 Seoul 151-744, Korea 310 Phone: +82 2 880 1832 311 Fax: +82 2 872 2045 312 EMail: eun@mmlab.snu.ac.kr