Network Working Group Keith Allen Internet Draft Weijing Chen Expiration Date: April 2003 SBC Technology Resources, Inc. October 2002 IPv6 for Large Access Providers draft-allen-lap-ipv6-00.txt 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." 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 discusses how Large Access Providers (LAP) could use IPv6 to solve current technical challenges. In particular, IPv6Æs large address space and optional header mechanism can be used to provide scalable and manageable broadband Internet access and Virtual Private Network (VPN) services. A new optional header to support forwarding-plane based VPNs is proposed. Table of Contents 1. Introduction.................................................2 2. Large Access Provider Problems...............................2 3. IPv6 Solutions...............................................3 3.1. IPv6 for Mass Market Broadband Internet Access..............3 3.1.1. IPv6 Broadband Access Operation..........................4 3.1.2. IPv4 Support.............................................5 3.1.3. Advantages of using IPv6 for Broadband Access............5 Allen and Chen Expire April 2003 [Page 1] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 3.2. Virtual Private Networking..................................5 3.2.1. IPv6 Connectionless VPN Operation........................6 3.2.2. Internet Access and VPN Site Discovery Problems..........7 3.2.3. VPN Site Discovery Solution..............................7 3.2.4. Internet Access Solution.................................8 3.2.5. IPv6 Connectionless VPN Advantages.......................9 4. VPN Header Details..........................................10 5. Security Consideration......................................11 6. Conclusion..................................................11 7. References..................................................11 8. Authors' Addresses..........................................12 1. Introduction Large providers of Internet access are faced with difficult demands that could be met by IPv6. This paper will show how large access providers could use IPv6 to meet their service needs and at the same time position them to support the evolution to IPv6. This paper will also propose some new capabilities for IPv6 to help meet the needs of large access providers. 2. Large Access Provider Problems Two of the hardest problems faced by large and very large access providers are: 1. Providing broadband access to large numbers of subscribers while offering them advanced capabilities such as QoS. 2. Implementing VPNs on a large scale. Currently, the industry seems to be turning towards the use of connections of one type or another to address these problems, rather than applying the datagram principles on which the Internet was founded. Many large access providers, particularly telcos, use ATM connections and PPP to provide users with a means to access the network. Some schemes for providing QoS will rely upon additional connections such as additional ATM connections and PPP sessions or MPLS label switched paths. The current solutions for VPNs also rely upon connections, usually MPLS paths. Adding connections to the Internet and trying to maintain them will in the end prove to be unduly complicated, increasing operational expenditures and slowing new service activations. Instead, this is a good time to take a step back and consider what makes a networking technology successful. There are two networking technologies that have achieved global deployment: telephony (PSTN) and IP. These two technologies are globally successful because they are scalable and manageable. But Allen and Chen Expire April 2003 [Page 2] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 what makes them scalable and manageable? Both technologies have two interesting traits that lend themselves to scalability and manageability: 1. Each subscriber on either network has a globally unique address that can be used to route communications to them. 2. All of the permanent state associated with a subscriber is maintained at their connection point with the network. No internal network resources need to be allocated for any particular subscriber. Basically, the simple idea behind both networks is: get the subscriber connected to some interface on the network, give them an address, and let them go. The management of some new feature (such as DHCP or Caller ID) requires only the simple configuration of the subscriberÆs router or switch interface. Resources internal to the network need to be administered and engineered, but on an aggregate basis, not per-subscriber. Once the administration and engineering of resources internal to the network is required for each subscriber (e.g. threading a permanent connection through the network, or creating virtual routing functions on a set of routers), easy manageability goes out the window. Just to clarify, the connections being discussed here are connections that are dedicated to individual subscribers and established and maintained through administrative means by the service provider. This does not include the connections (links or trunks) between switches or routers; all networks require these. Nor does it include the connections established on-demand through signaling in a telephone network. 3. IPv6 Solutions So how can IPv6 solve these problems and at the same remain true to the InternetÆs connectionless heritage? The broadband access and VPN problems are addressed separately below. 3.1. IPv6 for Mass Market Broadband Internet Access The challenge for large access providers in the broadband Internet access market is to connect the masses of residential and business subscribers on one side of their network with ISPs, Application Service Providers, and perhaps enterprise networks on the other side of their network. Traditionally, Layer 2 or Layer 2.5 technologies have been employed for this. IPv6, however, offers a much more scalable and manageable alternative. Consider that the job of a large access provider is to get a packet of data from a subscriberÆs premises across the providerÆs local network to an ISP or ASP, and the reverse for traffic going the other direction. IPv6 is an ideal Allen and Chen Expire April 2003 [Page 3] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 technology for this, especially given its large address space and routing header mechanism. 3.1.1. IPv6 Broadband Access Operation HereÆs how access providers can use IPv6 for broadband subscribers. Assume for the moment that a broadband Internet access subscriber has an IPv6-capable computer (or PDA, Internet appliance, etc.). As this computer boots up it will acquire an IPv6 address (which weÆll call its ôcare-ofö address) from the access provider (e.g. DSL or cable company) through either stateless [RFC2462] or stateful [RFC2131] address autoconfiguration. It cannot at this point, however, reach the public Internet. It can, though, communicate with the subscriberÆs ISP, which is also connected to the same IPv6 network. The computer next sends a directed DHCP request to an access gateway belonging to the subscriberÆs ISP, requesting an IPv6 address (which weÆll call its ôhomeö address) from the ISP. This request includes authentication information. Alternatively, the computer can be assigned a static IPv6 address from the ISP. The subscriberÆs computer now has two IPv6 addresses: a care-of address received from the access provider, and a home address received from the ISP. The home address is going to be the computerÆs main address. Traffic sent from this computer will have the home address as the IP source address, and traffic from other subscribers will be directed to this home address. Any traffic sent to the home address will be delivered to the ISP gateway from which the address was acquired. That gateway must then forward the traffic to the care-of address assigned to the computer. To make sure this forwarding occurs, the ISP gateway must associate, or ôbind,ö the home address with the care-of address. This binding can be accomplished in two ways. The first is to borrow the ôbinding updateö message from mobile IP. Using this approach, after acquiring both addresses, the subscriberÆs computer would send a binding update message to the ISP gateway, binding its home address with its care-of address. The other approach would instead have the subscriberÆs computer include the care-of address in the DHCP request. The ISP gateway could then bind the home address with the care-of address when the home address is allocated. Once the binding is in place, the ISP gateway then uses IPv6Æs routing header [RFC2460] capability (rather than IPv6 encapsulation) to forward Internet traffic to the subscriber. The route specified by the IPv6 header and this routing header will have two hops. The first hop is the care-of address and the second hop is the home address. The care-of address will get the packet to the subscriberÆs computer. The computerÆs internal protocol stack will then recognize the home address and process the packet. Allen and Chen Expire April 2003 [Page 4] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 The above describes routing traffic from the Internet to the subscriber. Traffic sent from the subscriber to the Internet follows the reverse route, also with a two-hop route specified by IPv6 header and routing header. The first hop is the ISP access gatewayÆs address and the next hop is the Internet destination address. The routing header is added into each IPv6 packet by the protocol stack inside the subscriberÆs computer. This will ensure that all of the subscriberÆs traffic is routed through the ISP. 3.1.2. IPv4 Support IPv6 support for address and routing headers make it well suited for broadband access, especially when subscribers natively use IPv6. During the transition from IPv4 to IPv6, an IPv4-in-IPv6 tunneling approach could be used. That is, an access node (e.g. modem or home gateway) on the subscriberÆs premises could take any IPv4 packets from the subscriber, encapsulate them in an IPv6 packet, and forward them to the ISP. IPv6 packets would be transferred by the access node without modification. 3.1.3. Advantages of using IPv6 for Broadband Access IPv6 offers many advantages over the Layer 2 and 2.5 technologies currently used for broadband Internet access. One is the simple ability for the access provider to ôpingö a subscriberÆs interface. Due to IPv6Æs enormous address space and support for address autoconfiguration, address management would be fairly simple. Finally, it would replace the need to establish connections between each subscriber and their ISP with a single, uniform, scalable, and manageable IPv6 network. Not only would these capabilities help to simplify operations for service providers, it could also help speed the introduction of IPv6 and actually help subscribers by solving the problems associated with private addresses and Network Address Translation (NAT). 3.2. Virtual Private Networking Another problem being faced by large access providers is implementing VPNs for large numbers of subscribers. Most of the industryÆs focus is on either Layer 3 VPNs as specified in [RFC2547] or Layer 2 VPNs, but IPv6 provides the basis for a connectionless approach to VPNs that will likely be more scalable and easier to manage than RFC 2547 L3VPNs or L2VPNs. First, consider the reasons why subscribers want VPNs: 1. Security. Subscribers want to control the traffic that comes in across their network interfaces. 2. Private Addresses. Subscribers donÆt want to be constrained in the assignment of addresses. Allen and Chen Expire April 2003 [Page 5] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 3. Ease-of-use. Subscribers want to offload some of the management of their network by buying a VPN instead of individual links between sites. 4. Economics. Again, subscribers want to buy a VPN instead of individual links between sites. 5. Quality of Service (QoS). Subscribers want QoS guarantees and Service Level Agreements (SLAs). Quickly scanning this list reveals that certainly the private address issue can be solved with IPv6. IPv6Æs enormous address space will make it possible to give subscribers sizable ranges of addresses for them to use. As for the other needs, typically the reason why subscribers buy individual links between sites is security. Security is really the key to VPNs. If security can be maintained, many subscribers will give up the maintenance of individual links between sites and turn to VPNs. The security approach taken by RFC 2547 is to limit the reachability of addresses in VPNs. This requires building not only many connections (and even layered connections) internal to the network, but also a rather elaborate control plane consisting of virtual routers exchanging routing information. Instead of this control plane approach to security, however, consider instead a more direct, forwarding plane approach. Instead of limiting reachability, why not simply stop unwanted packets from being delivered to VPN subscribers at the network egress? The key to this, of course, is to know which packets subscribers want and which they donÆt. This could be accomplished by securely marking each packet as belonging to a particular VPN when that packet enters the network. IPv6Æs optional header mechanism is a perfect means for accomplishing this. We propose, with details below, the definition of an IPv6 optional header for VPNs. The main purpose of this optional header is to carry a VPN identifier that marks a packet as belonging to a particular VPN. 3.2.1. IPv6 Connectionless VPN Operation Given this proposed capability to label VPN packets in IPv6, an access provider would create a VPN for a subscriber by first assigning a unique VPN ID to that subscriber. A unique VPN ID could be an IPv6 address prefix under control of the access provider, or a number allocated out of a separate space. The access provider then enables VPN processing on each interface on the Provider Edge (PE) routers serving a site in the VPN. The VPN ID assigned to the subscriber is included with the VPN interface configuration. When the PE receives a packet on a VPN interface, it adds the VPN header, containing the VPN ID, into the packet and sends it on its way. Any egress packets on the VPN interface are Allen and Chen Expire April 2003 [Page 6] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 first checked to make sure they have the VPN header and that the VPN ID inside matches that assigned to the interface. Any packets that do not are discarded. For those that do, the VPN header is stripped and the packet is delivered. An alternative to this would be for the Customer Edge (CE) equipment to add and strip the VPN headers, with the PE gear merely checking to make sure the VPN ID is valid. The access provider will have to make sure that ALL packets with VPN headers entering its network are valid by comparing them with the VPN id assigned to the interface. If the interface does not have VPN processing enabled, or if the VPN IDs do not match, the packet will either have to be dropped or stripped of its VPN header. To enable interworking between different VPNs, it might be necessary for PE router interfaces to be configurable with some small number of VPN IDs (instead of just one), and to allow packets with any VPN ID on the list to pass. Also, it might be necessary to either turn off the VPN rejection mechanism or to have a fairly large number of VPN IDs on peering points between access providers. Turning off the capability would mean the access providers entering into the peering relationship would have to trust each other, but trust is also required for VPN route exchanges in the RFC 2547 approach. 3.2.2. Internet Access and VPN Site Discovery Problems Two key issues, VPN Internet access and VPN site neighborhood discovery, must be solved to make this approach feasible. Fortunately IPv6 routing header and multicast address capabilities are well suited to solve these problems. The VPN header mechanism proposed above will keep traffic inside a VPN from getting outside the VPN, and traffic outside the VPN from getting inside it. Users on VPNs, however, often need to access sites that are not part of their VPN. Also, routers at each VPN site need to know how to route traffic to other VPN sites. The following sections describe how this can be implemented. 3.2.3. VPN Site Discovery Solution Often a VPN subscriber will have many sites, so the CE routers at these different sites will need a means to discover each other and to discover how to route packets among themselves. Before describing this, however, some terms must be defined. In addition to assigning a VPN ID to each VPN, the VPN subscriber will also be assigned an IPv6 address range to use as they choose. Addresses in this range will be referred to as ôhomeö addresses. The interfaces connecting the CE routers to the service providerÆs Allen and Chen Expire April 2003 [Page 7] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 network are also assigned IPv6 addresses, but these addresses come out of the service providerÆs address range, not the subscriberÆs address range. These addresses will be referred to as ôcare ofö addresses. One final action is required of the service provider when first establishing a VPN: the assignment of an IPv6 multicast address for each VPN. A slight modification to the CE routers could then enable them to multicast routing protocol discovery packets (e.g. OSPF HELO packets) on this multicast address. This will enable all of the CE routers in a VPN to discover each other, and they will all appear to be ôone hopö away from each other. When the routers discover each other using the multicast address, they will be identified by their ôhomeö addresses. To actually communicate directly with another CE, however, a CE will need to know its peerÆs ôcare ofö address. The equivalent of an ARP [RFC826] protocol will be needed, but this is straightforward. Each CE can then multicast a modified ARP message to find other CE's ôcare ofö address that can be used to reach other CE with a particular CE's home address. A CE router can then forward an IPv6 packet to another CE router by adding a routing header into the packet. The resulted route specified by IPv6 header and this new routing header will have two hops. The first hop is the other CE's care of address and the second hop is the original destination address of the packet. Note that even if a site not part of the VPN somehow gets added to the multicast group, it will still not be able to exchange routing information with any routers inside the VPN due to the VPN header checking mechanism. 3.2.4. Internet Access Solution Typically traffic to or from a site outside the VPN is passed through a firewall to prevent security violations, while traffic between sites within the VPN is not. Forwarding-plane based VPNs will work the same way. A firewall will have a separate interface (logical or physical) to the IPv6 service providerÆs network. The PE serving this interface will not be configured with a VPN ID, and thus will drop any egress packets on this interface with a VPN ID, and drop or strip the VPN header out of any ingress packets that have a VPN header. In addition to knowing how to route packets to other VPN sites, as described in the previous section, each CE router will also need to know how to route traffic destined outside the VPN. Once a default route to the Internet through firewall is established at one or more of the VPN sites, this information will also get propagated among Allen and Chen Expire April 2003 [Page 8] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 the CE routers using their routing protocol. A CE router at a site without a firewall will then automatically learn to route Internet- bound traffic securely to a VPN site equipped with a firewall. To actually forward the traffic it will add a routing header just as it did for other inter-site traffic. After arriving at the remote site the traffic will then pass through the firewall and out to the Internet. Return traffic will follow the reverse route, assuming the subscriber has correctly advertised the route to the network service provider using BGP. Provided with the ability to automatically discover all the CE routers in a VPN, and to forward packets between them, CE routers can then implement the necessary routing functions to enable VPN users to securely communicate with each other, and to also access other sites through a firewall. 3.2.5. IPv6 Connectionless VPN Advantages This forwarding plane based approach to implementing VPNs has many advantages. Service provider simplicity. This forwarding plane approach to VPNs aligns with the traits that keep networks scalable and manageable: service state is maintained at the subscriberÆs interface. Internal resources do not have to be allocated and maintained for a particular subscriber. Establishing a VPN for a subscriber requires only two simple one-time steps: allocating a VPN ID for the subscriber, and allocating an IPv6 multicast address for the subscriber. For each site in the VPN, the service provider must then of course establish a link to the site. After that, the service provider simply has to configure the PE interface serving the site with the VPN ID assigned to the subscriber. Subscriber simplicity. The subscriber can continue to use whatever internal routing protocol they want without change. Configuring a CE router takes only two simple steps (in addition to those required to set up any other router). First, the subscriber must configure the CE routerÆs WAN interface with the ôcare ofö address assigned by the service provider. Second, the subscriber must also configure that interface with the multicast address assigned by the service provider. After that, the router can join the multicast group and automatically discover the other sites. Compatibility. This approach also works well for IPv4 VPN and L2VPN subscribers. For IPv4 VPN, IPv4-in-IPv6 tunneling instead of IPv6 routing headers is used to encapsulate packet. A CE at a VPN site takes any IPv4 packets from the subscriber, encapsulates them in an IPv6 packet, and forwards them to the other site. Encapsulating L2 (VLAN) frames in IPv6 packets can easily support L2VPNs. Because Allen and Chen Expire April 2003 [Page 9] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 the network connecting the CE routers is a routable IPv6 network, spanning tree algorithms can be used for L2VPNs. Hardware-based solution. This VPN security approach relies on hardware instead of software. The packet processors serving all interfaces, not just VPN interfaces, will have to do more work to validate VPN headers, and even add and strip them. It does, however, relieve routers from having to implement large numbers of virtual routers and the software control mechanisms to coordinate them. It also eliminates the need for the large numbers of MPLS paths and paths within paths required to support VPNs. Finally, since MooreÆs law continues to hold for hardware but does not apply to software, it favors the forwarding plane approach to VPN security. Reviewing the VPN subscriber needs listed above reveals that IPv6 could be augmented to meet them all. The security mechanism proposed here can provide the security required by VPN users. IPv6 already provides a generous address space. Given these, the cost and hassle of maintaining separate links between sites will no longer be necessary for many subscribers. The only remaining issue from the list above is QoS. VPN subscribers, though, are not the only users requiring QoS. QoS is being addressed for both IPv4 and IPv6, and connectionless QoS mechanisms can still be utilized in a connectionless VPN. 4. VPN Header Details This section provides the details on the proposed VPN ID header for IPv6. The VPN ID header is a specific option of the more generic destination options header (header type 60). It has the following format: 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1|type = ? | length = 9 | VPN hop | +---------------------------------------------------------------+ | | | VPN ID (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first three bits of the first octet are 011 and the remaining five bits is the Destination Option Type number (to be determined). The meaning of first three bits is spelled out in [RFC2460]. The values specified here (011) require that nodes not recognizing this option type should discard the packet and that the option data (VPN hop count) may change en-route. Discarding the packet is a conservative choice meant to ensure that if a packet is somehow delivered to a node not capable of processing VPN headers the packet Allen and Chen Expire April 2003 [Page 10] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 is dropped rather than possibly delivered to a site outside the VPN. VPN hop count is an 8-bit unsigned integer. It will be incremented by 1 by each peering node of a VPN provider that forwards the packet. VPN ID is the 64-bit identifier of each VPN. 5. Security Consideration For broadband Internet access service, packet security is neither better nor worse than a typical Internet access connection. For VPN service, if the PE devices under the control of the access provider are properly configured with VPN ID(s), packets will not enter a VPN unless authorized to do so. If the CE devices under the control of the VPN subscriber are properly configured with home address, care-of address, and multicast address, packets will not leave a VPN unless in a manner consistent with the policies of the VPN. 6. Conclusion IPv6 is well-suited to provide solutions to problems currently faced by large Internet access providers. ItÆs multicast and routing header capabilities can be used for mass market broadband Internet access, and the addition of the proposed VPN header will provide a forwarding-plane based solution for VPNs. Using native IPv6 to solve these problems will avoid the scalability and manageability problems inherent with permanent connection based solutions, while positioning service providers to serve customers who are migrating to IPv6. 7. References [RFC826] "An Ethernet Address Resolution Protocol", D. Plummer, November, 1982. [RFC2026] "The Internet Standards Process -- Revision 3", S. Bradner, October, 1996. [RFC2131] "Dynamic Host Configuration Protocol", R. Droms, March 1997. [RFC2460] "Internet Protocol, Version 6 (IPv6) Specification", S. Deering, R. Hinden, December, 1998. [RFC2462] "IPv6 Stateless Address Autoconfiguration", S. Thomson, T. Narten, December 1998. [RFC2547bis] "BGP/MPLS VPNsö, draft-ietf-ppvpn-rfc2547bis-02.txt, E. Rosen, Y. Rekhter, etc, July, 2002. Allen and Chen Expire April 2003 [Page 11] Internet Draft draft-allen-LAP-IPv6-00.txt Oct. 2002 8. Authors' Addresses Keith Allen SBC Technology Resources, Inc. 9505 Arboretum Blvd. Austin, Texas 78759 Phone: +1 512 372 5741 Email: kallen@tri.sbc.com Weijing Chen SBC Technology Resources, Inc. 9505 Arboretum Blvd. Austin, Texas 78759 Phone: +1 512 372 5710 Email: wchen@tri.sbc.com Allen and Chen Expire April 2003 [Page 12]