Internet-DraftInternet Draft M. Lind <draft-ietf-v6ops-isp-scenarios-analysis-00.txt><draft-ietf-v6ops-isp-scenarios-analysis-01.txt> TeliaSonera Expires : May 2004V. Ksinant 6WIND D.S. Park Samsung Electronics A. Baudot France Telecom December 2003P. Savola CSC/Funet Expires: August 2004 February 2004 Scenarios and Analysis for Introducing IPv6 into ISP Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress".progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document first describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 ISPnetwork without disrupting the IPv4 service. Then, this document analyses these scenarios and evaluates the suitabilityrelevance of the already defined transition mechanisms in this context. Known challenges are also identified. Table of Contents 1. Introduction..................................................3Introduction................................................2 1.1 Goal and scopeScope of the document..........................3 1.2 Terminology used........................................3Document...........................2 2. Brief descriptionDescription of a genericGeneric ISP network....................4Network..................3 3. Transition scenarios..........................................6Scenarios........................................4 3.1 Identification of scenarios.............................6 3.1.1 Assumptions............................................6 3.1.2 Customer requirementsStages and ISP offerings................7 3.1.3Scenarios...................4 3.2 Stages...................................................5 3.2.1 Stage 1 Scenarios: Launch..............................8 3.1.4Launch..............................5 3.2.2 Stage 2a Scenarios: Backbone...........................8 3.1.5Backbone...........................6 3.2.3 Stage 2b Scenarios: Customer connection................8 3.1.6Connection................6 3.2.4 Stage 3 scenarios: Complete............................9 3.1.7 StageScenarios: Complete............................6 3.2.5 Stages 2a and 3 combination scenarios...................9 3.2 Transition Scenarios....................................93: Combination Scenarios.................7 3.3 Transition Scenarios.....................................7 3.4 Actions needed when deployingNeeded When Deploying IPv6 in an ISP network...10ISP's network...7 4. Backbone transition actions..................................11Transition Actions.................................8 4.1 Steps in transitioning backbone networks...............11Transitioning Backbone Networks.................8 4.1.1 MPLS Backbone..........................................9 4.2 Configuration of backbone equipment....................13Backbone Equipment.....................10 4.3 Routing................................................13Routing.................................................10 4.3.1 IGP...................................................13IGP...................................................10 4.3.2 EGP...................................................14EGP...................................................11 4.3.3 Transport of Routing protocols transport...........................15Protocols........................12 4.4 Multicast..............................................15Multicast...............................................12 5. Customer connection transition actions.......................15Connection Transition Actions.....................12 5.1 Steps in transitioning customer connection networks....15Transitioning Customer Connection Networks.....12 5.2 Access control requirements............................17Control Requirements.............................14 5.3 Configuration of customer equipment....................17Customer Equipment.....................15 5.4 Requirements for Traceability..........................18Traceability...........................16 5.5 Multi-homing...........................................18 5.6Ingress filteringFiltering in the customer connection network...19Customer Connection Network....16 5.6 Multi-Homing............................................16 5.7 Quality of Service......................................16 6. Network and service operation actions........................19Service Operation Actions......................17 7. Future Stages................................................20Stages..............................................17 8. Example networks.............................................20Networks...........................................18 8.1 Example 1..............................................221...............................................19 8.2 Example 2..............................................222...............................................21 8.3 Example 3..............................................233...............................................21 9. Security Considerations......................................23Considerations....................................22 10. Acknowledgements.............................................23Acknowledgements...........................................22 11. Informative references.......................................23References.....................................22 1. Introduction 1.1 Goal and scopeScope of the documentDocument When an ISP deploys IPv6, its goal is to provide IPv6 connectivity to its customers. The new IPv6 service must be added to an already existing IPv4 serviceservice, and the introduction of theIPv6 must not interrupt this IPv4 service. The case of an IPv6-only service provider is not addressed in this document.An ISP offering anIPv4 service will find that there aredifferent ways to add IPv6 to this service. This document discusses a small set of scenarios for the introduction of IPv6 ininto an ISPISP's IPv4 network. It evaluates the suitabilityrelevance of the existing transition mechanisms in the context of these deployment scenarios, and itpoints out the lack of functionality essential to the ISPISP's operation of an IPv6 service..service. The present document is focused on services that include both IPv6 and IPv4 and does not cover issues surrounding anIPv6-only service. It is also outside the scope of this document to describe different types of access or network technologies. 1.2 Terminology used This section defines2. Brief Description of a Generic ISP Network A generic network topology for an ISP can be divided into two main parts: the backbone network and clarifiesthe terminologycustomer connection networks connecting the customers. It includes, in addition to these, some other building blocks such as network and service operations. The additional building blocks used in this document:document are defined as follows: "CPE" : Customer PremisePremises Equipment "PE" : Provider Edge equipment "Network and service operation":operation" : This is the part of the ISPISP's network whichthat hosts the services required for the correct operation of the ISPISP's network. These services usually include management, supervision, accounting, billingbilling, and customer management applications. "Customer connection":connection" : This is the part of the network which isused by a customer when connecting to an ISPISP's network. It includes the CPEs,CPE, the last hop linkslink and the parts of the PE interfacing to the last hop links.link. "Backbone" : This is the rest of the ISPISP's network infrastructure. It includes the parts of the PE interfacing to the core, the core routers of the ISPISP, and the border routers used in orderto exchange routing information with other ISPs (or other administrative entities). "Dual-stack network": A network whichthat supports natively both IPv4 and IPv6. 2. Brief description ofIt is noted that, in some cases (e.g., incumbent national or regional operators), a generic ISP network A generic ISP network topology can be divided into two main parts; the backbone network and thegiven customer connection networks connecting the customers. The backbone is the part of thenetwork that interconnects themay have to be shared between or among different customer connection networks and provides transportISPs. According to the resttype of the Internet via exchange points or other means. The backbone network can be built on different technologies but in this document the only interest is whether it is capable of carrying IPv6 traffic natively or not. Since there is no clear definition of "backbone", it is defined in this document as being all routers that are a part of the same routed domain in the transport network. This means that all routers up to (and including, at least partially) the PE router are a part of the backbone. The customer connection networks provide connectivity to enterprise and private customers. Other ISPs might as well be customers and connected to the ISP's customer connection network. As with the backbone the absence or presence of native IPv6 capability is the only thing of real interest in the customer connection network technology. It is noticeable that, in some cases (e.g. incumbent national or regional operators), a given customer connection network may have to be shared between different ISPs. According to the type of the customer connectioncustomer connection network used (e.g.(e.g., one involving only layer 2 devices,devices or one involving non-IP technology), this constraint may result in architectural considerations that may berelevant into this document. "Network and service operation" building blocks refer to the basic main functions needed for a regular backbone operation. This building block is dealing with: network management, customers' authentication and accounting, address assignment and naming. It represents the minimum functions needed to provide a customer service, referring to both network infrastructure operation, and administrative management of customers. It doesn't matter if these customer networks have a single node or a large routed network. What is of interest is if routing information is exchanged or not since it will affect the ISP's network.The existence of customer premise equipment will also affect how a service can be delivered. In addition tobasic components in the ISP's actual network components there are a lot of support and backend systems that have to be considered. The basic components in an ISPnetwork are depicted in Figure 1. ------------ ---------- | Network and| | | | serviceService |--| Backbone | | operationOperation | | |\ ------------ ---------- \ . / | \ \ . / | \ \_Peering( Direct &and IX ) . / | \ . / | \ . / | \ ---------- / ---------- \ --------------------- | Customer | / | Customer | \ | Customer | |Connection|--/ |Connection| \--|Connection| | 1 | | 2 | | 3 | ---------- ---------- ---------- | | | ISPISP's Network ------------------------------------------------------- | | | CustomerCustomers' Networks +--------+ +--------+ +--------+ | | | | | | |Customer| |Customer| |Customer| | | | | | | +--------+ +--------+ +--------+ Figure 1: ISP network topologyNetwork Topology. 3. Transition scenariosScenarios 3.1 Identification of scenariosStages and Scenarios This section describes different stages an ISP might consider when introducing IPv6 connectivity in theinto its existing IPv4 network and the different scenarios that might occur in the respective stages. The stages here are snapshots of anthe ISP's network with respect to IPv6 maturity. Since anBecause the ISP's network is constantlycontinually evolving, a stage is a measure of how far analong the ISP has come in turnterms of implementing necessarythe functionality necessary to offer IPv6 to the customers. It is possible to freelytransition freely between different stages. However,Although a network segment can only be in one stage at a time but an ISPtime, the ISP's network as a whole can be in different stages. There are differentDifferent transition paths betweencan be followed from the first andto the final stage. The transition between two stages does not have to be immediate butinstantaneous; it can occur gradually. Each stage has different IPv6 properties. An ISP cancan, therefore, based on the requirements it has,its requirements, decide intowhich stageset of stages it will follow to transform its network. This document is not aimed to cover very small orsmall ISPs orISPs, hosting providers/dataproviders, or data centers; only the scenarios applicable to theISPs eligible for a /32 IPv6 prefix allocation from a RIR are covered. 3.1.1 Assumptions3.2 Stages The stages are derived from the generic description of an ISPISP's network in sectionSection 2. A combinationCombinations of different building blocks that constitute an ISPISP's environment willlead to a number of scenarios,scenarios from which anthe ISP can choose from.choose. The scenarios ofmost relevance torelevant for this document are considered to bethe ones that maximize ISP's ability to offer IPv6 to its customers in the most efficient and feasible way maximizeway. The assumption in all stages is that the ability for an ISPISP's goal is to offer both IPv4 and IPv6 to its customers.the customer. The four most predominant case todayprobable stages are: o Stage 1 Launch o Stage 2a Backbone o Stage 2b Customer connection o Stage 3 Complete Generally, an ISP is consideredable to be an operator withupgrade a core and accesscurrent IPv4 network delivering IPv4 service to a customer that is running IPv4 as well. At some point in the future, it is expected that the customer will wantto havean IPv6 service, in addition toIPv4/IPv6 dual-stack network via Stage 2b, but the already existing IPv4 service. ThisIPv6 service maycan also be offeredimplemented at a small cost by adding simple tunnel mechanisms to the same ISP, or byexisting configuration. When designing a different one. Anyway the challenge fornew network, Stage 3 might be the ISP is to deliverfirst and last step, because there are no legacy concerns. Nevertheless, the requestedabsence of IPv6 service over the existing infrastructure and atcapability in the same time keepnetwork equipment can still be a limiting factor. Note that in every stage except Stage 1, the ISP can offer both IPv4 service intact. 3.1.2 Customer requirementsand IPv6 services to its customers. 3.2.1 Stage 1 Scenarios: Launch The first stage is an IPv4-only ISP offerings Looking atwith an IPv4 customer. This is the scenarios frommost common case today and the end customer's perspective there might be a demandnatural starting point for three different services;the customer might demand IPv4 service, IPv6 service or both services. Thisintroduction of IPv6. From this stage, the ISP can leadmove (transition) from Stage 1 to two scenarios depending on theany other stage with the ISP's network is in. If an ISP only offers IPv4 orgoal of offering IPv6 service andto its customer. The immediate first step consists of getting a customer wantsprefix allocation (typically a /32) from the appropriate RIR according to connectallocation procedures. 3.2.2 Stage 2a Scenarios: Backbone Stage 2a consists of an ISP with IPv4-only customer connection networks and a device or networkbackbone that onlysupports one serviceboth IPv4 and if that service is not offered, it will lead to a dead-end. IfIPv6. In particular, the customer orISP instead connects a dual stack device it is possible to circumvent the lack of the missing service inhas the customer connection network by using some kindpossibility of tunneling mechanism. This scenario will only be considered inmaking the perspectivebackbone IPv6- capable through either software upgrades, hardware upgrades, or a combination of both. Since the ISP offeringcustomer connections are not yet upgraded, a tunneling mechanism has to be used to bridgeprovide IPv6 connectivity through the IPv4 customer connection and reachnetworks. The customer can terminate the IPv6 backbone. In the case wheretunnel at the customer connects a single stack device to a corresponding single stack customer connection networkCPE (if it has IPv6 support) or whenat each individual device. In the customer connects a single stack device to a dual stack customer connection network is covered byformer case, the CPE will then provide global IPv6 connectivity to all over dual stack case. Therefore, neither of these cases need further be explored separatelydevices in this document but can be seen as a part of a full dual stack case. After eliminating a numberthe customer's network. 3.2.3 Stage 2b Scenarios: Customer Connection Stage 2b consists of cases explained above, there are four stages that are most probable and wherean ISP will find itswith an IPv4 backbone network in. Which stageand a customer connection network that supports both IPv4 and IPv6. Because the service to the customer is in depends on whether or not some part ofnative IPv6, the network previously has been upgradedcustomer is not required to support IPv6 or if itboth IPv4 and IPv6. This is easier to enable IPv6 in one part or another. For instance, routersthe biggest difference in comparison with the backbone might haveprevious stage. The need to exchange IPv6 support ortraffic still exists but might be easily upgradeable, while the hardwaremore complicated than in the customer connection network might have to be completely replaced in order to handle IPv6 traffic. Note that in every stage exceptprevious case, because the backbone is not IPv6-enabled. After completing Stage 1,2b, the ISP can offer bothoriginal IPv4 andbackbone is unchanged. This means that the IPv6 services totraffic is transported by either tunnelling over the customer. The four most probable stages are: o Stage 1 Launch o Stage 2a Backbone o Stage 2b Customer connection o Stage 3 Complete Generallyexisting IPv4 backbone, or in an IPv6 overlay network more or less separated from the IPv4 backbone. Normally the ISP is ablewill continue to upgrade currentprovide IPv4 networkconnectivity; in many cases private IPv4 addresses and NATs will continue to IPv4/IPv6 dual-stack network via Stage 2b but the IPv6 service can alsobe implemented at a small cost with simple tunnel mechanisms on the existing system. When designing a new network,used. 3.2.4 Stage 3 Scenarios: Complete Stage 3 might be the first and last step since there are no legacy concerns. Absence of IPv6 capability in the network equipmentcan stillbe a limiting factor nevertheless. 3.1.3 Stage 1 Scenarios: Launch The first stage is an IPv4 only ISP with an IPv4 customer. This is the most common case today and hassaid to be the starting point forfinal step in introducing IPv6, at least within the introductionscope of IPv6. Fromthis stage, an ISP can move (transition) to any other stage with the goal to offer IPv6 to its customer. The immediate first stepdocument. This consists of getting a prefix allocation (typically a /32) from the appropriate RIR according to allocation procedures. 3.1.4 Stage 2a Scenarios: Backbone Stage 2a is an ISPubiquitous IPv6 service with customer connection networks that are IPv4 onlynative support for IPv6 and a backbone that supports bothIPv4 in both backbone and IPv6. In particular, the ISP considers it possiblecustomer connection networks. This stage is identical to makethe backbone IPv6 capable either through software or hardware upgrade, or a combination of both. In thisprevious stage from the customer's perspective, because the customer should have support for both IPv4 and IPv6. The ISP has to provide IPv6 connectivity through its IPv4 customer connection networks. In particular, the existence of NATs and firewalls in the path (at the CPE, or in the customer's network) need to be considered. 3.1.5 Stage 2b Scenarios: Customer connection Stage 2b is an ISP with a backbone network that is IPv4 and an customer connection network that supports both IPv4 and IPv6. Since the service to the customer is native IPv6 there is no requirement for the customer to support both IPv4 and IPv6. This is the biggest difference in comparison to the previous stage. The need to exchange IPv6 traffic or similar still exists but might be more complicated than in the previous case since the backbone isn't IPv6 enabled. After completing stage 2b the original IPv4 backbone still is unchanged. This doesn't imply that there is no IPv6 backbone just that the IPv6 backbone is an overlay to or partially separated from the IPv4 backbone. Generally, the ISP will continue providing IPv4 connectivity; in many cases private addresses and NATs will continue to be used. 3.1.6 Stage 3 scenarios: Complete Stage 3 can be said to be the final step in introducing IPv6, at least in the scope of this document. This is an all over IPv6 service with native support for IPv6 and IPv4 in both backbone and customer connection networks. This stage is identical to the previous stage in the customer's perspective since the customer connection network hasn't changed. The requirementconnection network has not changed. The requirement for exchanging IPv6 traffic is identical to stage 2. 3.1.7Stage 2. 3.2.5 Stages 2a and 3 combination scenarios3: Combination Scenarios Some ISPs may use different access technologies of varying IPv6 maturity. This may result in a combination of the stagesStages 2a and 3: some customer connections do not support IPv6, but someothers do; andin both cases the backbone is dual-stack. This is equivalent to stageStage 2a, but requiringit requires support for native IPv6 customer connections on some access technologies. 3.23.3 Transition Scenarios Given the different stagesstages, it is clear that thean ISP has to be able to transition from one stage to another. The initial stage, in this document, is the IPv4 onlyIPv4-only service and network. The end stage is thedual IPv4/IPv6 service and network. As mentioned in the scope, this document does not cover the IPv6 only service and network and its implications on IPv4 customers. This has nothing to do with the usability of an IPv6 only service.The transition starts outwith thean IPv4 ISP and then moves toin one of three choices. These choices aredirections. This choice corresponds to the different transition scenarios. One way would be to upgradeStage 2a consists of upgrading the backbone first which leads to stage 2a. Another way to go could be to upgradefirst. Stage 2b consists of upgrading the customer connection network which leads to stage 2b. The final possibility is to introducenetwork. Finally, Stage 3 consists of introducing IPv6 in both the backbone and customer connections as needed which would lead to stage 3. The choice is dependent on many different issues. For example it might not be possible to upgrade the backbone or the customer connection network without large investments in new equipment which could lead to any of the two first choices. In another case it might be easier to take the direct step to a complete IPv6/IPv4 network due to routing protocol issues or similar. If a partially upgraded network (stage 2a or 2b) was chosen as the first step, a second step remains before the network is all over native IPv6/IPv4. This is the transition to an all over dual stack network. This step is perhaps not necessary for stage 2b with an already native IPv6 service to the customer but might still occur when the timing is right. For stage 2a it is more obvious that a transition to a dual stack network is necessary since it has to be done to offer a native IPv6 service. Asneeded. Because most of theISPs keep evolving continuouslycontinually evolve their backbone IPv4 networks (new firmware versions(firmware replacements in therouters, new routers),routers, etc.), they will be able to get them ready for IPv6 ready,without additional investment, except theinvestment (except staff training. Ittraining). This may be a slower transition path,but still useful sincetransition path, because it allows anfor IPv6 introduction without any actual customer demand. This will probablymay be better than makingsuperior to doing everything at the last minute withminute, which may entail a higher investment. 3.3However, it is important to start considering (and requesting from the vendors) IPv6 features in all new equipment from the start. Otherwise, the time and effort to remove non-IPv6-capable hardware from the network will be significant. 3.4 Actions needed when deployingNeeded When Deploying IPv6 in an ISPISP's network When looking atExamination of the transitions described above, it appearsabove reveals that it is possible to split the work required byfor each transition ininto a small set of actions. Each action is mostlylargely independent from the othersothers, and some actions may be common to severalmultiple transitions. The analysisAnalysis of the possible transitions leads to a small list of actions: * Actions required for backbone transition actions:transition: - Connect dual-stack customer connection networks to other IPv6 networks through an IPv4 backbone,backbone. - Transform an IPv4 backbone into a dual-stack one. This action can be performed directly or through intermediate steps,steps. * Actions required for customer connection transition actions:transition: - Connect IPv6 customers to an IPv6 backbone through an IPv4 network,network. - Transform an IPv4 customer connection network into a dual- stack one,one. * Actions required for network and service operation transition actions:transition: - configureConfigure IPv6 functions into either backbone ornetwork and service operation devicescomponents. - upgradeUpgrade regular network management and monitoring applications to take IPv6 into accountaccount. - [NetworkExtend customer management (e.g., RADIUS) mechanisms to be able to supply IPv6 prefixes and service operation actionsother information to customers. - ToEnhance accounting, billing, etc. to work with IPv6 as needed. (Note: if dual-stack service is offered, this may not be completed.] Morenecessary.) - Implement security for network and service operation. Sections 4, 5, and 6 contain detailed descriptions of each action follow.action. 4. Backbone transition actionsTransition Actions 4.1 Steps in transitioning backbone networksTransitioning Backbone Networks In terms of physical equipment, backbone networks consist mainly inof high-speed core and edge high-speedrouters. Border routers provide peering with other providers. Filtering, routing policypolicy, and policing typefunctions are generally managed on border routers. The initial step is an IPv4-only backbone, and the final step is a wholecompletely dual-stack backbone. In between, intermediate steps may be identified: Tunnels Tunnels IPv4-only ----> or ---> or + DS -----> Full DS IPv6dedicated IPv6 dedicated IPv6 routers links links Figure 2: Migration Path. The first step involves tunnels or dedicated links but leaves existing routers are leftunchanged. Only a small set of routers then have IPv6 capabilities. ConfiguredUsing configured tunnels areis adequate for useduring this step. When MPLSIn the second step, some dual stack routers are added, progressively, to this network. The final step is already deployed inreached when all or almost all routers are dual- stack. For many reasons (technical, financial, etc.), the backbone, itISP may be desirable to provide IPv6-over-MPLS connectivity. However,progress step by step or jump directly the problem is that setting up an IPv6 Label Switched Path (LSP) requires some signaling throughfinal one. One of the MPLS network; both LDP and RSVP-TE can set up IPv6 LSPs, but this would require a software upgradeimportant criteria in planning this evolution is the number of IPv6 customers the ISP expects during its initial deployments. If few customers connect to the original IPv6 infrastructure, then the ISP is likely to remain in the initial steps for a long time. In short, each intermediate step is possible, but none is mandatory. 4.1.1 MPLS Backbone If MPLS is already deployed in the backbone, it may be desirable to provide IPv6-over-MPLS connectivity. However, setting up an IPv6 Label Switched Path (LSP) requires signaling through the MPLS network; both LDP and RSVP-TE can set up IPv6 LSPs, but this would require a software upgrade in the MPLS core network. A workaroundAn alternative approach is to use BGP for signaling and/oror to perform IPv6- over-IPv4/MPLSperform, for example, IPv6-over-IPv4/MPLS or IPv6-over-IPv4-over-IPv4/MPLS encapsulation, for example,as described in [BGPTUNNEL]. There seem to be multiple possibilities, someSome of which may be morethe multiple possibilities are preferable than others.to others depending on the specific environment under consideration. More analysis is needed in orderneeded, case by case, to determine which arethe best approach(es):approach or approaches: 1) requireRequire that MPLS networks deploy native IPv6 support or use configured tunneling for IPv6. 2) requireRequire that MPLS networks support setting up IPv6 LSPs, and IPv6 connectivity isset up IPv6 connectivity by using them,either these or configured tunneling is used.tunneling. 3) useUse only configured tunneling over theIPv4 LSPs; this seems practical with small-scale deployments when the number of tunnels is low.having few tunnels. 4) use something likeUse [BGPTUNNEL] or something comparable to perform IPv6-over- IPv4/MPLS encapsulation for IPv6 connectivity. In the second step, some dual stack routers are added in this network in a progressive manner. The final stage is reached when all or most routersApproaches 1 and 2 are dual-stack. According to many reasons (technical, financial, etc), an ISP may move forward from step to step or reach directly the final one. One of the important criteria in this evolution is the number of IPv6 customers the ISP gets on its initial deployments. If few customers connect tothe first IPv6 infrastructure, thenmost attractive if the ISP is likelywilling to perform an upgrade to remain onthe initial stepsMPLS network. Approach 3 does not require any upgrades but may lack scalability. Approach 4 may be economically attractive for an operator who does not wish to upgrade the MPLS network and has a long time. In short, each step remains possible, but no onelarge-scale deployment. MPLS networks have typically been deployed to facilitate services such as Provider-Provisioned VPNs. Software upgrades are commonplace in MPLS networks. No particular reason exists to avoid adding IPv6 functionality, except if the vendor is mandatory.unable to provide sufficient IPv6 forwarding capability (e.g., line-speed) in the existing hardware (independent of the capabilities for handling MPLS frames). Therefore, recommending mechanisms like [BGPTUNNEL] as the final solution might not be such a good idea. 4.2 Configuration of backbone equipmentBackbone Equipment In the backbone, the number of devices is small and IPv6 configuration mainly deals with routing protocolsprotocol parameters, interface addresses, loop-back addresses, ACLs...ACLs, etc. These IPv6 parameters are not supposed to be automatically configured.configured automatically. 4.3 Routing ISPs need routing protocols to advertise thereachability and to find the shortest working pathspaths, both internally and externally. OSPFv2 and IS-IS are typically used as an IPv4 IGP. RIPv2 is typicallynot in usetypically used in operator networks. BGP is the only IPv4 EGP. Static routes also are used in both.both cases. Note that it is possible to configure a given network so that it results in having an IPv6 topology different from theits IPv4 topology. For example, some links or interfaces may be dedicated to IPv4-only or IPv6-only traffic, or some routers may be dual-stack while somewhereas others maybe single stacked (IPv4may be IPv4 or IPv6).IPv6 only. In this case, therouting protocols must be able to manageunderstand and cope with multiple topologies. 4.3.1 IGP Once the IPv6 topology has been determineddetermined, the choice of IPv6 IGP must be made: either OSPFv3 or IS-IS for IPv6. RIPng is less appropriate in many contexts and is not discussed here. The IGP typically includes the routers' point-to-point and loop-back addresses. The most important decision to makeis whether one wishes to have separate routing protocol processes for IPv4 and IPv6. HavingSeparating them separaterequires more memory and CPU for route calculations e.g.calculations, e.g., when the links flap. On the other hand, theseparation provides a better reassurancecertain measure of assurance that if problems come uparise with IPv6 routing, they will not affect IPv4 the routing protocol at all. In the first phasesinitial phases, if it is uncertain whether joint IPv4/IPv6 networks workIPv4-IPv6 networking is working as intended, havingrunning separate processes may be desirable and easier to manage. Thus the possible combinations are: - Separatewith separate processes: o OSPFv2 for IPv4, IS-IS for IPv6 (-only)(only) o OSPFv2 for IPv4, OSPFv3 for IPv6, or o IS-IS for IPv4, OSPFv3 for IPv6 - Thewith the same process: o IS-IS for both IPv4 and IPv6 Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6 topologies must be "convex","convex," unless the Multiple-topology IS-IS extensions [MTISIS] have been implemented. In simpler networks or with careful planning of IS-IS link costs, it is possible to keep even non-congruentincongruent IPv4/IPv6 topologies "convex"."convex." Therefore, the use of same process is recommended especially for large ISPs which intendintending to deploy, in the short-term, a fully dual- stack backbone infrastructure. If the topologies arewill not be similar in the short term, two processes (or Multi-topology IS-IS extensions) are recommended. The IGP is not typically used to carry customer prefixes or external routes. Internal BGP (iBGP), as described in the next section, is most often deployed in all routers to spread thedistribute such other routing information. AsBecause some of the simplest devices, e.g.e.g., CPE routers, may not implement otherrouting protocols other than RIPng, in some cases it may also be necessary to alsorun RIPng in a limited fashion inaddition to another IGP,one of the above IGPs, at least in a limited fashion, and somehow to redistribute therouting information tobetween the otherrouting protocol(s).protocols. 4.3.2 EGP BGP is used for both internal BGPand external BGP sessions. BGP with Multi-protocol extensions [RFC 2858] can be used for IPv6 with Multi-protocol extensions [RFC 2858],[RFC 2545]. These extensions enable exchanging both IPv6 routing information asand establishing BGP sessions using TCP over IPv6. It is possible to use a single BGP session to advertise both IPv4 and IPv6 prefixes between two peers. However, typically, separate BGP sessions are used. 4.3.3 Transport of Routing protocols transportProtocols IPv4 routing information should be carried by IPv4 transport and similarly IPv6 onerouting information by IPv6 for several reasons: * TheIPv6 connectivity may work when theIPv4 oneconnectivity is down (or vice-versa). * The best route for IPv4 is not always the best one for IPv6. * The IPv4 logical topology and the IPv6 one may be different because,different, because the administrator may want to useassign different metric values for onemetrics to a physical link for load balancing or tunnels may be used. 4.4 Multicast Currently, IPv6 multicast is not a strongmajor concern for most ISPs. However, some of them considerare considering deploying it. Multicast is achieved using the PIM-SM and PIM-SSM protocols. These also work with IPv6. Information about multicast sources is exchanged using MSDP in IPv4, but itMSDP is intentionally not defined, on purpose,defined for IPv6. An alternative mechanism is toInstead, one should use only PIM-SSM or an alternative mechanism for conveying the information [EMBEDRP]. To be completed. send feedback/text!5. Customer connection transition actionsConnection Transition Actions 5.1 Steps in transitioning customer connection networks customerTransitioning Customer Connection Networks Customer connection networks are generally composed of a large numbersmall set of CPEsPEs connected to a smalllarge set of PEs.CPEs. Transitioning this infrastructure to IPv6 can be madeaccomplished in several steps, but some ISPs may avoid some of the stepsISPs, depending on their perception of risks.the risks, may avoid some of the steps. Connecting IPv6 customers to an IPv6 backbone through an IPv4 network can be considered as a first careful step taken by an ISP in orderto provide IPv6 services to its IPv4 customers. More,In addition, some ISPs may also provide IPv6 services to customers who get their IPv4 services from another ISP. This IPv6 service can be provided by using tunneling techniques. The tunnel may terminate at the CPE corresponding to the IPv4 service or in some other part of the customer's infrastructure (for instance, on an IPv6 specificIPv6-specific CPE or even on a host). Several tunneling techniques have already been defined: configured tunnels with tunnel broker, 6to4, Teredo...Teredo, etc. The selection of one candidate depends largely on the presence or notabsence of NATs between the two tunnel end-points,end-points and whether the user's IPv4 tunnel end-point address is static or dynamic. In most cases, 6to4 and ISATAP are incompatible with NATsNATs, and anUDP encapsulation for configured tunnels has not been specified. However, NAT traversal can be avoided if the NAT supports forwarding protocol-41 [PROTO41]. Firewalls in the waypath can also break these types of tunnels. The administrator of the firewall will haveneeds to create a hole for the tunnel. ItThis is not a big dealusually manageable, as long as the firewall is controlled eitherby either the customer or the ISP, which is almost always the case. AnWhen the CPE is performing NAT or firewall functions, terminating the tunnels directly at the CPE typically simplifies the scenario considerably, avoiding the NAT and firewall traversal. If such an approach is adopted, the CPE has to support the tunneling mechanism used, or be upgraded to do so. In practice, an ISP has practicallytwo kinds of customers in theits customer connection networks: small end users (mostly "unmanaged networks";unmanaged networks-- home and SOHO users),users) and others. The former category typically hasuses a dynamic IPv4 addressaddress, which is often NATted;non-routable; a reasonably static address is also possible. The latter category typically has static IPv4 addresses, and at least some of them are public; however, NAT traversal or configuring the NATconfiguration may be required to reach an internal IPv6 access router, though.router. Tunneling consideration for small andend sites are discussed in [UNMANCON], that may[UNMANCON] and [UNMANEVA]. These identify solutions relevant to the first category of unmanaged network. These solutions willnetworks. The connectivity mechanisms can be further discussed within an ISP context, when available. Forcategorized as "managed" or "opportunistic." The former consist of native service or a configured tunnel (with or without a tunnel broker); the second category, usually: * Configured tunnels as-islatter include 6to4 and, e.g., Teredo; they provide "short-cuts" between nodes using the same mechanisms and are available without contracts with the ISP. The ISP may offer opportunistic services, mainly a good solution6to4 relay, especially as a test when an NATno "real" service is not in the way andoffered yet. At the IPv4 end-point addresses are static. A mechanism to punch through NATslater phases, ISPs might also deploy 6to4 relays or Teredo servers (or similar) to forward packets through it may be desirable in some scenarios. If fine-grained access controloptimize their customers' connectivity to 6to4 or Teredo nodes. Most interesting are the managed services. When dual-stack is needed,not an authentication protocol needs tooption, a form of tunneling must be used. * A tunnel brokering solution,When configured tunneling is not an option (e.g., due to help facilitate the set-updynamic IPv4 addressing), some form of a bi-directional tunnel,automation has been proposed:to be used. The options are basically either to deploy an L2TP architecture (whereby the Tunnelcustomers would run L2TP clients and PPP over it to initiate IPv6 sessions) or to deploy a tunnel configuration service. The prime candidates for tunnel configuration are STEP [STEP] and TSP [TSP], which are not analyzed further in this document. For connecting larger customers: * Dual-stack access service is often a realistic possibility since the customer network is managed. * Configured tunnels, as-is, are a good solution when a NAT is not in the way and the IPv4 end-point addresses are static. In this scenario, NAT traversal is not typically required. If fine-grained access control is needed, an authentication protocol needs to be used. * A tunnel brokering solution, to help facilitate the set-up of a bi-directional tunnel, has been proposed: the Tunnel Set-up Protocol. Whether this is the right wayapproach needs to be determined. * Automatic tunneling mechanisms such as 6to4 or Teredo are not applicablesuggested in this scenario. Some otherOther ISPs may take a more direct approach and avoid the use of tunnels as much as possible. Note that when thecustomers use dynamic IPv4 addresses, the tunneling techniques may be more difficult to deploy at the ISP's end, especially if a protocol notincluding authentication (like PPP for IPv6) is not used. This may need to be considered in more detail with tunneling mechanisms. 5.2 Access control requirementsControl Requirements Access control is usually required in ISP networksnetworks, because the ISPs need to control to whowhom they are givinggranting access. For instance, it is important to check ifwhether the user who tries to connect is really a valid customer. In some cases, it is also important for billing purposes.billing. However, an IPv6 specificIPv6-specific access control is not always required. This is for instancethe casecase, for instance, when a customer of the IPv4 service has automatically access to theIPv6 service. Then, the IPv4 access control also givesprovides access to the IPv6 services. When thea provider does not wish to give toits IPv4 customers automaticallyautomatic access to IPv6 services, aspecific IPv6 access control for IPv6must be performed in parallel towith the IPv4 one. Itaccess control. This does not meanimply that adifferent user authentication must be performed for IPv6, but merely that the authentication process may lead to different results for IPv4 and IPv6 access. Access control traffic may use IPv4 or IPv6 transport. For instance, Radius traffic related to anIPv6 service can be transported over IPv4. 5.3 Configuration of customer equipmentCustomer Equipment The customer connection networks are composed of CPEsPE and PEs.CPE(s). Usually, each PE connects a large number of CPEsmultiple CPE components to the backbone network infrastructure. This number may reach tens of thousands or more. The configuration of CPEs is an heavyCPE is, in general, a difficult task for the ISPISP, and this iseven made harder as themore so in this case, because configuration must be done remotely. In this context, the use of auto-configuration mechanisms is verybeneficial, even if manual configuration is still an option. The parameters that usually need to be automaticallyprovided to thecustomers automatically are: - The network prefix delegated by the ISP, - The address of the Domain Name System server (DNS), - SomePossibly other parameters such asparameters, e.g., the address of ana NTP server may also be needed sometimes.server. When access controluser identification is required on the ISPISP's network, DHCPv6 canmay be used to provide the configuration parameters.configurations otherwise either DHCPv6 or a stateless mechanism can be used. This is discussed morein detailsmore detail in [DUAL ACCESS]. When access controlNote that when the customer connection network is shared between the users or the ISPs, and not required (unusual case),just a stateless mechanism could be used, but no standard definition exists atpoint-to-point link, authenticating the moment. 5.4 Requirements for Traceability Most ISPsconfiguration of the parameters (esp. prefix delegation) requires further study. As long as IPv4 service is available alongside of IPv6, no critical need exists to be able to autoconfigure IPv6 parameters (except for the prefix) in the CPE-- IPv4 settings work as well. 5.4 Requirements for Traceability Most ISPs have some kind of mechanism to trace the origin of traffic in their networks. This hasalso has to be available for IPv6 traffic. Thistraffic, which means that a specific IPv6 address or prefix has to be tied to a certain customer, or that records of which customer had which address/prefixaddress or prefix must be maintained. This also applies to the customers with tunneled connectivity. This can be donedone, for exampleexample, by mapping a DHCP response to a physical connection and storing this in a database. It can also be done by assigning a static address or refixprefix to the customer. For any traceability to be useful, ingress5.5 Ingress Filtering in the Customer Connection Network Ingress filtering must be deployed towards allthe customers. 5.5 Multi-homingcustomers, everywhere, to ensure traceability, to prevent DoS attacks using spoofed addresses, to prevent illegitimate access to the management infrastructure, etc. Ingress filtering can be done, for example, by using access lists or Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are described in [BCP38UPD]. 5.6 Multi-Homing Customers may desire multihomingmulti-homing or multi-connecting for a number of reasons [RFC3582]. MultihomingMulti-homing to more than one ISP is a subject still under debate. Deploying multiple addresses from each ISP and using the addresses of the ISP when sending traffic to that ISP is at least one working model; in addition, tunnels may be used for robustness [RFC3178]. Currently, there are no provider-independent addresses for end- sites. Multi-connecting more than once to just one ISP is a simple practice, and this can be done e.g. withdone, e.g., by using BGP with public or private AS numbers and a prefix assigned to the customer. To be further defined as the multihoming situation gets clearer. 5.6 Ingress filtering5.7 Quality of Service In most networks, quality of service in one form or another is important. Naturally, the customer connection network Ingress filtering must be deployed everywhere towardsintroduction of IPv6 should not impair existing Service Level Agreements (SLAs) or similar quality reassurances. Depending on the customers, to ensure traceability, prevent DoS attacks using spoofed addresses, prevent illegitimate access todeployment of the management infrastructure, etc. The ingress filtering canIPv6 service, the service could be done for example using access lists or Unicast Reverse Path Forwarding (uRPF). Mechanisms for thesebest-effort, at least initially, even if the IPv4 service had a SLA. Both IntServ and DiffServ are describedequally applicable in [BCP38UPD].IPv6 as well as in IPv4 and work in a similar fashion. Of these, typically only DiffServ has been implemented. 6. Network and service operation actionsService Operation Actions The network and service operation actions fall into different categories as listed below: - IPv6 network devicesdevice configuration: for initial configuration and updates - IPv6 Network Managementnetwork management - IPv6 Monitoringmonitoring - IPv6 customer management - built-in "networkIPv6 network and service operation" IPv6operation security Some of these actionsitems will require an IPv6 native transport layer to be available, while some otherwhereas others will not. InAs a first step, network devicesdevice configuration and regular network management operations can be performed over an IPv4 transport, asbecause IPv6 MIBs are also available over IPv4 transport. Nevertheless, some monitoring functions require the availability of IPv6 transport availability.transport. This is for instancethe casecase, for instance, when ICMPICMPv6 messages are used by the monitoring applications. InThe current inability to get IPv4 and IPv6 traffic statistics for management purposes by using SNMP separately from dual-stack interfaces is an issue. As a second step, IPv6 transport can be provided for any of these network and service operation facilities. [To be completed, send feedback/text!]7. Future Stages After a while theAt some point, an ISP might want to transition to a service that is IPv6 only, at least in certain parts of theits network. This transition creates a lot of new cases ininto which toit must factor inhow to maintain the IPv4 service. Providing an IPv6 onlyIPv6-only service is not much different thanfrom the dual IPv4/IPv6 service described in stage 3 except fromfor the need to phase out the IPv4 service. The delivery of IPv4 services over an IPv6 network and the phase out isof IPv4 are left for a futuresubsequent document. 8. Example networksNetworks In this section, a number of different network examples are presented. TheyThese are only example networks and will not necessarynecessarily match toany existing networks. Nevertheless, the examples will hopefullyare intended be useful even in thecases whenin which they do not match thespecific target networks. The purpose of the example networks is to exemplify the applicability of the transition mechanisms described in this document onto a number of different example networkssituations with different prerequisites. The examplesample network layout will be the same in all network examples. The networksnetwork examples are toshould be seenviewed as aspecific representationrepresentations of thea generic network with a limited number of network devices. An arbitraryA small number (in this case 7)of routers have been selected to representused in the network examples. However, sincebecause the network examples follow the implementation strategies recommended for the generic network scenario, it should be possible to scale the exampleexamples to fit a network with an arbitrary number, e.g. several hundreds or thousands, of routers. The routers in the examplesample network layout are interconnected with each other as well as with another ISP. The connection to another ISP can eitherbe aeither direct connectionor through an exchange point. In addition to these connections, there are alsoa number of customer connection networks connected to the routers. customer connection networksare normally connected to the backbone via access routers, but can in some cases be directlyalso connected to the backbonerouters. As described earlier in the generic network scenarios, the customer connection networks are used to connect the customers. customerCustomer connection networks can,can be, for example, bexDSL or cable network equipment. |ISP1 | ISP2 +------+ | +------+ | | | | | |Router|--|--|Router| | | | | | +------+ | +------+ / \ +----------------------- / \ / \ +------+ +------+ | | | | |Router|----|Router| | | | | +------+ +------+\ | | \ | Exchange point +------+ +------+ \ +------+ | +------+ | | | | \_| | | | |-- |Router|----|Router|----\|Router|--|--|Switch|-- | | | | | | | | |-- +------+ /+------+ +------+ | +------+ | / | | +-------+/ +-------+ | | | | | |Access1| |Access2| | | | | +-------+ +-------+ ||||| ||||| ISP Network ----|-----------|---------------------- | | Customer Networks +--------+ +--------+ | | | | |Customer| |Customer| | | | | +--------+ +--------+ Figure 2:3: ISP network exampleSample Network Layout. 8.1 Example 1 In exampleExample 1 presents a network built according to the sample network layout with a native IPv4 backbone. The backbone is running IS-IS and IBGP as routing protocols for internal and external routes, respectively. MBGP is used to exchange routes over the connections to ISP2 and the exchange point. Multicast using PIM-SM routing is present. QoS using DiffServ is deployed. Access 1 is xDSL connected to the backbone through an access router. The xDSL equipment, except for the access router, is considered to be layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically assigned to the customer using DHCP. No routing information is exchanged with the customer. Access control and traceability are preformed in the access router. Customers are separated into VLANs or separate ATM PVCs up to the access router. Access 2 is Fiber to the building or home (FTTB/H) connected directly to the backbone router. This is considered to be layer-3-aware, because it is using layer 3 switches and it performs access control and traceability through its layer 3 awareness by using DHCP snooping. IPv4 addresses are dynamically assigned to the customers using DHCP. No routing information is exchanged with the customer. The actual IPv6 deployment might start by enabling IPv6 on a couple of backbone routers, configuring tunnels between them (if not adjacent), and connecting to a few peers or upstream providers (either through tunnels or at an internet exchange). After a trial period, the rest of the backbone is upgraded to dual- stack, and IS-IS without multi-topology extensions (the upgrade order is considered with care) is used as an IPv6 and IPv4 IGP. When upgrading, it's important to note that until IPv6 customers are connected behind a backbone router, the convexity requirement is not critical: the routers just will not be able to be reached using IPv6. That is, a software supporting IPv6 could be installed even though the routers would not be used for (customer) IPv6 traffic yet. That way, IPv6 could be enabled in the backbone on a need-to-enable basis when needed. Separate IPv6 BGP sessions are built, similar to IPv4. Multicast (through SSM and Embedded-RP) and DiffServ are offered at a later phase of the network, e.g., after a year of stable IPv6 unicast operations. Customers (with some exceptions) are not connected using a tunnel broker, because offering native service faster is considered more important -- and then there will not be unnecessary parallel infrastructures to tear down later on. However, a 6to4 relay is provided in the meantime for optimized 6to4 connectivity. xDSL equipment, operating as bridges at Layer 2 only, do not require changes in CPE: IPv6 connectivity can be offered to the customers by upgrading the PE router to IPv6. In the initial phase, only Router Advertisements are used; DHCPv6 Prefix Delegation can be added as the next step if no other mechanisms are available. The FTTB/H access has to be upgraded to support access control and traceability in the switches, probably by using DHCP snooping or a network built accordingsimilar IPv6 capability, but it also has to be compatible with prefix delegation and not just address assignment. This could, however, lead to the need to use DHCPv6 for address assignment. 8.2 Example 2 In example topology is present with a native IPv4 backbone,2 the routers. Thebackbone is running IS-ISIPv4 with MPLS and is using OSPF and IBGP as routing protocolare for internal and external routes respectively. In theThe connection to ISP2 and the exchange point MBGP is usedrun BGP to exchange routes. Multicast is presentand is using PIM-SM routing.QoS is present and is using DiffServ.are not deployed. Access 1 is xDSL,a fixed line, e.g., fiber, connected directly to the backbone through an access router. The xDSL equipment, except for the access router, is considered to be layer 2 only, e.g. Ethernet or ATM. IPv4 addresses are dynamically assigned to the customer using DHCP. No routingbackbone. Routing information is in some cases exchanged with CPE at the customer. Access control and traceabilitycustomer's site; otherwise static routing is done in the access router. Customers are separated in VLANs or separate ATM PVCs upused. Access 1 can also be connected to BGP/MPLS-VPN running in the access router.backbone. Access 2 is Fiber to the building/homexDSL connected directly to the backbone router. The FTTB/HxDSL is considered to belayer 3 aware2 only, and performsaccess control and traceability through its layer 3 awareness. IPv4 addressesare dynamically assignedachieved through PPPoE/PPPoA. PPP also provides address assignment. No routing information is exchanged with the customer. IPv6 deployment might start with an upgrade of a couple of PE routers to support [BGPTUNNEL], because this will allow large-scale IPv6 support without hardware or software upgrades in the core. In a later phase, perhaps years later, IPv6 traffic would run natively in the whole network. In that case IS-IS or OSPF could be used for the internal routing, and a separate IPv6 BGP session would be run. For the fixed-line customers the CPE has to be upgraded and prefix delegation using DHCP. NoDHCPv6 or static assignment would be used. An IPv6 MBGP session would be used when routing information is exchanged withhas to be exchanged. In the customer. 8.2xDSL case the same conditions for IP-tunneling as in Example 21 apply. In example 2addition to IP-tunneling an additional PPP session can be used to offer IPv6 access to a limited number of customers. Later, when clients and servers have been updated, the backbone is running IPv4IPv6 PPP session can be replaced with MPLS. Routing protocols used are OSPFa combined PPP session for both IPv4 and IBGPIPv6. PPP has to be used for internaladdress and external routes. In the connectionprefix assignment. 8.3 Example 3 A transit provider offers IP connectivity to ISP2other providers, but not to end users or enterprises. IS-IS and the exchange point BGP isIBGP are used to exchange routes. Multicastinternally and BGP externally. Its accesses connect Tier-2 provider cores. No multicast or QoS are not present. Access 1is a fixed line access, e.g. fiber, connected directly toused. Even though the backbone. CPE is presentRIR policies on getting IPv6 prefixes require the assignment of at least 200 /48 prefixes to the customer and routing information is in some cases exchanged otherwise static routingcustomers, this type of transit provider obtains an allocation nonetheless, as the number of customers their customers serve is used. Access 1significant. The whole backbone can alsobe connectedupgraded to BGP/MPLS-VPN runningdual-stack in the backbone. Access 2 is xDSL connected directly to the backbone router. The xDSL is layer 3 aware. Addresses are dynamically assigned using DHCP. Access control is achieved on the physical layer and traceability is achieved using DHCP snooping. Noa reasonably rapid pace after trialing it with a couple of routers. IPv6 routing informationis exchanged withperformed using the customer. 8.3 Example 3 Asame IS-IS and separate IPv6 BGP sessions. The ISP provides IPv6 transit provider offers IP connectivityto other providers, but notits customers for free, as a competitive advantage. It also provides, at the first phase only, a configured tunnel service with BGP peering to end users or enterprises. IS-ISthe significant sites and IBGPcustomers (those with an AS number) which are the customers of its customers whenever its own customer networks are not offering IPv6. This is used internallydone both to introduce them to IPv6 and BGP externally. Its accesses connect Tier-2 provider cores. No multicast or QoSto create a beneficial side-effect: a bit of extra revenue is used.generated from its direct customers as the total amount of transited traffic grows. 9. Security Considerations This document analyses scenarios and identifies some transition mechanisms that could be used for the scenarios. It does not introduce any new security issues. Security considerations of each mechanism are described in the respective documents. However, a few generic observations are in order. o introducing IPv6 adds new classes of security threats or requires adopting new protocols or operational models than with IPv6; typically these are generic issues, and to be further discussed in other documents, for example, [V6SEC]. o the more complex the transition mechanisms employed become, the more difficult it will be to manage or analyze their impact on security; consequently, simple mechanisms are to be preferred. o this document has identified a number of requirements for analysis or further work which should be explicitly considered when adopting IPv6: how to perform access control over shared media or shared ISP customer connection media, how to manage the configuration management security on such environments (e.g., DHCPv6 authentication keying), and how to manage customer traceability if stateless address autoconfiguration is used. 10. Acknowledgements This draft has greatly benefited from inputs by Pekka Savola,Marc Blanchet, Jordi Palet.Palet, Francois Le Faucheur and Cleve Mickles. Special thanks to Richard Graveman for proofreading the document. 11. Informative referencesReferences [EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of RP in IPv6 Multicast Address" - draft-ietf-mboned-embeddedrp-00.txtWork in progress [MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M- ISIS: Multi Topology (MT) Routing in IS-IS" draft-ietf-isis-wg-multi-topology-06.txtWork in progress [RFC 2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz, "Multiprotocol Extensions for BGP-4" RFC 2858 [RFC 2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing" RFC 2545 [BCP38UPD] F. Baker, P. Savola "Ingress Filtering for Multihomed Networks" draft-savola-bcp38-multihoming-update-01.txtWork in progress [RFC3582] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site- Multihoming Architectures" RFC 3582 [RFC3178] J. Hagino, H. Snyder, "IPv6 Multihoming Support at Site Exit Routers" RFC 3178 [BGPTUNNEL] J. De Clercq, G. Gastaud, D. Ooms, S. Prevost, F. Le Faucheur "Connecting IPv6 Islands across IPv4 Clouds with BGP" draft-ooms-v6ops-bgp-tunnel-00.txt [DUAL ACCESS] Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi "A Model of IPv6/IPv4 Dual Stack Internet Access Service" draft-shirasaki-dualstack-service-02.txtWork in progress [UNMANCON] T.Chown, R. van der Pol, P. Savola, "Considerations for IPv6 Tunneling Solutions in Small End Sites" draft-chown-v6ops-unmanaged-connectivity-00Work in progress [UNMANEVA] C. Huitema, R. Austein, S. Satapati, R. van der Pol, "Evaluation of Transition Mechanisms for Unmanaged Networks" Work in progress [PROTO41] J. Palet, C. Olvera, D. Fernandez, "Forwarding Protocol 41 in NAT Boxes" Work in progress [V6SEC] P. Savola, "IPv6 Transition/Co-existence Security Considerations" Work in progress Authors' Addresses Mikael Lind TeliaSonera Vitsandsgatan 9B SE-12386 Farsta, Sweden Email: email@example.com Vladimir Ksinant 6WIND S.A. Immeuble Central Gare - Bat.C 1, place Charles de Gaulle 78180, Montigny-Le-Bretonneux - France Phone: +33 1 39 30 92 36 Email: firstname.lastname@example.org Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics. 416, Maetan-3dong, Paldal-Gu, Suwon, Gyeonggi-do, Korea Email: email@example.com Alain Baudot France Telecom R&D 42, rue des coutures 14066 Caen - FRANCE Email: firstname.lastname@example.org Pekka Savola CSC/FUNET Espoo, Finland EMail: email@example.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.