SprintLink IPv6
Services; Overview
Prepared by Rob
Rockell,
Updated by Ken
Rodgers,
Since 1997, Sprint has been actively involved in the
standardization, testing, and deployment of IPv6 (Internet Protocol version 6;
the planned replacement for the current IPv4, which the Internet uses today for
addressing and routing). Sprint was an
early adopter of IPv6 in an experimental capacity, and not only keeps an active
test-bed for IPv6, but is involved in the evolution and standardization of the IPv6
protocol. The 6bone was an IPv6 testbed
to assist in the evolution and deployment of IPv6. RFC2772,
which was written by Sprint, gives the common rules governing the route policy
guidelines for IPv6 on the 6Bone. The
6bone was phased out on
IPv6 is similar to IPv4, in that it is a connectionless routed protocol. Rather than the 32-bit IP address that people are familiar with today (1.2.3.4 for example) IPv6 uses 128-bit addressing. These addresses are written in Hexidecimal notation, to simplify the length of the address (HEX: symbolize 4 bits in one digit, 0-9, and A-F, where A=10, and F=15, so 0001 in hex is 1, 1111 in binary equals F in hex). While the increased address space alone is enough to make it an attractive protocol for deployment (IP addresses are believed to be depleting at an alarming rate; it is unclear exactly where we will run out, but aggressive estimates can be as little as 5 years from now), so Sprint is making sure to be ready and able to deploy this protocol as needed.
In addition to solving the address-depletion problem, IPv6 also tries to solve some past IPv4 problems in the process. It has a mechanism for aggregation of prefixes on the Internet core, so that routing table size scales (thus routing decision can be made quickly as the Internet grows), it has built in QoS capabilities (which exist in IPv4, but were never uniformly adopted for use in vendor implementations) as well as means for faster packet processing through the use of a "next-header" methodology. In this methodology, a base IPv6 header will convey forwarding information, such as source address, destination address, protocol type inside the payload, etc., but if this packet has a special forwarding or queuing needs, a subsequent header can be used to show a router or end-host to treat the packet. If there is no next-header, then the router or end-system does not need to waste resources in processing these useless bits; the source simply does not include a next-header.
There are numerous RFC's (standards documents) and Internet drafts (proposed standards documents) on file with the IETF, should the reader or the customer require more information on IPv6 and its specifications. Please see www.ietf.org, and the working groups IPv6 Operations (v6ops), and MULTI6 for more details.

The router names and IP addresses are:
|
Router Name |
Address |
|
sl-bb1v6-sea |
144.228.240.145 |
|
sl-bb1v6-sj |
144.228.240.165 |
|
sl-bb1v6-fw |
144.228.240.105 |
|
sl-bb1v6-nyc |
144.228.240.213 |
|
sl-s1v6-nyc |
144.232.70.5 |
|
sl-bb1v6-rly |
208.19.223.30 |
|
sl-bb1v6-bru |
80.66.128.3 |
Sprint’s Routing Policy
Route maps along with access-lists and prefix filters are used on a per neighbor basis to enforce Sprint’s routing policy. Route maps can be applied inbound or outbound. They filter updates and modify various route attributes. IPv6 customers using Sprint’s AS 6175 will use rout maps as follows:
· Configured inbound on customer BGP sessions. Prevents private IP space, private AS space, and peer routes from entering Sprints network.
· Configured outbound on customer BGP sessions. Prevents private IP space, private AS space, and peer routes from being advertised out to customers network.
· Customers can manipulate the local preference attribute to make their routes more or less preferred. The higher local preferences are preferred.
· Sprint accepts MEDs from all customers to adjust route preference on the network.
Sprint’s IPv6 team communicated to customers the need to
renumber their existing tunnels from 6bone block to the new sprint’s block if
they intend to continue use of IPv6 service through sprint. Sprint's 6bone
space (3ffe:2900::/24) has been removed from the
routing table in compliance with RFC 3701 http://www.ietf.org/rfc/rfc3701.txt.
If you are a current customer and are connected using one of these addresses,
please contact ipv6-support@sprint.net to renumber. If you do not have an IPv6 address block
allocated from your RIR, Sprint can delegate you a block. However, be advised
that these blocks are non-portable and we reserve the right to request
you return the block to Sprint at any time. If you need a block, please provide
justification.
GRE tunneling is used between IPv6 routers over the SprintLink (IPv4)
infrastructure. Sprint uses an iBGP full-mesh between IPv6 routers in AS6175. IPv6 routers are stand-alone boxes. There are no dynamic protocol-level
interactions with the IPv4 network (SprintLink; AS1239).
Sprint peers with numerous other IPv6 players, and has one
of the most well-connected IPv6 networks on the planet today (Graphical BGP+ tree). We peer
via BGP4+ through a combination of IPv6-over-IPv4 tunneling and through the
following two Native IPv6 exchanges. Currently, Sprint is at The Stokab in
DNS Services for
IPv6
In addition to connectivity and IPv6 address space (non-portable), Sprintv6.net also provides DNS, forward and reverse services, free of charge for IPv6. When we delegate a prefix to a customer, we will request that the customer give us the hostname of their IPv6 DNS server, and we will delegate that zone down to them. (Note: If a customer uses Sprint's service for their current DNS, this is TOTALLY separate, and on different hardware than the normal Sprint DNS service. This service description applies only to Sprint's IPv6 deployment). Root servers for IPv6 currently can be found at: http://www.root-servers.org/
Our IPv6 services LANs are currently built as follows:

Please note: Some of all of these services may not have an IPv4 address associated. In some cases, some or all of these services may only be reachable via IPv6, and not via IPv4. These services are not associated in any way with Sprint's IPv4 hosting or DNS services, and are completely separate.
If a customer is interested in connecting to Sprint's IPv6 network, please have them contact ipv6-support@sprint.net. The sales team may contact by proxy; but direct customer contact is preferred. We will require the following information to set up the IPv6 connection:
1. Which router in our IPv6 network has the best IPv4 connectivity to your network?
2. What is the IPv4 source address of the tunnel connection?
3. Do you prefer IPv6IP or GRE encapsulation on your tunnel?
4. Will you be doing static routing or BGP?
5. If static, what block(s) do we need to route to you?
6. If BGP, What is your ASN?
7. What blocks will you announce to us? (if it’s a lot, tell us how many, instead)
8. Do you want transit or non-transit service?
9. A contact e-mail address for the administrator(s) of this IPv6 connection.
10. The type of IPv6 machine that is terminating the tunnel (for our own records, to know what vendors customers are using, so we can tailor our configurations to their needs).
11. The hostname of the customer's DNS server that they wish their reverse zone delegated down to.
Sprint is currently working on its product offering to include a native dual-stack support for Dedicated IP Access, planned to debut in early 2008.