idnits 2.17.1 draft-rja-ilnp-intro-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 17. -- Found old boilerplate from RFC 3978, Section 5.2b on line 484. -- Found old boilerplate from RFC 3978, Section 5.3 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 481. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (16 February 2008) is 5907 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'ABH07' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'Clark82' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'GSE' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'IEN-19' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'IEN-23' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'IEN-31' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'PHG02' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'Saltzer93' is defined on line 426, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Atkinson 3 draft-rja-ilnp-intro-00.txt Extreme Networks 4 Category: Experimental 5 Expires April 2007 16 February 2008 7 ILNP Concept of Operations 8 draft-rja-ilnp-intro-00.txt 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-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 material 26 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/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document is a contribution to the IRTF Routing Research Group. 37 It is NOT a contribution to the IETF or to any IETF Working Group 38 or to any IETF Area. 40 This documents the Concept of Operations for an experimental 41 extension to IPv6 which is known as the Identifier Locator 42 network protocol. 44 Table of Contents 46 1. Introduction ....................................................2 47 2. Transport Protocols..............................................4 48 3. Multi-Homing.....................................................5 49 4. Mobility.........................................................5 50 5. Localised Addressing.............................................6 51 6. IP Security Enhancements.........................................6 52 7. Backwards Compatibility & Incremental Deployment.................7 53 8. Security Considerations .........................................8 54 9. IANA Considerations .............................................9 55 10. References ......................................................9 57 1. Introduction 59 At present, the IRTF Routing Research Group is studying different 60 approaches to evolving the Internet Architecture. Several different 61 classes of evolution are being considered. One class is often called 62 "Map and Encapsulate", where traffic would be mapped and then 63 tunnelled through the inter-domain core of the Internet. Another 64 class being considered is sometimes known as "Identifier/Locator 65 Split". This document relates to a proposal that is in the latter 66 class of evoluationary approaches. 68 This architectural concept derives originally from a note by Dave 69 Clark to the IETF mailing list suggesting that the IPv6 address be 70 split into separate Identifier and Locator fields. Afterwards, Mike 71 O'Dell persued this concept in Internet-Drafts describing "GSE" or 72 "8+8".[8+8,GSE] More recently, the IRTF Namespace Research Group 73 (NSRG) studied this matter. Unusually for an IRTF RG, the NSRG 74 operated on the principle that unanimity was required for the NSRG to 75 make a recommendation. The author was a member of the IRTF NSRG. At 76 least one other proposal, the Host Identity Protocol (HIP), also 77 derives in part from the IRTF NSRG studies (and related antecedant 78 work). This current proposal differs from O'Dell's work in various 79 ways. 81 The crux of this proposal is to split each 128-bit IPv6 address into 82 two separate fields, with crisp semantics for each. It is worth 83 remembering here that an IPv6 address names a specific interface on a 84 node, since the new scheme will be different in that regard. 86 1 1 2 3 87 0 4 8 2 6 4 1 88 +---------------+-----------------+----------------+---------------+ 89 | Version| Traffic Class | Flow Label | 90 +---------------+-----------------+----------------+---------------+ 91 | Payload Length | Next Header | Hop Limit | 92 +---------------+-----------------+--------------------------------+ 93 | Source Address | 94 + + 95 | | 96 + + 97 | | 98 + + 99 | | 100 +---------------+-----------------+----------------+---------------+ 101 | Destination Address | 102 + + 103 | | 104 + + 105 | | 106 + + 107 | | 108 +---------------+-----------------+----------------+---------------+ 110 Figure 1: Existing ("Classic") IPv6 Header 112 The high-order 64-bits of the IPv6 address become the Locator. 113 The Locator indicates the subnetwork point of attachment for 114 a node. In essence, the Locator names a subnetwork. Locators 115 are also known as Routing Prefixes. 117 The low-order 64-bits of the IPv6 address become the Identifier. 118 The Identifier provides a fixed-length identity for a node, 119 rather than an identity for a specific interface of a node. 120 Identifiers are bound to nodes, not to interfaces, and are 121 in the same modified EUI-64 syntax already specified for IPv6. 122 Identifiers are unique within the context of a given Locator; 123 in many cases, Identifiers might happen to be globally unique, 124 but that is not a functional requirement for this proposal. 126 1 1 2 3 127 0 4 8 2 6 4 1 128 +---------------+-----------------+----------------+---------------+ 129 | Version| Traffic Class | Flow Label | 130 +---------------+-----------------+----------------+---------------+ 131 | Payload Length | Next Header | Hop Limit | 132 +---------------+-----------------+----------------+---------------+ 133 | Source Locator | 134 + + 135 | | 136 +---------------+-----------------+----------------+---------------+ 137 | Source Identifier | 138 + + 139 | | 140 +---------------+-----------------+----------------+---------------+ 141 | Destination Locator | 142 + + 143 | | 144 +---------------+-----------------+----------------+---------------+ 145 | Destination Identifier | 146 + + 147 | | 148 +---------------+-----------------+----------------+---------------+ 150 Figure 2: Enhanced IPv6 Header 152 Most commonly, a node's set of Identifiers are derived from 153 the IEEE 802 or IEEE 1394 MAC addresses associated with that 154 node. This use of MAC addresses to generate Identifiers is 155 convenient and is not required. Other methods also might be 156 used to generate Identifiers. 158 So this proposal enhances the architecture by adding crisp 159 clear semantics for the Identifier and for the Locator, 160 removing the semantically muddled IP address, and updating 161 end system protocols slightly, without requiring router 162 changes. With these enhancements, we have improved 163 architectural support not only for multi-homing, but also for 164 mobility, localised addressing, and IP Security. 166 2. Transport Protocols 168 At present, transport protocols include a pseudo-header that 169 includes certain network-layer fields, the IP addresses for 170 the session, in its calculation. 172 With this proposal, transport protocols include the Identifier 173 in their pseudo-header calculations, but do not include the 174 Locator in their pseudo-header calculations. To minimise the 175 changes required within transport protocol implementations, 176 when this proposal is in use for an IP session, the network 177 layer zeros the Locator fields before passing the information 178 up to the transport protocol in use. 180 3. Multi-Homing 182 Conceptually, there are two kinds of multi-homing. Site 183 multi-homing is when all nodes at a site are multi-homed 184 at the same time. This is what most people mean when they 185 talk about multi-homing. However, there is also a separate 186 concept of node multi-homing, where only a single node is 187 multi-homed. 189 At present, site multi-homing is common in the deployed 190 Internet. This is primarily achieved by advertising 191 the site's routing prefix(es) to more than upstream 192 Internet service provider at a given time. In turn, 193 this requires de-aggregation of routing prefixes within 194 the inter-domain routing system. In turn, this increases 195 the entropy of the inter-omain routing system (e.g. 196 RIB/FIB size increases beyond the minimal RIB/FIB 197 size that would be required to reach all sites). 199 When a node is multi-homed, it has more than one valid 200 Locator value. When one upstream connection fails, 201 the node sends an ICMP Locator Update message to each 202 existing correspondent node to remove the no-longer-valid 203 Locator from the set of valid Locators. The node also 204 will use Secure Dynamic DNS Update to alter the set of 205 currently valid L records associated with that node. 206 This second step ensures that any new correspondents can 207 reach the node.[ILNP-ICMP] 209 Site multi-homing works in a similar manner, with 210 nodes having one Locator for each upstream connection 211 to the Internet. To avoid a DNS Update burst when a 212 site or subnetwork moves location, a DNS record 213 optimisation is possible. This would change the 214 number of DNS Updates required from O(number of nodes 215 at the site/subnetwork that moved) to O(1). 217 4. Mobility 219 There are no standardised mechanisms to update transport 220 protocols with new IP addresses in use for the session 221 (SCTP might be an exception, depending on the progress 222 of a current Internet-Draft). 224 This creates various issues for mobility. For example, 225 there is no method at present to update the IP addresses 226 associated with a transport layer session when one of the 227 nodes in that session moves. So, the several approaches 228 to Mobile IP seek to hide the change in location (and 229 corresponding change in IP addresses) via tunnelling, 230 home agents, foreign agents, and so forth. All of this 231 can add substantial complexity to IP mobility approaches. 233 By contrast, this new proposal hides the nodes location 234 information from the transport layer protocols at all times. 235 In this proposal, mobility is supported using the same 236 mechanisms as multihoming. That is, the us of Locator values 237 to identify different IP subnetworks. To handle the move of 238 a node, we add a new ICMP control message. The ICMP Locator 239 Update message is used by a node to inform its existing 240 correspondents that the set of valid Locators for the node 241 has changed. This mechanism can be used to add newly valid 242 Locators, to remove no longer valid Locators, or to do both 243 at the same time. Further, the node uses Secure Dynamic DNS 244 Update to correct the set of L records in the DNS for that node. 245 This enables any new correspondents to correctly initiate a new 246 session with the node at its new location. 248 Note that we can (and do) treat network mobility (as well 249 as node mobility) as a special case of multihoming. That is, 250 when a network moves, it uses a new Locator value for all 251 of its communications sessions. So, the same mechanism, 252 using a new or additional Locator value, also supports 253 network mobility. 255 5. Localised Addressing 257 As the Locator value no longer forms part of the node 258 session state (e.g. TCP pseudo-header), it is easier 259 to implement localised addressing based on the use of 260 local values of the Locator. This would be either 261 in place of, or to supplement, existing NAT-based schemes. 262 In the simplest case, an ILNP capable NAT only would need 263 to change the value of the Source Locator in an outbound 264 packet, and the value of the Destination Locator for an 265 inbound packet. Identifier values would not need to change 266 so a true end-to-end session can be maintained. 268 Note that localised addressing would work in harmony 269 with multihoming, mobility, and IP Security. 271 6. IP Security Enhancements 273 The IP Security protocols, AH and ESP, should be 274 enhanced to bind Security Associations only to 275 Identifier values and never to Locator values 276 (and not to an entire 128 bit IPv6 address). 278 This small change enables IPsec to work in harmony 279 with multihoming, mobility, and localised addressing. 280 Further, it would obviate the need for specialised 281 IPsec NAT Traversal mechanisms, thus simplifying 282 IPsec implementations while enhancing deployability 283 and interoperability. 285 7. Backwards Compatibility & Incremental Deployment 287 First, if one comapres Figure 1 and Figure 2, one can see that 288 IPv6 with the Identifier/Locator Split enhancement is fully 289 backwards compatible with existing IPv6. This means that 290 no router software or silicon changes are necessary to 291 support the proposed enhancements. A router would be unaware 292 whether the packet being forwarded were classic IPv6 or the 293 proposed enhanced version of IPv6. 295 Further, IPv6 Neighbour Discovery should work fine without 296 any significant protocol changes. 298 If a node has been enhanced to support the Identifier/Locator 299 Split operating mode, that node's fully-qualified domain name 300 will normally have one or more I records and one or more L 301 records associated with it in the DNS. 303 When a host ("initiator') initiates a new IP session with a 304 correspondent ("responder"), it normally will perform a DNS 305 lookup to determine the address(es) of the responder. A host 306 that has been enhanced to support the Identifier/Locator Split 307 operating mode normally will look for Identifier ("I") and 308 Locator ("L") records in any received DNS replies. DNS servers 309 that support I and L records should include them (when they 310 exist) as additional data in all DNS replies to queries for 311 DNS AAAA records.[ILNP-DNS] 313 If the initiator supports the I/L Split mode and from DNS 314 information learns that the responder also supports the I/L 315 Split mode, then the initiator will generate an unpredictable 316 nonce value, store that value in a local session cache, and 317 will include the Nonce Destination Option in its initial 318 packet(s) to the responder.[ILNP-Nonce] 320 If the responder supports the I/L Split mode and receives 321 initial packet(s) containing the Nonce Destination Option, 322 the responder will thereby know that the initiator supports 323 the I/L Split mode and the responder will also operate in 324 I/L Split mode for this new IP session. 326 If the responder supports the I/L Split mode and receives 327 initial packet(s) NOT containing the Nonce Destination Option, 328 the responder will thereby know that the initiator does NOT 329 support the I/L Split mode and the responder will operate 330 in classic IPv6 mode for this new IP session. 332 If the responder does not support the I/L Split mode and 333 receives initial packet(s) containing the Nonce Destination 334 Option, the responder will drop the packet and send an 335 ICMP Parameter Problem error message back to the initiator. 337 If the initiator does not receive a response from the 338 responder in a timely manner (e.g. within TCP timeout 339 for a TCP session) and also does not receive an ICMP 340 Unreachable error message for that packet, OR if the 341 initiator receives an ICMP Parameter Problem error 342 message for that packet, then the initiator knows 343 that the responder is not able to support the I/L Split 344 Operating mode. In this case, the initiator should 345 try again to create the new IP session but this time 346 OMITTING the Nonce Destination Option. 348 8. Security Considerations 350 This proposal defines a new non-cryptographic Nonce 351 Destination Option. That nonce provides protection 352 against off-path attacks on an Identifier/Locator session. 353 The Nonce Destination Option is used ONLY for IP sessions 354 in the Identifier/Locator Split mode. 356 Ordinary IPv6 is vulnerable to on-path attacks unless 357 the IP Authentication Header or IP Encapsulating Security 358 Payload is in use. So the Nonce Destination Option 359 only seeks to provide protection against off-path attacks 360 on an IP session -- equivalent to ordinary IPv6 when 361 not using IP Security. 363 When the Identifier/Locator split mode is in use for an 364 existing IP session, the Nonce Destination Option must be 365 included in any ICMP control messages (e.g. ICMP Unreachable, 366 ICMP Locator Update) sent with regard to that IP session. 368 When in the I/L Split operating mode for an existing IP 369 session, ICMP control messages received without a Nonce 370 Destination Option must be discarded as forgeries. This 371 security event should be logged. 373 When in the I/L Split operating mode for an existing IP 374 session, ICMP control messages received without a correct 375 nonce value inside the Nonce Destination Option must be 376 discarded as forgeries. This security event should be logged. 378 For ID/Locator Split mode sessions operating in higher risk 379 environments, the use of the cryptographic authentication 380 provided by IP Authentication Header is recommended 381 *in addition* to concurrent use of the Nonce Destination 382 Option. 384 9. IANA Considerations 386 This document has no IANA considerations. 388 10. References 390 This section provides both normative and informative 391 references relating to this note. 393 10.1. Normative References 395 None at this time. 397 10.2. Informative References 399 [8+8] M. O'Dell, "8+8 - An Alternate Addressing 400 Architecture for IPv6", Internet-Draft, October 1996. 401 [ABH07] R. Atkinson, S. Bhatti, & S. Hailes, "Mobility 402 as an Integrated Service Through the Use of Naming", 403 Proceedings of ACM MobiArch 2007, August 2007, 404 Kyoto, Japan. 405 [Clark82] D.D. Clark, "Names, Addresses, Ports, and Routes", 406 RFC-814, July 1982. 407 [GSE] M. O'Dell, "GSE - An Alternate Addressing 408 Architecture for IPv6", Internet-Draft, 409 February 1997. 410 [IEN-19] J. F. Shoch, "Inter-Network Naming, Addressing, 411 and Routing", IEN-19, January 1978. 412 [IEN-23] J. F. Shoch, "On Names, Addresses, and Routings", 413 IEN-23, January 1978. 414 [IEN-31] D. Cohen, "On Names, Addresses, and Routings (II)", 415 IEN-31, April 1978. 416 [ILNP-Nonce] R. Atkinson, "Nonce Destination Option", 417 February 2008. 418 [ILNP-DNS] R. Atkinson, "DNS Resource Records for 419 Identifier/Locator Use", February 2008. 420 [ILNP-ICMP] R. Atkinson, "ICMP Locator Update message" 421 February 2008. 422 [PHG02] Pappas, A, S. Hailes, & R. Giaffreda, "Mobile Host 423 Location Tracking through DNS", Proceedings of 424 IEEE London Communications Symposium, IEEE, 425 September 2002, London, England, UK. 426 [Saltzer93] Saltzer, J, "On the Naming and Binding of Network 427 Destinations", RFC-1498, August 1993. 429 (Additional references to be added later.) 431 Author's Address 433 R. Atkinson 434 Extreme Networks 435 3585 Monroe Street 436 Santa Clara, CA 437 95051 USA 439 Telephone: +1 (408)579-2800 440 Email: rja@extremenetworks.com 442 Full Copyright Statement 444 "Copyright (C) The IETF Trust (2008). 446 This document is subject to the rights, licenses and restrictions 447 contained in BCP 78, and except as set forth therein, the authors 448 retain all their rights." 450 "This document and the information contained herein are provided 451 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 452 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 453 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 454 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 455 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 456 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 457 FOR A PARTICULAR PURPOSE." 459 Intellectual Property 461 The IETF takes no position regarding the validity or scope of any 462 Intellectual Property Rights or other rights that might be claimed 463 to pertain to the implementation or use of the technology 464 described in this document or the extent to which any license 465 under such rights might or might not be available; nor does it 466 represent that it has made any independent effort to identify any 467 such rights. Information on the procedures with respect to 468 rights in RFC documents can be found in BCP 78 and BCP 79. 470 Copies of IPR disclosures made to the IETF Secretariat and any 471 assurances of licenses to be made available, or the result of an 472 attempt made to obtain a general license or permission for the use 473 of such proprietary rights by implementers or users of this 474 specification can be obtained from the IETF on-line IPR repository 475 at http://www.ietf.org/ipr. 477 The IETF invites any interested party to bring to its attention 478 any copyrights, patents or patent applications, or other 479 proprietary rights that may cover technology that may be required 480 to implement this standard. Please address the information to the 481 IETF at ietf-ipr@ietf.org. 483 This document may not be modified, and derivative works of it 484 may not be created. 486 This document may only be posted in an Internet-Draft.