idnits 2.17.1 draft-thubert-nina-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1036. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1060. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (September 12, 2008) is 5704 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) ** Obsolete normative reference: RFC 3344 (ref. '3') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-07 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 3633 (ref. '9') (Obsoleted by RFC 8415) == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-07 == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-07 -- Obsolete informational reference (is this intentional?): RFC 4941 (ref. '22') (Obsoleted by RFC 8981) == Outdated reference: A later version (-05) exists of draft-bernardos-manet-autoconf-survey-03 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Thubert 3 Internet-Draft Cisco 4 Intended status: Standards Track C. Bernardos, Ed. 5 Expires: March 16, 2009 UC3M 6 September 12, 2008 8 Network In Node Advertisement 9 draft-thubert-nina-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 16, 2009. 36 Abstract 38 The Internet is evolving to become a more ubiquitous network, driven 39 by the low prices of wireless routers and access points and by the 40 users' requirements of connectivity anytime and anywhere. For that 41 reason, a cloud of nodes connected by wireless technology is being 42 created at the edge of the Internet. We refer to this cloud as a 43 Fringe Stub (FS). It is expected that networking in the FS will be 44 highly unmanaged and ad-hoc, but at the same time will need to offer 45 excellent service availability. The NEMO Basic Support protocol 46 could be used to provide global reachability for a mobile access 47 network within the FS and the Tree-Discovery mechanism could be used 48 to avoid the formation of loops in this highly unmanaged structure. 50 Since Internet connectivity in mobile scenarios can be costly, 51 limited or unavailable, there is a need to enable local routing 52 between the Mobile Routers within a portion of the FS. This form of 53 local routing is useful for Route Optimization (RO) between Mobile 54 Routers that are communicating directly in a portion of the FS. 56 Network In Node Advertisement (NINA) is the second of a 2-passes 57 routing protocol; a first pass, Tree Discovery, builds a loop-less 58 structure -- a tree --, and the second pass, NINA, exposes the Mobile 59 Network Prefixes (MNPs) up the tree. The protocol operates as a 60 multi-hop extension of Neighbor Discovery (ND), to populate TD-based 61 trees with prefixes, and establish routes towards the MNPs down the 62 tree, from the root-MR towards the MR that owns the prefix, whereas 63 the default route is oriented towards the root-MR. 65 The NINA protocol introduces a new option in the ND Neighbor 66 Advertisement (NA), the Network In Node Option (NINO). An NA with 67 NINO(s) is called a NINA (Network In Node Advertisement). NINA is 68 designed for a hierarchical model, and by using this NA based 69 approach it abstracts the embedded network of a Mobile Router as a 70 host to the upper level of network abstraction. With NINA, a Mobile 71 Router presents its sub-tree to its parent as an embedded network and 72 hides the inner topology and movements. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 4. Rationale for the proposed solution . . . . . . . . . . . . . 5 80 4.1. Why ND based . . . . . . . . . . . . . . . . . . . . . . . 5 81 4.2. Why NA based . . . . . . . . . . . . . . . . . . . . . . . 6 82 4.3. Relationship with TD . . . . . . . . . . . . . . . . . . . 6 83 4.4. Relationship with RRH . . . . . . . . . . . . . . . . . . 7 84 5. NINA Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 85 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 86 6.1. NINA message . . . . . . . . . . . . . . . . . . . . . . . 9 87 6.2. NINO IPv4 option . . . . . . . . . . . . . . . . . . . . . 12 88 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 13 89 7.1. Multicast TD RA messages from parent . . . . . . . . . . . 15 90 7.2. Unicast NINA messages from child to parent . . . . . . . . 15 91 7.3. Other events . . . . . . . . . . . . . . . . . . . . . . . 16 92 7.4. Aggregation of prefixes on a same MR . . . . . . . . . . . 17 93 7.5. Aggregation of prefixes by a parent acting as mobile 94 Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 7.6. Default value . . . . . . . . . . . . . . . . . . . . . . 18 96 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 18 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 99 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 102 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 103 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 21 104 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 106 Intellectual Property and Copyright Statements . . . . . . . . . . 24 108 1. Introduction 110 Mobile IP [3] allows transparent routing of IPv4 datagrams to mobile 111 nodes in the Internet. Mobile IPv6 (MIPv6) [4] extends this facility 112 for IPv6, and NEMO [5] enables it for mobile prefixes. In any case, 113 a mobile node is always identified by its Home Address (HoA), 114 regardless of its current point of attachment to the Internet. In 115 turn, MANET [11], [14] allows a set of unrelated nodes and routers to 116 discover their peers and establish communication. 118 Mobile Routers (MRs) may attach to other MRs and form a Care-of 119 Address (CoA) from a Mobile Network Prefix (MNP). As a result, MRs 120 are really MARs, Mobile Access Routers, because they can accept 121 connections from other MRs on their ingress interfaces. When Mobile 122 Routers attach to other Mobile Routers with a single Care-of Address 123 in a loop-less manner, they end up building trees. This process is 124 supported in Tree Discovery (TD) [6]. 126 This draft provides a minimum extension to IPv6 Neighbor Discovery 127 (ND) Neighbors Advertisements (NA) - called NINA (Network In Node 128 Advertisement) - extending RFC 4861 [2] and RFC 4191 [7] to add the 129 capability to include a prefix option - called NINO (Network In Node 130 Option) - in the NAs of the MR. This enables an MR to learn the 131 prefixes of all other MRs down its sub-tree. Note that NINO is 132 pronounced NEE-GNO and NINA is pronounced NEE-GNA. 134 A NEMO Mobile Router has a double behavior. On its egress 135 interfaces, which are used to backhaul the traffic to the Home 136 Network and the rest of the Internet, it is seen as a Mobile Node 137 (MN), performing the IPv6 and MIPv6 host-required features such as 138 neighbor and router discovery [2]. On the (ingress) interfaces to 139 the Mobile Networks, the Mobile Router behaves as an IPv6 router with 140 support of the MIPv6 requirements on routers. This is why TD [6] 141 extends ND RA over the ingress interface of a Mobile Router whereas 142 NINA extends ND NAs to advertise over the egress interface the 143 prefixes that are reachable via the MR. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [1]. 151 Readers are expected to be familiar with all the terms defined in the 152 RFC 3753 [10], the NEMO Terminology draft [19] and the MANEMO Problem 153 Statement draft [18]. 155 NINO (Network In Node Option): a new Neighbor Discovery (ND) 156 option that adds the capability to include a prefix option in 157 Neighbor Advertisements (NAs). 158 NINA (Network In Node Advertisement): a Neighbor Discovery (ND) 159 Neighbor Advertisement (NA) carrying a NINO. NINA is also used to 160 refer to the protocol itself (defined in this document). 162 3. Motivations 164 The Internet is evolving to become a more ubiquitous network, driven 165 by the low prices of wireless routers and access points and by the 166 users' requirements of connectivity anytime and anywhere. For that 167 reason, a cloud of nodes connected by wireless technology is being 168 created at the edge of the Internet. We refer to this cloud as a 169 Fringe Stub (FS). Examples of wireless technologies used within a FS 170 are wireless metropolitan and local area network protocols (WiMAX, 171 WLAN, 802.20, etc), short distance wireless technology (bluetooth, 172 IrDA, UWB), and radio mesh networks (e.g., 802.11s). It is expected 173 that networking in the FS will be highly unmanaged and ad-hoc, but at 174 the same time will need to offer excellent service availability. 176 The NEMO Basic Support protocol [5] could be used to provide global 177 reachability for a mobile access network within the FS. Analogously, 178 the Tree-Discovery mechanism [6] could be used to avoid the formation 179 of loops in this highly unmanaged structure. However, even with 180 these two technologies in place, packet delivery within the FS can 181 still be highly inefficient. Since Internet connectivity in mobile 182 scenarios can be costly, limited or unavailable, there is a need to 183 enable local routing between the Mobile Routers within a portion of 184 the FS. NINA can provide this form of local routing; it is an 185 example of Route Optimization (RO) between Mobile Routers that are 186 communicating directly in a portion of the Fringe Stub. This type of 187 solution can be considered to be a MANET for NEMO (MANEMO) approach 188 that aims to optimise the local routing in a Nested NEMO topology. 189 When a Fringe Stub is supported in this manner we refer to it as a 190 MANEMO Fringe Stub. 192 4. Rationale for the proposed solution 194 4.1. Why ND based 196 NINA extends the Neighbor Discovery protocol to address the MANEMO 197 requirements listed in [18], although MANET protocols [12], [15], 198 [16] provides similar features such as local routing and Internet 199 access over multihop. 201 One of the drawbacks of MANET protocols is the question of which 202 protocol should be used. AODV, DSR, DYMO, OLSR, etc. are 203 standardized in IETF and each has distinct features, like proactive 204 and reactive. In MANEMO scenarios, Mobile Routers, mobile hosts, and 205 fixed access routers are involved, and therefore, it is highly 206 important to deploy a consistent protocol in the network. On the 207 other hand, ND is a core component of IPv6 and is supported by all 208 IPv6 nodes. All IPv6 nodes can process a NINO(s) in ND messages if 209 desired. 211 As opposed to most MANET scenarios, MANEMO scenarios do not typically 212 require to establish direct communication with other nodes in the 213 MFS. Instead their typical form of communication is with nodes 214 located in the Internet. Therefore the default route they are 215 interested in establishing is the one between themselves and their 216 respective Gateway. It should be noted however that communication 217 may consequently take place between two nodes in an MFS, in this case 218 the MANEMO protocol should optimise the delivery of packets to ensure 219 that they at least are not transmitted beyond the Gateway. 221 4.2. Why NA based 223 Since an MR appears as a host on the egress interface side, it is 224 legitimate to use NA in the visited network. There are two reasons 225 for that: 226 o If an MR advertises itself as a router in the visited network 227 using RA, it might get used as a default router by Local Fixed 228 Nodes (LFNs) attached to the visited network and cause trouble. 229 o By using NINA, the whole part of the fringe behind the MR has the 230 footprint of a single host from the visited network standpoint 231 (and moves as a single host). 233 By using NINA on top of a TD established tree, MANEMO can be made to 234 reproduce the NEMO behavior for a whole subtree by reducing to a 235 single host footprint, and retain NEMO compatibility by avoiding 236 spurious RAs. Thus, a whole subtree can move within the fringe as a 237 single host. 239 4.3. Relationship with TD 241 NINA exploits the loop-less cluster established by Tree Discovery, so 242 it does not need to provide loop avoidance. 244 With TD, MRs setup a default route up the tree via the parent Access 245 Router, and all the packets are directed by default towards the 246 clusterhead (Top Level Mobile Router or root-MR in NEMO terms). To 247 provide complete reachability, it is enough for NINA to expose the 248 prefixes down the tree from any given MR, while propagating prefixes 249 information up the tree. 251 This allows an extreme conciseness of the routing information, with 252 no topological knowledge past the first hop. That conciseness 253 enables a high degree of movement within the nested structure; in 254 particular, a movement within a subtree is not seen outside of that 255 subtree, so most of the connectivity is maintained at all times while 256 there might never be such a thing as a convergence. 258 4.4. Relationship with RRH 260 The Reverse Routing Header (RRH) described in [17] operates in the 261 nested NEMO as a layer 3 Source Route Bridging (SRB) technique for 262 nested NEMO Route Optimization. It allows a quick reaction to inner 263 movements with the resolution of the packet; but the cost, an IPv6 264 address per packet per hop, might be deemed excessive. 266 Also, the Home Agent needs to cache the RRH in its binding cache, and 267 again, the overhead might be significant for a large deployment. 269 On the other hand, NINA establishes states in the intermediate nodes, 270 in a fashion similar to Transparent Bridging (TB), but at layer 3. 271 The integration of these 2 approaches allows switching between SRB to 272 TB models dynamically as the NINA states are populated or become 273 obsolete. To obtain this capability, the operation of an 274 intermediate MR described in [17] is altered in the following manner: 275 o If the MR has a (NINA) route to the upper entry in the RRH via the 276 source of the packet, it still updates the source of the packet 277 with its own Care-of Address, but does not save the previous 278 source as a new entry in the RRH. 279 o At best, if NINA has established states all along in a given 280 branch of the tree, the RRH for that branch has always 2 entries, 281 the first MR's Home Address, and its Care-of Address, regardless 282 of the depth of the first MR in the nested NEMO. 283 o When some MRs in the tree support NINA and some do not, the 284 resulting RRH will be only partly compressed. Also, if the NINA 285 route does not match the RRH, then the route is obsolete and the 286 source address is added to the RRH as described in [17], in order 287 to ensure a correct routing on the way back. When NINA catches 288 up, the entry will be saved again. 290 The integration of NINA and RRH can offer the best of 2 worlds: a 291 quick (per packet) resolution to the network changes, and the 292 transparent (stateful) operation when the NINA routing protocol 293 establishes the states in the nested NEMO. 295 5. NINA Overview 297 This section provides an overview of the operation of NINA to set-up 298 MNP route state in a nested-NEMO scenario. 300 NINA requires the Tree Discovery protocol to build and maintain a 301 tree topology. It relies on TD to discover that a change occurs in a 302 sub-tree of the topology, and that change triggers a flow of route 303 updates for that sub-tree in the topology. 305 +---------------------+ 306 | Internet |---CN 307 +---------------|-----+ 308 / Access Router 309 MR3_HA | 310 ======?====== 311 MR1 312 | 313 ====?=============?==============?=== 314 MR5 MR2 MR6 315 | | | 316 =========== ===?========= ============= 317 MR3 318 | 319 ==|=========?== 320 LFN1 MR4 321 | 322 ========= 324 Figure 1: Nested NEMO scenario 326 Each tree that TD self-forms is considered a separate routing 327 topology. If a Mobile Router belongs to multiple of such topologies, 328 then it is expected that both the NINA signaling and the data packets 329 are flagged to follow the topology for which the packet was 330 introduced in the network. 332 NINA expects a Mobile Router to own one or more Mobile Network 333 Prefix(es) that move with the MR. With that model, it is assumed 334 that there is a single source for the advertisement of a given prefix 335 within a topology. If multiple MRs share a given MNP, some protocol 336 must take place between those MRs to make sure that one and only one 337 MR advertises a given prefix in a given tree. 339 Tree Discovery formats the nested NEMO into a loop-less logical 340 graph, thus providing loop avoidance for the NINA protocol. Each 341 time a movement occurs, TD restores the loop-less structure before 342 NINA can operate again and repaint the graph with prefixes. 344 The root-MR of a nested NEMO is selected for a number of properties, 345 the primary one being an access to the wired infrastructure. It is 346 the default sink for every node in the tree. 348 More generally, the default gateway for a Mobile Router is its parent 349 up in the tree; the more specific routes, towards the Mobile Network 350 Prefixes, are always oriented down the tree, and NINA advertisements 351 flow up the tree towards the root-MR. 353 Each NINO contains a prefix and a sequence counter. The Mobile 354 Router that owns the prefix generates the NINO for that prefix, 355 including the sequence counter associated to that prefix and that is 356 incremented each time it generates a new NINO. 358 Due to a movement, a sub-tree can be temporarily out of sequence and 359 a NINO can be received from a sub-tree where the MR was but is no 360 more, until the parents realize it is gone. But by construction of 361 the tree, there can be a single route to a given prefix, so older 362 information is always invalid. 364 A parent-MR maintains a state for each prefix it learns from NINA. 365 In particular, the last sequence number is kept. An out-of-sequence 366 NINO must be disregarded. If the NINO appears valid, it is forwarded 367 to the parent's parent in the next burst, carried by a NINA, together 368 with the parent's own prefixes. 370 6. Message Formats 372 6.1. NINA message 374 NINA extends Neighbor Discovery [2] and RFC 4191 [7] to allow an MR 375 include a prefix option in the Neighbor Advertisements (NAs). The NA 376 is a necessary exchange that allows the AR to map the IPv6 address of 377 a node with its L2 address. The prefix option is normally present in 378 Router Advertisements (RAs) only. The meaning of such an option in a 379 NA is the concept of 'network in node', so we refer to this new ND 380 option as NINO (Network In Node Option) and we name the resulting 381 message NINA (Network In Node Advertisement). 383 When Tree Discovery is used to build a tree, there can be a single 384 route to a given prefix along that tree, so the freshest information 385 is always the best for unicast routes. In order to track that, the 386 NINO includes a sequence counter to the prefix advertisement. 388 The sequence counter is incremented by the source of the NINO, that 389 is the Mobile Router that owns the MNP, each time it issues a NINA, 390 and then forwarded as is up the tree. A depth is also added for 391 tracking purposes; the depth is incremented at each hop as the NINO 392 is propagated up the tree. 394 On an egress interface, if NINA is configured, the MR: 395 o selects an Access Router (AR) as its point of attachment to the 396 network 397 o auto-configures a Care-of Address (CoA) 398 o acts as a host as opposed to a router. In particular, it refrains 399 from sending RAs 400 o sends NINAs, as unicast, to its AR only 401 o accepts unicast NINAs from any node BUT its AR 403 On an ingress interface, if NINA is configured, the MR: 404 o acts as a router, may accept visitors 405 o sends RAs with the Tree Information Option (RA-TIO) 406 o accepts NINAs from any node 408 Every NA to the AR contains a NINO. In particular, receiving a Tree 409 Discovery RA-TIO from the AR stimulates the sending of a delayed NINA 410 back, with the collection of all known prefixes (that is the prefixes 411 learned from NINO and the connected prefixes). A NINA is also sent 412 to the AR once it has been selected as new AR after a movement, or 413 when the list of advertised prefixes has changed. 415 NINA may advertise positive (prefix is present) or negative (removed) 416 NINOs. A no-NINO is stimulated by the disappearance of a prefix 417 below. This is discovered by timing out after a request (a RA-TIO) 418 or by receiving a no-NINO. A no-NINO is a NINO with a NINO Lifetime 419 of 0. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Type | Length | Prefix Length |L| Reserved1 |4| 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | NINO Lifetime | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Reserved2 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | NINO Depth | Reserved3 | NINO Sequence | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 + + 434 | | 435 + Prefix (Variable Length) + 436 | | 437 + + 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Type: 442 NINO (number to be assigned by IANA). 444 Length: 445 8-bit unsigned integer. The length of the option (including the 446 Type and Length fields) in units of 8 octets. 448 Prefix Length: 449 Number of valid leading bits in the IPv6 Prefix. 451 Reserved1: 452 6-bit unused field. It MUST be initialized to zero by the sender 453 and MUST be ignored by the receiver. 455 'L' bit: 456 Indicates that the prefix or address is on-link as opposed to 457 another interface of the MR. This is useful for a child MR to 458 expose its IPv4 address on its egress interface. In that case, 459 the parent can set up forwarding to all the IPv4 prefixes in the 460 NINA via that address on this link. 462 '4' bit: 463 Indicates that the Prefix field carries an IPv4 mapped address. 465 NINO Lifetime: 466 32-bit unsigned integer. The length of time in seconds (relative 467 to the time the packet is sent) that the prefix is valid for route 468 determination. A value of all one bits (0xFFFFFFFF) represents 469 infinity. A value of all zero bits (0x00000000) indicates a loss 470 of reachability. 472 Reserved2: 473 32-bit unused field. It MUST be initialized to zero by the sender 474 and MUST be ignored by the receiver. 476 NINO Depth: 477 Set to 0 by the MR that owns the MNP and issues the NINO. 478 Incremented by all MRs that propagate the NINO. 480 Reserved3: 481 8-bit unused field. It MUST be initialized to zero by the sender 482 and MUST be ignored by the receiver. 484 NINO Sequence: 486 Incremented by the MR that owns the MNP for each new NINO for that 487 prefix. Left unchanged by all MRs that propagate the NINO. A 488 lollipop mechanism is used to wrap from 0xFFFF directly to 10. 490 Prefix: 491 Variable-length field containing an IPv6 address or a prefix of an 492 IPv6 address. The Prefix Length field contains the number of 493 valid leading bits in the prefix. The bits in the prefix after 494 the prefix length (if any) are reserved and MUST be initialized to 495 zero by the sender and ignored by the receiver. 497 6.2. NINO IPv4 option 499 NINA is defined for both IPv4 and IPv6 address families. 501 For IPv4, a new NINO IPv4 option is introduced to be included in RA 502 and NA messages, for a node to advertise its IPv4 address on the 503 interface where the ND message is issued. 505 The NINO IPv4 option can be included in an RA by the sending router 506 to expose its IPv4 address to the attached visitors, so they can 507 install a default route via that address and use the sending router 508 as default gateway. 510 The option can also be included in a NA by a visiting node to expose 511 its IPv4 address to the Attachment Router; this address is used as 512 next hop by the AR as it installs routes via the visiting node 513 towards the IPv4 prefixes contained in the NINOs and passed as mapped 514 addresses in the NA message. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type | Length | Reserved | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | IPv4 address on sending interface | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Type: 525 NINO IPv4 (number to be assigned by IANA). 527 Length: 528 8-bit unsigned integer. The length of the option (including the 529 Type and Length fields) in units of 8 octets. 531 Reserved: 533 8-bit unused field. It MUST be initialized to zero by the sender 534 and MUST be ignored by the receiver. 536 IPv4 address on sending interface: 537 32-bit field containing the IPv4 address of the sending interface. 539 7. Mobile Router Operation 541 The Mobile Router operation is autonomous, based on the information 542 provided by the potential Access Routers in sight. Each MR selects 543 an AR (a MAR) in a loop-less and case-optimized fashion, and installs 544 a default route up the tree via the selected AR. The resulting tree 545 (the cluster) may never be globally stable enough to be mapped in a 546 global graph. So the adaptation to local movements must be rapid and 547 localized. 549 When the Reverse Routing Header (RRH) is used for NEMO flows, it 550 allows the update to the path on a per packet basis. Hopefully, the 551 root of the tree (the clusterhead) is connected to the infrastructure 552 where Home can be reached, and can be used as a gateway to discover 553 Home. When the NEMO tunnel is established, it becomes the default 554 route for the MR. 556 If the tree is not connected to the infrastructure or in any case if 557 Home can not be reached, MRs need an ad-hoc protocol to establish 558 local connectivity. This specification takes advantage of the TD 559 cluster and allows an MR to discover the prefixes below itself. 561 NINA information can be redistributed in a routing protocol, MANET or 562 IGP. But the MANET or the IGP SHOULD NOT be redistributed into NINA. 563 This creates a hierarchy of routing protocols where NINA routes stand 564 somewhere between connected and IGP routes. 566 NINA also allows a compression of the Reverse Routing header when the 567 routes match the topology as traced by RRH on a per packet basis. In 568 particular, if a NINA route exists to the first entry in the RRH via 569 the source of the packet, then the MR can override the source of the 570 packet with its own CoA without adding the original source to the 571 RRH. At that point, the RRH operation becomes loose, in other words 572 an hybrid between transparent (stateful) and source routing. 574 As a result: 575 o Tree Discovery establishes a tree using extended Neighbor 576 Discovery RS/RA flows. 577 o The NEMO Basic Support protocol exploits the tree to get optimally 578 out of a nested set of MRs and register Home. 580 o RRH extends the NEMO Basic Support to provide Route Optimization 581 and faster path reestablishment. 582 o NINA also extends Neighbor Discovery in order to establish quickly 583 the routes down the cluster. 585 NINA maintains abstract lists of known prefixes. A prefix entry 586 contains the following abstract information: NINA maintains abstract 587 lists of known prefixes. NINA stores the prefix entries in either 588 one of 3 abstract lists; the Connected, the Reachable and the 589 Unreachable lists. A prefix entry contains the following abstract 590 information: 591 o A reference to the ND entry that was created for the advertiser 592 Neighbor. 593 o The IPv6 address of the advertiser Neighbor. 594 o The logical equivalent of the full NINA information. 595 o A reference to the interface of the advertiser Neighbor. 596 o A 'reported' Boolean to keep track whether this prefix was 597 reported already to the parent AR. 598 o A counter of retries to count how many RA-TIOs were sent on the 599 interface to the neighbor without reachability confirmation for 600 the prefix. 602 NINA stores the prefix entries in either one of 3 abstract lists; the 603 Connected, the Reachable and the Unreachable lists. 605 The Connected list corresponds to the MNP of the Mobile Router. 607 As long as an MR keeps receiving NINOs for a prefix timely, its 608 prefix entry is listed in the Reachable list. 610 Once scheduled to be destroyed, a prefix entry is moved to the 611 Unreachable list if the MR has a parent to which it sends NINOs, 612 otherwise the entry is cleaned up right away. The entry is removed 613 from the Unreachable list when the parent changes or when a no-NINO 614 is sent to the parent indicating the loss of the prefix. 616 NINA requires 2 timers; the DelayNA timer and the DestroyTimer. 617 o The DelayNA timer is armed upon a stimulation to send a NINA (such 618 as a TIO from the AR). When the timer is armed, all entries in 619 the Reachable list as well as all entries for Connected list are 620 set to not reported yet. 621 o The DelayNA timer has a duration that is DEF_NA_LATENCY divided by 622 2 with the tree depth. 624 o The DestroyTimer is armed when at least one entry has exhausted 625 its retries, which means that a number of RA-TIO were sent over 626 the ingress interface but that the entry was not confirmed with a 627 NINO. When the destroy timer elapses, for all exhausted entries, 628 the associated route is removed, and the entry is scheduled to be 629 destroyed. 630 o The Destroy timer has a duration of min (MAX_DESTROY_INTERVAL, 631 RA_INTERVAL). 633 7.1. Multicast TD RA messages from parent 635 When ND sends a NA to the AR, NINA extends the message with prefix 636 options for: 637 o All the prefixes that are not 'DELETED' for all the ingress 638 interfaces. 639 o All the prefixes in the removed list as no-NINO. 640 o All the prefixes in the advertised list that are not reported yet. 641 The entries are set to reported. 643 When ND receives a NA from a visitor over an ingress interface, NINOs 644 are processed in a loop. For known prefixes, the sequence counter in 645 the NINO is checked against the last received and the update is used 646 only if the sequence is newer. This filters out obsolete 647 advertisements when a prefix has moved between 2 subtrees attached to 648 a same node. 650 If a prefix is advertised as a no-NINO, the associated route is 651 removed, and the entry is transferred to the removed list. 652 Otherwise, the route table is looked up: 653 o If a preferred route to that prefix from another protocol already 654 exists, the prefix is ignored. 655 o If a new route can be created, a new prefix entry is allocated to 656 track it, as CONFIRMED, but not reported. 657 o If a NINA route existed already via the same Neighbor, it is 658 CONFIRMED. 659 o If a NINA route existed via a different Neighbor, this is 660 equivalent to a no-NINO for the previous entry followed by a new 661 NINO for the new entry. So the old entry is scheduled to be 662 destroyed, whereas the new one is installed. 664 7.2. Unicast NINA messages from child to parent 666 When sending NINA to its parent, an MR includes the NINOs about not 667 already reported prefix entries in the Reachable and Connected lists, 668 as well as no-NINOs for all the entries in the Unreachable list. 669 Depending on its policy, the receiving MR SHOULD install a route to 670 the prefix in the NINO via the link local address of the source MR 671 and it SHOULD propagate the information, either as a NINO or by means 672 of redistribution into a routing protocol. 674 The RA-TIO from the root-MR is used to synchronize the whole tree. 675 Its period is expected to range from 500ms to hours, depending on the 676 stability of the configuration and the bandwidth available. 678 When an MR receives a RA-TIO over an egress interface from the 679 current parent AR, the DelayNA is armed to force a full update. As 680 described in [6] the MR also issues a propagated RA-TIO over all its 681 ingress interfaces, after a small jitter that aims at minimizing 682 collisions of RA-TIO messages over the radio as it is propagated down 683 the tree. 685 The design choice behind this is NOT TO synchronize the parent and 686 children databases, but instead to update them regularly to cover 687 from the loss of packets. The rationale for that choice is movement. 688 If the topology can be expected to change frequently, synchronization 689 might be an excessive goal in terms of exchanges and protocol 690 complexity. This results in a simple protocol with no real peering. 692 When the MR sends a RA-TIO over an ingress interface, for all entries 693 on that interface: 694 o If the entry is CONFIRMED, it goes PENDING with the retry count 695 set to 0. 696 o If the entry is PENDING, the retry count is incremented. If it 697 reaches a maximum threshold, the entry goes ELAPSED If at least 698 one entry is ELAPSED at the end of the process: if the Destroy 699 timer is not running then it is armed with a jitter. 701 Since the DelayNA has a duration that decreases with the depth, it is 702 expected to receive all NINOs from all children before the timer 703 elapses and the full update is sent to the parent. 705 7.3. Other events 707 Finally, NINA listens to a series of events, such as: 708 o MR stopped or unable to run: NINA routes are cleaned up. NINA is 709 inactive. 710 o NINA operation stopped: All entries in the abstract lists are 711 freed. All the NINA routes are destroyed. 712 o Interface going down: for all entries in the Reachable list on 713 that interface, the associated route is removed, and the entry is 714 scheduled to be destroyed. 715 o Neighbor being removed from the ND list: if the entry is in the 716 Reachable list the associated route is removed, and the entry is 717 scheduled to be destroyed. 718 o Roaming: All entries in the Reachable list are set to not 719 'reported' and DelayNA is armed. 721 7.4. Aggregation of prefixes on a same MR 723 When deploying an MR with multiple ingress interfaces, it makes sense 724 to affect an aggregation prefix (shorter than /64) to the MR and 725 partition it as /64 prefixes over the MR interfaces. An MR that owns 726 a contiguous set of prefixes should only report the aggregation of 727 these prefixes through NINA. 729 7.5. Aggregation of prefixes by a parent acting as mobile Home 731 There are also a number of cases where a mobile aggregation is shared 732 within a toon of Mobile Routers. For instance, a toon formed by 733 firefighters and their commander. In that case, it is still possible 734 to use aggregation techniques with NINA and improve its scalability. 735 In that case, the commander is configured as the NINA aggregator for 736 the group prefix. In run time, it absorbs the individual NINO 737 information it receives from the toon members down its subtree and 738 only reports the aggregation up the TD tree. This works fine when 739 the whole toon is attached within the commander's subtree. 741 But other cases might occur for which additional support is required: 742 1. the commander is attached within the subtree of one of its toon 743 members. 744 2. A toon member is somewhere else within the TD tree. 745 3. A toon member is somewhere else in the Internet. 747 In all those cases, a node situated above the commander in the TD 748 tree but not above the toon member will see the advertisements for 749 the aggregation owned by the commander but not that of the individual 750 toon member prefix. So it will route all the packets for the toon 751 member towards the commander, but the commander will have no route to 752 the toon and will fail to forward. 754 Section 8 'Mobile Home' of RFC 4887 [20] proposes a deployment model 755 where a Mobile Router would also act as Home Agent for a mobile 756 aggregation. This method can be used in the general case 3 to ensure 757 routability to the toon member. With that method, the Home Link for 758 a toon member should be one of the commander links. The Tree 759 Discovery plug-in should favor that link so that many toon members 760 actually attach at Home. 762 If a toon member is not at Home, then it will register to its Home 763 Agent using NEMO basic support (RFC 3963 [5]). Depending of the 764 location of a source, a packet to the toon member will either go 765 directly to it, or go to its commander. If the toon member as a 766 Mobile Router is registered to its commander as its Home Agent, the 767 commander can always encapsulate the packet to the CoA of the toon 768 member using NEMO, and ensure reachability to the MR. 770 Section 2.7 of RFC 4888 [21] explains that in the specific case of 771 case 1), the commander will not be able to reach Home using plain 772 NEMO basic support, and an additional mechanism such as RRH ([17]) is 773 required to fix that issue. 775 Also specifically in case 1), the toon member will refrain from 776 adding the NINO options for its own prefixes that are aggregated in 777 the NINO option of its commander that it propagates up the TD tree. 779 7.6. Default value 781 DEF_NA_LATENCY = 150 ms 783 MAX_DESTROY_INTERVAL = 200ms 785 8. Privacy Considerations 787 It is already possible for a visiting Mobile Node (Mobile Router) to 788 autoconfigure an address that will not identify the visitor [22], 789 [13]. It is also possible for a visitor to roll its CoA periodically 790 even when it stays attached to a same point, and register the new 791 addresses as it forms them. 793 CIA (Capability, Innocuousness and Anonymity) properties demand also 794 that the visited party might not be identified by the visitor. To 795 achieve that, a Mobile Router should not advertise its MNPs on its 796 links open to untrusted visitors. 798 This draft recommends that the interface that is open for untrusted 799 visitors uses unique local addresses (RFC 4193 [8]) and rolls the 800 advertised prefixes with a short lifetime. This can be achieved for 801 instance by obtaining short lived leases from the Home Agent using 802 DHCP-PD [23]. 804 Another possibility is to use strict RRH routing [17]; in that case, 805 the prefix that is presented on the link can be taken from anywhere 806 in the ULA range since it is not used for routing outside the link. 808 Alternatively, a global unique prefix obtained from an autoconf 809 solution [24], [25] or DHCPv6 prefix delegation [9] can be used as 810 well. 812 9. IANA Considerations 814 This document requires IANA to assign a number for a new ND option 815 type (NINO NA). 817 10. Security Considerations 819 Exposing the MRs' MNPs within the MFS introduces several security 820 threats that should be carefully tackled, mainly derived from the 821 fact that MRs are distributing prefixes (i.e., their MNPs) that are 822 not topologically correct within the MFS. 824 To avoid these security issues -- that might enable malicious nodes 825 to steal traffic addressed to other nodes (by spoofing their 826 prefixes) -- Mobile Routers should be provided with some security 827 mechanisms, ensuring that an MR that is advertising a certain MNP is 828 actually authorized to do that. 830 The use of L2 trusts and policies, SeND or preconfigured security 831 relationships might help in securing the mechanism described in this 832 draft. Additionally, if MRs have connectivity with their Home 833 Agents, a modified Return Routability mechanism -- extended to 834 support prefix checks (such as [26] or [27]) -- may be used to 835 provide the required authorization, before starting to use the RO 836 shortcut within the MFS. 838 11. Acknowledgments 840 We would like to thank all the people who have provided comments on 841 this draft. 843 12. References 845 12.1. Normative References 847 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 848 Levels", BCP 14, RFC 2119, March 1997. 850 [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 851 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 852 September 2007. 854 [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 855 August 2002. 857 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 858 IPv6", RFC 3775, June 2004. 860 [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 861 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 862 January 2005. 864 [6] Thubert, P., Bontoux, C., Montavont, N., and B. McCarthy, 865 "Nested Nemo Tree Discovery", draft-thubert-tree-discovery-07 866 (work in progress), August 2008. 868 [7] Draves, R. and D. Thaler, "Default Router Preferences and More- 869 Specific Routes", RFC 4191, November 2005. 871 [8] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 872 Addresses", RFC 4193, October 2005. 874 [9] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 875 Configuration Protocol (DHCP) version 6", RFC 3633, 876 December 2003. 878 12.2. Informative References 880 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 881 RFC 3753, June 2004. 883 [11] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): 884 Routing Protocol Performance Issues and Evaluation 885 Considerations", RFC 2501, January 1999. 887 [12] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing 888 Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, 889 February 2007. 891 [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 892 Neighbor Discovery (SEND)", RFC 3971, March 2005. 894 [14] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 895 Network Architecture", draft-ietf-autoconf-manetarch-07 (work 896 in progress), November 2007. 898 [15] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized Link 899 State Routing Protocol version 2", draft-ietf-manet-olsrv2-07 900 (work in progress), July 2008. 902 [16] Clausen, T., Dearlove, C., and J. Dean, "MANET Neighborhood 903 Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-07 (work in 904 progress), July 2008. 906 [17] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 907 its application to Mobile Networks", 908 draft-thubert-nemo-reverse-routing-header-07 (work in 909 progress), February 2007. 911 [18] Wakikawa, R., "Problem Statement and Requirements for MANEMO", 912 draft-wakikawa-manemo-problem-statement-01 (work in progress), 913 July 2007. 915 [19] Ernst, T. and H-Y. Lach, "Network Mobility Support 916 Terminology", RFC 4885, July 2007. 918 [20] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network 919 Mobility Home Network Models", RFC 4887, July 2007. 921 [21] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 922 Route Optimization Problem Statement", RFC 4888, July 2007. 924 [22] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions 925 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 926 September 2007. 928 [23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 929 draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. 931 [24] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address 932 Autoconfiguration for MANET: Terminology and Problem 933 Statement", draft-ietf-autoconf-statement-04 (work in 934 progress), February 2008. 936 [25] Bernardos, C., Calderon, M., and H. Moustafa, "Survey of IP 937 address autoconfiguration mechanisms for MANETs", 938 draft-bernardos-manet-autoconf-survey-03 (work in progress), 939 April 2008. 941 [26] Ng, C., "Extending Return Routability Procedure for Network 942 Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress), 943 October 2004. 945 [27] Bernardos, C., Soto, I., Maria, M., Fernando, F., and A. 946 Arturo, "VARON: Vehicular Ad hoc Route Optimisation for NEMO", 947 Computer Communications, vol. 30, pp. 1765-1784 , 2007. 949 Appendix A. Contributors 951 Ryuji Wakikawa 952 Toyota ITC 953 6-6-20 Akasaka, Minato-ku 954 Tokyo 107-0052 955 Japan 956 Phone: +81-3-5561-8276 957 Fax: +81-3-5561-8292 958 Email: ryuji@jp.toyota-itc.com 960 Roberto Baldessari 961 NEC Europe Network Laboratories 962 Kurfuersten-anlage 36 963 Heidelberg 69115 964 Germany 965 Phone: +49 6221 4342167 966 Email: roberto.baldessari@netlab.nec.de 968 Jean Lorchat 969 Keio University and WIDE 970 5322 Endo Fujisawa Kanagawa 971 252-8520 972 JAPAN 973 Email: lorchat@sfc.wide.ad.jp 975 Ben McCarthy 976 Lancaster University 977 Computing Department 978 Infolab21, South Drive 979 Lancaster University 980 Lancaster LA1 4WA 981 UK 982 Phone: +44 1524 510 383 983 Email: b.mccarthy@lancaster.ac.uk 985 Appendix B. Change Log 987 Changes from -01 to -02: 988 o NINA IPv4 support: added IPv4 NINO ND option. 989 o References updated. 990 o Updated the location of the 'L' bit in the NINO NA option, to 991 match format of RFC 4861. 993 Changes from -00 to -01: 994 o Basic kiss (MR to MR over egress) sections removed. 995 o Added sections about aggregation of prefixes. 996 o Added Privacy consideration section. 997 o NINO NA message format changed. 998 o Some text cleanups. 1000 Authors' Addresses 1002 Pascal Thubert 1003 Cisco Systems 1004 Village d'Entreprises Green Side 1005 400, Avenue de Roumanille 1006 Batiment T3 1007 Biot - Sophia Antipolis 06410 1008 FRANCE 1010 Phone: +33 4 97 23 26 34 1011 Email: pthubert@cisco.com 1013 Carlos J. Bernardos (editor) 1014 Universidad Carlos III de Madrid 1015 Av. Universidad, 30 1016 Leganes, Madrid 28911 1017 Spain 1019 Phone: +34 91624 6236 1020 Email: cjbc@it.uc3m.es 1022 Full Copyright Statement 1024 Copyright (C) The IETF Trust (2008). 1026 This document is subject to the rights, licenses and restrictions 1027 contained in BCP 78, and except as set forth therein, the authors 1028 retain all their rights. 1030 This document and the information contained herein are provided on an 1031 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1032 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1033 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1034 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1035 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1036 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1038 Intellectual Property 1040 The IETF takes no position regarding the validity or scope of any 1041 Intellectual Property Rights or other rights that might be claimed to 1042 pertain to the implementation or use of the technology described in 1043 this document or the extent to which any license under such rights 1044 might or might not be available; nor does it represent that it has 1045 made any independent effort to identify any such rights. Information 1046 on the procedures with respect to rights in RFC documents can be 1047 found in BCP 78 and BCP 79. 1049 Copies of IPR disclosures made to the IETF Secretariat and any 1050 assurances of licenses to be made available, or the result of an 1051 attempt made to obtain a general license or permission for the use of 1052 such proprietary rights by implementers or users of this 1053 specification can be obtained from the IETF on-line IPR repository at 1054 http://www.ietf.org/ipr. 1056 The IETF invites any interested party to bring to its attention any 1057 copyrights, patents or patent applications, or other proprietary 1058 rights that may cover technology that may be required to implement 1059 this standard. Please address the information to the IETF at 1060 ietf-ipr@ietf.org.