IPv4 to IPv6 Translation Mechanisms

There are two approaches to the transition, which may be applicable in different phases of the process: Dual-stack (all nodes implement both IPv4 and IPv6) and IPv6-only combined with translation. The former requires no special IPv6 architecture besides connectivity. The latter, in practice, requires some mechanisms to access IPv4-only services which are bound to be used for quite a while yet.

Here, the major translation mechanisms are very briefly introduced. These could be divided in two: those that work in the network or in the node itself.

TCP/UDP Relay

TCP/UDP relay works as a transport-level relay between IPv6 and IPv4: IPv6 node connects to a published address (e.g. in DNS) consisting of the network prefix and IPv4 address embedded in the last bits, e.g. ``3ffe:ffff::0b0c:0d0e'' for ``11.12.13.14''. This way, the TCP connection or a UDP stream is established first to a port of an IPv6 address, and all the payload of the protocol is relayed to the IPv4 address in a separate connection from the relay.

TCP/UDP relay can also be used as a full-fledged protocol translator like NAT-PT (see below) with a DNS proxy placed between the hosts and the DNS server. The advantage compared to NAT-PT is that nothing needs to be done on the direct path toward the destination (i.e. the router).

A disadvantage, in some scenarios, is that all the IPv6 traffic seems to originate from one IPv4 address of the from the relay; this can be bad from e.g. statistics point-of-view; this is common to NAT-PT and other mechanisms, of course.

Another disadvantage is that usually only the headers are translated; if addresses are transported in the payload (as e.g. some videoconferencing or VoIP applications do), they cannot be translated because the translator cannot know how to perform the operation for every possible protocol. Such a translation would require mechanisms similar to ALG; but if an algorithm is available for IPv4 NAT's, it could be reasonably well adopted to IPv6 too.

NAT-PT

Network Address Translation - Protocol Translation (NAT-PT) uses Stateless IP/ICMP Translation algorithm in a stateful manner. It uses the same address mapping as TCP/UDP relay, but DNS proxying is done transparently on the wire by inspecting DNS queries with IPv4 'A' records and rewriting the replies to be IPv6 'AAAA' records to point at the NAT-PT translator (see fig. below for an example of DNS proxying and translator; with NAT-PT DNS proxying is done on the router). The disadvantage is that all the packets need to go through the same device; in practice this is not a problem if e.g. an xDSL router performs this translation.

There are numerous problems with NAT-PT's DNS proxying mechanism: for example, with DNS queries that return both A and AAAA, or those that are done over native IPv6 transport

Multiprotocol Label Switching

In computer networking and telecommunications, MultiProtocol Label Switching (MPLS) is a data-carrying mechanism which emulates some properties of a circuit-switched network packet-switched network. MPLS operates at an OSI Model layer that is generally considered to lie between traditional definitions of Layer 2 (data link layer) and Layer 3 (network layer), and thus is often referred to as a "Layer 2.5" protocol. It was designed to provide a unified data-carrying service for both circuit-based clients and packet-switching datagram service model. It can be used to carry many different kinds of traffic, including IP packets, as well as native ATM, SONET, and Ethernet frames.

Background

A number of different technologies were previously deployed with essentially identical goals, such as frame relay and ATM. MPLS is now replacing these technologies in the marketplace, mostly because it is better aligned with current and future technology needs.

In particular, MPLS dispenses with the cell-switching and signaling-protocol baggage of ATM. MPLS recognizes that small ATM cells are not needed in the core of modern networks, since modern optical networks (as of 2001) are so fast (at 10 Gbit/s and well beyond) that even full-length 1500 byte packets do not incur significant real-time queuing delays (the need to reduce such delays, to support voice traffic, having been the motivation for the cell nature of ATM).

At the same time, it attempts to preserve the traffic engineering and out-of-band control that made frame relay and ATM attractive for deploying large-scale networks.

MPLS was originally proposed by a group of engineers from Cisco Systems, Inc.; it was called "Tag Switching" when it was a Cisco proprietary proposal, and was renamed "Label Switching" when it was handed over to the IETF for open standardization.

One original motivation was to allow the creation of simple high-speed switches, since for a significant length of time it was impossible to forward IP packets entirely in hardware. However, advances in VLSI have made such devices possible. The systemic advantages of MPLS, such as the ability to support multiple service models, do traffic management, etc., remain.

How MPLS works

MPLS works by preappending packets with an MPLS header, containing one or more 'labels'. This is called a label stack.

Each label stack entry contains four fields:

• a 20-bit label value.
• a 3-bit field for QoS priority (experimental).
• a 1-bit bottom of stack flag. If this is set, it signifies the current label is the last in the stack.
• an 8-bit TTL (time to live) field.

These MPLS labeled packets are switched after a Label Lookup/Switch instead of a lookup into the IP table. Label Lookup and Label Switching may be faster than usual RIB lookup because it can take place directly within the switching fabric and not the CPU.

The exit points of an MPLS network are called Label Edge Routers (LER). Routers that perform routing based only on Label Switching are called Label Switch Routers (LSR). Remember that a LER is not usually the one that pops the label. For more information see Penultimate Hop Popping.

Devices that function as ingress and/or egress routers are often called PE (Provider Edge) routers. Devices that function only as transit routers are similarly called P (Provider) routers. The job of a P router is significantly easier than that of a PE router, so they can be less complex and may be more dependable because of this.

When an unlabeled packet enters the ingress router and needs to be passed on to an MPLS tunnel, the router first determines the forwarding equivalence class the packet should be in, and then inserts one or more labels in the packet's newly created MPLS header. The packet is then passed on to the next hop router for this tunnel.

When a labeled packet is received by an MPLS router, the topmost label is examined. Based on the contents of the label a swap, push (impose) or pop (dispose) operation can be performed on the packet's label stack. Routers can have prebuilt lookup tables that tell them which kind of operation to do based on the topmost label of the incoming packet so they can process the packet very quickly. In a swap operation the label is swapped with a new label, and the packet is forwarded along the path associated with the new label.

In a push operation a new label is pushed on top of the existing label, effectively "encapsulating" the packet in another layer of MPLS. This allows the hierarchical routing of MPLS packets. Notably, this is used by MPLS VPNs.

In a pop operation the label is removed from the packet, which may reveal an inner label below. This process is called "decapsulation". If the popped label was the last on the label stack, the packet "leaves" the MPLS tunnel. This is usually done by the egress router, but see PHP below.

During these operations, the contents of the packet below the MPLS Label stack are not examined. Indeed transit routers typically need only to examine the topmost label on the stack. The forwarding of the packet is done based on the contents of the labels, which allows "protocol independent packet forwarding" that does not need to look at a protocol-dependent routing table and avoids the expensive IP longest prefix match at each hop.

At the egress router, when the last label has been popped, only the payload remains. This can be an IP packet, or any of a number of other kinds of payload packet. The egress router must therefore have routing information for the packet's payload, since it must forward it without the help of label lookup tables. An MPLS transit router has no such requirement.

In some special cases, the last label can also be popped off at the penultimate hop (the hop before the egress router). This is called Penultimate Hop Popping (PHP). This may be interesting in cases where the egress router has lots of packets leaving MPLS tunnels, and thus spends inordinate amounts of CPU time on this. By using PHP, transit routers connected directly to this egress router effectively offload it, by popping the last label themselves.

MPLS can make use of existing ATM network infrastructure, as its labeled flows can be mapped to ATM virtual circuit identifiers, and vice-versa.

MPLS VPN—VRF Selection

The VPN Routing and Forwarding (VRF) Selection feature allows a specified interface on a provider edge (PE) router to route packets to different Virtual Private Networks (VPNs) based on the source IP address of the packet. This feature is an improvement over using a policy-based router to route packets to different VPNs.

Feature Overview

The VRF Selection feature allows packets arriving on an interface to be switched into the appropriate VRF table based upon the source IP address of the packets. Once the packets have been "selected" into the correct VRF routing table, they are processed normally based upon the destination address and forwarded through the rest of the Multiprotocol Label Switching (MPLS) VPN.

In most cases, the VRF Selection feature is a "one way" feature; it works on packets coming from the end users to the PE router.

VRF Selection Process

The VRF Selection feature uses the following process to route packets from the customer networks to the PE router and into the provider network.

A two-table lookup mechanism is used at the ingress interface of the PE router to determine the routing and forwarding of packets coming from the customer networks, which use IP protocols, to the MPLS VPN networks, which use MPLS protocols.

• The first table, the VRF Selection table, is used to compare the source IP address of the packet with a list of IP addresses in the table. Each IP address in the table is associated with an MPLS VPN. If a match is found between the source IP address of the packet and an IP address in the VRF Selection table, the packet is routed to the second table (the VRF table) or the routing table for the appropriate VPN.

  If no match is found in the table for the source IP address of the packet, the packet will either be routed via the global routing table used by the PE router (this is the default behavior), or will be dropped. See the "Configuring a VRF to Eliminate Unnecessary Packet Forwarding" section for more information.

• The second table, the VRF table (also known as the VPN routing table), contains the virtual routing and forwarding information for the specified VPN and is used to forward the selected VPN traffic to the correct MPLS label switched path (LSP) based upon the destination IP address of the packet.

The VRF Selection process removes the association between the VPN and the interface and allows more than one MPLS VPN to be associated with the interface.

source: http://cisco.com

Configure OSPF

Configure OSPF

Open Shortest Path First (OSPF) is an IGP developed by the OSPF working group of the Internet Engineering Task Force (IETF). Designed expressly for IP networks, OSPF supports IP subnetting and tagging of externally derived routing information. OSPF also allows packet authentication and uses IP multicast when sending/receiving packets.

We support RFC 1253, Open Shortest Path First (OSPF) MIB, August 1991. The OSPF MIB defines an IP routing protocol that provides management information related to OSPF and is supported by Cisco routers.

Cisco's OSPF Implementation

Cisco's implementation conforms to the OSPF Version 2 specifications detailed in the Internet RFC 1583. The list that follows outlines key features supported in Cisco's OSPF implementation:

• Stub areas---Definition of stub areas is supported.
• Route redistribution---Routes learned via any IP routing protocol can be redistributed into any other IP routing protocol. At the intradomain level, this means that OSPF can import routes learned via IGRP, RIP, and IS-IS. OSPF routes can also be exported into IGRP, RIP, and IS-IS. At the interdomain level, OSPF can import routes learned via EGP and BGP. OSPF routes can be exported into EGP and BGP.
• Authentication---Simple and MD5 authentication among neighboring routers within an area is supported.
• Routing interface parameters---Configurable parameters supported include interface output cost, retransmission interval, interface transmit delay, router priority, router "dead" and hello intervals, and authentication key.
• Virtual links---Virtual links are supported.

---

Note In order to take advantage of the OSPF stub area support, default routing must be used in the stub area.

---

OSPF Configuration Task List

OSPF typically requires coordination among many internal routers, area border routers (routers connected to multiple areas), and autonomous system boundary routers. At a minimum, OSPF-based routers can be configured with all default parameter values, no authentication, and interfaces assigned to areas. If you intend to customize your environment, you must ensure coordinated configurations of all routers.

To configure OSPF, complete the tasks in the following sections. Enabling OSPF is mandatory; the other tasks are optional but might be required for your application.

• Enable OSPF
• Configure OSPF Interface Parameters
• Configure OSPF over Different Physical Networks
• Configure OSPF Area Parameters
• Configure Route Summarization between OSPF Areas
• Configure Route Summarization when Redistributing Routes into OSPF
• Create Virtual Links
• Generate a Default Route
• Configure Lookup of DNS Names
• Force the Router ID Choice with a Loopback Interface
• Disable Default OSPF Metric Calculation Based on Bandwidth
• Configure OSPF on Simplex Ethernet Interfaces
• Configure Route Calculation Timers

In addition, you can specify route redistribution; see the task "Redistribute Routing Information" later in this chapter for information on how to configure route redistribution.

Enable OSPF

As with other routing protocols, enabling OSPF requires that you create an OSPF routing process, specify the range of IP addresses to be associated with the routing process, and assign area IDs to be associated with that range of IP addresses. Perform the following tasks, starting in global configuration mode:

Task	Command
Step 1 Enable OSPF routing, which places you in router configuration mode.	router ospf process-id
Step 2 Define an interface on which OSPF runs and define the area ID for that interface.	network address wildcard-mask area area-id

Configure OSPF Interface Parameters

Our OSPF implementation allows you to alter certain interface-specific OSPF parameters, as needed. You are not required to alter any of these parameters, but some interface parameters must be consistent across all routers in an attached network. Those are the parameters set by the ip ospf hello-interval, ip ospf dead-interval, and ip ospf authentication-key commands. Therefore, be sure that if you do configure any of these parameters, the configurations for all routers on your network have compatible values.

In interface configuration mode, specify any of the following interface parameters as needed for your network:

Task	Command
Explicitly specify the cost of sending a packet on an OSPF interface.	ip ospf cost cost
Specify the number of seconds between link state advertisement retransmissions for adjacencies belonging to an OSPF interface.	ip ospf retransmit-interval seconds
Set the estimated number of seconds it takes to transmit a link state update packet on an OSPF interface.	ip ospf transmit-delay seconds
Set router priority to help determine the OSPF designated router for a network.	ip ospf priority number
Specify the length of time, in seconds, between the hello packets that a router sends on an OSPF interface.	ip ospf hello-interval seconds
Set the number of seconds that a router's hello packets must not have been seen before its neighbors declare the OSPF router down.	ip ospf dead-interval seconds
Assign a specific password to be used by neighboring OSPF routers on a network segment that is using OSPF's simple password authentication.	ip ospf authentication-key key
Enable OSPF MD5 authentication.	ip ospf message-digest-key keyid md5 key

Configure OSPF over Different Physical Networks

OSPF classifies different media into three types of networks by default:

• Broadcast networks (Ethernet, Token Ring, FDDI)
• Nonbroadcast multiaccess networks (SMDS, Frame Relay, X.25)
• Point-to-point networks (HDLC, PPP)

You can configure your network as either a broadcast or a nonbroadcast multiaccess network.

X.25 and Frame Relay provide an optional broadcast capability that can be configured in the map to allow OSPF to run as a broadcast network. See the x25 map and frame-relay map command descriptions in the Router Products Command Reference publication for more detail.

Configure Your OSPF Network Type

You have the choice of configuring your OSPF network type as either broadcast or nonbroadcast multiaccess, regardless of the default media type. Using this feature, you can configure broadcast networks as nonbroadcast multiaccess networks when, for example, you have routers in your network that do not support multicast addressing. You also can configure nonbroadcast multiaccess networks, such as X.25, Frame Relay, and SMDS, as broadcast networks. This feature saves you from having to configure neighbors, as described in the section "Configure OSPF for Nonbroadcast Networks."

Configuring nonbroadcast, multiaccess networks as either broadcast or nonbroadcast assumes that there are virtual circuits from every router to every router or fully-meshed network. This is not true for some cases, for example, due to cost constraints or when you have only a partially-meshed network. In these cases, you can configure the OSPF network type as a point-to-multipoint network. Routing between two routers that are not directly connected will go through the router that has virtual circuits to both routers. Note that you do not need to configure neighbors when using this feature.

An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface having one or more neighbors. It creates multiple host routes. An OSPF point-to-multipoint network has the following benefits compared to nonbroadcast multiaccess and point-to-point networks:

• Point-to-multipoint is easier to configure because it requires no configuration of neighbor commands, it consumes only one IP subnet, and it requires no designated router election.
• It costs less because it does not require a fully-meshed topology.
• It is more reliable because it maintains connectivity in the event of virtual circuit failure.

To configure your OSPF network type, perform the following task in interface configuration mode:

Task	Command
Configure the OSPF network type for a specified interface.	ip ospf network {broadcast | non-broadcast | point-to-multipoint}

For an example of an OSPF point-to-multipoint network, see the section "OSPF Point-to-Multipoint Example" at the end of this chapter.

Configure OSPF for Nonbroadcast Networks

Because there might be many routers attached to an OSPF network, a designated router is selected for the network. It is necessary to use special configuration parameters in the designated router selection if broadcast capability is not configured.

These parameters need only be configured in those routers that are themselves eligible to become the designated router or backup designated router (in other words, routers with a nonzero router priority value).

To configure routers that interconnect to nonbroadcast networks, perform the following task in router configuration mode

Task	Command
Configure routers interconnecting to nonbroadcast networks.	neighbor ip-address [priority number] [poll-interval seconds]

You can specify the following neighbor parameters, as required:

• Priority for a neighboring router
• Nonbroadcast poll interval
• Interface through which the neighbor is reachable

Configure OSPF Area Parameters

Our OSPF software allows you to configure several area parameters. These area parameters, shown in the following table, include authentication, defining stub areas, and assigning specific costs to the default summary route. Authentication allows password-based protection against unauthorized access to an area.

Stub areas are areas into which information on external routes is not sent. Instead, there is a default external route generated by the area border router into the stub area for destinations outside the autonomous system. To further reduce the number of link state advertisements (LSA) sent into a stub area, you can configure no-summary on the Area Border Router (ABR) to prevent it from sending summary link advertisement (LSA type 3) into the stub area.

In router configuration mode, specify any of the following area parameters as needed for your network:

Task	Command
Enable authentication for an OSPF area.	area area-id authentication
Enable MD5 authentication for an OSPF area.	area area-id authentication message-digest
Define an area to be a stub area.	area area-id stub [no-summary]
Assign a specific cost to the default summary route used for the stub area.	area area-id default-cost cost

Configure Route Summarization between OSPF Areas

Route summarization is the consolidation of advertised addresses. This feature causes a single summary route to be advertised to other areas by an area border router. In OSPF, an area border router will advertise networks in one area into another area. If the network numbers in an area are assigned in a way such that they are contiguous, you can configure the area border router to advertise a summary route that covers all the individual networks within the area that fall into the specified range.

To specify an address range, perform the following task in router configuration mode:

Task	Command
Specify an address range for which a single route will be advertised.	area area-id range address mask

Configure Route Summarization when Redistributing Routes into OSPF

When redistributing routes from other protocols into OSPF (as described in the section "Configure Routing Protocol-Independent Features" later in this chapter, each route is advertised individually in an external link state advertisement (LSA). However, you can configure the router to advertise a single route for all the redistributed routes that are covered by a specified network address and mask. Doing so helps decrease the size of the OSPF link state database.

To have the router advertise one summary route for all redistributed routes covered by a network address and mask, perform the following task in router configuration mode:

Task	Command
Specify an address and mask that covers redistributed routes, so only one summary route is advertised.	summary-address address mask

Create Virtual Links

In OSPF, all areas must be connected to a backbone area. If there is a break in backbone continuity, or the backbone is purposefully partitioned, you can establish a virtual link. The two end points of a virtual link are Area Border Routers. The virtual link must be configured in both routers. The configuration information in each router consists of the other virtual endpoint (the other Area Border Router), and the nonbackbone area that the two routers have in common (called the transit area). Note that virtual links cannot be configured through stub areas.

To establish a virtual link, perform the following task in router configuration mode:

Task	Command
Establish a virtual link.	area area-id virtual-link router-id [hello-interval seconds] [retransmit-interval seconds] [transmit-delay seconds] [dead-interval seconds] [[authentication-key key] | [message-digest-key keyid md5 key]]

To display information about virtual links, use the show ip ospf virtual-links EXEC command. To display the router ID of an OSPF router, use the show ip ospf EXEC command.

Generate a Default Route

You can force an autonomous system boundary router to generate a default route into an OSPF routing domain. Whenever you specifically configure redistribution of routes into an OSPF routing domain, the router automatically becomes an autonomous system boundary router. However, an autonomous system boundary router does not, by default, generate a default route into the OSPF routing domain.

To force the autonomous system boundary router to generate a default route, perform the following task in router configuration mode:

Task	Command
Force the autonomous system boundary router to generate a default route into the OSPF routing domain.	default-information originate [always] [metric metric-value] [metric-type type-value] [route-map map-name]

See also the discussion of redistribution of routes in the "Configure Routing Protocol-Independent Features" section later in this chapter.

Configure Lookup of DNS Names

You can configure OSPF to look up Domain Name System (DNS) names for use in all OSPF show command displays. This feature makes it easier to identify a router, because it is displayed by name rather than by its router ID or neighbor ID.

To configure DNS name lookup, perform the following task in global configuration mode:

Task	Command
Configure DNS name lookup.	ip ospf name-lookup

Force the Router ID Choice with a Loopback Interface

OSPF uses the largest IP address configured on the router's interfaces as its router ID. If the interface associated with this IP address is ever brought down, or if the address is removed, the OSPF process must recalculate a new router ID and resend all of its routing information out its interfaces.

If a loopback interface is configured with an IP address, the router will use this IP address as its router ID, even if other interfaces have larger IP addresses. Since loopback interfaces never go down, greater stability in the routing table is achieved.

OSPF automatically prefers a loopback interface over any other kind, and it chooses the highest IP address among all loopback interfaces in the router. If no loopback interfaces are present, the highest IP address in the router is chosen. You cannot tell OSPF to use any particular interface.

To configure an IP address on a loopback interface, perform the following tasks, starting in global configuration mode:

Task	Command
Step 1 Create a loopback interface, which places you in interface configuration mode.	interface loopback 01
Step 2 Assign an IP address to this interface.	ip address address mask2

1This command is documented in the "Interface Commands" chapter of the Router Products Command Reference publication. 2This command is documented in the "IP Commands" chapter of the Router Products Command Reference publication.

Disable Default OSPF Metric Calculation Based on Bandwidth

In Cisco IOS Release 10.2 and earlier, OSPF assigned default OSPF metrics to interfaces regardless of the interface bandwidth. It gave both 64K and T1 links the same metric (1562), and thus required an explicit ip ospf cost command in order to take advantage of the faster link.

In Cisco IOS Release 10.3, by default, OSPF calculates the OSPF metric for an interface according to the bandwidth of the interface. For example, a 64K link gets a metric of 1562, while a T1 link gets a metric of 64. To disable this feature, perform the following task in router configuration mode:

Task	Command
Disable default OSPF metric calculations based on interface bandwidth, resulting in a fixed default metric assignment.	no ospf auto-cost-determination

Configure OSPF on Simplex Ethernet Interfaces

Because simplex interfaces between two routers on an Ethernet represent only one network segment, for OSPF you have to configure the transmitting interface to be a passive interface. This prevents OSPF from sending hello packets for the transmitting interface. Both routers are able to see each other via the hello packet generated for the receiving interface.

To configure OSPF on simplex Ethernet interfaces, perform the following task in router configuration mode:

Task	Command
Suppress the sending of hello packets through the specified interface.	passive-interface type number

Configure Route Calculation Timers

You can configure the delay time between when OSPF receives a topology change and when it starts a Shortest Path First (SPF) calculation. You can also configure the hold time between two consecutive SPF calculations. To do this, perform the following task in router configuration mode:

Task	Command
Configure route calculation timers.	timers spf spf-delay spf-holdtime

Source : cisco.com