Introduction
Like the Internet Control Message Protocol (ICMP), the Internet Group Management Protocol (IGMP) is a integral part of IP. IP hosts use IGMPv2, described in RFC 2236, to report their multicast group memberships to routers. RFC 2236 updates RFC 1112. ICMPv6 incorporates some functions from IGMP.
IPv6 nodes on the same link use Neighbor Discovery for IP Version 6 (RFC 1970) to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.
This chapter briefly:
- Introduces the Internet Group Management Protocol and the IGMP message format, the IGMP message types as they apply to IPv6, and discusses the compatibility of IGMP v2 with IGMPv1 hosts.
- Describes Neighbor Discovery Messages as they apply to IPv6 including router solicitation messages, router advertisement messages, neighbor solicitation messages, neighbor advertisement messages, and redirect messages.
- Introduces the IP routing process including a brief description of Autonomous System. There is also a brief discussion about the differences between distance-vector routing, link state routing, interior routing, and exterior routing protocols.
- Discusses the impact of IPv6 on the RFC routing including the Internet Domain Routing Protocol (IDRP) for IPv4 and IPv6, the Routing Information Protocol (RIPng) for IPv6, and Open Shortest Path First (OSPF) Protocol for IPv6.
Internet Group Management Protocol
The Internet Group Management Protocol (IGMP) is an integral part of IP. All hosts that want to receive IP multicast must implement IGMP. IP hosts use the IGMP to:
- Report their multicast group memberships to any immediately-neighboring multicast routers
- Determine group between hosts and routers.
Any router that is a member of a multicast group should operate as a host as well as a router. Such routers can respond to their own queries. A router only needs to run IGMP on one of the interfaces if the router has multiple physical interfaces on a single network. Note however, that Hosts need to perform their actions on all interfaces that have memberships associated with them.
Multicast routers use IGMP to learn which groups have members on each of their attached physical networks. For each attached network a multicast router maintains a list of multicast group memberships and a timer for each membership. Interpret the phrase "multicast group memberships" to indicate the presence of at least one member of a multicast group on the attached network. Multicast group memberships does not mean a list of all of the members of the attached network.
IP datagrams encapsulate IGMP messages. IGMP messages are sent with IP TTL 1, and contain the new IP Router Alert option type in their IP header. RFC 2113 dated February 1997 by D. Katz describes this new IP option type that alerts transit routers to more closely examine the contents of an IP packet. This option type is useful with protocols, such as IGMP, that are addressed to a destination but require relatively complex processing in routers along the way.
IGMP message format
IGMP messages have the format shown in .
Type field ¾ As stated previously, ICMPv6 incorporates some functions from IGMP. ICMP divides its message header type field values into type 0 through127 for error messages and type 128 trough 255 for informational messages. Of particular interest here are the ICMP information messages that point to the IGMP information messages ().
Within IGMPv2 there is an additional message type for backwards-compatibility with IGMPv1 that triggers a version 1 group membership report.
Max Response Time field ¾ Membership query messages use the Max Response Time field. For all other message types, the sender sets this field to zero. By varying this setting in membership query messages, IGMPv2 routers can tune the time between the moment the last host leaves a group and when the routing protocol is notified that there are no more members
Checksum field ¾ IGMP sets the checksum field to zero for computing the checksum. The IGMP protocol (RFC 2236) specifies the checksum as the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). Note that IGMP messages can be longer than 8 octets. Always compute the IGMP checksum over the whole IP payload, not just over the first 8 octets.
The protocol specifies that the checksum must be computed and inserted into the checksum field when transmitting packets and that the checksum must be verified before processing the packets.
Group Address field ¾ IP addresses in this field identify the group address being queried, reported, or left.
IGMP message types
There are three types of IGMP messages about host and router interaction: multicast group membership queries, multicast group membership reports, and leave multicast group membership.
IGMP multicast group membership query
There are two sub-types of membership query message; general and group-specific. Usually membership query messages are referred to just as query messages. IGMP uses the general group membership query to learn which groups have members on an attached local network. And IGMP uses the group-specific query to learn if a particular group has members on an attached local network.
To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address must either be zero or a valid multicast group address.
The group address (see ) differentiates these two types of query messages. In a Membership Query message, set the group address field to zero when sending a General Query. Set the group address field to the group address being queried when sending a Group-Specific Query.
The Max Response Time field in the group membership query specifies the maximum allowed time before IGMP is to send a responding report. The response time is measured in units of 1/10 second.
IGMP multicast membership report
When a host receives a general or group-specific multicast membership query, it does a number of things.
First the host identifies the groups on the interface from which it received the query and sets delay timers for each group of which it is a member. If a timer for the group is already running, it is reset depending on the value of the Max Response Time.
The host multicasts a membership report to the group when the group’s timer expires. Under some conditions a host might receive another host’s report while it has a timer running. In this case, the host stops its timer for that group and does not send a report for that group.
When a router receives a Report, it:
- Adds the group being reported to the list of multicast group memberships on the network on which it received the Report
- Sets the timer for the membership to the Group Membership Interval. The Group Membership Interval is the amount of time that must pass before a multicast router decides there are no more members of a group on a network.
If the router does not receive reports for a particular group before the timer expires, the router assumes the group has no local members. In this case the router does not forward onto the attached network multicasts for that group that it receives from remote origins.
IGMP sets the group address field in the membership report message header to the IP multicast group address of the group being reported.
IGMP multicast leave group membership
When a host leaves a multicast group it sends a leave group message depending on the specific implementation of IGMP on the host. Some hosts send a leave group message if the host leaving the group was the last host to reply to a query with a membership report for that group. Other implementations might have any host leaving the group send a leave group message no matter when that host replied with a membership report to a query.
Routers should always accept a leave group message address to the group that is being left. Address any leave group messages to the all-router group; other group members do not need to know that a host has left the group. However, addressing the message to the group does no harm.
IGMP sets the group address field in the membership leave group message header to the IP multicast group address of the group being left. An IGMPv2 host can suppress leave group messages on a network where the host is using IGMPv1.
Compatibility IGMPv2 with IGMPv1 hosts
IGMPv2 and IGMPv1 host can coexist on the same subnet. In this case a host is required to permit the suppression the membership report of the opposite version.
IGMPv2 and IGMPv1 routers can coexist on the same subnet. In this case, a router receiving a Version 1 membership report is required to set a timer indicating the presence of version 1 hosts that are members of the group for which the router heard the report. This timer setting is the same as the group membership interval.
If any version 1 hosts are present for a particular group, a router is required to ignore any leave group messages that it receives for that group.
Message destinations
summarizes the IGMP message type and the message destination group.
Neighbor Discovery Protocol
The IPv6 Neighbor Discovery protocol is a synthesis of several IPv4 protocols. These protocols including the Address Resolution Protocol (ARP) RFC 826, the ICMP Router Discovery (RDISC) RFC 1256 protocol, and ICMP Redirect messages from RFC 792.
Hosts and routers use the Neighbor Discovery to determine the link-layer addresses for neighbors on attached links, detect changed link-layer address, and to purge invalid cached values. Hosts and routers can use this protocol to determine weather or not a neighbor is reachable. Hosts also use Neighbor Discovery to find neighboring routers that can forward packets on their behalf. When a router or the path to a router fails, a host actively searches for functioning alternates.
Protocol overview
The Neighbor Discovery protocol defines mechanisms for solving a number of problems including the following:
- Router Discovery: How hosts locate routers residing on an attached link.
- Prefix Discovery: How hosts discover the set of address prefixes defining which destinations are on-link for an attached link.
| NOTE: Nodes use prefixes to differentiate destinations residing on-link from destinations that are only reachable through a router. |
The Neighbor Discovery protocol specifies the use of link-layer multicast for some, but not all, of it services. Some services that are not dependent on multicast include redirects, next-hop determination, and neighbor unreachability detection. In addition, Neighbor Discovery makes use of a number of different addresses as shown in .
Neighbor Discovery message types
The Neighbor Discovery protocol defines five ICMPv6 packet types. These include a pair of Router Solicitation and Router Advertisement messages, another pair of Neighbor Solicitation and Neighbor Advertisements messages, and a Redirect message.
Router Solicitation messages:
Enabling an interface can cause the host to send out Router Solicitation messages that request routers to send out Router Advertisements immediately rather than at their next scheduled time. In addition to sending periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on an advertising interface. Router Solicitations can be sent after any of the following events occur:
- The interface initializes at system startup time.
- Interface reinitializes after a temporary interface failure or after being temporarily disabled by system management.
- The system changes from being a router to being a host when system management turns off its IP forwarding capability.
- The host attaches to a link for the first time.
- The host re-attaches to a link after being detached for some time.
RFC 1970 describes in detail how a router processes router solicitation messages.
Router Solicitation message fields
The Router Solicitation message format is as shown in.
The IP header fields for the Router Solicitation message include a hop limit of 255, a priority value of 15 and an authentication header if a security association exists between the sender and the destination address.
The identifying source address would be the IP address assigned to the sending interface. This address could be the unspecified address if the sending interface has no assigned address. The destination address in the IP header would typically be the all-routers multicast address.
The ICMP fields for the Router Solicitation message include the Type field set at 133, a Code value of 0, the ICMP checksum, and a reserved field initialized to zero by the sender and ignored by the receiver. Valid options can include the source link-layer address of the sender, if known.
Router Solicitation message validation
Hosts silently discard any received Router Solicitation messages. For a router to accept a Router Solicitation message the message must satisfy all of the following validity checks:
- The IP Hop Limit field value is 255 indicating that the packet could not have been forwarded by a router.
- Correct authentication if the message includes an IP Authentication Header
- A valid ICMP checksum
- The ICMP code set to 0.
- ICMP length of eight or more octets.
- All included options have a length greater than zero.
A solicitation that passes the validity checks is called a valid solicitation.
Sending Router Solicitations
Sometimes a host might be unwilling to wait for the next unsolicited Router Advertisement to locate default routers or learn prefixes when an interface come online. A host sends Router Solicitations to the all-routers multicast address. To obtain Router Advertisements quickly the host can send router Solicitations after any of the following events:
- Initialization of the interface at startup time
- Reinitialization of the interface after a temporary interface failure
- Reinitialization of the interface after being disabled by system management
- Changing of the system from a router to a host because system management turned off the systems IP forwarding capability
- Attachment of the host to a link for the first time.
- Reattachment of the host to a link after being detached for some time.
Router Advertisement messages
On multicast-capable links, each router periodically multicasts a Router Advertisement packet announcing its availability. Hosts receive Router Advertisements from all routers and build a list of default routers. Router Advertisement messages contain Internet parameters such as the hop limit and link parameters such as the link MTU. This centralizes administration of critical parameters that can be set on routers and automatically propagated to all attached hosts.
A host must not send Router Advertisement messages at any time.
Routers periodically advertise their presence and their various link and Internet parameters. Routers can all advertise their presence in response to a Router Solicitation message. Router Advertisements contain prefixes that are used for on-link determination.
The Router Advertisements prefixes can also be used for address configuration. For example, a router might want to send Router Advertisements without advertising itself as a default router. Such a router might advertise prefixes for address autoconfiguration while not wishing to forward packets. In this instance, the router sets the Router Lifetime field in outgoing advertisements to zero.
In addition to sending periodic unsolicited advertisements, a router sends advertisements in response to valid solicitations received on an advertising interface. A router sending unsolicited advertisements does not need to include options.
However, if a router is responding to a Router Solicitation message, the router should include all options so that all prefix information is propagated quickly during system initialization. If including all options causes the MTU of the advertisement to exceed the link MTU, the router can send multiple advertisements. In this case, each unsolicited advertisement would contain a subset of the options.
The actions of system management can cause the information contained in Router Advertisements to change. For example, the advertised prefix lifetimes could change, system management could add new prefixes. Or a router could switch from being a router to being a host. In this case, the router could send unsolicited Router Advertisement messages using the same rules as when an interface becomes an advertising interface.
Router Advertisement message fields
The Router Solicitation message format is as shown in. The IP header fields for the Router Advertisement message include a hop limit of 255, a priority value of 15 and an authentication header if a security association exists between the sender and the destination address.
The identifying source address is the link-local address assigned to the sending interface. The destination address in the IP header would typically be the source address of an invoking Router Solicitation or the all-nodes multicast address.
The ICMP fields for the Router Advertisement message include the Type field set at 134, a Code value of 0, and the ICMP checksum. summarizes the other ICMP fields in the Route Advertisement message.
Router Advertisement message validation
For a node to accept a Router Advertisement message it must satisfy all of the checks in the following list. Nodes must silently discard any Router Advertisement messages that do not pass the validity checks.
- The IP Source Address is a link-local address. Routers must use their link-local address as the source for Router Advertisement and Redirect messages. This means that hosts can uniquely identify routers.
- Correct authentication if the message includes an IP Authentication Header
- The IP Hop Limit field has a value of 255. This means that a router did not forward the packet.
- The ICMP Checksum is valid.
- The ICMP Code is 0.
- The ICMP length derived from the IP length is 16 or more octets.
- All included options have a length greater than zero.
An advertisement that passes the validity checks is called a valid advertisement.
Neighbor Solicitation messages
Nodes send Neighbor Solicitation messages to determine the link-layer address of a neighbor or target node. At the same time, the node provides their own link-layer address to the target node. Nodes can send these messages to verify that a neighbor is still reachable through a cached link-layer address.
Nodes can also accomplish address resolution by multicasting a Neighbor Solicitation messages. The message is sent to the solicited-node multicast address of the target address. The Neighbor Solicitation message asks the target node to return its link-layer address. The target returns its link-layer address in a unicast Neighbor Advertisement message.
Neighbor Solicitation messages can also be used to determine if more than one node has been assigned the same unicast address. S. Thomas and T Narten discuss the use of Neighbor Solicitation messages for duplicate address detection in RFC 1971, "IPv6 Stateless Address Autoconfiguration."
Nodes multicast Neighbor Solicitation messages when the node needs to resolve an address. Nodes unicast Neighbor Solicitation messages when the node needs to verify the reachability of a neighbor.
Sometimes a node needs to send a packet to a neighbor but does not know the neighbor's link-layer address. In this situation, the nodes performs address resolution.
RFC 1970 and RFC 1971 discuss the use of Neighbor Solicitation messages for Duplicate Address Detection which detects the failure of a neighbor or the failure of the forward path to the neighbor.
Neighbor Solicitation message fields
The Neighbor Solicitation message format is as shown in .
The IP header fields for the Neighbor Solicitation message include a hop limit of 255, a priority value of 15 and an authentication header if a security association exists between the sender and the destination address.
The identifying source address would be the IP address assigned to the sending interface. This address could be the unspecified address if duplicate address detection is in progress. The destination address in the IP header would be either the solicited-node multicast address that corresponds to the target address, or the target address.
The ICMP fields for the Router Solicitation message include the Type field set at 135, a Code value of 0, the ICMP checksum, and a reserved field initialized to zero by the sender and ignored by the receiver. Valid options can include the source link-layer address of the sender, if known.
There is also a Target Address field that contains the IP address of the target of the solicitation. This target address must not be a multicast address.
Source link-layer address field contains the link-layer address for the sender. Always include this option in multicast solicitations when the link layers has an addresses. You should but are not required to include this option in unicast neighbor solicitations.
Neighbor Solicitation message validation
For a node to accept a Neighbor Solicitation message it must satisfy all of the checks in the following list. Nodes must silently discard any Neighbor Solicitation messages that do not pass the validity checks.
- The IP Hop Limit field has a value of 255. This means that the packet was not forwarded by a router.
- Correct authentication if the message includes an IP Authentication Header
- The ICMP Checksum is valid.
- The ICMP Code is 0.
- The ICMP length derived from the IP length is 24 or more octets.
- The Target Address is not a multicast address.
- All included options have a length that is greater than zero.
A Neighbor Solicitation that passes the validity checks is called a valid solicitation.
Neighbor Advertisement messages
A node sends a neighbor advertisement message is a response to a Neighbor Solicitation message. A node can also send unsolicited Neighbor Advertisements to announce a link-layer address change. Use of an unsolicited Neighbor Advertisement in this way can unreliably propagate new information quickly.
Neighbor Advertisement message fields
The Neighbor Advertisement message format is as shown in .
The IP header fields for the Neighbor Solicitation message include a hop limit of 255, a priority value of 15 and an authentication header if a security association exists between the sender and the destination address.
The identifying source address would be the IP address assigned to the sending interface. The destination address in the IP header for a solicited advertisement the would be one of two addresses:
- The address of the source node that sent the Neighbor Solicitation message,
- The all-nodes multicast address if the solicitation's Source Address is the unspecified
The destination address for an unsolicited advertisement would be the all-nodes multicast address.
The ICMP fields for the Router Solicitation message include the Type field set at 136, a Code value of 0, the ICMP checksum, and a reserved field initialized to zero by the sender and ignored by the receiver. summarizes the other ICMP fields in the Route Advertisement message.
Neighbor Advertisement message validation
For a node to accept a Neighbor Advertisement message it must satisfy all of the checks in the following list. Nodes must silently discard any Neighbor Advertisement messages that do not pass the validity checks.
- The IP Hop Limit field has a value of 255. This means that the packet was not forwarded by a router.
- Correct authentication if the message includes an IP Authentication Header
- The ICMP Checksum is valid.
- The ICMP Code is 0.
- The ICMP length derived from the IP length is 24 or more octets.
- The Target Address is not a multicast address.
- The Solicited flag is zero if the IP Destination Address is a multicast.
- All included options have a length that is greater than zero.
A Neighbor Advertisements that passes the validity checks is called a valid advertisement.
Sending solicited Neighbor Advertisements
When a Neighbor Advertisement is in response to a valid Neighbor Solicitation targeting one of the node’s assigned addresses, the Target Address of the advertisement is a copy of the Target Address of the solicitation. Note the conditions listed in.
Sending unsolicited Neighbor Advertisements
Sometime a hot-swap of an interface card occurs and a node might be able to determine that its link-layer address has changed. In this case the node might want to quickly inform its neighbors of the new link-layer address. The node could send an unsolicited Neighbor Advertisement messages to the all-nodes multicast address. Note the conditions in the following list when sending unsolicited neighbor advertisements. Other conditions apply and are described in RFC 1970
- Set the Target Address field in the unsolicited advertisement to an IP address of the interface, and fill the Target Link-Layer Address option with the new link-layer address.
- A node that has multiple IP addresses assigned to an interface can multicast a separate Neighbor Advertisement for each address.
- A proxy can multicast Neighbor Advertisements when:
- Its link-layer address changes
- System management configures it to proxy for an address.
- A node belonging to an anycast address can multicast unsolicited Neighbor Advertisements for the anycast address when the node's link- layer address changes.
Redirect messages
Router use redirect messages to inform hosts of a better first hop node for a destination. A redirect message can inform hosts of a better first-hop router. In addition, by setting the ICMP Target Address equal to the ICMP Destination address, you can use a redirect message to inform a host that the destination is in fact a neighbor. Redirect messages apply to all flows that sent to a given destination.
A router must not update its routing tables whenever it receives a Redirect message. Whenever a router forwards a packet that is not explicitly addressed to itself it should also send a redirect message. A router likewise must limit the rate at which it sends Redirect messages to limit the bandwidth and processing costs that redirect messages use.
A host MUST NOT send Redirect messages. When a host receives a valid redirect, it should update its destination cache. Doing so means that subsequent traffic goes to the correct destination. Sometime a redirect could contain a Target Link-Layer Address option. In this case, the host either creates or updates the Neighbor Cache entry for the target.
Redirect message fields
The IP header fields for the Neighbor Solicitation message include a hop limit of 255, a priority value of 15 and an authentication header if a security association exists between the sender and the destination address.
The identifying source address is the link-local address assigned to the sending interface. The destination address is the source address of the packet that triggered the redirect.
The ICMP fields for the Redirect message include the Type field set at 137, a Code value of 0, the ICMP checksum, and a reserved field initialized to zero by the sender and ignored by the receiver.
summarizes the other ICMP fields in the Redirect message.
While used in the Redirect message, all other Neighbor Discovery messages must silently ignore this option. The Redirect Header has the form show in.
Field settings for the Redirect Heady include:
- Type ¾ 4
- Length ¾ The length of the option in units of 8 octets.
- Reserved ¾ Unused field and initialized to zero by the sender and ignored by the receiver
- IP header + data ¾ The original packet truncated to ensure that the size of the redirect message does not exceed 576 octets.
Redirect message validation
For a host to accept a Redirect message it must satisfy all of the checks in the following list. A host must silently discard any Redirect message that does not pass the validity check.
- IP Source Address is a link-local address. hosts can uniquely identify routers when Routers use their link-local address as the source for Router Advertisement and Redirect messages.
- The IP Hop Limit field has a value of 255. This means that the packet was not forwarded by a router.
- Correct authentication if the message includes an IP Authentication Header
- The ICMP Checksum is valid.
- The ICMP Code is 0.
- The ICMP length derived from the IP length is 40 or more octets.
- The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address.
- The ICMP Destination Address field in the redirect message does not contain a multicast address.
- The ICMP Target Address is one of the following:
- A link-local address when redirected to a router
- The same as the ICMP Destination Address when redirected to the on-link destination.
- All included options have a length that is greater than zero.
A redirect that passes the validity checks is called a valid redirect.
Overview of the IP the routing process
Routing is a method of switching data from one point on a network to a point on another network. It is the main process used by Internet hosts to deliver packets to the target machine. Each intermediary router passes along the message to the next router.
Routing requires a unique identification for each destination, usually the specific network number and host number. Routing assumes that the address has at least partial information about the location of a host. This means routers can forward data without having to broadcast and without having a complete list of all the possible destinations for the data. Part of this process involves analyzing a routing table to determine the best path.
IPv6 is causing changes to the requirements for devices and more specifically the protocols that perform routing. The Internet community usually refers to devices that perform the forwarding function if the Internet protocol suite as routers or IP routers. The OSI community usually refers to these devices as intermediate systems. Such devices are also sometimes referred to as gateways but use of this term should be avoided to prevent confusion with application gateways.
IP routing
IP routing involves the examination of the IP protocol header as part of the switching process. The ability to forward packets is a major difference between Internet hosts and routers. Routers use forwarding algorithms of one form or another, while Internet hosts do not require forwarding capabilities.
From a simplistic view, the Internet routing systems consists of two components: interior routing and exterior routing. The concept of an Autonomous System (AS plays a key role in separating interior from an exterior routing. Routing protocols form the heart of the Internet.
Autonomous Systems
An Autonomous System (AS) is a collection of subnetworks with hosts attached and interconnected by a set of routes inside a domain that is under common technical management. Put another way, an Autonomous System as a collection of CIDR IP address prefixes under common technical management. An AS is expected to presents a consistent picture to other ASs of which networks are reachable through the AS
An AS uses interior routing protocols such as Routing Information Protocol (RIP) and Open Shortest Path First protocol (OSPF) for routing within the AS. Exterior routing protocols such as the Border Gateway Protocol (BGP) provide inter-AS routing so that an AS can reach other autonomous systems in the internet.
An AS is identified by an Autonomous System number. The Internet Assigned Numbers Authority assigns AS numbers in the range of 1 through 65534. BGP uses the AS number to implement policy routing and avoid top-level routing loops. Each autonomous system that a route passes through prepends it's AS number to the beginning of the AS path. The AS path list the autonomous systems that the routing information passed through to get to a particular router.
Autonomous systems fall into three distinct types as shown in.
Routing protocols
Routing protocols form the heart of the Internet. Network engineers assign costs to network paths. Routing protocols select the least-cost path to the destination. Routing protocols fall into four categories. There are:
- Distance-vector routing protocols
- Link state routing protocols
- Interior routing protocols
- Exterior routing protocols
Distance-vector routing protocols
In distance-vector routing each router informs its neighbor about its routing table. To establish the network path, the receiving router chooses the neighbor that advertises the lowest cost. The receiving router then adds the path to its neighbor into its routing table for re-advertisement. The Hello and Routing Information Protocol (RIP) are examples of distance-vector routing protocols. The Interdomain Routing Protocol (IDRP) is an OSI-based distance-vector routing protocol that defines the path for packets sent through the network.
Link-state routing protocols
In link-state routing each router maintains a partial map of the network. If a network link comes up or goes down, link state protocols flood a notification of this change of state throughout the network. All routers note the change and recompute the routes in their routing table. Link-state routing is more reliable and easier to debug than distance-vector routing. However, link-state routing is more complex and more compute and memory-intensive. The Open Shortest Path First Protocol is an example of a link-state routing protocol.
Interior routing protocols
Interior protocols exchange reachability information within an autonomous system (AS) and are usually referred to as interior gateway protocols. Most common routing protocols, such as Hello, RIP, and OSPF, are interior routing protocols. The basic routable element is the IP network or subnetwork, or CIDR prefix for newer protocols.
Exterior routing protocols
Exterior routing occurs between autonomous systems. Exterior routing is mostly used by service providers and large or complex networks. The basic routable element is the Autonomous System, a collection of CIDR prefixes identified by an Autonomous System number.
There can be may different interior routing protocols in use but a single exterior routing protocol manages the global Internet. Exterior routing protocols are usually referred to as exterior gateway protocols. The Border Gateway Protocol (BGP-4) is that exterior routing protocol. IDRP is currently adapted to support exchange of inter-domain system routing information among routers that support the forwarding of IPv6 packets.
Routing protocol metrics
The metric is one of the units a routing protocol uses to help a system determine the best route. Metrics can be based on hop count, routing delay, or an arbitrary value set by the system manager depending on the type of routing protocol in use. Routing metrics can influence the value of assigned internal preferences.
shows the range of possible values for each routing protocol metric and the value used by each protocol to reach a destination. If a metric equals the value shown in in the unreachable column, the router can not route the packet to the destination node using the specified routing protocol.
Routing protocols for IPv6
IPv6 is causing changes to the requirements for devices and more specifically the protocols that perform routing.
Routing protocols define the mechanism for building routing tables, uniquely identifying routing packets, and the rules for switching data from one point on a network to another. The routing protocols described here include IDRP, RIPng, and OSPF.
Interdomain Routing Protocol
The Interdomain Routing Protocol (IDRP) is an Open Systems Interconnection (OSI) based routing protocol and is documented in International Organization for Standardization (ISO) 10747. IDRP was developed to support forwarding of Connectionless Network Protocol (CLNP) packets between routing domains. IDRP is based on BGP which is a TCP/IP based interdomain or exterior routing protocol. IDRP uses a number of different terms that you should be aware of, including the following:
- Routing domain (RD) ¾ Consists of a group of intermediate and end systems that share a common routing plan and operate under the same set of rules
- Routing domain identifier (RDI) ¾ A unique RD identifier.
- Border intermediate system (BIS) ¾ Consists of an intermediate system that uses IDRP and participates in interdomain routing.
- Routing information base (RIB) ¾ The routing database used by IDRP. Each BIS builds its routing information database from information communicated within the particular routing domain (RD) and from information obtained from other border intermediate systems. The information in the RIB consists of the set of routes chosen for use by a particular BIS.
- Confederation ¾ Consists of a group of RDs that appears to RDs outside the confederation as a single RD. RDs outside the confederation can not determine the topology of the confederation. Confederations can be nested within one another and can act as a firewall. As such, confederations can help reduce network traffic
A sequence of routing domain identifiers (RDIs) makes up an IDRP route just as a sequence of AS numbers makes up an AS path. It is quite possible for some or all of the RDIs in an IDRP route to be confederations.
Configure a BIS to know about the RD and confederation to which it belongs. The BIS exchanges information with its neighbors to acquire information about other border intermediate systems, routing domains, and confederations on the internet. If a route satisfies the local policies of a BIS and the BIS selects that route for use, then the BIS can pass the information for that route onto other BIS systems. IDRP updates a route when a neighbor goes down, a neighbor comes up, or a BIS receives a new route.
IDRP provides for systems that use Classless Inter-Domain Routing (CIDR) addressing and supports policy-based routing. This means IDRP provides the ability to control transits traffic. IDRP also includes support for the following:
- Tracking of all RDs transversed by a route
- Compression of RD path information and use of confederations to reduce route information and processing
Use of a reliable built-in transport and the capability to carry reachability and forwarding information associated with multiple network protocols such as IPv6, and IPv4 protocols.
- Provision for cryptographic signatures on a per-packet basis to provide security
- Use of routing domain confederations to provide enhanced scaling capabilities. This allows IDRP to express topology and policy information in terms of aggregates rather than individual domains.
IDRP and BGP router connectivity
Current exterior routing protocols such as BGP-4 and IDRP require all BGP and IDRP routers to have connectivity with each other to exchange routing information acquired from other routing domains. This is true for BGP/IDRP routers that belong to the same routing domain and take part in inter-domain routing. If the routing domain is large, each border route would need to maintain a substantial number of connections
Additionally, if border router in other domains are reachable through shared communication media it could be useful for a border router to establish and maintain routing sessions with those border routers. Routers that are directly reachable through a shared media are referred to as adjacent router. Direct peering with these routers allows a router to acquire information about destinations that are directly reachable through the adjacent border router.
This arrangement can work well in may instances, however, there can be problems with a switched media such as an ATM, SMDS, or Frame Relay network which can inter-connect a large number of routers. The number of connections required to maintain this type of direct peering between the routers could be very large and therefore impractical.
IDRP/BGP route servers
To solve the problem of maintain a large number of direct peering connections, D. Haskin in RFC 1863, proposes the use of IDRP/BGP Route Servers. This type of server would be used to relay external routes between client routers. The servers would relay these external routes with all of their attributes.
A client router would maintain IDRP/BGP sessions only with the assigned route servers. The router server would propagate all routes received from a client router to other client routers. The client routers would receive the same information as if they were participating in direct peering will all adjacent routers. Referred to as virtual peering, this type of arrangement allows client routers to independently apply their own criteria to these external routes according to their own local policies.
Routing Information Protocol
The Routing Information Protocol (RIP) is a distance vector, interior gateway protocol. RIP uses the Bellman/Ford algorithm to compute which path offers the fewest number of intermediate hops. Updated in RFC 2080 for IPv6, RIP was originally designed for Xerox and used in the Xerox Network Systems (XNS) protocol suite.
RIP has been associated with TCP/IP since 1982. RFC 1058, "Routing Information Protocol", June 1988 was the formal definition of this protocol for the Internet while RFC 1723, "RIP Version 2 - Carrying Additional Information", November 1994, added routing capabilities to this popular protocol.
This protocol does not solve all routing problems and if you implement RIP, note the following:
- Rip is limited to networks of a moderate size whose longest path is 15 hops. The reference to networks of moderate size assumes a cost of 1 for each network. If a network administrator assigns larger costs when configuring networks, the upper bound of 15 hops can easily become a problem.
- RIP depends on a process referred to as "counting to infinity" to resolve some infrequent situations such as the formation of a routing loop involving all the networks in a system of networks. Resolving the routing loop could consume a great deal of time and bandwidth.
- RIP uses fixed metrics to compare alternative routes. This can present difficulties in situations where routers need to be chosen based on parameters such as load, measured delay, or reliability.
RIPng for IPv6 protocol specification
RIPng for IPv6 (RFC 2080) allows routers to exchange information for computing routes through an IPv6-based network. network administrators should implement RIPng only in routers with one or more interfaces to one or more network. The IPv6 protocol suite includes "Neighbor Discovery for IP Version 6 (IPv6)" (RFC 1970) as mechanism for router discovery.
RIPng, like earlier versions of the protocol uses a hop as a metric where the maximum path limit is 15. In addition, each network should have an IPv6 destination address prefix and prefix length associated with it. The network administrator sets the hop metric and destination address prefix and length.
Routing table format
Routers in a RIP network share their routing tables. Each router broadcasts its routing table to all other router at set intervals. This generates a fair amount of traffic but each router ends up with a model of the network. The routers use the model to figure out the shortest route to use to send a particular packet to its destination.
Each router that implements RIPng is assumed to have a routing table. Each entry contains at least the following types of information:
- Destination ¾ The IPv6 prefix of the destination
- Metric ¾ A metric representing the total cost of getting a datagram from the router to the specified destination. This metric is the sum of the costs associated with the networks that would be traversed to get to the destination.
- Next router address ¾ The IPv6 address of the next router or hop on the path to the destination.
- Route change flag ¾ A flag indicating that information about the route has changed recently
- Timers ¾ Assorted timers associated with the router such as timers used to signal the sending of the complete routing table to every neighboring router.
The metric for a directly-connected network (usually 1) is set to the cost of that network. In some case, depending on the implementation of RIPng, the network administrator can enter static routes for networks outside the scope of the routing system.
RIP maintains only the best route to a destination. When new information provides a better route, this information replaces old route information. When implement RIPng, every router in the AS needs to participate in the protocol in order to receive complete routing information. Some ASs have multiple interior routing protocols in use. In this case, there needs to be at least one router that can provide routing information between the protocols.
RIP packet format
RIPng is UDP-based protocol and uses port 521 to send and receive datagrams. All communications intended for another router's RIPng process are sent to this RIPng port. All communications intended for another router's RIPng process are sent to the RIPng port. Specific queries can be sent from ports other than the RIPng port, but they must be directed to the RIPng port on the target machine.
shows the RIPng packet format and the routing table entry format that is a part of RIPng packet. The RIPng packet fields usually contain binary integers, in network byte order, with the most-significant octet first (big-endian).
When RIP-based router starts, it issues a REQUEST for routing information and then listens for responses to the request. If a system configured to supply RIP hears the request, it replies with a RESPONSE packet based on information in its routing table (its database). The RESPONSE packet contains destination network addresses and the routing metric for each destination. When the router receives a RIP RESPONSE packet, it uses the information to:
- Rebuild its routing table by adding new routes and better (lower metric) routes to destinations already listed in the routing table.
- Delete routes from the routing table if the next router to that destination says the:
- Route contains more than 15 hops
- Route is deleted
Each RIPng message contains a header with a command and version field containing the RIPng version number in use. The command field identifies the purpose of the message. This field is set to 1 if the message is a request for the responding system to send all or part of its routing table. This field is set to 2 if the message is a response containing all or part of the sender's routing table. A router can send this message in response to a request. A router can also send this message is response to an unsolicited routing update generated by the sender.
The rest of the packet lists the routing table entries (RTEs) as shown. Each entry contains:
- A destination prefix field. The destination prefix is a 128-bit, IPv6 address prefix. This prefix is stored as 16 octets in network byte order.
- A route tag field. A route tag provides a way to separate internal RIPng routes from RIPng route external to the RIPng routing domain that may have been imported from an external routing protocol or from another internal routing protocol.
- Prefix length field. The prefix length field is represented as a value between 0 and 128 inclusive. This field is the length in bits of the significant part of the prefix starting from the left of the prefix.
- A metric field. The metric field contains a value between 1 and 15 inclusive, that indicates the hop count to reach the destination. A value of 16 in this field indicates that destination is not reachable.
The maximum transmission unit size of the media over which the packet travels determines the maximum datagram size. The number of routing table entries permissible depends on the MTU of the media and the size of: the header preceding the RIPng message, the RIPng header, and the routing table entry. Use the formula shown in.
RIPng timers
Like other routing protocols, RIPng uses certain timers to regulate its performance. RIPng broadcasts a routing update message to its neighbors every 30 seconds even if no changes have occurred in the routing environment. Routers tend to synchronize with each other when there are a number of routes on a single network. Synchronized update messages can lead to collisions on broadcast networks. To avoid this possibility, RIPng implementations must take one of two following precautions:
- Set the 30-second updates to be controlled by a clock whose rate is not affected by system load or the time required to service the previous update timer.
- Offset the 30-second timer by a small random time (+/- 0 to 15 seconds) each time it is set. The offset is derived from: 0.5 * the update period; for example 30.
RIPng has a Timeout timer associated with each route. This timer initializes when ever a route is established or an update message for the route is received. When the Timeout timer expires, the route is no longer valid.
At this point a second timer, the garbage-collection timer, is set for 120 seconds and the metric for the route is set to 16 which removes the route from service. However, the invalid route stays in the routing table for a period of time so that neighbors can be informed that the route has been dropped. The expiration of garbage-collection timer triggers the actual removal of the route from the routing table.
Another timer limits the frequency of triggered updates. This timer is set to a random interval of 1 to 5 seconds. Triggered updates may be suppressed if a regular update is due by the time the triggered update would be sent.
Split horizons
RIPng uses the split horizons algorithm to avoid problems caused by including routes in updates sent to the gateway from which they were learned. Basically, this means that the algorithm omits routes learned from a neighbor from any updates sent to that neighbor. In, an example of split horizons, Router A advertises that it has a route to Network 1. Because Router A is closer to Network 1, Router B does not need to include this route in its update back to Router A. If the network is a broadcast network, the algorithm omits all routes learned from any neighbor on that network from updates sent on that network.
The split-horizon rule helps prevent two-node routing loops. For example, the interface to Network 1 from Router A fails. Without split horizons, Router B tells Router A that it can still get to Network 1 through Router A. In this case, depending on the intelligence of Router A, Router A might use Router B’s route to Network 1 as an alternate. This would cause a routing loop.
Split Horizon with Poisoned Reverse is intended to prevent large routing loops. Increases in routing metrics generally indicate routing loops. RIPng includes looping routes in updates but sets their metrics to infinity. Other routers interpret this to mean that those routes are not reachable. Poison reverse updates are then sent to remove the route. The RIPng protocol states that Implementations should provide a per-interface control allowing no horizoning, split horizoning, and poisoned reverse to be selected.
RIPng security
RIPng runs over IPv6 and therefor relies on the IP security features of IPv6. These include the IP Authentication Header and the IP Encapsulating Security Payload to ensure integrity and authentication/confidentiality of routing exchanges.
Administrative controls
While they are not part of the RIPng protocol, the protocol strongly recommends implementing at least some of the administrative controls described in the protocol. These controls are intended primarily to allow RIPng to be connected to networks whose routing may be unstable or subject to errors.
Some typical administrative controls you might want to consider include:
- Restricting which routers will accept or send updates. You might want to do this if a networks routing was unstable or for administrative routing policy reasons.
- Implementing a neighbor list that allows you to define a list of neighbors for each router. In this case, a given router would accept response messages only from routers on its list of neighbors.
- Implementing a list similar to a neighbor list for target routers. By default, the protocol defines no restrictions.
- Implementing a filter for specific destinations. This would allow you to specify a list of destination prefixes to allow or disallow. You would associate this list with a particular interface in the incoming direction, the outgoing direction, or both. If you specify a list of allowed prefixes, all other prefixes are disallowed. If you specify a list of disallowed prefixes, all other prefixes are allowed. By default, RIPng applies no filters.
RIPng limitations
RIPng has changed little in the past decade and suffers from several limitations. These limitations include:
- Restricted network size. The protocol uses a 4-bit metric to count router hops to a destination. A RIP network can accommodate a maximum of 15 hops. (16 is infinity). A high hop count on a slow or less reliable link can quickly become a problem.
- Limited subnet support. RIP was deployed prior to subnetting and has no direct support for it. It can be used in subnetted environments, subject to restrictions. RIP does not provide subnet mask information in its routing table update, so all routers on a network must have the same mask.
- Long convergence time. Convergence can cause a number of problems because routers are apt to keep information longer than they should. Convergence is the time it takes for a change to the routing topology to propagate throughout the network. In a RIP environment, the worst case is seven and one half minutes while the average is three minutes.
- High aging time. Aging in a RIPng environment can cause problems because the protocol allows a router to be down for more than two minutes seconds before it considers the router dead.
- Diagnostic problems. Distance vector protocols such as RIPng can be difficult to debug. A distance vector protocol distributes the routing algorithm over many different routers. In the past, many reported RIP problems could be traced to incorrect configuration and inadequate diagnosis.
- Potential high bandwidth use. RIPng routers broadcast their list of networks and subnets they can reach every 30 seconds. If the network is large, these lists are long and bandwidth usage can become prohibitive on slow links.
RIPng benefits
RIPng has some benefits. It is in widespread use, the only interior gateway protocol that can be counted on to really run everywhere. Configuring a RIP system requires little effort, beyond setting path costs. Finally, RIPng uses an algorithm that does not impose serious computation or storage requirements on hosts or routers.
Open Shortest Path First protocol for IPv6
The Open Shortest Path First protocol is a link state, interior gateway protocol. This means that the protocol distributes routing information between routers belonging to a single Autonomous System. Updated in RFC 2178, OSPF was originally published in RFC 1247. This protocol was developed by the interior gateway protocol (IGP) working group of the Internet Engineering Task Force (IETF) and is based on Bolt, Beranek, and Newman's (BBN's) shortest path first (SPF) algorithm. This algorithm is sometimes referred to as the Dijkstra algorithm which is the name of the person credited with its creation. The OSPF technology is a departure from the Bellman-Ford base used by traditional TCP/IP internet routing protocols.
OSPF was created to serve large heterogeneous internetworks and includes explicit support for CIDR and the tagging of externally-derived routing information. Each OSPF router maintains an identical database describing the Autonomous System's topology. OSPF also uses IP multicast to send and receive updates and quickly recalculates routes in the face of topological changes.
In addition, the protocol authenticates all OSPF routing protocol exchanges. This means that only trusted routers can participate in the Autonomous System's routing. OSPF allows the use numerous authentication schemes and it is possible to configure each IP subnet with a different authentication scheme.
OSPF protocol specification
As a link state protocol, OSPF sends link state advertisements (LSAs) to all routers in the same hierarchical area. The protocol floods each link state advertisement throughout the routing domain. The collected link state advertisements of all routers and networks forms the protocol's topological database.
This contrasts with distance vector protocols such as RIP that send all or a portion of their routing table in messages only to their neighbors. OSPF views the network as a collection of links between nodes and routes packets based on the destination IP address and IP Type of Service (TOS) specified in the packet header.
Each router maintains an identical link-state database that contains information about the router's usable interfaces and reachable neighbors. A router floods its local state information throughout the Autonomous System. If there is more than one route to a destination and those routes have an equal cost, OSPF discovers and uses the available routes. With this equal cost multipath, a router potentially has several available next hops towards any given destination.
Each area runs a separate copy of the basic OSPF algorithm. The OSPF algorithm is the basis for OSFP operations. The OSPF algorithm:
- Views the network as a collection of links between nodes
- Must know the up or down state of all network links
- Allows for variable metrics on each link
- Computes best path for all trips.
The shortest-path tree
If there are no configured OSPF areas, each router in the Autonomous System has an identical link-state database. All routers run the same algorithm and construct a shortest-path tree containing the route to each router within the AS with itself as root. The tree contains the entire path to any destination network or host. However, the OSPF protocol uses only the next hop to the destination in the forwarding process.
External routing information
Routing information derived from an external source, such as routes to networks belonging to other Autonomous Systems, appears on the tree as leaves. OSPF keeps this externally derived data separate from the protocol's link state data. This type of routing information is flooded unaltered throughout the AS and can originate from other routing protocols, static routes, or default routes.
OSPF supports two types of external metrics. Type 1 external metrics are equivalent to link state metrics. Type 2 external metrics represent a cost that is greater than the cost associated with any path within the AS.
Areas
An area is a generalization of an IP subnetted network and consist of a group of contiguous networks and attached hosts. To reduce network traffic, networks can be grouped together into an areas where the topology of an area is hidden from the rest of the AS. The topology of a area determines routing within that area. Routers within an area do not know about the topology of external to the area. This can help protect the area from bad routing data.
Each area runs a separate copy of the basic link-state routing algorithm and therefor has its own link-state database. Routers with multiple interfaces can participate in multiple areas. Routers connected to multiple areas have a database for each area. Such a router is referred to as an area border router.
Area partitioning creates two different types of OSPF routing within an AS that implements OSPF; intra-area routing and inter-area routing.
- The first, intra-area routing exists when the source and destination of a packet reside in the same area. The protocol routes the packet using information obtained only within the area. The protocol specifies that no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information.
- The second, inter-area routing exists when the source and destination of a packet reside in different areas.
The OSPF backbone
The OSPF backbone distributes routing information between areas. The OSPF backbone is the special OSPF Area 0. Because OSPF Area ID's are typically formatted as IP addresses, this backbone is often written as Area
The backbone consists of consists of all area border routers and networks not wholly contained in any area and their attached routers (). The backbone assumes the responsibility for distributing routing information between non-backbone areas.
Using as an example, lets assume that a host in area 2 sends a packet to router G destined for a host in area 3 configured to use router M. In this case router G forwards that packet through routers I and J. Router J forwards the packet over the backbone to the area border router K. This router then sends the packet through intra-area routers L and M and on to the specified destination host.
The topology of the backbone dictates the backbone paths used between areas. It is possible to define Areas in such a way that the backbone is not contiguous. The topology of the backbone can be enhanced by adding virtual links.
A system administrator can configure virtual links between any two backbone routers that have an interface to a common non-backbone area. The routing protocol traffic that flows along these virtual links uses intra-area routing only. Adding virtual links to the topology of the backbone gives the system administrator some control over the routes taken by inter-area traffic.
Classification of routers
Previously, the only OSPF routers that had a specialized function consisted of routers that advertises external routing information. When OSPF areas exist, four types of routers provide the routing information and are classified by function as shown in.
The protocol uses the following process to determine the correct area border router to use as the packet exits the source area.
- Causes each area border router in an area to summarize for the area its cost to all networks external to the area.
- Calculates the shortest path first tree for the area
- Calculates the routes to all inter-area destinations by examining the summaries of the area border routers.
OSPF packet types
There are five different OSPF packet types. All these packet types begin with a common 24 byte header as shown in. In addition, all the OSPF packet types except the OSPF Hello packet, deal with lists of link state advertisements (LSAs).
The Version Number field contains the OSPF protocol version number; for example, version 2. And the Type field list the packet type as shown in.
The Packet length field lists the protocol packet length in bytes. The Router ID field contains the Router ID of the packet's source while the Area ID field contains a 32 bit number identifying the area to which the packet belongs. Packets traveling over a virtual have the backbone Area ID of 0.0.0.0.
The Checksum field contains the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field. And the AuType field identifies the authentication procedure to be used for the packet as shown in.
The five OSPF packet types include the Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets.
- Hello packets are OSPF packet type 1. To establish neighbor relationships, the protocol sends OSPF Hello packets from time-to-time to all interfaces. The protocol also multicasts Hello packets on physical networks that have a multicast or broadcast capability.
- Database Description packets are OSPF packet type 2, these packets describe the contents of the link-state database. The protocol exchanges these packets when an adjacency is being initialized.
- Link State Request packets are OSPF packet type 3. After a router exchanges Database Description packets with a neighboring router, the router could discover that parts of its link-state database were out-of-date. The protocol uses these Link State Request packets to request pieces of the neighbor's database that are more current.
- Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. The protocol multicast Link State Update packets on physical networks that have a multicast or broadcast capability.
- Link State Acknowledgment Packets are OSPF packet type 5. The protocol uses Link State acknowledgment packets to acknowledge flooded LSAs. Doing so makes the Link State Update flooding procedure reliable. The protocol sends a Link State Acknowledgment packet either to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast.
Link state advertisement types
Each LSA in a link state update packet contains a type field. There are four LSA types: router link advertisements, Network link advertisements, Summary link advertisements, and AS external links advertisements
Router link advertisements describe the collected states of the router's links to a specific area. A router sends an RLA for each area to which it belongs. The protocol floods Router-LSAs throughout the entire area. However, the RLA goes no further than the particular area. The Router-LSA describes the router's working interfaces or links to the area. Each link has a Link ID that names the entity that is on the other end of the link. In addition, the link is typed according to the kind of attached network as summarized in.
Network link advertisements describe all the routers that are attached to a multiaccess network. The designated router for the network generated the network link advertisement for every transit broadcast network. (A transit network has two or more attached routers.) The protocol floods the Network-LSA throughout the area that contains the transit network, and no further.
Summary links advertisements describes the route to either an IP network, an AS boundary router, or a range of IP addresses. The destination is always external to the area but still is part of the AS. Area border routers generate the Summary-LSA which the protocol then floods throughout a single area.
By default, if a system administrator does no include a network any explicitly configured address range, the protocol generates a Type 3 summary-LSA. This Summary-LSA has a link state ID equal to the network's address and a metric equal to the network's routing table cost.
AS external links advertisements describe routes to a destination external to the AS. If the AS-external-LSA defines a route to a specific destination, the protocol set the link state ID to the destination network's IP address. The AS external-LSA could describe a default route for the AS by setting the link state ID to the destination 0.0.0.0. AS boundary routers originate this type of LSA. The AS external-LSA is the only type of LSA that is forwarded everywhere in the AS.
Some OSPF enhancements for IPv6
Some changes have been made to the OSPF protocol to support IPv6 and enhance performance. The following paragraphs summarized a few of these changes.
The Cryptographic authentication type has been added to the list of OSPF authentication types. The Cryptographic authentication type allows for the use of any arbitrary Keyed Message Digest algorithm for packet authentication.
The addition of Point-to-Multipoint interface adds an additional method for running OSPF over non-broadcast networks. The term non-broadcast networks describes networks that can connect many routers but do not native support for broadcast or multicast. An example of such a network would be a public Frame relay network).
The current version of the OSPF protocol removes the TOS routing option from the protocol. This occurred primarily due to lack of implementation experience with OSPF's TOS routing.
RFC 2178 provides support for overlapping area ranges and introduces a modification of the flooding algorithm to improve MaxAge processing. And protocol processing can occur on a per-link basis rather than on a per-subnet basis. It is possible with IPv6 to assign multiple subnets to a single link.
OSPF limitations
The OSPF algorithm is CPU intensive. For example, each node maintains a complete copy of the link state database. In addition, each node only runs the algorithm for routes originating at that node.
All nodes must agree on link states. One node in a subnet acts as a coordinator and is called the designated router; there is also a backup router. Each router maintains a copy of the link state database. When a new node comes on line, it receives a copy of the link state database from both the designated router and the backup router. When something changes, the designated router sends out updates.
Lots of data needs to be exchanged. The protocol acknowledges all messages at all times. This includes the different message types shown in.
From here …
This chapter briefly describe the Internet Group Management Protocol and Neighbor Discovery messages as they apply to IPv6. It also discussed the impact of IPv6 on the RFC routing including IDRP for IPv4 and IPv6, the RIPng for IPv6, and OSPF Protocol for IPv6. For additional information, you may want to see the following:
- Chapter 9, "IPv6 Performance" that introduces and discusses performance issues for IPv6.
- Chapters 10, "Transmitting IPv6 Packets Over the Ethernet" that describes using IPv6 with Ethernet network implementations.
- Chapter 11, "ICMPv6 and IPv6"
- Chapter 14, "IPv6 Autoconfiguration" that introduces the IPv6 autoconfiguration capabilities and describes when to use this capability.
No comments:
Post a Comment