idnits 2.17.1 draft-morelli-v6ops-ipv6-ix-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.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1115. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1131), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (July 12, 2004) is 7228 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: '16' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1048, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. '1') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2374 (ref. '2') (Obsoleted by RFC 3587) -- Obsolete informational reference (is this intentional?): RFC 3177 (ref. '3') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 1863 (ref. '4') (Obsoleted by RFC 4223) == Outdated reference: A later version (-02) exists of draft-bhatia-ecmp-routes-in-bgp-00 -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '7') (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '11') (Obsoleted by RFC 7526) == Outdated reference: A later version (-03) exists of draft-palet-v6ops-tun-auto-disc-01 == Outdated reference: A later version (-02) exists of draft-palet-v6ops-auto-trans-00 == Outdated reference: A later version (-03) exists of draft-vives-v6ops-ipv6-security-ps-00 == Outdated reference: A later version (-02) exists of draft-palet-v6ops-ipv6security-00 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Morelli 3 Internet-Draft Telecom Italia Lab. 4 Expires: January 10, 2005 J. Palet 5 Consulintel 6 D. Fernandez 7 Technical Univ. of Madrid (UPM) 8 A. Gomez 9 University of Murcia (UMU) 10 July 12, 2004 12 Advanced IPv6 Internet Exchange model 13 draft-morelli-v6ops-ipv6-ix-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 10, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 Abstract 48 Internet Exchanges (IX) have played a key role in the development of 49 Internet, organizing and coordinating the traffic interchange among 50 Internet Service Providers (ISP). Traditionally, IXs have been based 51 on layer 2 infrastructures, being the layer 3 services managed by the 52 participant ISPs. 54 However, IPv6 hierarchical and aggregatable routing and addressing 55 model comes to enhance the IX functionalities by proposing to 56 directly assign addresses to IX customer's networks. The customers 57 can connect with one or several upstream providers and have a 58 separated addressing space, dependent on the IX instead of the 59 providers, in order to facilitate multihoming or avoid renumbering 60 procedures when changing the provider. 62 In addition, being an IX a central point where traffic is 63 concentrated, several networks and application services benefit from 64 the fact of being partial or totally offered from an IX, opening the 65 IX to the world of new advanced services and functionalities like 66 security, AAA, QoS, multicast, mobility, PKI, DNSSEC or policy 67 provision, that could also facilitate the deployment of IPv6 and 68 their required transition mechanisms. 70 This document describes an architectural model for an advanced IPv6 71 Internet Exchange that offers IPv6 address delegation services, as 72 well as other advanced network and application services. The 73 document discusses also about how these services can be offered from 74 an IX and their associated requirements. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Reference Scenario . . . . . . . . . . . . . . . . . . . . . . 6 81 4. Relationship with the traditional IX model . . . . . . . . . . 7 82 5. Overview of the new advanced IPv6 IX model . . . . . . . . . . 7 83 5.1 Layer 2 infrastructure . . . . . . . . . . . . . . . . . . 9 84 5.2 Layer 3 infrastructure . . . . . . . . . . . . . . . . . . 9 85 5.3 Server Farm . . . . . . . . . . . . . . . . . . . . . . . 10 86 6. Advanced IPv6 IX Services . . . . . . . . . . . . . . . . . . 10 87 6.1 Network services . . . . . . . . . . . . . . . . . . . . . 10 88 6.1.1 Address Delegation . . . . . . . . . . . . . . . . . . 10 89 6.1.2 Route Server . . . . . . . . . . . . . . . . . . . . . 12 90 6.1.3 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 6.1.4 AAA Services . . . . . . . . . . . . . . . . . . . . . 15 92 6.1.5 Multicast . . . . . . . . . . . . . . . . . . . . . . 17 93 6.1.6 Mobility . . . . . . . . . . . . . . . . . . . . . . . 18 94 6.1.7 Multihoming . . . . . . . . . . . . . . . . . . . . . 18 95 6.1.8 DNS . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 6.2 Transition services . . . . . . . . . . . . . . . . . . . 18 97 6.3 Support and policy-based management services . . . . . . . 19 98 6.4 Security services . . . . . . . . . . . . . . . . . . . . 20 99 6.4.1 PKI . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 6.4.2 DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 20 101 6.4.3 Distributed security . . . . . . . . . . . . . . . . . 20 102 6.5 Other services . . . . . . . . . . . . . . . . . . . . . . 21 103 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 106 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 107 11. Informative References . . . . . . . . . . . . . . . . . . . 22 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 109 Intellectual Property and Copyright Statements . . . . . . . . 25 111 1. Introduction 113 In recent years, Internet Exchanges (IX) and Network Access Points 114 (NAP) have played a key role in the development of Internet. 116 An IX is commonly a neutral point where different Internet Service 117 Providers (ISP) deploy their routers in order to exchange their 118 traffic according to some kind of commercial and peering agreements 119 (i.e. public peering agreement). 121 A NAP is basically an enhancement of the IX concept that, apart from 122 a place to host bilateral peering arrangements between similar 123 providers, it takes the role of a transit purchase venue, where 124 regional ISPs can acquire transit services from long-haul or transit 125 providers. 127 Although there are differences between an IX and a NAP, in the 128 context of this document we will use the term IX to refer to both of 129 them. As described later, the IX model presented here can be 130 classified as an enhanced NAP, adding new services like IPv6 address 131 delegation to a classical NAP. 133 An IX is usually based on a layer 2 infrastructure, fully redundant 134 and made of high performance switches, where ISPs layer 3 equipment 135 (routers) connect to. 137 Typically, IXs do not provide any layer 3 services to their 138 customers, apart from route servers or other specific functions that 139 help to organize and simplify routing in the IX. Other services, 140 like AAA or multicast, are normally offered by each ISP. 142 However, being the IX a central point where the traffic is 143 concentrated, several network and application services being offered 144 nowadays would benefit from being partially or totally supported in 145 the IX itself. 147 On the other hand, IPv6 proposes a strictly hierarchical routing and 148 addressing model that essentially follows the principles stated in 149 CIDR [1]: hierarchical assignment of addresses and routing based on 150 aggregation. The addresses assigned to an organization depend on the 151 point they connect to the Internet. As a consequence, if the site 152 changes its provider, its global prefix must be changed according to 153 its new location in the global topology. 155 In order to avoid renumbering when changing provider, IPv6 routing 156 model [2] proposes a new way of assigning addresses based on IXs. It 157 basically consists on delegating prefixes to IXs that are later 158 sub-assigned to organizations connecting to the IX. In this way, the 159 address assignment is decoupled from the connectivity provision, 160 taking the IX the role of address provider. 162 This new IPv6 IX based addressing model, as well as the advantages of 163 locating network and application services inside the IXs, bring new 164 possibilities for the design of new advanced IPv6 Internet Exchanges 165 architectures, opening the providers market to new opportunities and 166 actors. 168 Therefore, this document extensively describes an advanced IPv6 IX 169 model and their requirements, providing details about the different 170 ways customers can access IX services, the way routing is organized 171 between customers and providers, as well as a list of services that 172 benefit from being offered from the IX and the way they can be 173 organized and operated. 175 2. Terminology 177 o Address Delegation (AD): The process by which an IX assigns 178 address space to an IXC. 180 o Customer Exchange Routers (CER): The routers used to connect IX 181 customers to the IX. 183 o Internet Exchange (IX): It refers to a generalized exchange point 184 including basic peering functionalities, as well as transit 185 purchase services found in NAPs 187 o IX Address Prefix: An IPv6 address prefix assigned by a Regional 188 Registry to the IX with the objective to be later sub-delegated to 189 IX customers. 191 o IX Administrator: The entity in charge of IX management. 193 o IX Customer (IXC): A customer network that uses an IPv6 address 194 prefix sub-delegated from an IX Address Prefix. 196 o IX Local Customer (IXLC): An IXC which is directly connected to 197 the IX through a router that can be either managed by the IX 198 administrator or by the customer. 200 o IX Remote Customer (IXRC): An IXC which is not directly connected 201 to the IX, but through a regional provider present on the IX. The 202 regional provider manages the distribution of the customer IX 203 sub-prefix through its network. 205 o IX Value Added Services: Network and application services offered 206 by the IX to its customers and/or providers peering on the IX. 208 o Layer 3 Mediation Function (L3MF): An entity acting as the 209 intermediary between IX customers and providers. 211 o Long Haul Provider (LHP): An Internet Service Provider (ISP) 212 present on the IX that provides transit services to IX customers 213 and regional providers. 215 o Regional Provider (RP): An Internet Service Provider that peers 216 with other providers at the IX and optionally gets transit 217 services from LHP. 219 3. Reference Scenario 221 The following figure describes the main reference scenario of the 222 advanced IPv6 Internet Exchange model defined in this document. 224 Long Haul Providers 225 +------+ +------+ 226 | LHP1 |...| LHPm | 227 +------+ +------+ 228 | | 229 +------------------|--------|----------------+ 230 | +----+ +----+ | 231 | IX | R1 |...| Rm | | 232 | +----+ +----+ | 233 | | | | IX Customers 234 |+----------+ +-----------------+ +------+ | +-------+ 235 || | | |--| CER1 |-|-| IXLC1 | 236 || Value | | Layer Three | +------+ | +-------+ 237 || Added |--| Mediation | : | : 238 || Services | | Function | +------+ | +-------+ 239 || | | |--| CERn |-|-| IXLCn | 240 |+----------+ +-----------------+ +------+ | +-------+ 241 | | | | 242 | +----+ +----+ | 243 | | R1 |...| Rk | | 244 | +----+ +----+ | 245 +------------------|-------|-----------------+ 246 | | 247 +--------+ +--------+ 248 | RP1 | | RPk | 249 | | | | 250 | +-----+|...| +-----+| 251 | |IXRC1|| | |IXRCk|| 252 | +-----+| | +-----+| 253 +--------+ +--------+ 254 Regional Providers 256 The IX is made of: 258 o A classical L2 infrastructure (i.e, a high speed LAN), not 259 represented on the figure. 261 o ISP routers (R), that connect ISP networks to the IX. 263 o Customer Exchange Routers (CER), that connect local customer 264 networks to the IX. 266 o The L3MF that acts as an intermediary between IX customers and 267 ISPs. 269 o Value Added Services, that refers to those additional network and 270 application services that can be partially or totally offered from 271 inside the IX. 273 Two types of IX customers are foreseen in the scenario: 275 1. IX Local Customers (IXLC), which are directly connected to the IX 276 through a router that can be either managed by the IX 277 administrator or the customer network administrator. 279 2. IX Remote Customers (IXRC), which are not directly connected to 280 the IX but to a regional provider that is present on the IX. 282 Both type of customers use address prefixes sub-delegated from the IX 283 addressing range. 285 The figure above is a functional scheme and it does not imply in 286 which way the functionalities described here have to be implemented. 288 4. Relationship with the traditional IX model 290 From a theoretical point of view, there are no constraints in merging 291 the traditional model with this new advanced model, that means that 292 some customers may use the IX to exchange traffic among each others 293 and simultaneously other customers (IXLC) may use the Internet 294 Exchange according to this new functionality. 296 In the following, we refer only to the new advanced model so the term 297 customer refers only to the IXLC. 299 5. Overview of the new advanced IPv6 IX model 301 In a classical model, an IX is not normally opened to the direct 302 connection of customers (i.e. large corporate networks or small ISPs 303 or whatever). Instead of that, customers are connected to ISP 304 networks, which are present on the IXs. 306 In those cases where customers are directly connected to an IX, they 307 typically subscribe an agreement with one or several Long Haul 308 Providers present on the IX to route their traffic and announce their 309 prefix addresses. Customer addresses can be sub-assigned from the 310 provider ranges, that is, customers can use Provider Aggregatable 311 (PA) address space. Alternatively, customers can get Provider 312 Independent (PI) addresses directly from the RIRs. 314 If the customer changes its Long Haul Provider and is using PA 315 addresses, it will have to renumber its network. The only way to 316 avoid renumbering is to use PI addresses. However, to preserve the 317 scalability of the whole routing system, PI addresses do not longer 318 exist in IPv6. Therefore, following a classical IX model, changing 319 provider in IPv6 implies renumbering the customer network. 321 To solve this problem, the advanced IX model presented in this 322 document uses a different approach based on the possibility (new for 323 an IX) to directly assign IPv6 addresses to the customers. 324 Connectivity provision and IPv6 address assignment are now separated 325 issues and they are no longer both linked to the LHP. 327 In this way, if an IX customer wants to change its service provider 328 (e.g. because it gets a better service or price from another LHP), 329 it does not need to change its own addresses, as they have been 330 assigned by the IX and not by the service provider. It only will 331 have to renumber if it changes the IX it is connected to (or from IX 332 group, for instance, in case of distributed IX). 334 Consequently, in this new model the IX plays an important role in the 335 Internet service provision: assigning addresses to customers and 336 acting as a mediator between them and the LHPs. That is the reason 337 why the main new IX functionality has been called Layer Three 338 Mediation Function (L3MF), as it provides the decoupling among the 339 customers and the LHPs. 341 Note that in the traditional IXs, agreements among the parties are 342 usually taken among the ISPs connected to the IX itself. In fact, 343 the IX is a neutral entity that does not have a particular role, 344 since it basically provides the Layer 2 Connectivity infrastructure. 346 In the advanced model proposed here, three different entities are, in 347 principle, involved: the IX itself, the IX customers and the LHPs. 348 This means that different agreements could be taken, for example, 349 according to the role of the IX. 351 Hence, it does not mean that IX customers will necessarily have to 352 negotiate with two or more different organizations (IX administrator 353 and ISPs) in order to get Internet services. Instead, IXs could act 354 as intermediaries between customers and ISPs, offering a 355 one-stop-shop service. This will depend on business particularities/ 356 models instead of technical ones and consequently are no further 357 described in this document. 359 Another advantage is the possibility to use this model in order to 360 provide value added services to the customers. The main concept is 361 in fact that each IX can be considered as a place where services and 362 ISP can be co-located and can be provided to a large amount of users 363 taking advantage of the natural aggregation (in terms of Providers) 364 that may happen inside an IX. These services will be discussed in 365 the remaining sections. 367 The proposed model can be considered as the sum of different 368 infrastructural layers. In fact, whereas the traditional IX model is 369 mainly based on a layer 2 infrastructure used to exchange traffic in 370 a quick, scalable and reliable way, on the other hand, the advanced 371 IPv6 IX is to be considered like an extended one, where it is 372 possible to find, together with the above mentioned layer 2 373 functionalities and the layer 3 infrastructure, other services and 374 functionalities usually not present in the traditional model. 376 From a theoretical point of view, there are no constraints in merging 377 the traditional IX model with this new advanced model. This means 378 that some traditional customers may use the IX to exchange traffic 379 among them while simultaneously other customers (so-called "next 380 generation" customer) may use the Internet Exchange according to this 381 new functionality. In the following, we will refer only to the new 382 advanced model, so the term customer refers only to the "next 383 generation" customers. 385 What is proposed here is essentially an architectural model, 386 identifying the logical blocks to put inside the IX. This draft does 387 not make reference to the real implementation model and its 388 relationship with existing ISP architectural and commercial models. 390 5.1 Layer 2 infrastructure 392 It is basically the same as in the traditional IX. It consists on a 393 switching platform (usually fully redundant and high performing) 394 where the customers' routers are connected. In the new advanced 395 model there are no particular changes related to this model. 397 5.2 Layer 3 infrastructure 399 This part of the structure depends on the implementation of the 400 so-called intermediation function between the connectivity provider 401 and the customer. In a traditional IX, the layer 3 framework 402 consists basically on the routers of the ISPs present in the IX. 404 Other L3 functionalities can be present, for example, a Route Server 405 used to centralize and simplify the exchange of the routes between 406 the peering partners. Additionally, other entities can be included 407 to give support to services like multicast, mobility, etc. 409 5.3 Server Farm 411 The new model here proposed foresees that services are placed inside 412 an IX. This is a revolutionary concept that permits the development 413 of a different technical and business scenarios. Putting services 414 inside an IX can take advantage because somehow it reduces the 415 "distance" between who provides the service and who (the users) use 416 that service. This may mean, for example, to reduce the response 417 time of the service and to reduce the probability to have service 418 unavailability. Obviously these considerations does not take into 419 account the impact that this kind of model can have on the 420 pre-existing ISP networks and a lot of attention should be paid on 421 this aspect, not covered in this draft. Suitable IX models can be 422 implemented in order to avoid conflicts with the pre-existing 423 scenario and to take advantage of this solution. 425 6. Advanced IPv6 IX Services 427 This section describes and discusses about the services that can be 428 offered from an IX based on the model introduced in this document 429 according to the structure presented in the previous section. 430 Services are grouped in network services, transition services, 431 support and management services, security services and other 432 services. 434 6.1 Network services 436 6.1.1 Address Delegation 438 Address delegation is one of the main functions to be offered by an 439 advanced IPv6 IX. As mentioned, the new IX model decouples address 440 assignment from connectivity provision, taking the IX the role of 441 assigning addresses to its customers and the ISPs connected to the IX 442 the provision of the connectivity to Internet. 444 IX administrators will request to their corresponding Regional 445 Internet Registry (RIR) one or more address prefixes, basically 446 following the same rules defined for ISPs or, as they are named, 447 Local Internet Registries (LIRs). Technically, the IX will behave as 448 a LIR, being assigned by the registries the required prefixes. 450 Later, the prefixes assigned to the IX will be sub-delegated to IX 451 customers, following the same rules a LIR uses to assign addresses to 452 its customers [3]. 454 The address delegation service is the basement of two basic services 455 that can be offered to IX customers: 457 1. Provider Selection, that allows customers to choose the ISPs they 458 want to get connectivity service from, as well as easily changing 459 the selection without having to renumber their network. 461 2. Multihoming, which allows customers to simultaneously get 462 connectivity services from two or more ISPs and define their 463 routing policy. For example, customers can use one of the 464 providers as the primary connection and using others as a 465 fallback solution, or do load sharing among them. 467 L3MF will be the basic functional entity managing address delegation 468 service in the IX. It will be in charge of: 470 1. Announcing the IX prefix/es to the ISPs peering on the IX. 472 2. Organizing the routing among IX customers and ISPs. 474 3. Implementing address delegation associated services like provider 475 selection and multihoming. 477 In order to keep routing scalability, IX prefix/es must be announced 478 aggregated to the IPv6 Internet through the ISPs peering on the IX. 479 In principle, unaggregated prefixes assigned to IX customers must not 480 be redistributed outside the IX (only to routers present on the IX). 481 This fact imposes the limitation that all incoming traffic (that is, 482 traffic destined to IX addresses) will follow the same path, 483 independently of the IX customer it is directed to. 485 The only way to exert some control over the incoming path is to relax 486 the rule mentioned above and allow the distribution of IX customer's 487 unaggregated prefixes. However, that can only be done if they are 488 distributed to a limited scoped, for example, though an ISP that has 489 agreed with the IX to allow that or through a link that connects to 490 another IX being part of an IX group or confederation. In any case, 491 mechanisms must exist to guaranty that unaggregated prefixes are not 492 freely redistributed (for example, filters based on community tags 493 defined by the IX). 495 Typically, the L3MF will be implemented inside an IX managed router 496 using BGP protocol. L3MF will maintain external BGP peering with the 497 ISPs and IX customer routers in order to direct each customer's 498 traffic to its corresponding ISP. L3MF router will intelligently 499 modify the NEXT_HOP BGP attribute to avoid that traffic passing 500 through the L3MF router. However, there are other possible ways of 501 implementing L3MF functionality, for example, using static routing or 502 with the help of a route sever, as it is mentioned on the next 503 section. The way the L3MF is implemented is out of the scope of this 504 document. 506 As presented in section 3, two types of IX customers are defined: 508 1. IX Local Customers (IXLC), which have a direct layer 3 connection 509 to a router in the IX (named CER), either managed by the customer 510 or by the IX administrator. These customers can be connected to 511 the IX using different technologies like point to point links, 512 Frame relay, MPLS VPNs, etc. Customer routers (CER) can be 513 dedicated to a customer or can be shared between several. 514 However, in the shared case, all the preferences and routing 515 policies will be common to all customers sharing the router. 517 2. IX Remote Customers (IXRC), which have not direct layer 3 518 connection with any router in the IX. They are customers of one 519 of the providers present on the IX and so they are connected to 520 the ISP network at some place different from the IX, but they use 521 addresses form the IX prefix. In this case, the ISP has to cope 522 with the distribution of the prefix assigned to the customer 523 through its routing system, in order to have the customer 524 accessible from the IX. 526 Both services defined (provider selection and multihoming) are 527 available for IXLC. However, none of them are available for IXRC, as 528 the customer is integrated in ISP network. Even that, the customer 529 maintains the advantage that it is using IX assigned addresses, so in 530 case he changes provider to another one present on the IX, it avoids 531 having to renumber its network. 533 6.1.2 Route Server 535 Another service that it is commonly found on IXs is the route server. 536 Roughly speaking, a Route Server is a modified BGP daemon designed to 537 act as a central point for peering, changing the classical mesh 538 topology of an IX into a star topology, where each ISP's border 539 router maintains just one BGP peering with the route server. 541 By using a route server the scalability of the IX is greatly 542 improved, because, being "n" the number of ISPs present in the IX, 543 the number of BGP peering is O(n) and not O(n2) as it is with a mesh 544 topology. Moreover, the addition of new members to the IX is 545 simplified, as only a new peering between new ISP router and the 546 route server has to be configured. 548 The route server service can play an important role in the IPv6 IX 549 model described in this document. Apart from the usual benefits that 550 arise from the use of a route server mentioned above, it can help 551 implementing the provider selection and multihoming services 552 associated with IX based address delegation. 554 In particular, L3MF can be integrated with the route server 555 functionality, giving rise to an Enhanced Route Server (ERS) that 556 centralizes the peering among ISPs and IX customers routing related 557 functions. 559 The use of a route server on an IX must not change the way routing is 560 organized among ISPs. In other words, the route server must be 561 transparent, meaning that the routes learned and installed by each 562 border router must be the same when the route server is present than 563 when it is not (mesh topology). 565 With this premise in mind, two types of route servers arise, 566 depending on how much "intelligence" we relay on them: 568 1. Transparent Route Server, which propagates all the routes 569 received from any router to the rest of routers, without 570 modifying route attributes. In this way, routers acquire the 571 same routing information as they would do via direct peering 572 ("full mesh" topology), allowing them to apply their selection 573 criteria according to their local policies. 575 2. Smart Route Server, which is an "intelligent" BGP daemon which 576 performs best path selection on behalf of client routers. For 577 this purpose, it must maintain a separate RIB for each of the 578 clients, and it must also know the routing policies of all the 579 clients. When the Route Server receives some announce it applies 580 the appropriate policies before inserting them into the Loc-RIB 581 corresponding to each client. 583 The main drawback of the first type of Route Server is that it needs 584 to introduce some modifications to BGP protocol, because in BGP-4 it 585 is not possible to send more than one announcement corresponding to 586 the same prefix through a single peering. There are some proposals 587 for modifying the protocol in order to make that possible, for 588 example, the mechanism proposed in [4] or the new attribute proposed 589 in [5]. 591 However, the second type seems the most appropriate for the advanced 592 IX model purposes, due to the following reasons: 594 o It does not need any modification to route server clients BGP 595 implementations (any currently available BGP implementation will 596 suffice for ISP and customer routers). 598 o The provision of the new services associated to IX based address 599 delegation suggests keeping the client-side BGP configuration as 600 simple as possible (at least, for IX customer routers), and this 601 means moving all the policies and best path selection process into 602 the Route Server. This is precisely the idea of the smart route 603 server. 605 In summary, the use of an ERS based on a smart route server to 606 implement L3MF greatly simplifies the provision of complex services 607 like load sharing multihoming. All the complex functions (filtering, 608 policies, etc) that in other case should be implemented on IX 609 customer routers are moved into the route server, who performs them 610 on behalf of the customers and under the management of the IX 611 administrator. In this way, requirements for IX customer routers are 612 reduced and their management greatly simplified. 614 It is important to note that the use of an ERS to give service to IX 615 customers does not necessarily imply that ISP peering sessions must 616 be integrated on that. ISPs can peer directly among them over the 617 layer 2 infrastructure or even the ERS can coexist with another route 618 server that centralizes peering among ISPs. 620 6.1.3 QoS 622 The management of QoS can be efficiently done by means of policy 623 provision architectures. With this approach, the functionality and 624 flexibility increases notably. The utility of this kind of solution 625 can be improved by advanced IX, as they can be a key element of such 626 architectures. 628 The QoS provision usually is made by means of Policy Based Networks 629 (PBNs) architectures based on the one proposed at [6], although it is 630 strongly oriented to intra-domains enviroments. 632 The IX can provide solutions more scalable and more powerful in order 633 to achieve end-to-end QoS allocation among different domains. Being 634 the IX the common point where different domains are connected to, 635 they might store information about the network status, user rights 636 and so on, in order to decide if a given QoS request can be 637 successfully granted. 639 Even if domains physically attached to other IX have to participate 640 to provide QoS resources, communication between the IX involved could 641 be done to share the required information in order to decide whether 642 or not the QoS resources allocation is possible. 644 Consequently, the main functionalities that the IXs could provide 645 regarding QoS provision are: 647 o Provision of policies among QoS edge routers belonging to 648 different domains. 650 o Define QoS policies for classifying data streams traversing the 651 network. 653 o Store the policies edited by network administrators. 655 One of the main keys to succeed with this solution is the 656 implementation of the policies. In general, PBN enforces the usage 657 of network resources based on policies derived from criteria defined 658 by network administrators, particularly, QoS PBNs allocate QoS 659 reservations based on such policies. 661 However, policy is a general and abstract concept, which needs to be 662 specified in particular actions. On the other hand, such policies 663 should be defined by using high-level languages to let administrators 664 easily define conditions that influence on the resource reservations 665 and at the same time, easily understand the policies defined by other 666 administrators. Thus, the more flexible are the policies, the more 667 powerful is the PBN. 669 Given the fact that an IX is a network point where a number of 670 different technologies can be present, the policies used on this type 671 of environments should be as more general as possible in order to do 672 not exclude any type of network. 674 6.1.4 AAA Services 676 AAA infrastructure can be deployed in an IX service network to offer 677 authentication, authorization and accounting services in a wide 678 variety of ways and to different kind of users and purposes. The 679 main advantage to use AAA services is that they can provide support 680 to mobile and roaming end users that roam between different ISPs or 681 IXs. The recommended protocol defined to transport AAA information 682 is DIAMETER [7]. 684 Depending of the functionality provided by the IX to the clients 685 (ISPs or end users), the AAA service has different requirements. For 686 example, the IX could need to offer secure access control to end 687 users connected directly to the network IX, also, the AAA services 688 can be used by the security services defined in the clients ISP 689 service network. Some of the possible alternatives are listed below. 691 6.1.4.1 IX provides only internal AAA service 693 An IPv6 IX can provide AAA services to directly connected AAA end 694 users, that is, users that do not arrive from a local ISP. 696 When the IX network receives connections from end users through 697 network access services (NAS), users can be authenticated and 698 authorized to obtain the network connection using the local AAA 699 server sited in the IX service network. 701 If the number of NAS in the IX network becomes unmanageable, 702 intermediate elements can be used, like Relay or Proxy AAA agents. 704 If the user's authentication or authorization process requires the 705 exchange of information between external AAA servers, then a Redirect 706 AAA service (described below) can be deployed locally. 708 6.1.4.2 IX provides accounting service to ISPs 710 The AAA service can be used only to get accounting information about 711 the connected ISPs. For example, an IX charges to ISP by the 712 bandwidth consumed in the link between them, the IX can deploy an AAA 713 service used to obtain accounting information from the link to the 714 ISP. In this case could not have authentication or authorization 715 process. 717 6.1.4.3 IX provides AAA Routing service 719 Assuming an IX with several local ISPs, when an AAA server (AAA-A) 720 sited on a local ISP network (ISP-A) needs to exchange information to 721 another AAA server (AAA-B) sited on another local ISP network 722 (ISP-B), the IX can provide Relay and Proxy AAA services to allow 723 AAA-A to reach easily AAA-B and vice-versa. 725 6.1.4.4 IX provides AAA Redirect service 727 If AAA servers sited in ISPs local to an IX need to interact with 728 external to the IX AAA servers. The own IX can provide a common AAA 729 Redirect service to allow locate and provide information about these 730 remote servers. 732 6.1.4.5 IX provides AAA Translation Service 734 Supposing the common situation, in which the ISPs have a RADIUS [8] 735 or TACACS+ [9] system used to authenticate users, the IX can offer a 736 common point to translate the RADIUS domains to DIAMETER domains, 737 adding additional functionalities to the RADIUS technology. This 738 translation can be done placing an AAA translation service in the IX 739 network. 741 To locate an AAA infrastructure inside an IX network implies to 742 provide authentication and authorization services. In base of the 743 AAA specification, the AAA server could use ASM modules to interact 744 with external entities, which offer advanced authentication and 745 authorization services to help the AAA server. That is, advanced 746 authentication and authorization entities could be deployed in the 747 IX. An authentication system can be deployed using a Public Key 748 Infrastructure (PKI) and an authorization system can be deployed 749 using an Authorization Authority, based, for example, on SAML or PMI 750 technologies. 752 Moreover, to locate an AAA infrastructure inside an IX may imply that 753 the AAA services need to establish authorization and authentication 754 data exchanges between external AAA servers. These external servers 755 sometimes have a trusted relationship with the original IX, but in 756 other occasions, the AAA servers belong to not previously known 757 organizations. In any case the exchange between servers must be 758 protected establishing secure channels, commonly using IPsec or TLS 759 protocols. The secure channels should be established using public 760 key cryptography to avoid the problem of distribute secret keys 761 between organizations. 763 If the AAA servers belong to a well-known organization, a 764 cross-certification relationship can be established between the 765 servers to protect the AAA exchanges. If the AAA servers belong to a 766 not known organization the exchange only could be possible if a 767 certification path can be discovered between the peers CAs. 769 Additionally in large networks, which may include millions of users, 770 the management of mobility services and as a consequence their Home 771 Agents, become operationally and administratively a complex scenario. 772 Then a solution where the AAA infrastructure can help to solve this 773 situation and then the integration of a AAA services like this within 774 the IX is needed. 776 6.1.5 Multicast 778 Multicast Transmission Services are one of the services that can be 779 provided in this advanced IX scenario. With reference to the ASM 780 approach (PIM-SM particularly), the IX could be in fact the right 781 location where to place the RendezVous Point, since it is the focal 782 point where the IX customers and the ISP could meet. The 783 introduction of RP inside the IX could take some advantage as for 784 example the optimisation of latency in transmission with a 785 better-perceived quality by the users. 787 6.1.6 Mobility 789 TBD. 791 6.1.7 Multihoming 793 Moreover, this model could facilitate a multihoming solution since a 794 customer is naturally multihomed (connected to more than one LHP/ISP 795 at the same time). ??? TBD. 797 6.1.8 DNS 799 TBD. 801 6.2 Transition services 803 Most of transition mechanisms are tunnel-based and/or require a 804 relay, server, tunnel-end-point (TEP) or other similar 805 functionalities. 807 Some of them, such as 6to4 [10][11], use mechanism such as anycast, 808 to discover the TEP. But others require a manual configuration 809 (users have to know where the TEP is located or a method to find it), 810 while already automatic discovery procedures had been proposed [12]. 812 Furthermore users without technical knowledge don't know in general, 813 how to choose the best transition mechanism (the one that provides de 814 "best performance"). 816 The IXs can play an important role to help to overcome such barriers, 817 so users do not need to know anything about which are the best 818 mechanisms and/or TEPs or other configuration parameters (i.e. 819 tunnel brokers/servers). Therefore, the following advantage can be 820 obtained by using IX with auto-discovery capabilities: 822 o Simplicity to client's configuration because they only would need 823 to know one destination to get the best IPv6 connectivity, and 824 this can be automatically discovered. 826 o Transparency in the communication in case that a server gets down 827 because datagrams would be automatically redirected to the nearest 828 alternative TEP. 830 o Load balancing in order to have a uniform resource share. 832 o Facility for the scalability of new TEPs. 834 In general, the IX seems to be a good place to provide transition 835 mechanisms, and even not just one, but a set of them which can be 836 used by different hosts, in different scenarios connected to ISPs 837 collocated in the IX. 839 In addition to that, the IX can be used as a policy distribution 840 service for the managed auto-transition [13], as a kind of helper to 841 increase the performance of the transition at a large. For instance 842 given the fact that a broker located into the IX has real-time 843 information about the associated TEPs implemented on different ISP, 844 this information should be utilized by the auto-transition mechanisms 845 in order to select the best one. 847 The combination of services like DNS, AAA, anycast, within the IX, 848 together with transition, provide a perfect framework and 849 facilitates: 851 o The scalability of the transition mechanisms. 853 o The automation of the discovery and selection of the "best 854 performing" transition mechanism and its parameters. 856 o The management of the transition service. 858 o Avoid deploying transition mechanism in every ISP, but providing 859 the service to all the users (depending on the defined ISP 860 policy). 862 6.3 Support and policy-based management services 864 The goal of policy-based management is to enable network, service and 865 application control and management on a high abstraction layer. The 866 administrator specifies rules that describe domain-wide policies 867 independent of the implementation of the particular network node, 868 service or application. It is then the policy management 869 architecture that provides support to transform and distribute the 870 policies to each node and thus to enforce a consistent configuration 871 in all involved elements, which is a prerequisite for achieving end 872 to end security services, for example. 874 Use of policies is an intrinsically layered approach allowing several 875 levels of abstraction. There can be, for example, general policies 876 expressing an abstract business goal, and on the other end there can 877 be policies that express a rather specific, device or service 878 dependent rule. In fact, one of the current research issues in 879 policy management is the refinement of high-level goals into 880 implementable policies. 882 Policy rules are independent of a specific device and implementation, 883 but define in abstract terms a desired behaviour. They are stored 884 and interpreted by the policy framework, which intent to provide a 885 consistent behaviour in all affected policy enforcement points. 887 As IX models become more complex with increased functionalities, will 888 required the more management and then the support of Policy Based 889 Management Network will certainly be fundamental. 891 6.4 Security services 893 6.4.1 PKI 895 One central component in the Security Architecture is the provision/ 896 distribution of keys. In order to do that one of main component for 897 the support of the security services is the PKIs. They are needed in 898 the IPv6 world to offer cryptographic features to security services 899 like HTTPS, IPsec, etc. and also can be used for the securization of 900 the different elements appearing in the infrastructure. 902 6.4.2 DNSSEC 904 Services like DNSSEC are being used to secure DNS transactions 905 between clients and servers and among servers, as well as to store 906 cryptographic information about the entities stored in it. 907 Therefore, DNSSEC can be naturally used by a PKI to store the 908 security information of the PKI clients, offering a worldwide 909 distributed cryptographic storage mechanism. Using DNSSEC to store 910 Public Key Certificates (PKC) and Certificate Revocation Lists (CRL), 911 an IPv6 user can easily find the public certificate associated to 912 other person/entity by means of a simple DNS request, in order to 913 exchange information in a secure way. 915 6.4.3 Distributed security 917 With the deployment of IPv6 networks a revision of existent security 918 models and architectures is a must. As new paradigms and 919 applications enabled by IPv6 end-to-end appears the security 920 infrastructure must be ready. 922 The IPv6 Distributed Security model [14][15] goal is to move the 923 Security Policy Enforcement Point (PEP) to the end device to be 924 protected. This is accomplished by the distribution of the security 925 policy to the PEP from a central Policy Decision Point (PDP). Three 926 main elements are needed: 928 1. Security Policy definition language. 930 2. Security Policy distribution protocol. 932 3. Unique and secure identification of entities. 934 As the Distributed Security involves policy distribution the IX could 935 be used as a repository for Security Policies. Even different 936 repositories could be located in an IX, acting as the PDP, and share 937 some security information and alerts. 939 The fact that an IX will also have IPv4 connectivity could enhance 940 the collaboration between IPv6 and IPv4 Security Policies 941 repositories. 943 Even some business case could be foreseen if the up-dated last-minute 944 security policy distribution service is charged to some users. 946 6.5 Other services 948 TBD. 950 7. Conclusions 952 This advanced IPv6 IX model could be described closer to an advanced 953 Point of Presence (PoP) instead of just a traditional IX, when 954 considering that it provides services and addresses to the customers. 956 A traditional PoP can also provide addresses, being the difference 957 that in the advanced IPv6 IX model, the addresses are assigned by the 958 IX itself and consequently do not change even if the customer of the 959 IX changes its provider. 961 The model could be further extended to groups of advanced IX and/or 962 distributed IX. 964 8. Security Considerations 966 This memo does not add any new security implication. 968 TBD. 970 9. IANA Considerations 972 This document requests no action for IANA. 974 [[note to RFC-editor: this section can be removed upon publication.]] 976 10. Acknowledgements 978 This memo is result of the work done in the Euro6IX project. The 979 authors would also like to acknowledge the inputs from Ivano 980 Guardini, Miguel A. Diaz, Alvaro Vives, Gabriel Lopez, Jose A. 981 Garcia, Jose L. Rubio and the European Commission support in the 982 co-funding of the Euro6IX project, where this work is being 983 developed. 985 11 Informative References 987 [1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless 988 Inter-Domain Routing (CIDR): an Address Assignment and 989 Aggregation Strategy", RFC 1519, September 1993. 991 [2] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast 992 Address Format", RFC 2374, July 1998. 994 [3] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 995 Allocations to Sites", RFC 3177, September 2001. 997 [4] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh 998 routing", RFC 1863, October 1995. 1000 [5] Bhatia, M., "Advertising Equal Cost Multi-Path (ECMP) routes in 1001 BGP", draft-bhatia-ecmp-routes-in-bgp-00 (work in progress), 1002 May 2003. 1004 [6] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for 1005 Policy-based Admission Control", RFC 2753, January 2000. 1007 [7] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 1008 "Diameter Base Protocol", RFC 3588, September 2003. 1010 [8] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1011 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1012 2000. 1014 [9] Finseth, C., "An Access Control Protocol, Sometimes Called 1015 TACACS", RFC 1492, July 1993. 1017 [10] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 1018 IPv4 Clouds", RFC 3056, February 2001. 1020 [11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 1021 3068, June 2001. 1023 [12] Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery for 1024 Tunneling Mechanisms", draft-palet-v6ops-tun-auto-disc-01 (work 1025 in progress), June 2004. 1027 [13] Palet, J. and M. Diaz, "Evaluation of IPv6 Auto-Transition 1028 Mechanism", draft-palet-v6ops-auto-trans-00 (work in progress), 1029 April 2004. 1031 [14] Vives, A. and J. Palet, "IPv6 Security Problem Statement", 1032 draft-vives-v6ops-ipv6-security-ps-00 (work in progress), April 1033 2004. 1035 [15] Palet, J., Vives, A., Martinez, G. and A. Gomez, "IPv6 1036 distributed security requirements", 1037 draft-palet-v6ops-ipv6security-00 (work in progress), March 1038 2004. 1040 [16] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. 1041 Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 1042 2748, January 2000. 1044 [17] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple 1045 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1046 1990. 1048 [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1049 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1050 Session Initiation Protocol", RFC 3261, June 2002. 1052 Authors' Addresses 1054 Mario Morelli 1055 Telecom Italia Lab. 1056 ??? 1057 Torino 1058 IT-????? - Italy 1060 Phone: +???? 1061 Fax: +??? 1062 EMail: mario.morelli@tilab.com 1063 Jordi Palet Martinez 1064 Consulintel 1065 San Jose Artesano, 1 1066 Alcobendas - Madrid 1067 E-28108 - Spain 1069 Phone: +34 91 151 81 99 1070 Fax: +34 91 151 81 98 1071 EMail: jordi.palet@consulintel.es 1073 David Fernandez Cambronero 1074 Technical Univ. of Madrid (UPM) 1075 Ciudad Universitaria s/n 1076 Madrid 1077 E-28040 - Spain 1079 Phone: +34 91 549 57 00 1080 Fax: +34 91 336 73 33 1081 EMail: david@dit.upm.es 1083 Antonio F. Gomez Skarmeta 1084 University of Murcia (UMU) 1085 Campus de Espinardo s/n 1086 Murcia 1087 E-30071 - Spain 1089 Phone: +34 968 364 607 1090 Fax: +34 968 364 151 1091 EMail: skarmeta@um.es 1093 Intellectual Property Statement 1095 The IETF takes no position regarding the validity or scope of any 1096 Intellectual Property Rights or other rights that might be claimed to 1097 pertain to the implementation or use of the technology described in 1098 this document or the extent to which any license under such rights 1099 might or might not be available; nor does it represent that it has 1100 made any independent effort to identify any such rights. Information 1101 on the procedures with respect to rights in RFC documents can be 1102 found in BCP 78 and BCP 79. 1104 Copies of IPR disclosures made to the IETF Secretariat and any 1105 assurances of licenses to be made available, or the result of an 1106 attempt made to obtain a general license or permission for the use of 1107 such proprietary rights by implementers or users of this 1108 specification can be obtained from the IETF on-line IPR repository at 1109 http://www.ietf.org/ipr. 1111 The IETF invites any interested party to bring to its attention any 1112 copyrights, patents or patent applications, or other proprietary 1113 rights that may cover technology that may be required to implement 1114 this standard. Please address the information to the IETF at 1115 ietf-ipr@ietf.org. 1117 Disclaimer of Validity 1119 This document and the information contained herein are provided on an 1120 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1121 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1122 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1123 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1124 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1125 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1127 Copyright Statement 1129 Copyright (C) The Internet Society (2004). This document is subject 1130 to the rights, licenses and restrictions contained in BCP 78, and 1131 except as set forth therein, the authors retain all their rights. 1133 Acknowledgment 1135 Funding for the RFC Editor function is currently provided by the 1136 Internet Society.