Internet DRAFT - draft-allen-lap-ipv6
draft-allen-lap-ipv6
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]
