idnits 2.17.1 draft-bagnulo-multi6-mhexthdr-00.txt: -(247): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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 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. ** There are 4 instances of too long lines in the document, the longest one being 28 characters in excess of 72. 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 (October 29, 2002) is 7850 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) == Unused Reference: '2' is defined on line 392, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft A. Garcia-Martinez 4 Expires: April 29, 2003 UC3M 5 October 29, 2002 7 Extension Header for Site-Multi-homing support 8 draft-bagnulo-multi6-mhexthdr-00 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 months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 29, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This note describes an IPv6 multi-homing solution that achieves 40 equivalent fault tolerance benefits to those provided by current IPv4 41 multi-homing solution while preserving the route aggregation 42 capabilities of the Provider-based Aggregation scheme. The solution 43 lies on the inclusion, in every packet flowing to a multi-homed site, 44 of an extension header containing multiple alternative route 45 information to the destination, so that if the original destination 46 address becomes unreachable, alternative route is used for reaching 47 the destination. 49 1. Introduction 51 This note describes an IPv6 multi-homing solution that achieves 52 equivalent fault tolerance benefits to those provided by current IPv4 53 multi-homing solution while preserving the route aggregation 54 capabilities of the Provider-based Aggregation scheme. The solution 55 lies on the inclusion, in every packet flowing to a multi-homed site, 56 of an extension header containing multiple alternative route 57 information to the destination, so that if the original destination 58 address becomes unreachable, alternative route is used for reaching 59 the destination. Additionally, a Destination option is defined (the 60 Alternative Prefix Destination Option) to convey multiple alternative 61 prefix information from a multi-homed host to the other end of the 62 communication. 64 2. Solution components 66 2.1 Alternative Prefix Destination option 68 The following destination option is defined: 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 | Option Type |Opt Data Len | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 | Reserved | 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 | Alternative Prefix #1 (64 bits) | 76 | | 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 . . . 79 . . . 80 . . . 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | Alternative Prefix #n (64 bits) | 83 | | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 Option Type value is 000xxxxx (in bits): The two highest order bits 87 set to O, so that if the option is not recognized, the option is 88 ignored and the packet is processed [1]. This allows that hosts not 89 implementing this solution to be capable of communication with hosts 90 which do implement the solution. Note that multi-homing benefits are 91 lost in this particular communication. The third bit is set to 0, 92 since the option data does not change in the route [1]. Remaining 93 bits are set to xxxxx (TBD by IANA) 95 Option Data Length value is 4n+2, since the option contains n 96 Alternative Prefixes, and each one has 4 octets and 2 octets to 97 preserve alignment. 99 Alternative Prefix field contains alternative Prefixes assigned to 100 the source interface other than the one included in the Source 101 Address field of the IPv6 header [1]. 103 The intended use of the above destination option is the communication 104 of multiple alternative routes to the multi-homed site, from a multi- 105 homed source node to a destination node. 107 2.2 Alternative Prefix Extension Header 109 A new Extension Header is defined with the following format: 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Next Header | Hdr Ext Len | Pleft | Reserved | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Reserved | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Alternative Prefix #1 (64 bits) | 117 | | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 . . . 120 . . . 121 . . . 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Alternative Prefix #n (64 bits) | 124 | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Next header value: 8-bit selector. Identifies the type of header 128 immediately following the Alternative Prefix Extension Header. 130 Hdr Ext Len: 8-bit unsigned integer. Length of the Alternative 131 Prefix Extension Header in 8-octet units, not including the first 8 132 octets. 134 Pleft: 8-bit unsigned integer. Number of Alternative Prefixes left, 135 i.e., number of Prefixes that have not been used for reaching the 136 final destination. 138 Alternative Prefix field contains alternative prefixes assigned to 139 the destination interface other than the one included in the 140 Destination Address field of the IPv6 header [1]. 142 The Alternative Prefix Extension Header is identified by a Next 143 Header value of xx (TBD by IANA) in the immediately preceding header. 145 The position of the new extension header relative to the ones already 146 defined is after the routing header and before the fragment header, 147 since it is to be processed by intermediate routers when no route to 148 destination is found. 150 The intended usage of the above Extension header is the following: 151 when a router receives a packet and it has no route to the address 152 contained in the destination field, the router must look for an 153 Alternative Prefix Extension Header. If such header is included in 154 the packet, and the value of Pleft is different than zero, then the 155 router must swap the 64 most significant bits of the Destination 156 address with the ones located in the position number (Ext Hdr Len 157 minus Pleft) of the extension header. Then the router must update 158 the Pleft by Pleft minus one. Finally, the router must try to 159 forward the packet to the new destination address. If there is no 160 Alternative Prefix Extension Header or the Pleft value is zero, then 161 the packet must be discarded and an ICMP error must be sent to the 162 source. 164 If (No Route to Destination) AND (Exists Alternative Prefix Extension Header) 165 then 166 { 167 if Pleft = 0 { 168 Discard packet 169 } 170 else { 171 if Pleft is greater than Hdr Ext Len 172 { 173 send an ICMP Parameter Problem, Code 0, message to the Source 174 Address, pointing to the Pleft field, and discard the 175 packet 176 } 177 else { 178 decrement Pleft by 1; 179 compute i, the index of the next Prefix to be used by subtracting Pleft from Hdr Ext Len 180 and swap the prefix of the IPv6 Destination Address and the Alternative Prefix #i 181 resubmit the packet to the IPv6 module for transmission 182 to the new destination 183 } 184 } 185 } 187 3. Solution description 189 3.1 Scenario Description 191 +-----+ 192 |Host1| 193 | | 194 +-----+ 195 | 196 ... 197 | 198 _______|_______________________________________ 199 | | 200 | | 201 | | 202 | +------------+ +------------+ | 203 | | PA::/nA | | PB::/nB | | 204 | | ISPA | DFZ | ISPB | | 205 | +------------+ +------------+ | 206 | | | | 207 |_______|_____________________________|________| 208 | | 209 | | ^ | | ^ 210 | | |PA:PC::/nC |link2| 211 0::/0| link1 | 0::/0| | |PB:PD::/nD 212 V | | V | | 213 +---------------+ +---------------+ 214 | ISPC | | ISPD | 215 | PA:PC::/nC | | PB:PD::/nD | 216 +---------------+ +---------------+ 217 | | 218 | | 219 | | 220 link3 link4 221 __|____________________________|___ 222 | RA RB | 223 | | 224 | Multi-homed end-site | 225 |PA:PC:PS1::/n1 Host2 | 226 |PB:PD:PS2::/n2 | 227 |___________________________________| 229 The considered scenario is as follows: 231 A Multi-homed end-site obtains global connectivity through two ISPs 232 i.e. ISPC and ISPD. These ISPs do not belong to the Default free 233 zone and they buy transit from ISPA and ISPB respectively. ISPA and 234 ISPB do belong to the Default Free Zone i.e. at least one of their 235 routers have full routing information. In the figure above, some of 236 the routing information exchanged between peers is included. Since 237 the end-site is multi-homed, it has obtained two address ranges: one 238 delegated from ISPC address range i.e. PA:PC:PS1::/n1 and the other 239 one from ISPD address space i.e. PB:PD:PS2::/n2. ISPC and ISPD have 240 obtained a range of the address space from the address range assigned 241 to their respective providers, i.e. ISPA and ISPB. So ISPA has 242 delegated the range PA:PC::/nC to ISPC and ISPB has delegated the 243 range PB:PD::/nD to ISPD. 245 3.2 Normal operation. 247 Let�s now consider the possible communication between Host1 (a given 248 host in the Internet) and Host2 (a host belonging to the multi-homed 249 end-site considered) 251 Since Host2 belongs to the Site, it has at least two addresses i.e. 252 PA:PC:PS1:PL1:IIdHost2 and PB:PD:PS2:PL2:IIdHost2, which will be 253 included in the DNS (if we suppose that Host2 wants to be reached 254 through the two providers). It should be noted that the solution 255 requires that all addresses of the same interface used in the 256 solution share the Interface identifier part 258 Communication initiated by Host2. 260 Host2 sends a packet to Host1 address and it includes a Alternative 261 Prefix Destination option with all the different prefixes it is 262 willing to use to receive replies to this packet. When Host1 263 replies, it addresses the packet to the source address included in 264 the first packet and it also includes in the reply packet an 265 Alternative Prefix Extension Header with the prefixes included in the 266 Alternative Prefix Destination option of the initial packet. When 267 Host2 receives the reply, it verifies that the destination address 268 and all the prefixes included in the Alternative Prefix Extension 269 Header are assigned to its interfaces. If at least one of the 270 derived addresses is not assigned to any of the interfaces, the 271 packet is discarded (See Security Considerations Section). Even if 272 different packets of a given communication may have different 273 destination addresses, Host2 must present them to its upper layer as 274 if they had the same destination address. This can be done since it 275 is possible to identify the original destination address used by 276 Host1 in the following way: If the Ext Hdr Len value in the 277 Alternative Prefix Extension Header is equal to the value of the 278 Pleft field, then the original Destination address is the one 279 included in the Destination Address field of the IPv6 header. If the 280 Ext Hdr Len value in the Alternative Prefix Extension Header is 281 greater than the value of the Pleft field, then the original 282 Destination address can be reconstructed by replacing the prefix of 283 the address included in the destination address field of the IPv6 284 header by the first prefix included in the Extension header. Then 285 the packet exchange will continue as above. 287 Communication initiated by Host1: 289 Host1 performs an A-type query to the DNS and it obtains two 290 addresses i.e. PA:PC:PS1:PL1:IIdHost2 and PB:PD:PS2:PL2:IIdHost2. 292 At this point Host1 can make two different uses of the obtained 293 information: 295 First option: Host1 uses one of the obtained addresses as the 296 destination address and it includes the other address in an 297 Alternative Prefix Extension Header. This option would provide the 298 same treatment for all the packets sent by Host1 and in particular it 299 would provide fault tolerance for this packet. However, this option 300 would imply some changes in the way applications manage multiple 301 addresses obtained from a DNS query. 303 Second option: The first packet is sent using available fault 304 tolerance capabilities when multiple addresses are available i.e. 305 Host1 sends a first packet with one of the obtained addresses and if 306 no reply is obtained it retries with an alternative address. When 307 finally a reply is received, an Alternative Prefix Destination Option 308 is included in it, so that alternative addresses are learned, as in 309 the previous case. 311 Eventually, in either case, packets flowing from Host1 to Host2 will 312 carry the Alternative Prefix Extension Header, and communication will 313 continue as detailed above. 315 3.3 Fault Tolerance Support 317 We will next study fault tolerance performance of the solution. 318 Let�s suppose that Host1 is sending packets to Host2 address 319 PA:PC:PS1:PL1:IIdHost2 and Link1 fails. In this case, when next 320 packets arrive to ISPA, there will be no route to the destination, so 321 the ISPA router with no route to destination in its routing tables 322 will look for an Alternative Prefix Extension Header in the packet. 323 If this header is found, it will be processed and the prefix of the 324 destination address will be replaced with the one found in the 325 extension header, and the packet will follow the alternative route 326 towards its destination. Some may argue that Alternative Prefix 327 Extension Header processing imposes an unacceptable load in routers, 328 specially in Core Routers. Another issue that could be raised, is 329 the need for upgrading all the routers of the ISP in order to be able 330 to process the newly defined Extension Header. A workaround for this 331 issues can be found by noting that the extension header processing 332 can be performed by specific upgraded routers connected to the ISP 333 network which would work in the following way: These upgraded routers 334 announce a default route (in our example, the upgraded router is 335 connected to the ISPA network and it announces the a route to 0/0). 336 Then if link1 is working properly, longest prefix match rule will 337 make packets flow through link1. If link1 is down, packets will be 338 forwarded to the upgraded router, that will process the Alternative 339 Prefix Extension Header, swapping prefix information. Once this is 340 done, it will forward the packet to the ISPA network, and then to the 341 alternative route. A slightly different approach is needed to 342 provide a sink route for packets with unreachable destination address 343 when link3 fails. Since ISPC obtains a default route from its 344 provider ISPA, it is not possible to announce a default route to sink 345 packets with unreachable destination, as in the previous case where 346 the ISP (ISPA) belongs to the default free zone. In this case, the 347 upgraded routers announce a route to the address range allocated to 348 the ISP (in our example, the upgraded router is connected to the ISPC 349 network and it announces the a route to PA:PC::/nC). Then if link3 350 is working properly, the longest prefix match rule will make packets 351 flow through link3. If link3 is down, packets will be forwarded to 352 the upgraded router, who will process the Alternative Prefix 353 Extension Header, swapping prefix information. Once this is done, it 354 will forward the packet to the ISPC network, and then to the 355 alternative route. 357 4. Security Considerations. 359 The extension header and the destination option defined above may 360 seem to introduce new security risks, since they seem to enable the 361 inclusion of spoofed alternative address. This would allow different 362 type of attacks such as communication hijacking. However, this 363 situation can detected by the host belonging to the multi-homed site, 364 since if any of the addresses included in the Alternative Prefix 365 Extension Header does not correspond to a configured one, the packet 366 will be discarded. This makes us to conclude that packets carrying 367 the newly defined option or header are not more susceptible to 368 attacks than regular unicast packets. It must be noted that both 369 types of packets are susceptible to man in the middle attacks, but 370 the goal of this solution is not improving security features but 371 avoiding the introduction of new security risks. 373 IPSec support: Alternative Prefix Destination option does not change 374 in route so interaction with IPSec is straightforward. Alternative 375 Prefix Extension Header can be modified en-route, as well as the 376 destination address of the IPv6 header during extension header 377 processing. However, original IPv6 header and extension header can 378 be reconstructed at the destination with the information included in 379 the packet, so this solution is compatible with IPSec. 381 5. Acknowledgements 383 We would like to thank Ignacio Soto, Juan Francisco Rodriguez 384 Hervella, Iljitsch van Beijnum and Michael Py for their reviews and 385 comments. 387 References 389 [1] Hinden, R. and S. Deering, "Internet Protocol, Version 6 (IPv6) 390 Specification", December 1998. 392 [2] Hinden, R. and S. Deering, "IP version 6 Addressing 393 Architecture", July 1998. 395 Authors' Addresses 397 Marcelo Bagnulo 398 Universidad Carlos III de Madrid 399 Av. Universidad 30 400 Leganes, Madrid 28911 401 SPAIN 403 Phone: 34 91 6249500 404 EMail: marcelo@it.uc3m.es 405 URI: http://www.it.uc3m.es/marcelo 407 Alberto Garcia-Martinez 408 Universidad Carlos III de Madrid 409 Av. Universidad 30 410 Leganes, Madrid 28911 411 SPAIN 413 Phone: 34 91 6249500 414 EMail: alberto@it.uc3m.es 415 URI: http://www.it.uc3m.es/alberto 417 Full Copyright Statement 419 Copyright (C) The Internet Society (2002). All Rights Reserved. 421 This document and translations of it may be copied and furnished to 422 others, and derivative works that comment on or otherwise explain it 423 or assist in its implementation may be prepared, copied, published 424 and distributed, in whole or in part, without restriction of any 425 kind, provided that the above copyright notice and this paragraph are 426 included on all such copies and derivative works. However, this 427 document itself may not be modified in any way, such as by removing 428 the copyright notice or references to the Internet Society or other 429 Internet organizations, except as needed for the purpose of 430 developing Internet standards in which case the procedures for 431 copyrights defined in the Internet Standards process must be 432 followed, or as required to translate it into languages other than 433 English. 435 The limited permissions granted above are perpetual and will not be 436 revoked by the Internet Society or its successors or assigns. 438 This document and the information contained herein is provided on an 439 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 440 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 441 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 442 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 443 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 445 Acknowledgement 447 Funding for the RFC Editor function is currently provided by the 448 Internet Society.