Previous Page
Next Page

Basic Services Design and Implementation

RTPCom's IPv6 deployment strategy was set for dual stack, a framework that now shapes the design of all IPv6 services. The foundation of the deployment is the addressing plan.

Addressing Plan

RTPCom secured the 2600:A000::/24 prefix from the American Registry for Internet Numbers (ARIN) for its IPv6 nationwide deployment. It made a strong business case for such a large address space based on its current customer base growth rate. RTPCom's ARIN record for this allocation is shown in Table 14-3.

Table 14-3. RTPCom Address-Allocation Record

network:ID:

NET-RTPCom

network:Network-Name:

RTPCOM

network:IP-Network:

2600:A000::/24

network:Org-Name:

RTPCom Corporation

network:Street-Address:

4704 Davis Drive

network:City:

Research Triangle Park

network:State:

NC

network:Postal-Code:

27709

network:Country-Code:

US

network:Tech-Contact:

rtpcom-ops@rtpcom.net

network:Updates:

20050505

network:Updated-By:

jo@myrwhois.net

network:Class-Name:network:

network


In designing the addressing structure of the IPv6 deployment and service, RTPCom decided to use the following constraints:

  • Leverage the large address space to create a logical hierarchy in its addressing scheme.

  • Customers will be assigned either /64 or /56 prefixes.

  • A portion of the address space will be reserved for internal infrastructure needs.

For administrative purposes, RTPCom's network was divided in two areas: East and West. Three bits are reserved to identify each L1 POP in each area. Four bits are reserved to identify the L2 POPs, and the subsequent 6 bits are used to identify the L3 POPs. Table 14-4 summarizes the addressing scheme that will be implemented by RTPCom.

Table 14-4. RTPCom Address Design

Admin Significance

Bits

Count

Prefix

RTPCom

124

 

2600:A000::/24

 

RTPComEast

25

1

2600:A000::/25

 

RTPComWest

25

1

2600:A080::/25

  

L1 POP ID East

2628

8

2600:A010::/282600:A070::/28

  

L1 POP ID West

2628

8

2600:A090::/282600:A0F0::/28

   

L2 POP ID East

2932

16

2600:A01X::/32

   

L2 POP ID West

2932

16

2600:A09X::/32

    

L3 POP ID East

3338

64

2600:A01X:Yy00::/38

    

L3 POP ID West

3338

64

2600:A09X:Yy00::/38

     

L3 POP Router ID East

3944

64

2600:A01X:YyZ0::/44

     

L3 POP Router ID West

3944

64

2600:A09X:YyZ0::/44

      

Customer Prefix East

4556

4096

2600:A01X:YyZP:PP000::/56

      

Customer Prefix West

4556

4096

2600:A09X:YyZP:PP000::/56


As an example, the prefixes used for the L1 POPs and their respective subdivisions are shown in Table 14-5.

Table 14-5. Prefix Distribution per L1 POPs

L1 Name

Prefix

East

Atlanta

2600:A010::/28

New York

2600:A020::/28

Miami

2600:A030::/28

Chicago

2600:A040::/28

West

Houston

2600:A090::/28

Denver

2600:A0A0::/28

Seattle

2600:A0B0::/28

San Francisco

2600:A0C0::/28


The first prefix in both East (2600:A000::/28) and West (2600:A080::/28) ranges was reserved for infrastructure purposes. The 2600:A000::/28 prefix is used in the manner described in Table 14-6.

Table 14-6. RTPCom Infrastructure Addressing Scheme

Use

Bits

Prefix

L1 POP Routers

2932

2600:A00(L1):0000:XX00::/56

L2 POP Routers

3336

2600:A00(L1):(L2)000:XX00::/56

L3 POP Routers

3744

2600:A00(L1):(L2)(L3)(L3)0:XX00::/56


The 2600:A080::/28 is reserved for further growth needs. These prefixes will be protected against outside reach.

Unicast Connectivity

Unicast connectivity between customers and between customers and the ISP provides the underlying service upon which all other services are built.

As it was mentioned earlier, RTPCom decided to deploy IPv6 in dual-stack mode, unlike the PPP/L2TP-based model used for the IPv4 service. RTPCom will switch the customer IPv6 traffic at layer 3 throughout its network, as depicted in Figure 14-8.

Router naming conventions in RTPCom's network are as follows:

  • Router_Name = (L1 name)-(L2 number)-(L3 number)-(POP router).

  • For routers within an L2 POP the (L3 number) field is 0.

  • For routers within and L1 POP the (L2 number) and (L3 number) fields are 0.

  • Routers in the data center are marked with D in the (L2 number) field.

The routers that are used in the following sections to exemplify the implementation of the design concepts are identified based on the naming convention in Figure 14-9.

Figure 14-9. Example of Router-Naming Convention Within the New York L1 POP


RTPCom's addressing scheme presented earlier provides the prefixes relevant to the routers identified in Figure 14-9:

  • L1 = New York (2600:A020::/28)

  • L2 = 10 (2600:A02A::/32)

  • L3 = 12 (2600:A02A:3000::/38)

  • L3 POP Router = 16 (2600:A02A:30F0::/44)

  • L3 POP Router 16 subscriber (/64) = 10 (2600:A02A:30F0:0A01::/64)

  • L3 POP Router 16 subscriber (/56) = 100 (2600:A02A:30F0:6400::/56)

These prefixes are used for service purposes, while the 2600:A002:A::/36 prefix range is used for infrastructure purposes.

From a routing perspective, the IPv6 deployment matches the IPv4 for the most part. The same routing protocols are operating in the same areas of the network. There is, however, a significant difference in that the IPv4 infrastructure is not aware of prefixes outside of it. RTPCom provides virtual pipes between the ISPs and the customers over its self-contained infrastructure. RTPCom's network is aware of the customer's IPv6 traffic, so it will have to carry prefixes used for the services provided by the content or Internet service providers.

Access

At the access layer, it is important to note that the same virtual links (VLANs for FTTH and PVCs for ADSL) used to provide IPv4 address are used to provide IPv6 access, too. For IPv4 the access router merely bridges the customer initiated PPPoE sessions into an L2TP tunnel, although for IPv6, the access router represents the layer 3 gateway for the customer. Implementing this hybrid access model is straight forward on the FTTH interfaces. On the ATM interfaces, the access router has to know to bridge the IPv4 traffic and to route the IPv6. The IPv6 RBE feature will be used for this purpose.

RTPCom is in this case responsible for provisioning the customer and it decided to use the following two mechanisms:

  • For single-network customers, provide a /64 prefix through Router Advertisements. The user is instructed to obtain the other provisioning parameters via stateless DHCP (resources being provided by RTPCom). The stateful DHCPv6 option was not selected because it is not implemented in most host stacks.

  • Customers that manage multiple networks on their site through a CPE router are provided a /56 prefix via DHCP-PD based on the DUID of their CPE router (see Chapter 3). On the link between the access router and the CPE, no prefix is assigned.

Note

RTPCom considered a PPP-based solution at the access layer where PPPoE sessions initiated by the customer would be terminated by the access router and the traffic IP switched through the rest of the network. The advantage of this approach is that it allows RTPCom to leverage PPP for authenticating and authorizing the customer with the help of a RADIUS server. This would simplify provisioning by centralizing it in the RADIUS server. RTPCom decided, however, to keep the deployment simple and avoid the additional encapsulation even if that might imply more involved provisioning.


Router NY-10-12-16 in Figure 14-9 provides ADSL access and has the relevant configuration shown in Example 14-1.

Example 14-1. ADSL Access Router Configuration

hostname NY-10-12-16
!
ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool DHCP-Customers
 prefix-delegation 2600:A02A:30F0:6400::/56 00030001000BBFAA7400
 dns-server 2600:A002::1/64
 domain-name RTPCom.com
!
interface ATM1/0
 no ip address
 load-interval 30
 atm pvp 0 70000
 atm pvp 1 70000
 no atm ilmi-keepalive
!
interface ATM1/0.10 point-to-point
 atm route-bridged ipv6
pvc 0/42
  encapsulation aal5snap
  protocol pppoe
 !
 ipv6 address 2600:A02A:30F0:A01::1/64
 ipv6 enable
 ipv6 nd other-config-flag
!
interface ATM1/0.100 point-to-point
 atm route-bridged ipv6
 pvc 0/132
  encapsulation aal5snap
 !
 ipv6 dhcp server DHCP-Customers
 ipv6 enable
 ipv6 nd other-config-flag
!

Note

The DUID of subscriber 100 CPE is 00030001000BBFAA7400 and 2600:A002::1/64 is the address of the DNS server in the New York L1 POP.


No routing protocol is running between the access router and the CPE while OSPFv3 is running between the L3 POP routers. The following three points have to be considered:

  • For the single-network customers, the assigned /64 prefix is directly connected, so directly connected prefixes have to be redistributed.

  • For the multiple-network customers, a static route is installed by the access router for each /56 prefix assigned. These static routes have to be redistributed into OSPFv3.

  • Summarize prefixes up to the range assigned for this L3 POP router (2600:A02A:30F0::/44) to minimize the size of the routing tables.

The relevant configuration that meets these constraints is shown in Example 14-2.

Example 14-2. Access Router OSPFv3 Configuration

interface GigabitEthernet6/1
 no ip address
 ipv6 address 2600:A002:A0C0:F001::2/64
 ipv6 enable
 ipv6 ospf 100 area 10
!
interface GigabitEthernet6/2
 no ip address
 ipv6 address 2600:A002:A0C0:F002::2/64
 ipv6 enable
 ipv6 ospf 100 area 10
!
ipv6 router ospf 100
 router-id 2.10.12.16
 log-adjacency-changes
 summary-prefix 2600:A02A:30F0::/44
 redistribute connected
 redistribute static

Interfaces GigabitEthernet6/1 and 6/2 link the access router NY-10-12-16 to the routers that connect this L3 POP to its L2 upstream POP.

Edge and Core

The L2 POPs aggregate the L3 POPs and they do not run any specific features other than OSPFv3 and iBGP. One of the two L2 POP routers that interface with the New York L1 POP is named NY-10-0-1; the other is NY-10-0-2. The relevant routing points in this case are as follows:

  • Routers NY-10-0-1 and NY-10-0-2 should be set with higher priority to be elected DR and BDR in that respective order.

  • The OSPFv3 prefixes should be redistributed into iBGP.

  • The iBGP prefixes should be redistributed into OSPFv3.

  • A loop avoidance mechanism should be implemented for the redistribution between OSPFv3 and iBGP because of the redundancy in the design.

  • OSPFv3 should summarize the prefixes to the L2 POP boundary (2600:A02A::/32).

Router NY-10-0-1's IPv6 relevant configuration is shown in Example 14-3.

Example 14-3. L2 POP Router NY-10-0-1 Configuration

hostname NY-10-0-1
!
ipv6 unicast-routing
ipv6 cef
!
interface SRP1/1
 no ip directed-broadcast
 ipv6 address 2600:A002:A000:1::1/64
 ipv6 enable
 ipv6 ospf priority 3
 ipv6 ospf 100 area 0
 srp clock-source line a
 srp clock-source line b
 no clns route-cache
!
interface TenGigabitEthernet9/1
 no ip address
 ipv6 address 2600:A002:A000:1100::2/64
 ipv6 enable
!
interface TenGigabitEthernet9/2
 no ip address
 ipv6 address 2600:A002:A000:1200::2/64
 ipv6 enable
!
router bgp 1600
 bgp router-id 2.10.0.1
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2600:A002:A000:1100::1 remote-as 1600
 neighbor 2600:A002:A000:1100::1 update-source TenGigabitEthernet9/1
 neighbor 2600:A002:A000:1200::1 remote-as 1600
 neighbor 2600:A002:A000:1200::1 update-source TenGigabitEthernet9/2
 !
 address-family ipv6
 neighbor 2600:A002:A000:1100::1 activate
 neighbor 2600:A002:A000:1200::1 activate
 no synchronization
 redistribute ospf 100 match external 2 route-map OSPF-to-BGP
 exit-address-family
!
ipv6 router ospf 100
 router-id 2.10.0.1
 log-adjacency-changes
 summary-prefix 2600:A02A::/32
 redistribute bgp 1600 tag 1600
!
!
route-map OSPF-to-BGP deny 10
 match tag 100
!
route-map OSPF-to-BGP permit 20
!

The TenGigabitEthernet9/1 and 9/2 interfaces provide the uplink to L1 POP, while the SRP1/1 interface provides the link to the rest of the routers in its L2 POP.

IPv6 prefixes redistributed from iBGP into OSPFv3 are marked with tag 100. When NY-10-0-1 is redistributing the external type 2 prefixes from OSPFv3 into iBGP, the prefixes with tag 100 are dropped. This avoids the loop created by the redistribution between the two routing protocols.

It is interesting to observe that even though NY-10-0-1 already peers with the L1 POP routers over IPv4, RTPCom decided to enable separate peering over IPv6. Another option would have been to simply add the IPv6 address family to the BGP processes and activate the IPv4 neighbors. Despite its apparent redundancy, RTPCom opted for the approach described in Example 14-3 for two reasons:

  • Limit the impact of one protocol on the other. Terminating the IPv4 peer TCP session will not affect IPv6. Bringing it up would not lead to possible contention between the two protocols.

  • Allow for the possibility that the IPv4 and IPv6 topologies are not congruent.

RTPCom assumes a certain level of risk because it uses the same routers as IPv4 and IPv6 route reflectors (RRs). The risk is further enhanced because in this design, the RRs are in the forwarding path (a risk assumed for IPv4, as well). Based on its operational experience with the current infrastructure, RTPCom is comfortable with this design. It is also studying the option of deploying dedicated RRs in each L1 POP. Considering the redundancy in the RR design, a migration to this alternate design would not imply a downtime for RTPCom's network.

The L1 routers are running OSPFv3 in area 0 for IGP. At the same time, the L1 routers that provide access to the core for the L1 POP data centers and for the L2 POPs are all part of the iBGP infrastructure shown in Figure 14-10.

Figure 14-10. RTPCom Backbone iBGP Design


The L1 routers providing access for the L1 POP data centers and for the L2 POPs are also acting as route reflectors for the IPv6 service. They in turn peer with the two pairs of second-level Top-RRs in L1-Denver and L1-Atlanta. This hierarchical RR design provides scalability for RTPCom's network core. The prefixes in the core of the network that are handled by OSPFv3 are redistributed into BGP but not the other way around. Under this design, the relevant configuration elements for NY-0-0-1 are shown in Example 14-4.

Example 14-4. IPv6 Routing Configuration of NY-0-0-1

interface TenGigabitEthernet9/1
 no ip address
 ipv6 address 2600:A002:A000:1100::1/64
 ipv6 enable
!
interface TenGigabitEthernet9/2
 no ip address
 ipv6 address 2600:A002:A000:1200::1/64
 ipv6 enable
!
router bgp 1600
 bgp router-id 2.10.0.1
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2600:A002:A000:1100::2  remote-as 1600
 neighbor 2600:A002:A000:1100::2 update-source TenGigabitEthernet9/1
 neighbor 2600:A002:A000:1200::2 remote-as 1600
 neighbor 2600:A002:A000:1200::2 update-source TenGigabitEthernet9/2
 neighbor 2600:A001:0:F000::2 remote-as 1600
 neighbor 2600:A001:0:F000::2 update-source Loopback0
 neighbor 2600:A00A:0:F000::2 remote-as 1600
 neighbor 2600:A00A:0:F000::2 update-source Loopback0
 !
 address-family ipv6
 neighbor 2600:A002:A000:1100::2 activate
 neighbor 2600:A002:A000:1100::2 route-reflector-client
 neighbor 2600:A002:A000:1200::2 activate
 neighbor 2600:A002:A000:1200::2 route-reflector-client
 neighbor 2600:A001:0:F000::2 activate
 neighbor 2600:A00A:0:F000::2 activate
 no synchronization
 redistribute ospf 100 match external 2
 exit-address-family
!

The address of the Top-RRs are 2600:A001:0:F000::2 (Atlanta) 2600:A00A:0:F000::2 (Denver).

The Top-RRs shown in Figure 14-10 are dedicated to the IPv6 deployment and were installed in L1-Denver and L1-Atlanta POPs in addition to the existent IPv4 RRs. RTPCom considers the investment in the additional equipment worthwhile for the benefit of further minimizing the interaction between the IPv4 and IPv6 services.

With the above configuration in place, RTPCom established unicast connectivity between its customers and some services, such as DNS and content hosting/storage, which can already operate. On the other hand, considering the new architecture used for IPv6, RTPCom has the responsibility to control user access based on its subscription. With the basic IPv6 unicast service, the user can reach other RTPCom customers but should not have access to the Internet. To enforce this policy, RTPCom applies an IPv6 filter on the subscriber line at the access layer, as shown in Example 14-5.

Example 14-5. User Access Control Configuration

interface ATM1/0.10 point-to-point
 atm route-bridged ipv6
 pvc 0/42
  encapsulation aal5snap
  protocol pppoe
 !
 ipv6 address 2600:A02A:30F0:A01::1/64
 ipv6 enable
 ipv6 traffic-filter Basic-Access in
 ipv6 nd other-config-flag
!
ipv6 access-list Basic-Access
 deny ipv6 any 2600:A000::/28
 deny ipv6 any 2600:A080::/28
 permit ipv6 any 2600:A000:/24

Access list Basic-Access blocks access to the infrastructure address space (2600:A000::/28 and 2600:A080::/28), and allows access to the other RTPCom customers but not beyond that. This filter is modified based on the services paid for by the user.

Service Rollout Plan

To safeguard the stability of its network, RTPCom intends to enable it for IPv6 unicast connectivity in phases. In the first phase, it will enable IPv6 in the backbone. In the subsequent phases, it will move toward the access layer based on customer demands. RTPCom's deployment will precede demand in the major metropolitan areas where the service will be aggressively advertised. The service rollout steps are summarized in Table 14-7.

Table 14-7. Unicast Connectivity Service Rollout Checklist
 

RTPCom Task

Customer Task

1

Enable IPv6 throughout the backbone and the L1 POPs:

Install the IPv6 dedicated TOP-RRs in L1-Denver and L1-Atlanta.

Configure links for dual stack.

Enable OSPFv3.

Configure the iBGP peering between the L1 POP routers and the TOP-RRs.

 

2

Enable IPv6 in the L2 POPs in the major metropolitan areas:

Configure links for dual stack.

Enable OSPFv3.

Configure the iBGP peering between the L1 POP routers and the L2 POP routers.

Enable IPv6 in the access layer of the L2 POPs in the major metropolitan areas:

Configure links for dual stack.

Enable OSPFv3.

Configure the Basic-Access ACL on the access routers.

Configure the DNS relevant information.

 
  

Customer requests basic-access service.

3

Provision the customer access link:

Enable the virtual circuit for IPv6.

For a /64 service configure the IPv6 prefix assigned.

For a /56 service request the customer DUID, configure the pool entry and enable DHCP-PD on the virtual circuit (PVC or VLAN).

Configure the service control ACL Basic-Access.

The customer is provided with the prefixes that will be assigned to him. If a CPE is used, configure it as a DHCPPD client. This might be the responsibility of RTPCom if it manages the CPE.


Steps 2 and 3 can be repeated for other L2 and L3 POPs based on customer demand for service. By the time the customer is provided access, the DNS and content resources are already installed in the data centers.

DNS and Content Hosting/Storage

The DNS and content hosting/storage resources are installed in the data center of the L1 POPs. The unicast service enables the IPv6 customers to reach these resources and take advantage of these two services. The DNS server addresses are provided to users via DHCP. The addresses for the content hosting/storage servers are available on RTPCom's service web pages where subscribers are provided with all the information necessary to use these services.

Internet Access

To provide its customer with Internet access service, RTPCom partnered with USInternet, an ISP similar to EuropCom described in Chapter 13. USInternet will provide IPv6 Internet access in addition to its existent IPv4 Internet access offering. It also packages e-mail services together with the Internet access subscription.

Like the other ISPs that provide IPv4 Internet access services to RTPCom's customers, USInternet has two routers collocated with RTPCom's edge routers in the data centers of the L1 POPs. These two routers aggregate the LNS routers that are dedicated to USInternet. Open Shortest Path First (OSPF) is used for routing purposes between the LNS, RTPCom edge and ISP edge routers. An interior gateway protocol (IGP) is seen as a simpler solution than the use of eBGP mainly because RTPCom does not need to use its global addresses and its autonomous system for the service. RTPCom can be viewed as merely a virtual access layer for the ISPs it partners with.

In the IPv6 service design, RTPCom plays a more involved role. It now routes the customer traffic throughout its network, it is responsible for providing addresses to customers and have them globally routed under its own autonomous system number. In this case, the use of just and IGP is not feasible. For this reason USInternet peers with the RTPCom at its L1 POPs through eBGP and the following constraints shape the configuration of NY-D-0-3:

  • RTPCom's autonomous system number is 1600.

  • It peers with USInternet and also with the routers that provide the data center with access to the core.

  • Dampening is used to minimize external impact on RTPCom's network.

  • The infrastructure prefixes are not advertised outside RTPCom's network.

The implementation of these constraints is shown in the configuration Example 14-6.

Example 14-6. IPv6 eBGP Configuration of Router NY-D-0-3

router bgp 1600
 bgp router-id 2.0.255.1
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2600:A002:D0:1100::1 remote-as 1600
 neighbor 2600:A002:D0:1100::1 update-source TenGigabitEthernet1/1
 neighbor 2600:A002:D0:2100::1 remote-as 1600
 neighbor 2600:A002:D0:2100::1 update-source TenGigabitEthernet1/2
 neighbor FE80::200:FF:FE01:F remote-as 500
 neighbor FE80::200:FF:FE01:F update-source GigabitEthernet2/1
 !
 address-family ipv6
 neighbor 2600:A002:D0:1100::1 activate
 neighbor 2600:A002:D0:2100::1 activate
 neighbor FE80::200:FF:FE01:F activate
 neighbor FE80::200:FF:FE01:F route-map Block-Infra out
 bgp dampening 15 750 3000 60
 no synchronization
 exit-address-family
!
ipv6 prefix-list Infra seq 5 permit 2600:A000::/28
ipv6 prefix-list Infra seq 10 permit 2600:A080::/28
!
route-map Block-Infra deny 10
 match ipv6 address prefix-list Infra
!
route-map Block-Infra permit 20
!

The addresses of the data center RRs are 2600:A002:D0:1100::1 and 2600:A002: D0:2100::1. USInternet's autonomous system number is 500. The eBGP peering is done through the link-local addresses on the link between RTPCom and the USInternet. Route map Block-Infra is used to stop the infrastructure prefixes 2600:A000::/28 and 2600:A080::/28 from being advertised outside RTPCom's network.

Note

The configuration shows the fact that the eBGP peering is done through link-local addresses. Chapter 2, "An IPv6 Refresher," describes the benefits of using this option. The important thing is to have a set of rules that make the link-local addresses of the peer deterministic. The details of how the link-local addresses are being assigned will not be discussed here because they were presented in a similar example in Chapter 13.


These changes made on the ISP-facing routers open RTPCom's network to the wider IPv6 Internet. All of its customers could in principle access the Internet once they have IPv6 access to the RTPCom network. However, the service is controlled with the help of access lists. When a user decides to add Internet access to his service subscription, the access list applied to its access line is changed from Basic-Access to Internet-Access:

ipv6 access-list Internet-Access
 deny ipv6 any 2600:A000::/28
 deny ipv6 any 2600:A080::/28
 permit ipv6 any any

In the first phase of the IPv6 deployment, the services offered are contained within RTPCom's network or within a data center on USInternet's premises (e-mail services, for example). This way the services are easier to manage, and the corresponding business model is not complex. The Internet access service is turned on in a subsequent phase of the deployment when interest for it becomes relevant.

The Internet access service rollout steps are summarized in Table 14-8. Basic connectivity is assumed to add Internet access.

Table 14-8. Internet Access Service Rollout Checklist
 

RTPCom Task

Customer Task

1

Enable connectivity to the ISP:

Configure the IPv6 eBGP peering to the ISP in the L1 POP data centers.

Configure the Internet-Access ACL on the access routers.

 
  

Customer requests Internet access service.

2

Provision the customer access link:

Provide basic connectivity if not available.

Replace the service control ACL Basic-Access with the Internet-Access one.

 



Previous Page
Next Page