idnits 2.17.1 draft-mickles-v6ops-isp-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Abstract section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2003) is 7740 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) -- Missing reference section? '1' on line 459 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Cleve Mickles(Co-Author/Editor) 3 Document: draft-mickles-v6ops-isp-analysis-00.txt AOL Time Warner 4 Expires: Aug 2003 February 2003 6 Transition Analysis for ISP Networks 8 Status of this Memo 9 This document is an Internet-Draft and is subject to all 10 Provisions of Section 10 of RFC2026. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. Internet-Drafts 14 are draft documents valid for a maximum of six months and may be 15 updated, replaced, or obsoleted by other documents at any time. 16 It is inappropriate to use Internet-Drafts as reference material 17 or to cite them other than as "work in progress." 18 The list of current Internet-Drafts can be accessed at 19 http://www.ietf.org/ietf/1id-abstracts.txt 20 The list of Internet-Draft Shadow Directories can be accessed at 21 http://www.ietf.org/shadow.html. 22 Abstract 23 This document provides analysis of how to transition the different 24 types of Internet Service Provider (ISP) networks to IPv6. It 25 will provide design recommendations which may be followed to 26 successfully deploy IPv6 services on a network that began as an 27 IPv4 network. This is the companion document to 28 draft-mickles-v6ops-isp-scenarios-04.txt which provides detailed 29 background information on all scenarios. 31 mail list for the design team: IPV6@LISTSERV.SUP.AOL.COM 32 Transition Analysis for ISP Networks Feb. 2003 34 Table of Contents 35 1. Introduction................................................3 36 2. Scope of the document.......................................3 37 3. Core/Backbone Networks......................................4 38 3.1 IPv6 Routing Considerations..........................4 39 3.2 IPv6 Peering Considerations..........................5 40 3.3 IPv6 Transition Mechanisms...........................5 41 3.4 Security Considerations..............................6 42 3.5 Network Management...................................6 43 4. Broadband HFC/Coax Networks...............................7 44 4.1 IPv6 Routing Considerations..........................7 45 4.2 IPv6 Transition Mechanisms...........................7 46 4.3 Security Considerations..............................7 47 4.4 Network Management...................................7 48 5. Broadband DSL Networks.....................................8 49 5.1 IPv6 Routing Considerations..........................8 50 5.2 IPv6 Transition Mechanisms...........................8 51 5.3 Security Considerations..............................8 52 5.4 Network Management...................................8 53 6. Narrowband Dialup Networks.................................9 54 6.1 IPv6 Routing Considerations..........................9 55 6.2 IPv6 Transition Mechanisms..........................10 56 6.3 Security Considerations.............................10 57 6.4 Network Management..................................10 58 7. Public Wireless LAN.......................................11 59 7.1 IPv6 Routing Considerations.........................11 60 7.2 IPv6 Transition Mechanisms..........................11 61 7.3 Security Considerations.............................11 62 7.4 Network Management..................................11 63 8. Broadband Ethernet .......................................12 64 8.1 IPv6 Routing Considerations.........................12 65 8.2 IPv6 Transition Mechanisms..........................12 66 8.3 Security Considerations.............................12 67 8.4 Network Management..................................12 68 9. Internet Exchange Point...................................13 69 9.1 IPv6 Routing Considerations.........................13 70 9.2 IPv6 Transition Mechanisms..........................13 71 9.3 Security Considerations.............................13 72 9.4 Network Management..................................13 73 10.0 Security Considerations...................................14 74 11.0 Network Management Considerations.........................14 75 Acknowledgements..................................................14 76 References........................................................14 77 Terminology.......................................................14 78 Author's Addresses................................................15 80 Copyright 81 (C) The Internet Society (2003). All Rights Reserved. 83 Transition Analysis for ISP Networks Feb. 2003 85 1. Introduction 87 This document will provide analysis and recommendations for 88 ISPs to use in transitioning their existing IPv4 networks to 89 IPv6. It will show how existing mechanisms can be used to enable 90 IPv6 capabilities over IP networking components and highlight any 91 known challenges that may arise during a network transition. 93 2. Scope of the document 95 The scope of this document is to cover the major topics ISPs must 96 consider in transitioning their IP networks to IPv6. It is not 97 meant to address every detail provided in the scenario document, 98 but will highlight those details which are most important to the 99 transition. 101 Transition Analysis for ISP Networks Feb. 2003 103 3. Core/Backbone Networks 105 Transition to IPv6 in the Core network can be done in multiple 106 ways. The mechanisms discussed below are well known and the 107 discussion will be scoped based on the general topology below 108 in figure 3.1 110 Trunks to remote sites 112 ^ ^ 113 | | 114 / / 115 / / 116 /\/ / 117 / /\/ 118 / / 119 ____/____ ____/____ 120 | | | | 121 | CORE1 | | CORE2 | 122 |_________| |_________| 123 ____________/ | \ | | | 124 / | \ | | | 125 / +===========|===\=========+ | | 126 | / | +=\==========+ | 127 ___|_/_ ___|_/_ \ _____|_ 128 | | | | \____| | 129 | BDR1 | | BDR2 | | BDR(n)| 130 |_______| |_______| |_______|\ 131 | | | \ 132 | | | \ 133 | | | \_Peering( Direct & IX ) 134 | | | 135 ___|___ ___|__ ___|___ 136 | | | | | | 137 | CPE1 | | CPE2 | | CPE(n)| 138 |_______| |______| |_______| 140 Figure 3.1 142 3.1 IPv6 Routing Considerations 144 In this section we will discuss considerations for the IPv6 in the 145 internal network as well as the external networking issues. 147 Since IPv4 exists in the Core IGP, IPv6 capabilities must be added 148 Transition Analysis for ISP Networks Feb. 2003 150 while maintaining IPv4 reachability. In essence two IGP protocols 151 will exist in one routing domain. This mode is generally referred 152 to as dual-stack mode or "ships in the night" mode. This is not 153 an entirely new function of routers since running multiple routing 154 protocols on routers has been a fairly common practice. The 155 limitations for this practice include CPU power and memory. 157 To add IPv6 capability to the core network, IPv6 routes must be 158 present in the IGP. The choices of IGP for IPv6 networking 159 include ISIS and RIPv2. Ripv2 is the simplest solution. ISIS has 160 the advantage of being able to carry both IPv4 and IPv6 routes in 161 one IGP. OSPFv3 is a potential solution but is not currently 162 available and similar to RIPv2 in that it is not backward 163 compatible with OSPFv1 which supports IPv4 routes. 165 For networks which use OSPF as its IGP for IPv4 routes, the 166 recommendation is to continue carrying IPv4 routes in OSPFv1 and 167 configure IPv6 routes in ISIS. 169 For networks which use ISIS, the recommendation is to add IPv6 170 routes to the existing IGP and run IPv4 and IPv6 integrated within 171 ISIS. 173 As the IPv6 network grows, there will exist routers which are only 174 reachable via IPv6. 176 3.2 IPv6 Peering Considerations 178 Generally peering is done on border routers. The two choices for 179 IPv6 peering include deploying a separate border router for 180 external IPv6 peering or converting existing IPv4 peering routers 181 to support IPv6 and IPv4 peering. 183 In both cases the border routers will exchange IPv6 reachability 184 information using its IGP. 186 To exchange IPv6 traffic over an EGP boundary, the routing 187 protocol of choice remains BGP. The EGP boundary can be 188 established using either physical circuits or tunneled circuits 189 which are discussed below. The routing table for IPv6 routes is 190 separate from the table for Ipv4 routes. 192 3.3 IPv6 Transition Mechanisms 193 Once basic decisions about deploying IPv6 services have been 194 determined how to establish connectivity between IPv6 nodes is the 195 next step. Since the transition assumes an IPv4 network exists, 196 there will be transitional nodes which operate in dual stack mode. 198 There are two choices that may be used to inteconnect IPv6 199 capable nodes. The first is to use physical links between nodes. 201 Transition Analysis for ISP Networks Feb. 2003 203 This has been standard procedure in networking. Point-to-point or 204 LAN media may be used to establish connectivity and IPv6 205 addressing is configured over the link. The second choice is to 206 use "IPv4 over IPv4" tunneling mechanisms to route IPv6 traffic 207 over IPv4 networks. 209 3.4 Network Management 211 Since NM systems are used to monitor and configure networks, the 212 ability for NM systems to manage IPv6 capable routers must be 213 maintained. While NM systems will reach dual stack routers over 214 the IPv4 path, there will be routers which are only reacheable via 215 IPv6 and therefore NM systems must have an IPv6 presence to manage 216 those devices 218 3.5 Security Considerations 220 Route filtering techniques should continue to be done for IPv6. 222 IPv6 networks are open to hacking attempts just as IPv4 networks, 223 but the number of potential devices on a network make random port 224 scaning less effective. 226 Mickles, et al. Expires - Aug 2003 [Page 6] 227 Transition Analysis for ISP Networks Feb. 2003 229 4. Broadband HFC/Coax Networks 231 This section describes the infrastructure that exists in today's 232 HFC cable networks that support cable modem services to the home. 233 Since many cable providers are regional they generally have used 234 the backbone ISP networks for transit IP services beyond their 235 region. 237 +-----------+ 238 | | 239 | | 240 /-----+ | +--------+ 241 WAN <------+ CMTS |<========>| Modem |<===> CPE 242 \-----+ | Cable +--------+ | 243 | | | Network | 244 | | | | 245 | +-----------+ | 246 | | 247 +-------------------+------------------+ 248 | 249 "Transparent IP Traffic Through the System" 250 Figure 4.2.2 252 4.1 IPv6 Routing Considerations 253 4.2 IPv6 Transition Mechanisms 254 4.2.1 Dual Stack Mode 255 4.2.2 Tunneling 256 4.2.3 Physical 257 4.3 Network Management 258 4.4 Security Considerations 260 Mickles, et al. Expires - Aug 2003 [Page 7] 261 Transition Analysis for ISP Networks Feb. 2003 263 5. Broadband DSL Networks 265 This section describes the infrastructure that exists in todays 266 High Speed DSL Networks. 268 Customer Premises | Network Access Provider | Network Service Provider 269 CP NAP NSP 271 +-----+ +-----+ +-----+ 272 |Hosts|--| DSL +-------+DSLAM| 273 +-----+ |Modem| | +----+ 274 +-----+ +-----+ | 275 | 276 +-----+ +------+ | +-----+ +-------+ 277 |Hosts|--|Router| +--+ BAS +----+ ISP | ISP 278 +-----+ +--+---+ +--+ | | Edge +===> Network 279 | | +-----+ | Router| 280 +--+--+ | +-------+ 281 | DSL +---+ | 282 |Modem| | | 283 +-----+ | | 284 | +-----+ | 285 +-----+ +------+ +---+DSLAM+----+ 286 |Hosts|--|Router| +---+ | 287 +-----+ +--+---+ | +-----+ 288 | | 289 +--+--+ | 290 | DSL +---+ 291 |Modem| 292 +-----+ 294 Figure 5.1 296 5.1 IPv6 Routing Considerations 297 5.2 IPv6 Transition Mechanisms 298 5.2.1 Dual Stack Mode 299 5.2.2 Tunneling 300 5.3 Network Management 301 5.4 Security Considerations 303 Mickles, et al. Expires - Aug 2003 [Page 8] 304 Transition Analysis for ISP Networks Feb. 2003 306 6. Narrowband Dialup Networks 308 Transitioning the dial up ISP to IPv6 is somewhat straight forward 309 since the major network devices in this model reside on a single 310 LAN. 312 +-----+ +------+ +------+ 313 |Hosts|--| 56K +-------+Modem | +----------+ 314 +-----+ |Modem | |Bank +----------+ ISP 1 | NSP 1 315 +------+ +------+ | Edge +=====> Network 316 | | | Router | 317 | | +----------+ 318 | | 319 | | +----------+ 320 +-------+ +----------+ ISP 2 | NSP 2 321 |Radius | | | Edge +=====> Network 322 |Server | | | Router | 323 +-------+ | +----------+ 324 | 325 | +----------+ 326 +----------+ ISP 3 | NSP 3 327 | Edge +=====> Network 328 | Router | 329 +----------+ 331 Figure 6.1 333 6.1 IPv6 Routing Considerations 335 To establish IPv6 connectivity in the dial up environment, the 336 devices between the end user host and NSP Network router must be 337 IPv6 capable. The ISP edge router must be a dual-stack router. 338 The ISP edge router should have an IPv6 default route for global 339 IPv6 reachability. This can be accomplished via the existing 340 physical circuit to the NSP router if the NSP supports IPv6 or to 341 a separate NSP' which supports IPv6. An additional alternative is 342 for the ISP router to tunnel IPv6 traffic over IPv4 to an IPv6 343 router with global IPv6 reachability. 345 Mickles, et al. Expires - Aug 2003 [Page 9] 346 Transition Analysis for ISP Networks Feb. 2003 348 6.2 IPv6 Transition Mechanisms 349 In the dial up ISP environment the devices between the ISP router 350 and host appear to reside on the same LAN. Therefore the devices 351 on the LAN must support IPv6. 353 6.3 Network Management 355 Since NM systems are used to monitor and configure networks, the 356 ability for NM systems to manage IPv6 capable devices must be 357 maintained. While NM systems will reach dual stack devices over 358 the IPv4 path, there will be devices which are only reacheable via 359 IPv6 and therefore NM systems must have an IPv6 presence to manage 360 those devices. 362 6.4 Security Considerations 364 Route filtering techniques should continue to be done for IPv6. 366 IPv6 networks are open to hacking attempts just as IPv4 networks, 367 but the number of potential devices on a network make random port 368 scaning less effective. 370 Transition Analysis for ISP Networks Feb. 2003 372 7. Public Wireless LAN 374 This section describes the infrastructure that exists in today's 375 public wireless LAN services. 377 +-------+ 378 | AAA | 379 | Radius| 380 | TACACS| 381 '---' +-------+ 382 ( ) | 383 +-----+ (Wireless) +----+ /------------\ +-------+ 384 |Hosts+--( LAN )---| AP |----| Underlying \--- | ISP |=>Core 385 +-----+ ( ) +----+ \ technology | | Edge | 386 ( ) \-----------/ | Router| 387 '---' +-------+ 389 Figure 7.1.1. Physical architecture of WLAN model. 391 7.1 IPv6 Routing Considerations 392 7.2 IPv6 Transition Mechanisms 393 7.2.1 Dual Stack Mode 394 7.2.2 Tunneling 395 7.3 Network Management 396 7.4 Security Considerations 397 Transition Analysis for ISP Networks Feb. 2003 399 8.0 Broadband Ethernet 401 This section provides recommendations on how to transition 402 Ethernet based residential access networks to IPv6. 404 8.1 IPv6 Routing Considerations 405 8.2 IPv6 Transition Mechanisms 406 8.2.1 Dual Stack Mode 407 8.2.2 Tunneling 408 8.3 Network Management 409 8.4 Security Considerations 410 Transition Analysis for ISP Networks Feb. 2003 412 9.0 Internet Exchange (IX) 414 This section provides recommendations on how to transition IPv4 415 Internet exchanges (IX) to IPv6 exchanges. 417 ______________ 418 ____________ +----+ / \ 419 / \ / | +-( LHP2 router ) 420 ( LHP1 router )+ +--+----+ / \______________/ 421 \____________/ | |----+ 422 +---| L2 SW | 423 ______________ / | |-+ ______________ 424 / \+ +---+---+ \ / \ 425 ( LHP3 router ) | +( LHP4 router ) 426 \______________/ | \______________/ 427 +---+----+ 428 | | ____________ 429 | IX | / \ 430 | router +------(IX subscriber ) 431 | | \____________/ 432 +--------+ 434 Figure 9.1 436 9.1 IPv6 Routing Considerations 437 9.2 IPv6 Transition Mechanisms 438 9.2.1 Dual Stack Mode 439 9.2.2 Tunneling 440 9.3 Network Management 441 9.4 Security Considerations 442 Transition Analysis for ISP Networks Feb. 2003 444 10. SECURITY CONSIDERATIONS 446 Security concerns will be described within the context of each 447 scenario. After the various scenarios are documented, a 448 summarized section including all of the security considerations 449 may be provided. 451 11. NETWORK MANAGEMENT CONSIDERATIONS 453 Network Management concerns will be described within the context 454 of each scenario. After the various scenarios are documented, a 455 summarized section including all of the Network Management 456 considerations may be provided. 458 ACKNOWLEDGEMENTS 459 [1] The comments from the V6OPS working group are appreciated. 461 REFERENCES 463 [ISP Scenarios] Mickles, C., et al: "Transition Scenarios 464 for ISP Networks", February 2003, 465 draft-mickles-v6ops-isp-scenario-04.txt, work in progress. 467 [3gpp analysis] Wiljakka, J., et al: "Analysis on IPv6 468 Transition in 3GPP Networks", January 2003, 469 draft-ietf-v6ops-3gpp-analysis-01.txt, work in progress. 471 [Unman Scenarios] Huitema, C., et al: "Unmanaged Networks 472 IPv6 Transition Scenarios", January 2003, 473 draft-ietf-v6ops-unman-scenarios-00.txt, work in progress. 475 TERMS AND ACRONYMS 476 Transition Analysis for ISP Networks Feb. 2003 478 Author's Addresses 480 Vladimir Ksinant 481 6Wind 482 1 place Charles de Gaulle - 78180 Phone: +33139309236 483 Montigny Le Bretonneux - France Email:vladimir.ksinant@6wind.com 485 Jae-Hwoon Lee 486 Dongguk Univ. 487 26, 3 Pil-Dong, Chung-gu, Phone: +82 2 2260 3849 488 Seoul 100-715, Korea Email: jaehwoon@dgu.ac.kr 490 Myung-Ki Shin 491 ETRI PEC 492 161 Kajong-Dong, Yusong-Gu, Phone: +82 42 860 4847 493 Taejon 305-350, Korea Email: mkshin@pec.etri.re.kr 495 Aidan Williams 496 Motorola Australian Research Centre 497 Locked Bag 5028 Phone: +61 2 9666 0500 498 Botany, NSW 1455 Email: Aidan.Williams@motorola.com 499 Australia 500 URI: http://www.motorola.com.au/marc/ 502 Alain Baudot 503 France Telecom R&D 504 42, rue des coutures Phone: +33 2.31.75.94.27 505 BP 6243 Email: alain.baudot@rd.francetelecom.com 506 14066 Caen, FRANCE 508 Mikael Lind 509 Telia Research 510 Vitsandsgatan 9B 511 123 86 Farsta Phone: +46 70 2406140 512 Sweden Email: Mikael.e.lind@telia.se 514 Cleveland Mickles 515 America Online, Inc (owned by AOL Time Warner) 516 12100 Sunrise Valley Drive. Phone: +1 703-265-5618 517 Reston, VA 20191, USA Email: micklesc@aol.net