bgp

BGP Overview

BGP is an external gateway protocol, meant to be used between different networks. It is the protocol used between Internet service providers (ISPs) and also can be used between an Enterprise and an ISP. BGP was built for reliability, scalability, and control, not speed. Because of this, it behaves differently from the protocols covered so far in this book:

• BGP stands for Border Gateway Protocol. Routers running BGP are termed BGP speakers.
• BGP uses the concept of autonomous systems (AS). An autonomous system is a group of networks under a common administration. The Internet Assigned Numbers Authority (IANA) assigns AS numbers: 1 to 64511 are public AS numbers and 64512 to 65535 are private AS numbers.
• Autonomous systems run Interior Gateway Protocols (IGP) within the system. They run an Exterior Gateway Protocol (EGP) between them. BGP version 4 is the only EGP currently in use.
• Routing between autonomous systems is called interdomain routing.
• The administrative distance for EBGP routes is 20. The administrative distance for IBGP routes is 200.
• BGP neighbors are called peers and must be statically configured.
• BGP uses TCP port 179. BGP peers exchange incremental, triggered route updates and periodic keepalives.
• Routers can run only one instance of BGP at a time.
• BGP is a path-vector protocol. Its route to a network consists of a list of autonomous systems on the path to that network.
• BGP's loop prevention mechanism is an autonomous system number. When an update about a network leaves an autonomous system, that autonomous system's number is prepended to the list of autonomous systems that have handled that update. When an autonomous system receives an update, it examines the autonomous system list. If it finds its own autonomous system number in that list, the update is discarded.

In Figure 6-1, BGP routers in AS 65100 see network 10.1.1.0 as having an autonomous system path of 65200 65300 65400.

Figure 6-1 BGP AS-Path Advertisement

Use BGP when the AS is multihomed, when route path manipulation is needed, or when the AS is a transit AS. (Traffic flows through it to another AS, such as with an ISP.)
Do not use BGP in a single-homed AS, with a router that does not have sufficient resources to handle it, or with a staff that does not have a good understanding of BGP path selection and manipulation.

BGP Databases

BGP uses three databases. The first two listed are BGP-specific; the third is shared by all routing processes on the router:

• Neighbor database: A list of all configured BGP neighbors. To view it, use the show ip bgp summary command.
• BGP database, or RIB (Routing Information Base): A list of networks known by BGP, along with their paths and attributes. To view it, use the show ip bgp command.
• Routing table: A list of the paths to each network used by the router, and the next hop for each network. To view it, use the show ip route command.

BGP Message Types

BGP has four types of messages:

• Open: After a neighbor is configured, BGP sends an open message to try to establish peering with that neighbor. Includes information such as autonomous system number, router ID, and hold time.
• Update: Message used to transfer routing information between peers. Includes new routes, withdrawn routes, and path attributes.
• Keepalive: BGP peers exchange keepalive messages every 60 seconds by default. These keep the peering session active.
• Notification: When a problem occurs that causes a router to end the BGP peering session, a notification message is sent to the BGP neighbor and the connection is closed.

Internal and External BGP

Internal BGP (IBGP) is a BGP peering relationship between routers in the same autonomous system. External BGP (EBGP) is a BGP peering relationship between routers in different autonomous systems. BGP treats updates from internal peers differently than updates from external peers.
Before any BGP speaker can peer with a neighbor router, that neighbor must be statically defined. A TCP session must be established, so the IP address used to peer with must be reachable.
In Figure 6-2, Routers A and B are EBGP peers. Routers B, C, and D are IBGP peers.

Figure 6-2 Identifying EBGP and IBGP Peers

BGP Next-Hop Selection

The next hop for a route received from an EBGP neighbor is the IP address of the neighbor that sent the update.
When a BGP router receives an update from an EBGP neighbor, it must pass that update to its IBGP neighbors without changing the next-hop attribute. The next-hop IP address is the IP address of an edge router belonging to the next-hop autonomous system. Therefore, IBGP routers must have a route to the network connecting their autonomous system to that edge router. For example, in Figure 6-3, RtrA sends an update to RtrB, listing a next hop of 10.2.2.1, its serial interface. When RtrB forwards that update to RtrC, the next-hop IP address will still be 10.2.2.1. RtrC needs to have a route to the 10.2.2.0 network to have a valid next hop.

Figure 6-3 BGP Next-Hop Behavior

To change this behavior, use the neighbor [ip address] next-hop-self command in BGP configuration mode. In Figure 6-3, this configuration goes on RtrB. After you give this command, RtrB advertises its IP address to RtrC as the next hop for networks from AS 65100, rather than the address of RtrA. Thus, RtrC does not have to know about the external network between RtrA and RtrB (network 10.2.2.0).

BGP Next Hop on a Multiaccess Network

On a multiaccess network, BGP can adjust the next-hop attribute to avoid an extra hop. In Figure 6-3, RtrC and RtrD are EBGP peers, and RtrC is an IBGP peer with RtrB. When C sends an update to D about network 10.2.2.0, it normally gives its interface IP address as the next hop for D to use. But because B, C, and D are all on the same multiaccess network, it is inefficient for D to send traffic to C, and C to then send it on to B. This process unnecessarily adds an extra hop to the path. So, by default, RtrC advertises a next hop of 10.3.3.3 (RtrB's interface) for the 10.2.2.0 network. This behavior can also be adjusted with the neighbor [ip address] next-hop-self command.

BGP Synchronization Rule

The BGP synchronization rule requires that when a BGP router receives information about a network from an IBGP neighbor, it does not use that information until a matching route is learned via an IGP or static route. It also does not advertise that route to an EBGP neighbor unless a matching route is in the routing table. In Figure 6-3, if RtrB advertises a route to RtrC, then RtrC does not submit it to the routing table or advertise it to RtrD unless it also learns the route from some other IGP source.
Recent IOS versions have synchronization disabled by default. It is usually safe to turn off synchronization when all routers in the autonomous system run BGP. To turn it off in earlier IOS versions, use the command no synchronization under BGP router configuration mode.

Configuring BGP

Before beginning to configure BGP, gather the network requirements you need, which should include the following:

• Whether you need to run IBGP for internal connectivity
• External connectivity to the ISP
• Configuration parameters such as neighbor IP addresses and their AS number, and which networks you will advertise via BGP

Table 6-1 lists the basic BGP configuration commands and their functions.

Table 6-1. Basic BGP Configuration Commands

Command	Description
router bgp AS-number	Starts the BGP routing process on the router.
neighbor ip-address remote-as AS-number	Sets up peering between BGP routers. IP address must match the source of routing updates.
neighbor peer - group-name peer-group	Creates a peer group to which you can then assign neighbors.
neighbor ip-address peer-group peer-group-name	Assigns a neighbor to a peer group.
neighbor ip-address next-hop-self	Configures a router to advertise its connected interface as the next hop for all routes to this neighbor.
neighbor ip-address update-source interface-type number	Configures a router to use the IP address of a specific interface as the source for its advertisements to this neighbor.
no synchronization	Turns off BGP synchronization.
network prefix [ mask subnet-mask ]	Initiates the advertisement of a network in BGP.

BGP Network Command

In most IGPs, the network command starts the routing process on an interface. In BGP, the command tells the router to originate an advertisement for that network. The network does not have to be connected to the router; it just has to be in the routing table. In theory, it can even be a network in a different autonomous system (not usually recommended).
When advertising a network, BGP assumes you are using the default classful subnet mask. If you want to advertise a subnet, you must use the optional keyword mask and specify the subnet mask to use. Note that this is a subnet mask, not the inverse mask used by OSPF and EIGRP network statements. The routing table must contain an exact match (prefix and subnet mask) to the network listed in the network statement before BGP advertises the route.

BGP Peering

BGP assumes that external neighbors are directly connected and that they are peering with the IP address of the directly connected interface of their neighbor. If not, you must tell BGP to look more than one hop away for its neighbor, with the neighbor ip-address ebgp-multihop number-of-hops command. You might use this command if you are peering with loopback interface IP addresses, for instance. BGP assumes that internal neighbors might not be directly connected, so this command is not needed with IBGP. If you do peer with loopback IP addresses, you must change the source of the BGP packets to match the loopback address with the neighbor ip-address update-source interface command.
To take down the peering session with a neighbor but keep the neighbor configuration, use the neighbor ip-address shutdown command.

BGP Peering States

The command show ip bgp neighbors shows a list of peers and the status of their peering session. This status can include the following states:

• Idle: No peering; router is looking for neighbor. Idle (admin) means that the neighbor relationship has been administratively shut down.
• Connect: TCP handshake completed.
• OpenSent, or Active: An open message was sent to try to establish the peering.
• OpenConfirm: Router has received a reply to the open message.
• Established: Routers have a BGP peering session. This is the desired state.

You can troubleshoot session establishment with debug commands. Use debug ip bgp events or debug ip bgp ipv4 unicast (in IOS versions 12.4 and up) to see where the process fails. Some common failure causes include AS number misconfiguration, neighbor IP address misconfiguration, a neighbor with no neighbor statement for your router, and a neighbor with no route to the source address of your router's BGP messages.

BGP Path Selection

IGPs, such as EIGRP or OSPF, choose routes based on lowest metric. They attempt to find the shortest, fastest way to get traffic to its destination. BGP, however, has a different way of route selection. It assigns various attributes to each path; these attributes can be administratively manipulated to control the path that is selected. It then examines the value of these attributes in an ordered fashion until it can narrow all the possible routes down to one path.

BGP Attributes

BGP chooses a route to a network based on the attributes of its path. Four categories of attributes exist as follows:

• Well-known mandatory: Must be recognized by all BGP routers, present in all BGP updates, and passed on to other BGP routers. For example, AS path, origin, and next hop.
• Well-known discretionary: Must be recognized by all BGP routers and passed on to other BGP routers but need not be present in an update, for example, local preference.
• Optional transitive: Might or might not be recognized by a BGP router but is passed on to other BGP routers. If not recognized, it is marked as partial, for example, aggregator, community.
• Optional nontransitive: Might or might not be recognized by a BGP router and is not passed on to other routers, for example, Multi-Exit Discriminator (MED), originator ID.

Table 6-2 lists common BGP attributes, their meanings, and their category.

Table 6-2. BGP Attributes

Attribute	Meaning
AS path	An ordered list of all the autonomous systems through which this update has passed. Well-known, mandatory.
Origin	How BGP learned of this network. i = by network command, e = from EGP, ? = redistributed from other source. Well-known, mandatory.
Local Preference	A value telling IBGP peers which path to select for traffic leaving the AS. Default value is 100. Well-known, discretionary.
Multi-Exit Discriminator (MED)	Suggests to a neighboring autonomous system which of multiple paths to select for traffic bound into your autonomous system. Lowest MED is preferred. Optional, non-transitive.
Weight	Cisco proprietary, to tell a router which of multiple local paths to select for traffic leaving the AS. Highest weight is preferred. Only has local significance.

BGP Path Selection Criteria

BGP tries to narrow its path selection down to one best path; it does not load balance by default. To do so, it examines the path attributes of any loop-free, synchronized (if synchronization is enabled) routes with a reachable next-hop in the following order:

1. Choose the route with the highest weight.
2. If weight is not set, choose the route with the highest local preference.
3. Choose routes that this router originated.
4. Choose the path with the shortest Autonomous System path.
5. Choose the path with the lowest origin code (i is lowest, e is next, ? is last).
6. Choose the route with the lowest MED, if the same Autonomous System advertises the possible routes.
7. Choose an EBGP route over an IBGP route.
8. Choose the route through the nearest IGP neighbor as determined by the lowest IGP metric.
9. Choose the oldest route
10. Choose a path through the neighbor with the lowest router ID.
11. Choose a path through the neighbor with the lowest IP address.

To enable BGP to load balance over more than one path, you must enter the command maximum-paths number-of-paths. BGP can load balance over a maximum of six paths.

Influencing BGP Path Selection

BGP was not created to be a fast protocol; it was created to enable as much administrative control over route path selection as possible. Path selection is controlled by manipulating BGP attributes, usually using route maps. You can set a default local preference by using the command bgp default local-preference and a default MED for redistributed routes with the default-metric command under the BGP routing process. But by using route maps, you can change attributes for certain neighbors only or for certain routes only. The earlier section on route maps contains an example of using a route map to set a local preference of 200 for specific redistributed routes. This is higher than the default local preference of 120, so routers within the AS are more likely to prefer that path than others.
Route maps can also be applied to routes sent to or received from a neighbor. The following example shows a simple route map that sets a MED value and adds two more copies of its AS number to the AS path on all routes advertised out to an EBGP neighbor:

route-map MED permit 10
 set metric 50
 set as-path prepend 65001 65001
!
router bgp 65001
 neighbor 10.1.1.1 route-map MED out

When attributes are changed, you must tell BGP to apply the changes. Either clear the BGP session (clear ip bgp *) or do a soft reset (clear ip bgp * soft in | out). Routers using recent IOS versions do a route refresh when the session in cleared inbound.

Filtering BGP Routes

You can combine route maps with prefix lists to filter the routes advertised to or received from a BGP peer, to control routes redistributed into BGP, and to set BGP attributes for specific routes. Prefix lists alone can be applied to a neighbor to filter route updates.
To use a prefix list, plan the implementation by determining the requirements. Then create a prefix list to match the networks to be filtered. Permit the networks you want to allow to be advertised and deny all others. Next apply the prefix list to the BGP neighbor, inbound or outbound. The next example shows a prefix list that permits only summary routes in the 172.31.0.0 network. All other routes are denied by default. The prefix list is then applied to BGP neighbor 10.1.1.1 outbound, so only these routes will be advertised to that peer:

ip prefix-list Summary permit 172.31.0.0/16 le 20
!
router bgp 65001
neighbor 10.1.1.1 prefix-list Summary out

To verify the results of your configuration use the command show ip prefix-list. To clear the counters shown in that command, use the clear ip prefix-list command.
Combine a prefix list with a route map to set attributes on the routes allowed in the prefix list. In the following example, prefix list Summary is used again. A route map sets the Med for those routes to 100 when they are advertised. It sets a Med of 200 for all other routes advertised. The route map is then applied to BGP neighbor 10.1.1.1 outbound:

route-map CCNP permit 10
match ip address prefix-list Summary
set metric 100
route-map CCNP permit 20
set metric 200
!
router bgp 65001
neighbor 10.1.1.1 route-map CCNP out

BGP Authentication

BGP supports MD5 authentication between neighbors, using a shared password. It is configured under BGP router configuration mode with the command neighbor {ip-address | peer-group-name} password password. When authentication is configured, BGP authenticates every TCP segment from its peer and checks the source of each routing update. Most ISPs require authentication for their EBGP peers.
Peering succeeds only if both routers are configured for authentication and have the same password. If a router has a password configured for a neighbor, but the neighbor router does not, a message such as the following displays on the console while the routers attempt to establish a BGP session between them:

%TCP-6-BADAUTH: No MD5 digest from [peer's IP address]:11003 to
 [local router's IP address]:179

Similarly, if the two routers have different passwords configured, a message such as the following will display on the screen:

%TCP-6-BADAUTH: Invalid MD5 digest from [peer's IP
 address]:11004 to [local router's IP address]:179

Verifying BGP

One of the best commands to verify and troubleshoot your BGP configuration is show ip bgp to see the BGP topology database. This is such an important command that it's worth looking at in depth. The command output lists a table of all the networks BGP knows about, the next hop for each network, some of the attributes for each route, and the AS path for each route. The sample output from this command was taken from an actual Internet BGP peer.

route-server>show ip bgp
BGP table version is 22285573, local router ID is 12.0.1.28
Status codes: s suppressed, d damped, h history, * valid, > best, i
 - internal,
       r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network     Next Hop         Metric LocPrf Weight Path
* 3.0.0.0     12.123.137.124                  0     7018 2914 9304
 80 i
*>            12.123.1.236                    0     7018 2914 9304
 80 i
* 3.51.92.0/23 12.123.137.124                 0     7018 ?
*             12.122.125.4     2366           0     7018 ?
*>            12.123.1.236                    0     7018 ?
* 8.6.6.0/24  12.123.137.124                  0     7018 701 14744
 14744 14276 i
*             12.123.145.124                  0     7018 701 14744
 14744 14276 i
*>            12.123.1.236                    0     7018 701 14744
 14744 14276 i

Networks are listed in numerical order, smallest to largest. The first three columns list each route's status. An asterisk (*) in the first column means that the route has a valid next hop. Some other options for the first column include the following:

• "s" for suppressed: BGP knows about this network but is not advertising it, usually because it is part of a summarized route.
• "d" for dampened: BGP can stop advertising a network that flaps (goes up and down) too often until it is stable for a period of time.
• "h" for history: BGP knows about this network but does not currently have a valid route to it.
• "r" for RIB failure: The route was advertised to BGP but it was not installed in the IP routing table. This might be because of another protocol having the same route with a better administrative distance.
• "S" for stale: Used with nonstop forwarding to indicate that the route is stale and needs to be refreshed when the peer is reestablished.

The second column has a greater-than sign (>) beside the route that was selected as the best path to that network. In the example, the second route was selected for network 3.0.0.0.
The third column is blank in the example, which means that the router learned all the routes from an external neighbor. A route learned from an IBGP neighbor would have an "I" in the third column.
The fourth column lists the networks. Those without a subnet mask, such as network 3.0.0.0, use their classful mask. As seen in the example, when the router learns about the same network from multiple sources, it lists only the network once.
The fifth column lists the next-hop address for each route. As you learned in the previous sections on BGP next hops, this might or might not be a directly connected router. A next-hop of 0.0.0.0 means that the local router originated the route.
If a Med value was received with the route, it is listed in the Metric column. Notice that the advertisement for network 3.51.92.0/23 from the router at 12.122.125.4 has a large Med value of 2366. Because the default Local Preference is used for each of the routes shown, no local preference value is displayed. The default Weight value of 0 is listed, however.
The ninth column shows the AS path for each network. Reading this field from left to right, the first AS number shown is the adjacent AS this router learned the route from. After that, the AS paths that this route traversed are shown in order. The last AS number listed is the originating AS. In the example, our router received an advertisement about network 3.0.0.0 from its neighbor AS 7018, which heard about it from AS 2914, which heard about it from AS 9304. And AS 9304 learned the route from AS 80, which originated it. A blank AS path means that the route was originated in the local AS.

NOTE

In the AS Path column, note that network 8.6.6.0 shows AS 14744 twice in its AS path list. Most likely AS 14744 has prepended an extra copy of its AS number to make the path through it less attractive than the path through other autonomous systems. In this case it did not work because the only paths to 8.6.6.0 this router knows about all go through AS 14744.

The last column shows how BGP originally learned about the route. Networks 3.0.0.0 and 8.6.6.0 show an "i" for their origin codes. This means that the originating router had a network statement for that route. Network 3.51.92.0 shows a "?" as its origin. This means that the route was redistributed into BGP; BGP considers it an "incomplete" route. You will likely never see the third possibility, an "e," because that means BGP learned the route from the Exterior Gateway Protocol (EGP), which is no longer in use.
Some other useful commands for verifying and troubleshooting BGP include

• show ip bgp rib-failure: Displays routes that were not inserted into the IP routing table and the reason they were not used.
• show ip bgp summary: Displays the memory used by the various BGP databases, BGP activity statistics and a list of BGP neighbors.
• show ip bgp neighbors: Displays details about each neighbor. Can be modified by adding the neighbor IP address.
• show ip bgp neighbors address [received | routes | advertised]: Lets you monitor the routes received from and advertised to a particular neighbor.

You can search for "Internet route servers" to find listings of BGP routers that enable public telnet access for viewing their BGP tables. Trying some of these commands on a public route server can help you become familiar with them.

6to4 tunnel more

6to4 is an Internet transition mechanism for migrating from IPv4 to IPv6, a system that allows IPv6 packets to be transmitted over an IPv4 network (generally the IPv4 Internet) without the need to configure explicit tunnels. Special relay servers are also in place that allow 6to4 networks to communicate with native IPv6 networks.
6to4 is especially relevant during the initial phases of deployment to full, native IPv6 connectivity, since IPv6 is not required on nodes between the host and the destination. However, it is intended only as a transition mechanism and is not meant to be used permanently.
6to4 may be used by an individual host, or by a local IPv6 network. When used by a host, it must have a global IPv4 address connected, and the host is responsible for encapsulation of outgoing IPv6 packets and decapsulation of incoming 6to4 packets. If the host is configured to forward packets for other clients, often a local network, it is then a router.
Most IPv6 networks use autoconfiguration, which requires the last 64 bits for the host. The first 64 bits are the IPv6 prefix. The first 16 bits of the prefix are always 2002:, the next 32 bits are the IPv4 address, and the last 16 bits of the prefix are available for addressing multiple IPv6 subnets behind the same 6to4 router. Since the IPv6 hosts using autoconfiguration already have determined the unique 64 bit host portion of their address, they must simply wait for a Router Advertisement indicating the first 64 bits of prefix to have a complete IPv6 address. A 6to4 router will know to send an encapsulated packet directly over IPv4 if the first 16 bits are 2002, using the next 32 as the destination, or otherwise send the packet to a well-known relay server, which has access to native IPv6.
6to4 does not facilitate interoperation between IPv4-only hosts and IPv6-only hosts. 6to4 is simply a transparent mechanism used as a transport layer between IPv6 nodes.
Due to the high levels of misconfigured hosts and poor performance observed, an advisory about how 6to4 should be deployed was published in August 2011.^[1]

Contents

• 1 How 6to4 works
  • 1.1 Address block allocation
  • 1.2 Encapsulation and transmission
  • 1.3 Routing between 6to4 and native IPv6
• 2 Reverse DNS delegation
• 3 Security considerations
• 4 6to4 relays
• 5 About 6to4
• 6 How 6to4 Relay Routers Are Used (example)
• 7 Downsides of 6to4
  • 7.1 Websites and lists
  • 7.2 Other hosts
• 8 See also
• 9 References
• 10 External links

How 6to4 works

6to4

6to4 performs three functions:

• Assigns a block of IPv6 address space to any host or network that has a global IPv4 address.
• Encapsulates IPv6 packets inside IPv4 packets for transmission over an IPv4 network using 6in4.
• Routes traffic between 6to4 and "native" IPv6 networks.

Address block allocation

6to4 address

For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
For example the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
Any IPv6 address that begins with the 2002::/16 prefix (in other words, any address with the first two octets of 2002 hexadecimal) is known as a 6to4 address, as opposed to a native IPv6 address which does not use transition technologies.
Note that using a reserved IPv4 address, such as those provided by RFC 1918, is undefined, since these networks are disallowed from being routed on the public Internet. For example, using 192.168.1.1 as the router's WAN address would be invalid since a return packet would not be able to determine the destination IPv4 address of the actual sender.

Encapsulation and transmission

6to4 embeds an IPv6 packet in the payload portion of an IPv4 packet with protocol type 41. To send an IPv6 packet over an IPv4 network to a 6to4 destination address, an IPv4 header with protocol type 41 is prepended to the IPv6 packet. The IPv4 destination address for the prepended packet header is derived from the IPv6 destination address of the inner packet (which is in the format of a 6to4 address), by extracting the 32 bits immediately following the IPv6 destination address's 2002::/16 prefix. The IPv4 source address in the prepended packet header is the IPv4 address of the host or router which is sending the packet over IPv4. The resulting IPv4 packet is then routed to its IPv4 destination address just like any other IPv4 packet.

Routing between 6to4 and native IPv6

To allow hosts and networks using 6to4 addresses to exchange traffic with hosts using "native" IPv6 addresses, "relay routers" have been established. A relay router connects to an IPv4 network and an IPv6 network. 6to4 packets arriving on an IPv4 interface will have their IPv6 payloads routed to the IPv6 network, while packets arriving on the IPv6 interface with a destination address prefix of 2002::/16 will be encapsulated and forwarded over the IPv4 network.
There is a difference between a "relay router" and a "border router" (also known as a "6to4 border router"). A 6to4 border router is an IPv6 router supporting a 6to4 pseudo-interface. It is normally the border router between an IPv6 site and a wide-area IPv4 network, where the IPv6 site uses 2002::/16 co-related to the IPv4 address used later on. On the other hand, a "relay router" is a 6to4 router configured to support transit routing between 6to4 addresses and pure native IPv6 addresses.
To allow a 6to4 host to communicate with the native IPv6 Internet, it must have its IPv6 default gateway set to a 6to4 address which contains the IPv4 address of a 6to4 relay router. To avoid the need for users to set this up manually, the anycast address of 192.88.99.1 has been allocated for the purpose of sending packets to a 6to4 relay router. Note that when wrapped in 6to4 with the subnet and hosts fields set to zero this IPv4 address (192.88.99.1) becomes the IPv6 address 2002:c058:6301::. To ensure BGP routing propagation, a short prefix of 192.88.99.0/24 has been allocated for routes pointed at 6to4 relay routers that use this anycast IP address. Providers willing to provide 6to4 service to their clients or peers should advertise the anycast prefix like any other IP prefix, and route the prefix to their 6to4 relay.
Packets from the IPv6 Internet to 6to4 systems must be sent to a 6to4 relay router by normal IPv6 routing methods. The specification states that such relay routers must only advertise 2002::/16 and not subdivisions of it to prevent IPv4 routes polluting the routing tables of IPv6 routers. From here they can then be sent over the IPv4 Internet to the destination.
For a 6to4 host to have fast and reliable connectivity with a host natively using the IPv6 Internet, both the 6to4 host and the native IPv6 host must have a route to a fast, reliable and correctly configured relay server. The 6to4 host's ISP can ensure that outgoing packets go to such a relay, but they have no control over the relay used for the responses from the native IPv6 host. A variant called IPv6 rapid deployment ("6rd") uses the same basic principles as 6to4 but uses a relay operated by the 6rd user's ISP for traffic in both directions. To achieve this an address block allocated by the user's ISP is used instead of 2002::/16.

Reverse DNS delegation

When a site using 6to4 has a fixed global IPv4 address, its 6to4 IPv6 prefix is also fixed. It is then possible to request reverse DNS delegation for an individual 6to4 48-bits prefix inside the 2.0.0.2.ip6.arpa DNS zone from the Number Resource Organization at [1] . The process is entirely automatic.

Security considerations

According to RFC 3964, 6to4 routers and relays should ensure that:

• either or both the source and destination addresses of any encapsulated packet is within the 6to4 IPv6 prefix 2002::/16,
• if the source IPv6 address is a 6to4 IPv6 address, its corresponding 6to4 router IPv4 address matches the IPv4 source address in the IPv4 encapsulation header,
• similarly, if the destination IPv6 address is a 6to4 IPv6 address, its corresponding 6to4 router IPv4 address matches the IPv4 destination address in the IPv4 encapsulation header,
• any embedded 6to4 router IPv4 address is global unicast.

6to4 relays

Pv6 6to4 Relay Routing Service
Overview of UW-Madison 6to4 protocol IPv6 service for both the campus and wan environments. Update: Nov. 2012, 6to4 relay routing has been effectively deprecated. Do not use it. Essentially, 6to4 was elegantly sunsetted by the availability of native IPv6 connectivity, the 6rd tunneling mechanism which fixes issues with blindly picking relays, with the help of implementations of rfc6724 and "happy eyeballs" enabled by default on all new clients. For more information, see draft-ietf-v6ops-6to4-to-historic. At this time, UW's as well as most all other public open relays have been disabled.

IPV6 6to4 Tunnel

Contents IPv6 Automatic 6to4 Tunnels Finding Feature Information Information About IPv6 Automatic 6to4 Tunnels Automatic 6to4 Tunnels How to Configure IPv6 Automatic 6to4 Tunnels Configuring Automatic 6to4 Tunnels Configuration Examples for IPv6 Automatic 6to4 Tunnels Example: Configuring 6to4 Tunnels Additional References Feature Information for IPv6 Automatic 6to4 Tunnels IPv6 Automatic 6to4 Tunnels This feature provides support for IPv6 automatic 6to4 tunnels. An automatic 6to4 tunnel allows isolated IPv6 domains to be connected over an IPv4 network to remote IPv6 networks. Finding Feature Information Information About IPv6 Automatic 6to4 Tunnels How to Configure IPv6 Automatic 6to4 Tunnels Configuration Examples for IPv6 Automatic 6to4 Tunnels Additional References Feature Information for IPv6 Automatic 6to4 Tunnels Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required. Information About IPv6 Automatic 6to4 Tunnels Automatic 6to4 Tunnels Automatic 6to4 Tunnels An automatic 6to4 tunnel allows isolated IPv6 domains to be connected over an IPv4 network to remote IPv6 networks. The key difference between automatic 6to4 tunnels and manually configured tunnels is that the tunnel is not point-to-point; it is point-to-multipoint. In automatic 6to4 tunnels, routers are not configured in pairs because they treat the IPv4 infrastructure as a virtual nonbroadcast multiaccess (NBMA) link. The IPv4 address embedded in the IPv6 address is used to find the other end of the automatic tunnel. An automatic 6to4 tunnel may be configured on a border router in an isolated IPv6 network, which creates a tunnel on a per-packet basis to a border router in another IPv6 network over an IPv4 infrastructure. The tunnel destination is determined by the IPv4 address of the border router extracted from the IPv6 address that starts with the prefix 2002::/16, where the format is 2002:border-router-IPv4-address ::/48. Following the embedded IPv4 address are 16 bits that can be used to number networks within the site. The border router at each end of a 6to4 tunnel must support both the IPv4 and IPv6 protocol stacks. 6to4 tunnels are configured between border routers or between a border router and a host. The simplest deployment scenario for 6to4 tunnels is to interconnect multiple IPv6 sites, each of which has at least one connection to a shared IPv4 network. This IPv4 network could be the global Internet or a corporate backbone. The key requirement is that each site have a globally unique IPv4 address; the Cisco software uses this address to construct a globally unique 6to4/48 IPv6 prefix. As with other tunnel mechanisms, appropriate entries in a Domain Name System (DNS) that map between hostnames and IP addresses for both IPv4 and IPv6 allow the applications to choose the required address. How to Configure IPv6 Automatic 6to4 Tunnels Configuring Automatic 6to4 Tunnels Configuring Automatic 6to4 Tunnels Before You Begin With 6to4 tunnels, the tunnel destination is determined by the border router IPv4 address, which is concatenated to the prefix 2002::/16 in the format 2002:border-router-IPv4-address ::/48. The border router at each end of a 6to4 tunnel must support both the IPv4 and IPv6 protocol stacks. Note The configuration of only one IPv4-compatible tunnel and one 6to4 IPv6 tunnel is supported on a router. If you choose to configure both of those tunnel types on the same router, we strongly recommend that they do not share the same tunnel source. The reason that a 6to4 tunnel and an IPv4-compatible tunnel cannot share an interface is that both of them are NBMA "point-to-multipoint" access links and only the tunnel source can be used to reorder the packets from a multiplexed packet stream into a single packet stream for an incoming interface. So when a packet with an IPv4 protocol type of 41 arrives on an interface, that packet is mapped to an IPv6 tunnel interface based on the IPv4 address. However, if both the 6to4 tunnel and the IPv4-compatible tunnel share the same source interface, the router is not able to determine the IPv6 tunnel interface to which it should assign the incoming packet. IPv6 manually configured tunnels can share the same source interface because a manual tunnel is a "point-to-point" link, and both the IPv4 source and IPv4 destination of the tunnel are defined. > SUMMARY STEPS 1.    enable 2.    configure terminal 3.    interface tunnel tunnel-number 4.    ipv6 address {ipv6-address / prefix-length | prefix-name sub-bits/prefix-length 5.    tunnel source {ip-address| interface-t ype interface-number} 6.    tunnel mode ipv6ip [6rd | 6to4 | auto-tunnel | isatap 7.    exit 8.    ipv6 route [vrf vrf-name] ipv6-prefix / prefix-length{ipv6-address | interface-type interface-number [ipv6-address]} [nexthop-vrf [vrf-name1 | default]] [administrative-distance] [administrative-multicast-distance | unicast | multicast] [next-hop-address] [tag tag] DETAILED STEPS   Command or Action Purpose Step 1 enable Example: Router> enable   Enables privileged EXEC mode. Enter your password if prompted.   Step 2 configure terminal Example: Router# configure terminal   Enters global configuration mode.   Step 3 interface tunnel tunnel-number Example: Router(config)# interface tunnel 1   Specifies a tunnel interface and number, and enters interface configuration mode.   Step 4 ipv6 address {ipv6-address / prefix-length | prefix-name sub-bits/prefix-length Example: Router(config-if)# ipv6 address 3ffe:b00:c18:1::3/127   Specifies the IPv6 network assigned to the interface and enables IPv6 processing on the interface.   Step 5 tunnel source {ip-address| interface-t ype interface-number} Example: Router(config-if)# tunnel source loopback 1   Specifies the source interface type and number for the tunnel interface.   Step 6 tunnel mode ipv6ip [6rd | 6to4 | auto-tunnel | isatap Example: Router(config-if)# tunnel mode ipv6ip 6rd   Configures a static IPv6 tunnel interface. The auto-tunnel keyword is not supported on Cisco ASR 1000 series routers.   Step 7 exit Example: Router(config-if) exit   Exits interface configuration mode, and enters global configuration mode.   Step 8 ipv6 route [vrf vrf-name] ipv6-prefix / prefix-length{ipv6-address | interface-type interface-number [ipv6-address]} [nexthop-vrf [vrf-name1 | default]] [administrative-distance] [administrative-multicast-distance | unicast | multicast] [next-hop-address] [tag tag] Example: Router(config)# ipv6 route 2002::/16 tunnel 0   Configures a static route for the IPv6 6to4 prefix 2002::/16 to the specified tunnel interface. Note    When configuring a 6to4 overlay tunnel, you must configure a static route for the IPv6 6to4 prefix 2002::/16 to the 6to4 tunnel interface. The tunnel number specified in the ipv6 route command must be the same tunnel number specified in the interface tunnel command.   Configuration Examples for IPv6 Automatic 6to4 Tunnels Example: Configuring 6to4 Tunnels Example: Configuring 6to4 Tunnels The following example configures a 6to4 tunnel on a border router in an isolated IPv6 network. The IPv4 address is 192.168.99.1, which translates to the IPv6 prefix of 2002:c0a8:6301::/48. The IPv6 prefix is subnetted into 2002:c0a8:6301::/64 for the tunnel interface: 2002:c0a8:6301:1::/64 for the first IPv6 network, and 2002:c0a8:6301:2::/64 for the second IPv6 network. The static route ensures that any other traffic for the IPv6 prefix 2002::/16 is directed to tunnel interface 0 for automatic tunneling. interface GigabitEthernet0/0/0 description IPv4 uplink ip address 192.168.99.1 255.255.255.0 ! interface GigabitEthernet1/0/0 description IPv6 local network 1 ipv6 address 2002:c0a8:6301:1::1/64 ! interface GigabitEthernet2/0/0 description IPv6 local network 2 ipv6 address 2002:c0a8:6301:2::1/64 ! interface Tunnel0 description IPv6 uplink no ip address ipv6 address 2002:c0a8:6301::1/64 tunnel source GigabitEthernet0/0/0 tunnel mode ipv6ip 6to4 ! ipv6 route 2002::/16 tunnel 0 Additional References Related Documents Related Topic Document Title IPv6 addressing and connectivity IPv6 Configuration Guide Cisco IOS commands Cisco IOS Master Commands List, All Releases IPv6 commands Cisco IOS IPv6 Command Reference Cisco IOS IPv6 features Cisco IOS IPv6 Feature Mapping Standards and RFCs Standard/RFC Title RFCs for IPv6 IPv6 RFCs MIBs MIB MIBs Link To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: http:/​/​www.cisco.com/​go/​mibs Technical Assistance Description Link The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. http:/​/​www.cisco.com/​cisco/​web/​support/​index.html Feature Information for IPv6 Automatic 6to4 Tunnels The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required. Table 1 Feature Information for IPv6 Automatic 6to4 Tunnels Feature Name Releases Feature Information IPv6 Tunneling: Automatic 6to4 Tunnels Cisco IOS XE Release 2.1 An automatic 6to4 tunnel allows isolated IPv6 domains to be connected over an IPv4 network to remote IPv6 networks. The following commands were introduced or modified: tunnel mode ipv6ip, tunnel source.

IPV6RD rapid deployment

Contents IPv6 Rapid Deployment Finding Feature Information Information About IPv6 Rapid Deployment IPv6 Rapid Deployment Tunnels How to Configure IPv6 Rapid Deployment Configuring 6RD Tunnels Configuration Examples for IPv6 Rapid Deployment Example: Configuring 6RD Tunnels Additional References Feature Information for IPv6 Rapid Deployment IPv6 Rapid Deployment The IPv6 rapid deployment feature allows a service provider to provide a unicast IPv6 service to customers over its IPv4 network by using encapsulation of IPv6 in IPv4. Finding Feature Information Information About IPv6 Rapid Deployment How to Configure IPv6 Rapid Deployment Configuration Examples for IPv6 Rapid Deployment Additional References Feature Information for IPv6 Rapid Deployment Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required. Information About IPv6 Rapid Deployment IPv6 Rapid Deployment Tunnels IPv6 Rapid Deployment Tunnels The 6RD feature is an extension of the 6to4 feature. The 6RD feature allows a service provider (SP) to provide a unicast IPv6 service to customers over its IPv4 network by using encapsulation of IPv6 in IPv4. The main differences between 6RD and 6to4 tunneling are as follows: 6RD does not require addresses to have a 2002::/16 prefix; therefore, the prefix can be from the SP’s own address block. This function allows the 6RD operational domain to be within the SP network. From the perspective of customer sites and the general IPv6 internet connected to a 6RD-enabled SP network, the IPv6 service provided is equivalent to native IPv6. All 32 bits of the IPv4 destination need not be carried in the IPv6 payload header. The IPv4 destination is obtained from a combination of bits in the payload header and information on the router. Furthermore, the IPv4 address is not at a fixed location in the IPv6 header as it is in 6to4. The 6RD SP prefix was selected by the SP for the IPv6 deployment shown in the figure below. The 6RD delegated prefix is derived from the SP prefix and the IPv4 address bits, and is used by the CE for hosts within its site. Figure 1. 6RD Deployment The figure below shows how 6RD prefix delegation works. Figure 2. 6RD Prefix Delegation Explanation The figure below shows a 6RD prefix delegation topology. Figure 3. 6RD Prefix Delegation and Explanation How to Configure IPv6 Rapid Deployment Configuring 6RD Tunnels Configuring 6RD Tunnels SUMMARY STEPS 1.    enable 2.    configure terminal 3.    interface tunnel tunnel-number 4.    tunnel source {ip-address| interface-t ype interface-number} 5.    tunnel mode ipv6ip [6rd | 6to4 | auto-tunnel | isatap] 6.    tunnel 6rd prefix ipv6-prefix / prefix-length 7.    tunnel 6rd ipv4 {prefix-length length} {suffix-length length} DETAILED STEPS   Command or Action Purpose Step 1 enable Example: Router> enable   Enables privileged EXEC mode. Enter your password if prompted.   Step 2 configure terminal Example: Router# configure terminal   Enters global configuration mode.   Step 3 interface tunnel tunnel-number Example: Router(config)# interface tunnel 1   Specifies a tunnel interface and number, and enters interface configuration mode.   Step 4 tunnel source {ip-address| interface-t ype interface-number} Example: Router(config-if)# tunnel source loopback 1   Specifies the source interface type and number for the tunnel interface.   Step 5 tunnel mode ipv6ip [6rd | 6to4 | auto-tunnel | isatap] Example: Router(config-if)# tunnel mode ipv6ip 6rd   Configures a static IPv6 tunnel interface. The auto-tunnel keyword is not supported on Cisco ASR 1000 series routers.   Step 6 tunnel 6rd prefix ipv6-prefix / prefix-length Example: Router(config-if)# tunnel 6rd prefix 2001:B000::/32   Specifies the common IPv6 prefix on IPv6 rapid 6RD tunnels.   Step 7 tunnel 6rd ipv4 {prefix-length length} {suffix-length length} Example: Router(config-if)# tunnel 6rd ipv4 prefix-length 16 suffix 8   Specifies the prefix length and suffix length of the IPv4 transport address common to all the 6RD routers in a domain.   Configuration Examples for IPv6 Rapid Deployment Example: Configuring 6RD Tunnels Example: Configuring 6RD Tunnels The following example shows the running configuration of a 6RD tunnel and the corresponding output of the show tunnel 6rd command: interface Tunnel1 ipv6 address 2001:B000:100::1/32 tunnel source loopback 1 tunnel mode ipv6ip 6rd tunnel 6rd prefix 2001:B000::/32 tunnel 6rd ipv4 prefix-len 16 suffix-len 8 end Router# show tunnel 6rd tunnel 1 Interface Tunnel1: Tunnel Source: 10.1.1.1 6RD: Operational, V6 Prefix: 2001:B000::/32 V4 Common Prefix Length: 16, Value: 10.1.0.0 V4 Common Suffix Length: 8, Value: 0.0.0.1 Additional References Related Documents Related Topic Document Title IPv6 addressing and connectivity IPv6 Configuration Guide Cisco IOS commands Cisco IOS Master Commands List, All Releases IPv6 commands Cisco IOS IPv6 Command Reference Cisco IOS IPv6 features Cisco IOS IPv6 Feature Mapping Standards and RFCs Standard/RFC Title RFCs for IPv6 IPv6 RFCs Technical Assistance Description Link The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. http:/​/​www.cisco.com/​cisco/​web/​support/​index.html Feature Information for IPv6 Rapid Deployment The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required. Table 1 Feature Information for IPv6 Rapid Deployment Feature Name Releases Feature Information IP Tunneling: 6RD IPv6 Rapid Deployment Cisco IOS XE Release 3.1S The 6RD feature allows a service provider to provide a unicast IPv6 service to customers over its IPv4 network by using encapsulation of IPv6 in IPv4. The following commands were introduced or modified: tunnel 6rd ipv4, tunnel 6rd prefix, tunnel mode ipv6ip, tunnel source.