INTERNET DRAFT Cleve Mickles (Co-Author) Document: draft-mickles-v6ops-isp-cases-05.txt AOL Time Warner Expires: Sept 2003 March 2003 Transition Scenarios for ISP Networks Status of this Memo This document is an Internet-Draft and is subject to 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 describes the different types of Internet Service Provider (ISP) networks in existence today. It will provide design and operational considerations in delivering network services to customers for seven specific areas in an effort to better identify specific issues which may arise during a transition to IPv6. Mickles, et al. Expires - Sept. 2003 [Page 1]
Transition Scenarios for ISP Networks Mar. 2003 Table of Contents 1. Introduction................................................4 2. Scope of the document.......................................4 3. Core/Backbone Networks......................................5 3.1 Topology.............................................5 3.2 Hardware.............................................6 3.3 Routing..............................................6 3.4 Traffic Engineering..................................9 3.5 Security.............................................9 3.6 Network Management..................................10 3.7 Hosting Gear........................................11 4. Broadband HFC/Coax Networks..............................12 4.1 Terminology.........................................12 4.2 Topology............................................12 4.3 Hardware............................................13 4.4 Routing.............................................15 4.5 Policing............................................15 4.6 Security............................................15 4.7 Network Management..................................16 4.8 Host Gear...........................................16 5. Broadband DSL Networks....................................17 5.1 DSL physical architecture ..........................17 5.2 Logical architectures used today for IPv4 access....19 5.3 Addressing for today's IPv4 access..................24 5.4 Routing.............................................25 5.5 DNS.................................................25 5.6 Network Management..................................25 6. Narrowband Dialup Networks................................26 6.1 Topology............................................27 6.2 Hardware............................................27 6.3 Routing.............................................27 6.4 Traffic Engineering.................................28 6.5 Security............................................28 6.6 Network Management..................................28 6.7 Hosting Gear........................................29 7. Public Wireless LAN.......................................30 7.1 Topology............................................30 7.2 Routing and Addressing..............................31 7.3 Traffic Engineering.................................31 7.4 Security............................................32 7.5 Network Management..................................33 7.6 Hosting Gear........................................33 Mickles, et al. Expires - Sept. 2003 [Page 2]
Transition Scenarios for ISP Networks Mar. 2003 8. Broadband Ethernet .......................................34 8.1 Topology............................................34 8.2 Hardware............................................34 8.3 Routing.............................................35 8.4 Traffic Engineering.................................35 8.5 Security............................................35 8.6 Network Management..................................36 8.7 Hosting Gear........................................36 9. Internet Exchange Point...................................37 9.1 Topology............................................37 9.2 Routing and Addressing..............................38 9.3 Traffic Engineering.................................38 9.4 Security............................................39 9.5 Network Management..................................39 9.6 Hosting Gear........................................39 10.0 Security Considerations...................................39 11.0 Network Management Considerations.........................39 Acknowledgements..................................................40 References........................................................40 Terminology.......................................................42 Author's Addresses................................................43 Copyright (C) The Internet Society (2003). All Rights Reserved. Mickles, et al. Expires - Sept. 2003 [Page 3]
Transition Scenarios for ISP Networks Mar. 2003 1. Introduction This document will describe the basic design of ISP networks today. It will be used to provide direction on what must be considered to transition IPv4 networks to IPv6. The main purpose of this document is to identify, and document the issues that must be considered before transitioning a network to IPv6. This document is not meant to determine exactly how the transition will occur for the various ISP networks. This document is not meant to describe how to build an IPv6 network from scratch. This document will not describe what is or is not a "Tier 1" or "Tier 2"..."Tier N" ISP. The document focuses on IP capable network devices and may reference non-IP related devices for clarification purposes only. 2. Scope of the document The scope of this document is to cover the major topics ISPs must consider in building and running their IP networks. The following sections include descriptions and design considerations for Core backbone networks, Broadband DSL networks, Broadband HFC Cable networks, Narrowband Dialup networks, Public Wireless LAN Networks, Broadband Ethernet and Public Exchange Point networks. The document will also identify Security and Network Management concerns which in some cases will be common to all as well some areas that may be unique to the particular service. In some cases a single ISP may provide services in more than one of the areas mentioned below. Although the Optical core is important in today's networks, that layer is generally transparent to the IP layer except in a few special cases where ISPs have allowed the IP core to be aware of the optical layer underneath. Hence, this draft does not include further optical considerations. Each scenario will discuss issues related to network topology, network hardware, routing, policing, security, network management, configuration and host gear. Mickles, et al. Expires - Sept. 2003 [Page 4]
Transition Scenarios for ISP Networks Mar. 2003 3. Core/Backbone Networks This section describes the general topologies of and characteristics of today's CORE networks. Although there are numerous large scale networks out there today, most employ the same basic set of principles when designing and building their networks. Trunks to remote sites ^ ^ | | / / / / /\/ / / /\/ / / ____/____ ____/____ | | | | | CORE1 | | CORE2 | |_________| |_________| ____________/ | \ | | | / | \ | | | / +===========|===\=========+ | | | / | +=\==========+ | ___|_/_ ___|_/_ \ _____|_ | | | | \____| | | BDR1 | | BDR2 | | BDR(n)| |_______| |_______| |_______|\ | | | \ | | | \ | | | \_Peering( Direct & IX ) | | | ___|___ ___|__ ___|___ | | | | | | | CPE1 | | CPE2 | | CPE(n)| |_______| |______| |_______| Figure 3.1 3.1 Topology In terms of physical equipment, today's backbone networks consist mainly of high-speed routers that are configured in a basic core and edge configuration. In most configurations, for redundancy, there are two or more core routers as well as two or more border routers. The border routers provide any local connectivity and peering. Generally filtering, routing policy and policing type functions are done on the border routers. The core routers provide aggregation of border router traffic as well as aggregation of long haul circuits to remote sites. The physical topology is depicted in Figure 3.1. Mickles, et al. Expires - Sept. 2003 [Page 5]
Transition Scenarios for ISP Networks Mar. 2003 The logical topology includes the core routers being IBGP peers with every other POP in the mesh. The local border routers are route reflector clients of the core. 3.2. Hardware The hardware deployed in the CORE Backbone is similar across ISPs and generally consists of high-speed routers. The requirement for switches in the CORE network is for infrastructure type hosting gear. In some cases CPE equipment is provided by the CORE ISP. 3.3. Routing An assumption is that all routers in the core will have some IPv4 reachability. As the network grows additional routers may be added which only have IPv6 reachability but most routers which support IPv6 networking will be dual stack. In the routing area ISPs must consider how IPv6 traffic will be exchanged over the link layer of the network. There are two cases which are available. Either all routers within the network will be IPv6 capable or a disjoint subset of routers will have IPv6 capabilties. This decision will determine whether IPv6 addressing is configured over each IPv4 point to point link or the more likely scenario is configuring IPv6 on some point to point links and tunneling IPv6 over IPv4 to reach other network devices. 3.3.1 IGP Internally Core ISPs generally use OSPF or ISIS as an IGP. Loopback interfaces and point-to-point links are what make up routes within the IGP. Once the IPv6 link layer topology has be determined the IPv6 IGP choice must be made. The choices in the Core network include basically OSPF or ISIS for IPv6 routing. For networks which have deployed one or the other for IPv4 traffic, the ISP must consider the ramifications of the choice. Case 1: Existing OSPF IPv4 network If the ISP chooses to build IPv6 capabilities using OSPFv3, then considerations of existing hardware and memory constraints must be made since OSPFv3 places additional load on network gear. This IGP will operate in separate memory space and will need to be configured separately from any existing OSPFv1 implementation. Mickles, et al. Expires - Sept. 2003 [Page 6]
Transition Scenarios for ISP Networks Mar. 2003 If the ISP chooses to build IPv6 capabilities using ISIS, then considerations of existing hardware and memory must constraints must be made as adding ISIS to an existing OSPFv1 implementation. The amount of hardware resources are not as taxing. As with the OSPF scenario, ISIS would be configured separately from the existing OSPFv1 implementation. Case 2: Existing ISIS IPv4 network If the ISP chooses to build IPv6 capabilities using OSPFv3, then considerations of existing hardware and memory constraints must be made since OSPFv3 places additional load on network gear. This IGP will operate in separate memory space and will need to be configured separately from any existing ISIS implementation. If the ISP chooses to build IPv6 capabilities using ISIS, then the amount of hardware resources are not as taxing since IPv6 is integrated within ISIS. The protocol does not need to be configured separately. 3.3.2 EGP Generally BGP4 is the Edge gateway protocol of choice. The EGP routing table consists of networks, which are received via customer advertisements, statically configured for customers who are not running a dynamic routing protocol or networks that are nailed up as part of the ISP infrastructure. A decision must be made on whether the exchange IPv6 routes via BGP4+ or to use static addressing with each neighbor. 3.3.3 IRR & Routing Policy Routing policy on the core includes multiple peer-groups setup to represent a collection of customers, external peers or internal peers. In the case of customer connections, there are peer groups that are configured to send FULL_ROUTES, CUSTOMER-ROUTES or DEFAULT-ROUTES to a particular set of customers. To perform this function, the peer groups reference ROUTE-MAPs. External peers generally fit into the CUSTOMER_ROUTES peer group. In the case of internal peers an INTERNAL peer group is used to identify internal routers that carry backbone circuits and an RRCLIENT peer-group is created to group border routers with a common set of characteristics. Mickles, et al. Expires - Sept. 2003 [Page 7]
Transition Scenarios for ISP Networks Mar. 2003 Assuming most Core providers are using BGP4 to exchange IPv4 routes the providers will have multiple routing policies and various peer groups setup for IPv4 neighbors. A sample of these various policies are noted above. A choice must be made as to whether to create parallel sets of routing policy for IPv6 neighbors whether they are INTERNAL or EXTERNAL to the network. A decision on where/how to register IPv6 routing policy in the IRR must be done as well. 3.3.4 Multicast PIM-SM is the generally accepted solution for deploying multicast. For IPv6, this is a hard problem. 3.3.5 Addressing Addressing in the Core of the network has two components. The infrastructure routers have requirements for loopback and point-to-point addresses. These addresses are routed within the IGP. Customer routes are pinned up on core routers. In the area of IPv6 addressing, the core providers should determine whether create additional IPv6 loopback interfaces as well as decide whether to add IPv6 addresses on all point to point links along side IPv4 addresses. As with IPv4 aggregate routes, the core provider must determine whether IPv6 aggregate routes should be "pinned up" or advertised from the edge network. 3.3.6 NAT NAT may be deployed in the Core provider networks only in special cases. In terms of IPv6 routing in the core, IPv4 NATs should be avoided when trying to exchange IPv6 traffic. 3.3.7 Aggregation Aggregation of routes in the Core networks should be done. Networks that are used for loopbacks and interfaces should be aggregated prior to being advertised externally. Generally aggregated "pin up" routes are placed on routers that carry backbone trunks. For IPv6, ISPs must choose whether they will aggregate loopbacks and interfaces as is done in IPv4. Mickles, et al. Expires - Sept. 2003 [Page 8]
Transition Scenarios for ISP Networks Mar. 2003 3.4. Traffic Engineering Core providers have few choices in terms of traffic engineering. One method is MPLS. To use MPLS, a provider only needs a traffic matrix of next-hop data from within their network. Once a provider knows how much traffic is sent between all routers in the network, MPLS tunnels can be built to steer traffic over the optimum path to deliver all traffic. This scheme is analogous to the use of ATM PVCs over OC-12 circuits in prior years. Most networks employ some type of traffic engineering mechanism to steer traffic around potentially congestive areas. Beyond the standard methods of TE, some ISPs attempt to adjust metrics or cost on p2p links to perform TE. An additional method involves using varying BGP routing announcements to increase or decrease traffic on a particular link. Finally, there are also networks that employ an over provisioning model to limit packet loss. This involves adding capacity above and beyond what is needed. Core ISPs must consider whether to deploy IPv6 traffic engineering mechanisms to control the flow of IPv6 traffic through the network. IPv6 has inherent advantages to perform native traffic engineering or the provider may use existing IPv4 "tweaks" to control IPv6 traffic flow. 3.5. Security In the Core provider's network, security has a specific scope. Securing a network is typically done on the border or edge router. Generally an attempt is made to filter BOGON(RFC 1918) routes, traffic sourced from unallocated address space or sourced from address ranges that are internal to the local ISP. In some cases, hosts that support the infrastructure network equipment generally have filters in place to protect those hosts from outside attacks. In many Core networks, there is IPv4 filtering in place for many reasons. The ISP must determine whether adding IPv6 filtering policy to the current set of policy will add the protection needed and allow the network to remain stable. 3.5.1 Intrusion Detection Intrusion detection mechanisms and systems are used to protect infrastructure and host gear. Generally these intrusion detection systems are placed at various points within the network to search for vulnerabilities within the infrastructure as well as monitor activity that may be considered suspicious. Mickles, et al. Expires - Sept. 2003 [Page 9]
Transition Scenarios for ISP Networks Mar. 2003 For IPv6 intrusion detection may be more difficult to perform due to the large subnet size generally deployed in IPv6 networks. The average subnet is a /64 network which makes random scans by attackers less effective. There are cases where known server systems which may be published in DNS may be targeted. The ISP must choose whether to deploy IPv6 intrusion detection mechanisms prior to implementing IPv6. 3.5.2 Ingress Filtering Ingress filtering on Core networks comes in multiple flavors. For providers that do filter, the first level is EGP filtering. When a peering session is setup, ISPs require a peer to register their routes in an IRR and that data is used to create an EGP filter on the peering session to only accept registered advertised routes. A step beyond this includes Reverse Path Forwarding (RPF) checks to verify that traffic sourced from the customer link is within the advertised range. An alternative to the automated RPF checks is the brute force static packet filters which can be used to control traffic sourced from a particular customer link. For IPv6, Core providers must determine whether to implement similar ingress filtering mechanisms which are currently deployed in IPv4 networks. 3.6. Network Management Devices within the network must be monitored. This is done over in-band connections to the network devices. Generally there are filters on the routers to allow SNMP queries from the query server. 3.6.1 Out of band Out of band networks allow access to consoles of the network gear. In some cases this access is done in-band. There are also cases where separate networks are built to allow access. The Core ISP must determine whether to convert it's out of band network to IPv6 or not. 3.6.2 Configuration Tools Many ISPs have monitoring tools that query the network gear to gather data. These scripts may be written in perl or expect and will access the device via the CLI over the in-band ipv4 connection. Mickles, et al. Expires - Sept. 2003 [Page 10]
Transition Scenarios for ISP Networks Mar. 2003 The ISP must determine whether support servers will have the ability to contact network gear over native IPv6 connections or not. 3.6.3 SNMP Statistical monitoring of network gear is done via SNMP queries. These queries are done via the in-band connection. The ISP must decide whether Network Management devices will contact infrastructure over native IPv6 or IPv4 connections. 3.7. Hosting Gear In terms of host gear, the Core networks maintain hosts for supporting and managing the network, but not necessarily the end user. The standard set of hosts include DNS servers, mail gateways, authentication( RADIUS or TACACS), and network management servers. The servers are distributed to strategic locations for diversity purposes. Servers included in this model include DNS and TACACS servers that directly support the operator's network. Reachability to the servers is over an IPv4 routed connection. Caching infrastructure is deployed in CORE provider networks in a very limited fashion to assist in reducing the traffic pulled from external sources. For IPv6, providers must decide whether to deploy parallel host infrastructure for IPv6. Other considerations include whether all existing host infrastructure should have IPv6 reachability. Mickles, et al. Expires - Sept. 2003 [Page 11]
Transition Scenarios for ISP Networks Mar. 2003 4. Broadband HFC/Coax Networks This section describes the infrastructure that exists in today's HFC cable networks that support cable modem services to the home. Since many cable providers are regional they generally have used the backbone ISP networks for transit IP services beyond their region. 4.1 Terminology HFC network: Hybrid Fiber Coaxial network CM: Cable Modem CMTS: Cable Modem Termination System CPE: Customer Premises Equipment DOCSIS: Data Over Cable Service Interface Specification -- the standards defining how data should be carried on HFC networks 4.2 Topology 4.2.1 Physical HFC networks are a mix of fiber optic and coaxial cables originally designed for the delivery of cable television. A single infrastructure can support video distribution, data networking and telephony. Video and data signals are typically sourced from different systems and frequency division multiplexed over the HFC network. Historically HFC networks were uni-directional and required some kind of telco-return path to support bi-directional data. Today much of the cable infrastructure has been upgraded to support return paths over the HFC network. A CMTS can serve quite a large geographic area: 10s of miles radius is not uncommon and DOCSIS specifies a 100 mile diameter upper limit. In a DOCSIS system, down-stream and up-stream channels are distinct and occupy different frequency bands. A CMTS may terminate multiple up and downstream channels and a CM must tune in to an up-stream and down-stream channels before communicating. All packets on the HFC network are forwarded via the CMTS. Cable modems may forward packets between network segments attached to CPE. Hundreds of hosts on a cable network may be part of the same broadcast domain. Mickles, et al. Expires - Sept. 2003 [Page 12]
Transition Scenarios for ISP Networks Mar. 2003 4.2.2 Logical DOCSIS systems are designed to transport IP traffic. The following two paragraphs are present in all current DOCSIS specifications. Section 1.3.1 [DOCSIS-1.1]: "The intended service will allow transparent bi-directional transfer of Internet Protocol (IP) traffic, between the cable system headed and customer locations, over an all-coaxial or hybrid-fiber/coax(HFC) cable network." Section 3.2.2.1 [DOCSIS-1.1]: "Forwarding of IP traffic MUST be supported. Other network layer protocols MAY be supported. The ability to restrict the network layer to a single protocol such as IP MUST be supported." In the context of the [DOCSIS-1.0], [DOCSIS-1.1] and [DOCSIS-2.0] specifications "Internet Protocol (IP) traffic" means IPv4 traffic. The following diagram(Figure 5.2.2) has been reproduced from the DOCSIS RFI specification [DOCSIS-1.1] and slightly simplified: +-----------+ | | | | /-----+ | +--------+ WAN <------+ CMTS |<========>| Modem |<===> CPE \-----+ | Cable +--------+ | | | | Network | | | | | | +-----------+ | | | +-------------------+------------------+ | "Transparent IP Traffic Through the System" Figure 4.2.2 Note that between the WAN and the CPE, both forwarding at Layer-2 (bridging) and at Layer-3 (routing) will meet the goal of transparent transport of IP traffic. 4.3. Hardware 4.3.1 Cable Modems Cable modems operate as transparent L2 bridges forwarding datagrams from the HFC network to the CPE network. Mickles, et al. Expires - Sept. 2003 [Page 13] Transition Scenarios for ISP Networks Mar. 2003 Cable modems use a combination of policy settings and IGMPv2[RFC2236] to control multicast forwarding (see Section 3.3.1 [DOCSIS-1.1]). Forwarding of IPv6 multicast datagrams may not occur properly as CMs are required to forward multicast datagrams only when CPE equipment has joined that group. This is potentially a show-stopper if native IPv6 Neighbor Discovery[RFC2461] is being used through a CM. 4.3.2 CMTS Layer-2 Bridge A DOCSIS compliant CMTS may be implemented as a Layer-2 transparent bridge. Forwarding of IPv4 packets by the transparent bridge is mandatory and forwarding of other protocols may be supported. It is likely that implementers using this approach will support forwarding of arbitrary protocols using 802.1d hence forwarding of native IPv6 datagrams should just work. IPv6 is then deployed on the ISP router infrastructure natively or using an automatic tunneling scheme like 6to4[RFC3056]. As with the CM, a bridged CMTS that selectively forwards multicast datagrams on the basis of IGMPv2 will potentially break IPv6 ND. This behavior is recommended but not mandated for a Layer-2 CMTS. Communication between CPE behind different cable modems is always forwarded by the CMTS. IPv6 communication between the different sites relies on multicast IPv6 Neighbor Discovery [RFC2461] frames being forwarded correctly by the CM and the CMTS. 4.3.3 CMTS IP Router A DOCSIS compliant CMTS may be implemented as a Layer-3 IPv4 router. In this case IPv6 packets passing from the WAN network to CPE must be encapsulated in IPv4. Forwarding between channels on the HFC network (i.e. within a CMTS) may still take place at L2 hence the comments in Section 3.2 may also apply. A CMTS may also be an IPv6 router and thus support IPv6 natively. 4.3.4 IPv4 NAT CPE routers A fairly common CPE device in HFC networks is the IPv4 NAT/DHCP router. It is usually connected between the cable modem and all other CPE equipment allows multiple devices to share a single IPv4 address and cable modem connection with a minimum of configuration overhead. The NAT/DHCP router is a directional IPv4-only device in the communication path between the CMTS and the CPE. Unfortunately the IPv4 NAT router prevents (or at least seriously complicates) the deployment of IPv6 in a number of ways: o As an IPv4-only device it will block native IPv6 frames forwarded through the cable modem. Mickles, et al. Expires - Sept. 2003 [Page 14]
Transition Scenarios for ISP Networks Mar. 2003 o The use of private addresses on the CPE network means that schemes relying on global IPv4 addresses (e.g. 6to4[RFC3056]) cannot be used. o Many NAT/DHCP routers only support forwarding of a limited number of IPv4 protocols (e.g. TCP, UDP, ICMP) and will drop IPv4 encapsulated IPv6 with an "unknown" protocol number (e.g. 6to4 packets). In an ideal world every IPv4 NAT router would be upgraded to additionally become a native IPv6 router using 6to4 automatic tunneling. In general 6to4 residential gateway devices must be made as self-configuring as existing IPv4 NAT routers. 4.4 Routing There are no known HFC-specific routing issues. Cable networks are typically access networks. If the CMTS is a native IPv6 router then it will likely need to participate in ISPs the IGP of choice. If the CMTS is a bridge, the infrastructure router(s) that it connects to will need to speak an IGP. If 6to4[RFC3056] is used, it is recommended that the ISP sink (and forward) traffic to the anycast 6to4 relay router address [RFC3068]. 4.5 Policing Cable networks are large shared subnets. Filtering is extensively used in this environment to ensure stability of the network and to protect subscribers. For example, filters are used to prevent CPE DHCP server responses from escaping from the CPE network. As a security measure, filters are very often deployed to prevent file sharing protocols leaking between different CPE sites. IPv6 opens up a new communication channel. Existing IPv4 filter software will not block IPv6 communication. If IPv6 is tunneled over an IPv4 infrastructure filters may need to examine the contents of encapsulated packets. 4.6 Security CPE NAT boxes are rectifying routers. This can be viewed as an implementation of an "outgoing only" security policy. IPv6 devices need to be able to support a similar kind of policy. Mickles, et al. Expires - Sept. 2003 [Page 15]
Transition Scenarios for ISP Networks Mar. 2003 4.7 Network Management DOCSIS cable modems use an out of band, privately addressed IPv4 network for configuration and network management functions. DOCSIS cable modems and CMTS are IPv4 hosts on the out of band management network. At present there is no compelling need to update this network to support IPv6. DOCSIS cable modems use: SNMP [RFC1157] for network management. TFTP [RFC1350] for software and configuration parameter download DHCP [RFC2131] for acquiring IPv4 address, etc allowing communication on the management network. ToD [RFC0868] for initial time synchronization. Various MIBs for RF and CPE filter configuration.. DOCSIS OSSI docs override the IETF MIB specifications. Any IPv6 issues in there? 4.8 Host Gear Dual stack DNS server is necessary if you want to support IPv6-only CPE equipment. DDNS is pretty much mandatory if you want to give CPE devices DNS names. This is because only the IPv6 host knows what its full IPv6 address is (esp when privacy addresses are used). Transition functionality.. which? where? v4/v6 translation between devices in the home is done where? If RFC1918 addresses are in use (perhaps behind the NAT), then there isn't much choice but to do it inside the CPE box. Transparent proxy caches aren't going to cache IPv6 web traffic. Mickles, et al. Expires - Sept. 2003 [Page 16]
Transition Scenarios for ISP Networks Mar. 2003 5. Broadband DSL Networks This section describes the infrastructure that exists in todays High Speed DSL Networks. 5.1 DSL physical architecture Digital Subscriber Line (DSL) technology is a modem technology that allows subscribers to perform access from the home or office to broadband network services by using existing twisted-pair copper wire telephone lines. The term xDSL is the generic name that has been given to the family of digital subscriber line technologies, including ADSL, SDSL, HDSL, VDSL, and IDSL. The POTS (Plain Old Telephone Service) takes only the frequency range 0-3000 Hz but there is considerably more bandwidth on these copper lines; DSL gets more from them by using sophisticated digital coding and splitting the line (reserving the higher frequencies for data, the lower for voice and fax) to achieve high-speed data transmission over the local loop from the customer site to a service provider's switching center. But the bandwidth a subscriber can receive depends on the quality of the line and on the distance to the service provider's center. Distance can be increased, but then speed is reduced. For instance, it is possible to use ADSL up to 18,000 feet, but the maximum downstream speed is then reduced to 1544 kbps. Several models are used to deploy IP over DSL services, but all use the same components: Mickles, et al. Expires - Sept. 2003 [Page 17]
Transition Scenarios for ISP Networks Mar. 2003 Customer Premises | Network Access Provider | Network Service Provider CP NAP NSP +-----+ +-----+ +-----+ |Hosts|--| DSL +-------+DSLAM| +-----+ |Modem| | +----+ +-----+ +-----+ | | +-----+ +------+ | +-----+ +-------+ |Hosts|--|Router| +--+ BAS +----+ ISP | ISP +-----+ +--+---+ +--+ | | Edge +===> Network | | +-----+ | Router| +--+--+ | +-------+ | DSL +---+ | |Modem| | | +-----+ | | | +-----+ | +-----+ +------+ +---+DSLAM+----+ |Hosts|--|Router| +---+ | +-----+ +--+---+ | +-----+ | | +--+--+ | | DSL +---+ |Modem| +-----+ Figure 5.1 The hosts are connected to the DSL network either directly through a modem, either through a router and a modem. The modems may be included in the hosts or in the routers. When it is not the case, the DSL modems may be accessed through ATM, Ethernet or USB. It must be noted that when a router is used in customer premises, it often has only very limited resources in terms of memory or processing power. IP packets are then transported on twisted-pair telephone lines to the NAP's DSLAM (DSL Access Multiplexer), thanks to DSL technology. The DSLAM terminates and multiplexes several DSL accesses to the NAP's backbone. It forwards data to the BAS (Broadband Access Server = DSLAM aggregator), which is in charge of directing them to the POP (Point Of Presence = the ISP Edge Router) of the NSP that the client has subscribed to. Note that NAP and NSP can be the same organization. The technology used in the NAP network is usually ATM, but other types of layer 2 technologies may be used. This model enables the local operator to make its local copper available to other companies. Operators are then able to offer DSL technology for broadband Internet access. Mickles, et al. Expires - Sept. 2003 [Page 18]
Transition Scenarios for ISP Networks Mar. 2003 As the access network puts service users in communication with their NSPs, security and access control are required. 5.2 Logical architectures used today for IPv4 access Data transport between the CPE and the service provider's point of presence (POP) generally relies on an ATM based infrastructure. Two types of use of this infrastructure are common: * ATM point-to-point model: one PVC connects each subscriber to its NSP. From the Broadband Access Server (BAS), there are exactly as many PVCs across the NAP network as the number of subscribers (i.e. one PVC per subscriber). This model is detailed in section 5.2.1. * Aggregation model: the BAS aggregates multiple subscriber PVCs into trunk PVCs to reduce the number of PVC connections across the NAP core network (one PVC provisioned for many subscribers to the same destination NSP, or if the NSP offers multiple service levels, more than one PVC could be established across the core). There are two usual ways to aggregate connections: - PPP Terminated Aggregation (PTA): PPP sessions are opened between each subscriber and the BAS. The BAS terminates PPP sessions and transfers subscriber's traffic up to the POP. This model is detailed in section 5.2.2. - L2TP Access Aggregation (LAA): PPP sessions are opened between each subscriber and the POP. The BAS dispatches PPP sessions up to the POP, by encapsulating them into L2TP tunnels. This model is detailed in section 5.2.3. 5.2.1 ATM POINT-TO-POINT MODEL This model is adapted to networks with few subscribers and static configuration. It is simple to deploy but it cannot be used in large networks. In this model, each subscriber is connected to its NSP via one PVC. The user network IP packets are transmitted frames from the CPE to the DSL modem or router. There, RFC 2684 bridging occurs: The LAN frames are forwarded into an ATM PVC (segmenting them into ATM cells through AAL5). The following figure describes the protocol architecture of this model. Mickles, et al. Expires - Sept. 2003 [Page 19]
Transition Scenarios for ISP Networks Mar. 2003 Customer Premises NAP NSP <-------------------------> <---------------> <--------------------> +-----+ +-------+ +-----+ +--------+ +-----------+ |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ ISP | ISP +-----+ +-------+ |Modem| +--------+ | Edge +==> Network +-----+ | Router | +-----------+ <----------------------------> ATM Figure 5.2.1 Since the CPE is in bridging mode, this model is layer 3-independent and the NAP is free of addressing and routing concerns. The NSP edge router sees all subscribers as attached to the same Ethernet link. Very complex controls and restrictions must thus be performed to avoid spoofing and broadcast storms. Last, subscribers do not have access to multiple ISPs over a single DSL line. 5.2.2 PPP TERMINATED AGGREGATION (PTA) MODEL The PTA architecture relies on PPP-based technologies (PPPoA and PPPoE), terminated at the BAS. The BAS has at least one PVC opened to each NSP, but several PVCs are sometimes used when the NSP offers differentiated services (QoS...). In this architecture, the aggregator BAS provides PPP session termination and the subscriber data is then forwarded to the NSP's edge router using IP over ATM. Since the PPP session is terminated at the BAS, the BAS must perform per session authentication, authorization and accounting on behalf of the NSP, and perform layer 3 routing. The PTA architecture has several advantages. First, it reduces the number of PVCs used in the NAP core network. Second, it offers the subscribers the capability to choose between several NSPs. However, it is not as flexible as the LAA model from this point of view: it requires strong coordination between the NSP and the NAP. This model is often used when the NSP is also the NAP. 5.2.2.1 Connection using PPPoA The following figure describes the protocol architecture of this model. Mickles, et al. Expires - Sept. 2003 [Page 20]
Transition Scenarios for ISP Networks Mar. 2003 Customer Premises NAP NSP <--------------------> <----------------------> <-----------------> +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----------+ | +-----+ +-------+ +--------+ +----+-----+ +-----------+ |Hosts|--+Router +------+ DSLAM +-+ BAS +-+ ISP | +-----+ +-------+ +--------+ +----------+ | Edge +=>Core | Router | +-----------+ <--------------------------> PPP Figure 5.2.2.1 The PPP sessions initiated by the CPEs are terminated at the aggregation device (BAS), which authenticates users either by using a local database or by sending a request to a remote server located at the NSP (a RADIUS server for instance). When RADIUS is used, a user can be authenticated based on a username or based on the VPI/VCI used. There is only one PPP session per ATM PVC. Upon successful authentication, the customer premises equipment may then be configured dynamically. Of course, static configuration is also possible. When dynamic configuration is used, the BAS obtains the address of a DNS server and an IPv4 address or prefix for the customer, usually through a DHCP server or a RADIUS server. The BAS then sends this information to the CPE via IPCP, and establishes a new route between the CPE and the BAS. 5.2.2.2 Connection using PPPoE The following figure describes the protocol architecture of this model. Mickles, et al. Expires - Sept. 2003 [Page 21]
Transition Scenarios for ISP Networks Mar. 2003 Customer Premises NAP NSP <--------------------> <----------------------> <-----------------> +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----------+ | +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ |Hosts|--+Router +-+ Modem +-+ DSLAM +-+ BAS +-+ ISP | C +-----+ +-------+ +--------+ +--------+ +----------+ | Edge +=>O | Router | R +-----------+ E <--------------------------------> PPP Figure 5.2.2.2 The PPPoE-based PTA model is more flexible than the PPPoA based one: several PPP sessions may be opened with the BAS at the same time, over as many PPPoE sessions. This allows subscriber to access several services at the same time, on the same VC. The authentication process is the same as the PPPoA one except that VPI/VCI-based authentication cannot be used. It must be noted that the extra PPPoE encapsulation reduces the IP MTU and MRU, because two PPP and PPPoE headers (2+6 bytes) are inserted between the IP packet and the Ethernet header. This also results in a decrease of the MSS of TCP that applications should use. 5.2.3 L2TP ACCESS AGGREGATION (LAA) MODEL While PTA model terminates PPP sessions at the aggregation device and then forwards IP traffic to its destination, LAA model allows forwarding PPP sessions from subscribers to the NSP's point of presence, via a L2TP tunnel. When a CPE initiates a session with its NSP, the BAS intercepts the PPP connection request. It reads the PPP identities of the subscriber and of the NSP, and sends a request to the NSP's RADIUS server, asking for the address of the device to which the PPP connection should be forwarded. If not opened yet, a L2TP tunnel is established between the BAS and the NSP's server. The PPP connection is then encapsulated and forwarded into this tunnel. User authentication and dynamic configuration are performed by the NSP itself. Mickles, et al. Expires - Sept. 2003 [Page 22]
Transition Scenarios for ISP Networks Mar. 2003 5.2.3.1 Connection via PPPoA The following figure describes the protocol architecture of this model. Customer Premises NAP NSP <--------------------> <----------------------> <-----------------> +-----------+ | AAA | + Radius | | TACACS | +-----+-----+ | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |Hosts|--+Router +------+ DSLAM +-+ BAS +-+ ISP | +-----+ +-------+ +--------+ +----------+ | Edge +=>Core | Router | +-----------+ <----------------------------------------> PPP <------------> L2TP Figure 5.2.3.1 5.2.3.2 Connection via PPPoE The following figure describes the protocol architecture of this model. Mickles, et al. Expires - Sept. 2003 [Page 23]
Transition Scenarios for ISP Networks Mar. 2003 Customer Premises NAP NSP <--------------------> <----------------------> <-----------------> +-----------+ | AAA | | Radius | | TACACS | +-----+-----+ | +-----+ +-------+ +--------+ +--------+ +----+-----+ +----+------+ |Hosts|--+Router +-+ Modem +-+ DSLAM +-+ BAS +-+ ISP | C +-----+ +-------+ +--------+ +--------+ +----------+ | Edge +=>O | Router | R +-----------+ E <-----------------------------------------------> PPP <--------------> L2TP Figure 5.2.3.2 5.2.4 OPTIMAL MTU CONFIGURATION FOR DSL CONNECTIONS USING PPPOE While PPPoA does not impact the default MTU on an LAN environment (1500 bytes), PPPoE induces a smaller MTU (1492 bytes, 1500 bytes minus 2 bytes for PPP header and 6 bytes for PPPoE header). This causes some problems, especially when ICMP error messages such as "Packet Too Big' are filtered by intermediate nodes. 5.3 ADDRESSING FOR TODAY'S IPv4 ACCESS One of the benefits of DSL for the customer is the capability to enjoy a permanent connection to the Internet on the telephone line. This allows the customers to use peer-to-peer applications and to set up servers when they are given stable global IP addresses. However, some service providers do not supply static addresses by default, and a lot of customers are using dynamic addresses today. Customers are usually disconnected every day and are given a new address each time they reconnect. Most of the times, customers use private addressing on their LAN and the access routers then perform NAT for Internet access. Some small ISPs do not even provide global addresses to their customers. These ISPs then operate NATs on their backbones. Mickles, et al. Expires - Sept. 2003 [Page 24]
Transition Scenarios for ISP Networks Mar. 2003 5.4 ROUTING Customers of DSL services may run routing protocols on their LAN (usually RIP or OSPF), but these LANs are usually small and do not require the use of a routing protocol. When a router is used in the customer premises, it is usually configured with a default route to the NSP's edge router. In case of multi-homing, the customer's router may use BGP. The NAP may have to run an IGP (OSPF or IS-IS). Usually, the NSP uses an IGP (OSPF or IS-IS) on its core network. 5.5 DNS Very often, the domain name of the customer is managed by the NSP and the domain name server is also hosted by the NSP. In fewer cases, the customer hosts the server on its own LAN. 5.6 Network management Usually, NSPs manage the edge routers by SNMP. The management stations are located on the core network. Very few service providers manage equipment located on customers LANs. The use of NAT on the customer edge router forbids this type of service. Mickles, et al. Expires - Sept. 2003 [Page 25]
Transition Scenarios for ISP Networks Mar. 2003 6. Narrowband Dialup Networks This section describes Narrowband dialup networks that the majority of internet users use today to get online. The scenarios will include solutions where the dial infrastructure is controlled by one entity as well as solutions where ISPs lease modems from a wholesale modem providers. There are multiple types of dialup services from plain/no frills access to the Internet, to wholesale dialup networks that can purchased by an organization wanting to resell internet services, and then there are the full service dialup providers that provide a long list of features to the end user. Generally smaller dialup ISPs purchase a T1 or greater facility from a Local Exchange Carrier(LEC) to the facility where modem equipment is housed. The choice in terms of the number of T1s (or other) is made dependent on how many simultaneous users are supported in the ISP's business model. Depending on the coverage area multiple phone numbers may be provided for the end-user to dial and the LEC may choose to route all calls to a common termination point or provide the traffic across multiple T1 facilities. When an end-user dials an access number, the LEC routes the call to the modem server location and is generally mapped by the LEC into a T1 facility that terminates on the modem server. The modem server attempts to verify the user credentials by querying the authentication server via an IP interface on the modem server. The modem server is present on a LAN network segment along with any relevant hosts as well as the default gateway router. Some services that are common to all dialup providers include the ability to provide DNS service either primary or secondary and an authentication server. The wholesale dial provider builds out the dial network just as the small dialup provider does. Differences include the ability of the wholesale provider to hand off aggregated traffic to the organization purchasing wholesale access or to allow the aggregated traffic to reach the Internet at large without the purchasing organization needing major internet access facilities. Each case has different implications. The infrastructure used in the foundation of these various offerings is somewhat similar although the deployments vary depending on the level of service offered. The basic dialup service provider model that includes modem access to the Internet can be built from a terminal server (generally a digital modem bank), a Layer 2 switch and routers. For global reachability the dialup provider must connect to a backbone provider. The basic design calls for the terminal server to be attached to a layer 2 switch that would in turn have connections to a router. For redundancy, a dialup Mickles, et al. Expires - Sept. 2003 [Page 26]
Transition Scenarios for ISP Networks Mar. 2003 provider can spread multiple shelves of terminal servers across individual routers and manually shift traffic if a router becomes disabled. A more robust redundant solution would be to deploy pairs of routers and use some Router Redundancy Protocol functionality to maintain traffic in the event of a failure of one router. 6.1 Topology +-----+ +------+ +------+ |Hosts|--| 56K +-------+Modem | +----------+ +-----+ |Modem | |Bank +----------+ ISP 1 | NSP 1 +------+ +------+ | Edge +=====> Network | | | Router | | | +----------+ | | | | +----------+ +-------+ +----------+ ISP 2 | NSP 2 |Radius | | | Edge +=====> Network |Server | | | Router | +-------+ | +----------+ | | +----------+ +----------+ ISP 3 | NSP 3 | Edge +=====> Network | Router | +----------+ Figure 6.1 6.2. Hardware The hardware involved in dialup service provider connections include the CPE device that is usually a 56K modem, the Terminal server/modem bank and an authentication server. 6.3. Routing From the host device the user connects to the terminal server using Point-to-Point Protocol (PPP). Once the PPP connection is made the user credentials are sent to the Authentication server. The user is then assigned an IP address and then the connection is forwarded to the appropriate Internet Service Provider (ISP) and then on to a Network Service Provider (NSP). The NSP and ISP network can be external or internal to the dialup service provider. Mickles, et al. Expires - Sept. 2003 [Page 27]
Transition Scenarios for ISP Networks Mar. 2003 In some cases Dial-up service providers will use Network Address Translation (NAT) to connect to external networks. NAT is only required if the address assigned by the authentication server is not a public address. Routing protocols such as an IGP or EGP will only come into play between the ISP and NSP networks. The address space required at a point of presence (POP) is determined by summing the number of modem ports available at a POP. IRR routing policy is generally registered by the ISP or NSP but in some cases the dialup provider may register policy. For IPv6, the Dial-up provider must consider the location of IPv4 NAT devices since IPv6 traffic does not pass through NAT devices. This ISP must also consider how traffic will be exchanged with the NSP. The choice will be determined by whether the existing NSP router has IPv6 reachability. If the NSP does not provide IPv6 access, the Dial-up provider may install additional connectivity to alternate NSP providers of IPv6 reachability to deliver IPv6 traffic or build IPv6 tunnels over IPv4 to reach an IPv6 router which has global IPv6 reachability. 6.4. Traffic Engineering Traffic Engineering (TE) at the dialup ISP level is closer to connection load balancing. TE is generally done by the authentication servers, which monitor the number of active connections and balance connections across available ISP routed connections. There are no considerations for IPv6 in terms of traditional traffic engineering in the dialup scenario. There may be a need to balance incoming IPv6 dialup connections across a radius server via a load-balancing switch device. 6.5. Security Security in the dialup ISP model is mainly meant to protect the network gear from intrusion. By default the terminal servers prevent connections between users. For IPv6, the Dial-up ISP must determine whether to protect all devices on local segments from being attacked via a native IPv6 transport. 6.6. Network Management Accounting and statistical information is collected on a per-user basis for billing purposes and the tools required need to support gathering IPv6 data. Mickles, et al. Expires - Sept. 2003 [Page 28]
Transition Scenarios for ISP Networks Mar. 2003 6.7. Hosting Gear There are a number of hosts that support the dialup ISP model. All servers do not necessarily reside at the terminal server point of connection. Servers included in this model include DNS, Radius, and Mail servers that directly support the end user but are deployed in an optimum location. Reachability to the servers is over an IPv4 routed connection. Servers indirectly related to supporting the user include TACACS servers used to authenticate access to network equipment, tool servers to query and monitor, and cache servers that assist in handling web requests. Cache servers are typically used transparently in between the user and the Internet. The Dial-up ISP must determine which host infrastructure must be reachable via IPv6. The devices in question may include all the servers mentioned above depending on the service offering. Mickles, et al. Expires - Sept. 2003 [Page 29]
Transition Scenarios for ISP Networks Mar. 2003 7. Public Wireless LAN This section describes the infrastructure that exists in today's public wireless LAN services. 7.1 Topology 7.1.1 Physical architecture of public wireless LAN Public wireless LAN (WLAN) enables subscribers within home, office or the outdoors to perform Internet access by using WLAN technology. WLAN technology is standardized by IEEE 802.11, and its maximum transmission speed varies from 1 or 2 Mbps (IEEE 802.11) and 11 Mbps (IEEE 802.11b) to 54 Mbps (IEEE 802.11a). Figure 7.1.1 describes the physical architecture of wireless LAN model. +-------+ | AAA | | Radius| | TACACS| '---' +-------+ ( ) | +-----+ (Wireless) +----+ /------------\ +-------+ |Hosts+--( LAN )---| AP |----| Underlying \--- | ISP |=>Core +-----+ ( ) +----+ \ technology | | Edge | ( ) \-----------/ | Router| '---' +-------+ Figure 7.1.1. Physical architecture of WLAN model. Hosts can connect to WLAN by using WLAN network interface card (NIC), by using PCI or PCMCIA slot. WLAN is basically a broadcast network, and several hosts can share the network by using carrier sense multiple access with collision avoidance (CSMA/CA) access mechanism. Legacy WLAN does not consider authentication and security, but allow any subscriber to connect the network at any time. However, in order for WLAN to be used as public access network, such authentication and security mechanisms are required. Access point (AP) acts as an authentication client, and sends host's authentication parameter to authentication server. Such mechanisms are presented in 3.x.5 in detail. Once the host is authenticated, AP acts as a bridge in order to relay host's information to ISP or vice versa. Various access network technologies can be used between AP and ISP. Lease line, xDSL and HFC/cable are few examples. 7.1.2 Logical architecture of WLAN for data transmission Mickles, et al. Expires - Sept. 2003 [Page 30]
Transition Scenarios for ISP Networks Mar. 2003 Figure 7.1.2 describes protocol architecture of WLAN model. +-------+ | AAA | | Radius| | TACACS| '---' +-------+ ( ) | +-----+ (Wireless) +----+ /------------\ +-------+ |Hosts+--( LAN )---| AP |----| Access \--- | ISP |=>Core +-----+ ( ) +----+ \ technology | | Edge | ( ) \-----------/ | Router| '---' +-------+ +----------+ +-------+ | IP | | IP | +----------+ +-----------+ +-------+ | Wireless | | Bridging | | | | | LAN | +-----------+ | X | Y | | | |WLAN | X | | | | +----------+ +-----+-----+ +---+---+ Figure 7.1.2 Logical architecture of WLAN for data transmission X is subscriber technology (leased line, xDSL, HFC/cable, etc.). Y is WAN technology (SONET/SDH, ATM, etc.). 7.2 Routing and Addressing Public wireless LANs are usually configured in small area (aka, hot spots) and basically broadcast networks. Thus, they do not require the use of a routing protocol. One of benefits of public WLAN is to provide for customers convenient Internet access. This allows the customers in the outdoors to connect to public access networks. ISPs supply not static addresses by default but dynamic addresses by DHCP. The customers are usually disconnected every time and are given a new address each time they reconnect. Most of the times, customers use private addressing and the access routers then perform NAT for Internet access. 7.3 Traffic Engineering ISPs may need to configure traffic filtering or provisioning on demand of their customers. Mickles, et al. Expires - Sept. 2003 [Page 31]
Transition Scenarios for ISP Networks Mar. 2003 7.4 Security Like ethernet, IEEE 802.11 standard dose not define authentication and security mechanisms. Moreover, WLAN is basically a broadcast network and each host can listen information of another host within the same AP service area. Therefore, in order for ISPs to use WLAN as public access network, they should provide authentication and data privacy mechanisms. Authentication mechanism is used to identify whether a subscriber is registered to access the Internet. There can be two authentication mechanisms: (1) IEEE 802.1x and (2) non-standard MAC address based authentication. Once a subscriber is considered as valid, information exchanged between AP and the subscriber should be encrypted in order not to be understood by others. IEEE 802.11i is being standardized on new form of robust security network (RSN) architecture. 7.4.1 IEEE 802.1x based authentication IEEE 802.1x enables edge devices such as bridge or AP to perform authentication mechanism, and determines whether to allow or block data transmitted by hosts. It uses extended authentication protocol (EAP) as a standard protocol to transmit subscriber's authentication data. Authentication is based of userID and/or password, and packets transmitted by un-authenticated hosts are filtered and dropped by AP Figure 8.4.1 describes logical architecture of 802.1x based authentication +-------+ | AAA | | Radius| | TACACS| '---' +-------+ ( ) | +-----+ (Wireless) +----+ /------------\ +-------+ |Hosts+--( LAN )---| AP |----| Underlying \--- | ISP |=>Core +-----+ ( ) +----+ \ technology | | Edge | ( ) \-----------/ | Router| '---' +-------+ +----------+ +------------+ | EAP | | EAP | +----------+ +------------+ | EAPoW | |EAPoW|Auth- | | | | |client| +----------+ +-----+------+ | Wireless | |WLAN | UDP | | LAN | | | | +----------+ +-----+------+ +-------+ | IP | | IP | +------+ +-------+ | X | | X | Y | +------+ +-------+ Figure 7.4.1 Logical architecture for authentication Mickles, et al. Expires - Sept. 2003 [Page 32]
Transition Scenarios for ISP Networks Mar. 2003 The operation of IEEE 802.11 is as follows. Host trying to access the Internet sends EAP-start message to AP. Then AP requests to host subscriber ID information necessary for user authentication. In this case, subscriber ID follows network access ID (NAI) similar to e-mail address format, in order to support global roaming and accounting. Subscriber ID is inserted in AAA EAP-attribute message and transmitted to authentication server (such as Radius or TACACS server). Finally, authentication procedure is completed when AP receives authentication success/failure message from authentication server. 7.4.2 MAC address based authentication (non-standard) This mechanism supports host that does not support IEEE 802.1x. In this mechanism, AP inserts MAC address of hosts into username field and sends authentication message to authentication server. The server determines authentication based on MAC address of host. This mechanism can be considered as unsafe method because subscriber can lose the WLAN card and MAC address can be changed. 7.4.3 Data privacy WLAN is basically broadcast network. Therefore, every host within service area of an AP can listen another host's communication contents. Therefore, very complicated data privacy mechanism must be provided in order not to be revealed by other hosts except intended host. One method to accomplish privacy is to use extension of IEEE 802.1x. Once the subscriber is successfully authenticated, master session key generated during authentication procedure is inserted in authentication success message and transmitted to AP. Then, AP exchanges the key with end host by using EAPoL-key message and synchronizes when to use the key. And then, AP encrypts EAP-success message with the key and sends it to the host in order to notify that the host is allowed to connect WLAN by using IEEE 802.1x. After that, host and AP use dynamically distributed key in order to guarantee privacy within wireless area. 7.4.4 Intrusion Detection, Ingress Filtering, and Prevention Moreover, intrusion detection, ingress filtering and prevention should be considered. 7.5 Network Management ISPs manage the edge routers by SNMP. As well, ISPs need the management of AP by means of its configuration tools. 7.6 Hosting Gear The mail, dns, caching, etc. servers for the customer is usually managed by the ISPs. Mickles, et al. Expires - Sept. 2003 [Page 33]
Transition Scenarios for ISP Networks Mar. 2003 8.0 Broadband Ethernet This section describes the Ethernet based residential access. 8.1. Topology Physical The layouts of Ethernet based accesses to the home are all almost identical. They usually consist in a star topology terminated in the apartment building or at a central point in the network. The latter is probably not a common case and is used only for fiber based access. The termination point usually consists of a switch with varying functionality and in some cases a router. At this termination point the network can be connected directly to a metro network or to an aggregation point and a network access server. Logical The logical architecture for an Ethernet based access varies but is fundamentally the same. A common practice is to use layer 2 Ethernet VLANs to separate the customers up to the network access server. This is done to assure traceability and prevent eavesdropping by customers as well as to be able to block services such as local file sharing. User authentication, other than the physical connection, is in some cases used. It can consist of web login or PPPoE. Web login can be done in two ways, one time login where the device's MAC- address is registered and kept or session login where login is done to activate the connection every time the user starts to use it. The simplest solution is a pure switched network where the users are assigned static addresses and the only controlled device is a router servicing one or several apartment buildings. In this case PPPoE can be used for user authentication if any authentication is used at all. 8.2 Hardware Routers Routers are used in the apartment buildings or centralized to control the user traffic in addition to the actual routing. The most common case is to have only switches in the apartment buildings and the routers at an aggregation point since this allows for one router to service several apartment buildings. Switches Switches are common in an Ethernet based home access. Usually only layer 2 functionality is used such as Ethernet VLAN. Mickles, et al. Expires - Sept. 2003 [Page 34]
Transition Scenarios for ISP Networks Mar. 2003 CPE (router, modem, pc, gateway, appliance, etc) There is no actual CPEs used if not the actual appliances used by the customer is included. 8.3 Routing IGP The interior routing for Ethernet access doesn't differ to any other routing used with in one particular ISP. The routing protocols normally used are IS-IS or OSPF. EGP BGP is used for exchanging external routes. Exterior routing is not used towards the end customers since the customer networks are seen as being directly connected to the edge router and not having a CPE router in between. This means that the customer network is routed directly to an interface on the edge router and not to a customer router. Multicast Sometimes locally enabled to support services like IP-TV. At the moment multicast is not commonly deployed and it is therefore no general way of implementing it. Addressing Usually one address is assigned to the user, dynamically by DHCP or statically by manual configuration. Some operators may allow the use of multiple addresses. NAT Used in some cases when the operator doesn't have enough addresses. Aggregation Aggregation of routes is usually done in several stages in the network. 8.4 Traffic Engineering Traffic engineering is sometime used in the form of bandwidth throttling. This sometimes adds equipment to the network due to the need of an enforcer. The enforcer could be integrated in the edge router or in a separate entity. Filtering of traffic is also implemented in many networks mostly as a simple protection of the users or in other cases as a way of preventing certain services such as mail servers. Mickles, et al. Expires - Sept. 2003 [Page 35]
Transition Scenarios for ISP Networks Mar. 2003 8.5 Security Security is usually implemented in the form of Ethernet VLAN to separate the users and to enable traceability. The use of VLAN is then used instead of any form of login since the users can be traced through their VLAN TAG. A database mapping VLAN to IP- address is used to allow historical traceability. To prevent misuse of addresses anti spoofing is implemented in the network, usually on a per user level to prevent a user from *borrowing* another users address. If PPPoE is used it provides both user authentication and traceability. Filtering of well known file sharing ports to prevent unintentional services is used as mentioned earlier. 8.6 Network Management Usually out of band management is used to configure both routers and switches located in the apartment buildings. This is normally done through a separate Ethernet VLAN. The management tools are more or less the same as in the core network. 8.7 Hosting Gear DNS is managed by the operator as well as any additional services such as mail and web servers. The latter can also in some cases be run by the customer but for the mainstream user this is not the case. Mickles, et al. Expires - Sept. 2003 [Page 36]
Transition Scenarios for ISP Networks Mar. 2003 9.0 Internet Exchange (IX) This section describes the infrastructure that exists in IPv4 Internet exchanges (IX). An IPv6 IX, unlike current NAPs, may assign independent long-haul provider addresses, according to [RFC2374]. An organization subscribing such addresses will be able to change long-haul provider without having to renumber. 9.1 Topology An IX is based on a layer 2 infrastructure that can be, either local to given building, or distributed over a large are by the way multiple interconnected point of presence. This layer 2 infrastructure enables players (e.g. long haul providers) that are connected to the IX to exchange routes. Figure 9.1a below, describes a typical single sited IX. ______________ ____________ +----+ / \ / \ / | +-( LHP2 router ) ( LHP1 router )+ +--+----+ / \______________/ \____________/ | |----+ +---| L2 SW | ______________ / | |-+ ______________ / \+ +-------+ \ / \ ( LHP3 router ) +( LHP4 router ) \______________/ \______________/ Figure 9.1a According to [RFC2374] aggreatable addresses are organized into a three level hierarchy. IXs, together with long haul providers, belong the higher one called "Public Topology". IXs will allocate IPv6 addresses to its directly connected subscribers, providing them addressing independence from long haul providers. IX will then have to include layer 3 functions, e.g. by the means of a router, in order to exchange routes with long haul provider, for gaining global connectivity to its subscribers. The figure below, describes such a new type of IX introducing layer 3 functions, and that topology differs from regular IPv4 IX. Mickles, et al. Expires - Sept. 2003 [Page 37]
Transition Scenarios for ISP Networks Mar. 2003 ______________ ____________ +----+ / \ / \ / | +-( LHP2 router ) ( LHP1 router )+ +--+----+ / \______________/ \____________/ | |----+ +---| L2 SW | ______________ / | |-+ ______________ / \+ +---+---+ \ / \ ( LHP3 router ) | +( LHP4 router ) \______________/ | \______________/ +---+----+ | | ____________ | IX | / \ | router +------(IX subscriber ) | | \____________/ +--------+ Figure 9.1b 9.1.1 Hardware Basically, a regular IX is based on a layer 2 switch, or set of layer 2 switches that may either local to a building, or distributed over larger area. It provides also room space and power supply to enable long haul providers to install their own routers and to exchange routes to each other according to a peering agreement. In the case of an IX providing independent addresses to its directly connected subscribers, the needed layer 3 function will be based on a regular IPv6 router. 9.2 Routing The main goal of an IX, is to enable long haul provider to exchange routes by the way of BGP4+ peering. An IX implementing layer 2 devices only will not participate to into routing and BGP4+ peering. An IX providing independent addresses to its directly connected subscribers, will exchange routes with long haul provider by the way of BGP4+ peering. 9.3 Traffic Engineering/Policing In the case of an IX providing independent addresses to its directly connected subscribers, specific rules may be introduced in order to filter the traffic from a given subscriber to a provider (or a set of provider) according to a given subscription agreement. Mickles, et al. Expires - Sept. 2003 [Page 38]
Transition Scenarios for ISP Networks Mar. 2003 9.4 Security 9.5 Network Management This section does not apply to regular layer 2 based IX, since only local direct peering between third parties is involved. 9.6 Host gear Do not apply. 10. SECURITY CONSIDERATIONS Security concerns will be described within the context of each scenario. After the various scenarios are documented, a summarized section including all of the security considerations may be provided. 11. NETWORK MANAGEMENT CONSIDERATIONS Network Management concerns will be described within the context of each scenario. After the various scenarios are documented, a summarized section including all of the Network Management considerations may be provided. Mickles, et al. Expires - Sept. 2003 [Page 39]
Transition Scenarios for ISP Networks Mar. 2003 ACKNOWLEDGEMENTS [1] The comments from the V6OPS working group are appreciated. REFERENCES [01] TR-025 Core Network Architecture for Access to Legacy Data Networks over ADSL, TR-025 - ADSL Forum, September 1999 [02] RFC 1661 The Point-to-Point Protocol (PPP) [03] RFC 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 [04] RFC 2364 PPP Over AAL5 [05] RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE) [06] RFC 2661 Layer Two Tunneling Protocol "L2TP" [07] RFC 2138 Remote Authentication Dial In User Service (RADIUS) [08] RFC 3162 RADIUS and IPv6 [09] ANSI/IEEE Std 802.11, 1999 Edition: "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications". [10] IEEE Std 802.11b-1999 (Supplement to IEEE 802.11, 1999 Edition): "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Higher-Speed Physical Layer Extension in the 2.4GHz Band". [11] IEEE Std 802.11a-1999 (Supplement to IEEE 802.11, 1999 Edition): "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: High-speed Physical Layer in the 5GHz Band". [12] IEEE Std 802.1x-2001, "Port-based Network Access Control". [13] IEEE Std 802.11i/D2.0, "Specification for Enhanced Security", Mar. 2002. [14] B. Aboba and M. Beadles, "The Network Access Identifier", IETF RFC 2486, Jan. 1999. [15] P. Calhoun and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", IETF RFC 2794, Mar. 2000. [16] L. Blink and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", IETF RFC 2284, Mar. 1998. [17] B. Aboba and D. Simon, "PPP EAP TLS Authentication Protocol", IETF RFC 2716, Oct. 1999. [18] Society of Cable Telecommunications Engineers (SCTE), "SCTE 22-1 2002 DOCSIS 1.0 Radio Frequency Interface", Nov 2001, <http://www.scte.org/standards/standardsavailable.html>. [19] Society of Cable Telecommunications Engineers (SCTE), "SCTE 23-1 2002 DOCSIS 1.1 Part 1: Radio Frequency Interface", Aug 2002, <http://www.scte.org/standards/ standardsavailable.html>. [20] Cable Labs, "Radio Frequency Interface Specification SP-RFIv2.0-I02-020617", Jun 2002, <http:// www.cablemodem.org/specifications/>. Mickles, et al. Expires - Sept. 2003 [Page 40]
Transition Scenarios for ISP Networks Mar. 2003 [21] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983. [22] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [23] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992. [24] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Aug 1997. [25] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [26] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [27] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [28] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, February 2001. [29] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [30] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, Aug 2001. Mickles, et al. Expires - Sept. 2003 [Page 41]
Transition Scenarios for ISP Networks Mar. 2003 TERMS AND ACRONYMS AAL5 ATM Adaptation Layer 5 ADSL Asymmetric Digital Subscriber Line BAS Broadband Access Server CPE Customer Premises Equipment DSL Digital Subscriber Line DSLAM DSL Access Multiplexer L2TP Layer Two Tunneling Protocol LAA L2TP Access Aggregation (model) LAC L2TP Access Concentrator LNS L2TP Network Server MSS Maximum Segment Size (MTU - 40 bytes for IP and TCP headers) MTU Maximum Transmission Unit NAP Network Access Provider NAT Network Address and Port Translation NSP Network Service Provider POP Point Of Presence POTS Plain Old Telephone Service PPP Point-to-Point Protocol PPPoA PPP over ATM PPPoE PPP over Ethernet PSTN Public Switched Telephone Network PTA PPP Terminated Aggregation (model) PVC Permanent Virtual Circuit RADIUS Remote Authentication Dial In User Service USB Universal Serial Bus VPI/VCI Virtual Path Identifier with Virtual Channel Identifier VPN Virtual Private Network Mickles, et al. Expires - Sept. 2003 [Page 42]
Transition Scenarios for ISP Networks Mar. 2003 Author's Addresses Vladimir Ksinant 6Wind 1 place Charles de Gaulle - 78180 Phone: +33139309236 Montigny Le Bretonneux - France Email:vladimir.ksinant@6wind.com Jae-Hwoon Lee Dongguk Univ. 26, 3 Pil-Dong, Chung-gu, Phone: +82 2 2260 3849 Seoul 100-715, Korea Email: jaehwoon@dgu.ac.kr Myung-Ki Shin ETRI PEC 161 Kajong-Dong, Yusong-Gu, Phone: +82 42 860 4847 Taejon 305-350, Korea Email: mkshin@pec.etri.re.kr Aidan Williams Motorola Australian Research Centre Locked Bag 5028 Phone: +61 2 9666 0500 Botany, NSW 1455 Email: Aidan.Williams@motorola.com Australia URI: http://www.motorola.com.au/marc/ Alain Baudot France Telecom R&D 42, rue des coutures Phone: +33 2.31.75.94.27 BP 6243 Email: alain.baudot@rd.francetelecom.com 14066 Caen, FRANCE Mikael Lind Telia Research Vitsandsgatan 9B 123 86 Farsta Phone: +46 70 2406140 Sweden Email: Mikael.e.lind@telia.se Cleveland Mickles America Online, Inc (owned by AOL Time Warner) 12100 Sunrise Valley Drive. Phone: +1 703-265-5618 Reston, VA 20191, USA Email: micklesc@aol.net Mickles, et al. Expires - Sept. 2003 [Page 43]