Basic Services

IP isn't really useful without a number of other protocols, such as ICMP and the many flavors of ARP and address assignment. Just studying IP doesn't give you everything you need to know.

Mapping to Sub-IP Addresses

Both ARP and Proxy ARP are motivated by a desire for efficiency. While nodes, at least those on the same subnet, could communicate simply by sending Layer 2 broadcasts, every node would hear and have to process the broadcast for every data packet sent.

Table 20. IP-to-Sub-IP Mapping Mechanisms

[1]Think of the lighted button on a multiline phone. This is usually a physical identifier telling you which specific telephone interface is active.

[2]There is a triple address mapping here, first from IP to the emulated MAC address and second from the emulated MAC address to a VPI/VCI going to the LAN Emulation client (LEC) serving the destination. The LEC does the final mapping to the destination MAC.

Address Resolution Protocol (ARP)

ARP allows you to broadcast only once to find the MAC address of another node on your subnet. Once you know that and store the information in your local ARP table, you can unicast to that node.

ARP tables periodically expire and refresh, for several reasons. First, the ARP table is of limited size and it can become filled up with stale entries. Second, what if the NIC changes on another node, changing the MAC address associated with the IP address? What if a DHCP lease expires and the host is inactive for a time and then acquires a new address?

Some of the original host implementations of ARP taught us about broadcast storms. When all the hosts were time-synchronized and sent out an ARP according to the same timer value, the network became congested from all the ARP requests. Since the default behavior of ARP is to retransmit if it gets no response, the responses lost by congestion caused even worse congestion. Competent ARP implementations now randomize the timeout on their ARP tables.

IPv6 provides a mechanism for changing Link Layer addresses on demand rather than waiting for timeouts: sending Neighbor Advertisements to all nodes. These advertisements contain the new Link Layer address.

Proxy ARP

When Proxy ARP is enabled, a router will respond to an ARP request with its own MAC address, if the requested IP address in the ARP request has a prefix that is present in its routing table. Unfortunately, the router has knowledge only of the prefix, not of hosts on it, so it may answer for a dead (but obviously not forgotten) host. Other mechanisms, such as TCP timeouts, will usually tell the originating host that the destination is down, but there is apt to be needless retransmission traffic before this is discovered.

Proxy ARP is needed when the hosts are not terribly bright: they cannot be configured with a default gateway, nor do they understand routing. You will need Proxy ARP if you are using the Cisco Local Area Mobility (LAM) feature.

In addition to the black hole problem, Proxy ARP has other disadvantages. There will be more ARP traffic on the subnet, and the ARP tables will have to be larger to contain references to off-subnet hosts.

The ARP tables are configured on a per-interface basis:

interface e0/0
ip proxy-arp

While Proxy ARP is not a true feature of IPv6, it is possible for a router to issue non-override Neighbor Advertisements on behalf of the host and achieve a similar effect.

Inverse ARP

Inverse ARP is a means of discovering your interface address on an NBMA medium such as Frame Relay. Frame Relay and ATM, loosely speaking, are Layer 2 protocols, but they have an end-to-end property more like that seen at higher levels.

Inverse ARP is really a means of learning IP addresses rather than MAC addresses. It could equally well have been discussed in the section on dynamically acquiring IP addresses, but it fits better into the discussion of ARP alternatives.

Since Frame Relay is non-broadcast, you can't use a broadcast ARP to map between an IP address and a Frame Relay DLCI. The Inverse ARP protocol [RFC 2390] is one way to do this. Another way is to use static mapping statements, but these become difficult to maintain in large networks.

When a Frame Relay interface or subinterface initializes, it checks the local management interface to determine which PVCs are up. It then sends an Inverse ARP request over every active PVC, and will receive the corresponding IP address if Inverse ARP is enabled at the other end.

Whenever a new PVC comes up, the interface should send it a new Inverse ARP. For Frame Relay, the Inverse ARP requests contain:

Table 21. Fields in Inverse ARP

You configure this on a subinterface, or on a Frame Relay physical interface without subnetting, with:

interface s0/0
encapsulation frame-relay
interface s0/0.1
ip address sender's-IP sender's-mask
frame-relay interface-dlci sender's-DLCI

ICMP

For all practical purposes, ICMP is part of every IP implementation. It is the set of mechanisms that IP uses to signal errors or to send information to other IP speakers, both routers and end hosts. As opposed to ARP, it does have scope beyond a single subnet, although in practice some ICMP messages are of link-local scope. ICMP packets follow IP packets, with a common header (Figure 24) and variable additional information [RFC 0792, updated by RFC 0950]. The Type field indicates the ICMP message type and thus the format of the rest of the message. The Code field contains supplemental information on why the ICMP message was issued.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 24. ICMPv4 Header

Table 22 lists the currently defined ICMP codes. Once a code is assigned, it is never reassigned, so there are many obsolete or experimental codes. Those highlighted are the ones you are likely to see.

Table 22. ICMPv4 Codes

[1]ICMP Router Discovery Protocol.

ICMP, Ping, and Traceroute

Your basic tools for active connectivity checking are ping and traceroute. Think of ping as an end-to-end test. It's not quite a Transport Layer test because it doesn't consider transport identifiers, but it is end-to-end as long as there are no tunnels, proxies, or address translators in the path.

ping sends out an echo request and expects to receive an echo reply. Most implementations send several consecutive pings and time each one. Cisco supports an extended ping, which allows you to vary IP parameters (e.g., packet length) and to test non-IP protocols such as IPX.

traceroute is hop-by-hop at the Network Layer. It uses different protocol mechanisms than ping, and relies on the TTL mechanism. traceroute information complements that given to you by ping. As with ping, Cisco supports an extended IP traceroute in which you can vary IP parameters.

traceroute generates UDP datagrams and encapsulates them in IP packets. The UDP packets don't have a predefined port, but Cisco starts with a number in the 33000 range. Cisco increments the port number on successive transmissions.

traceroute, in its first iteration, sets the TTL to 1, and the packet, as it should, triggers an ICMP TTL Exceeded message to be returned from routers one hop away. Cisco sends three such packets on each pass.

On the second iteration, traceroute sets the TTL to 2, and routers two hops away generate the ICMP response. In successive iterations, the TTL continues to be incremented until either the destination is reached or a hop count limit is reached.

traceroute may fail due to access lists rather than lack of connectivity. Access lists that cause it to fail include deny rules for high-numbered UDP ports. ping and traceroute both can fail because outbound ICMP is being denied. If inbound ICMP is denied, ping might fail but traceroute may work.

Destination Unreachable

When a Cisco router receives a packet with a destination for which it has no matching route table entry, it drops the packet and returns an ICMP Host Unreachable message to the source address.

If a host, or a router that is the destination address for a packet, receives a packet with an unknown protocol ID or port number, it sends "unreachable" with the appropriate type code.

Table 23. ICMP Unreachable Codes

[1]Or router, when it is the endpoint.

Denial of service attacks may try to overwhelm your router with bogus packets. While under attack, you may want to disable or rate-limit unreachable messages:

interface e0/0
[no] ip unreachables

or

interface e0/0
ip icmp rate-limit unreachable [df] milliseconds

Security Considerations in Destination Unreachable and Destination Administratively Prohibited

The most obvious special case is that the destination is not found in the FIB and there is no default route. In this case, the router creates an ICMP Destination Unreachable message and returns this to the originating host. The source address of this ICMP packet is that of the router interface that received it, and the destination address is that of the originator of the packet that could not be forwarded.

If a packet fails a filtering test, the default action prescribed in [RFC 1812] is to return an Internet Control Message Protocol (ICMP) Destination Administratively Prohibited message. This can be questioned both from a security and a performance standpoint, but it is the expected behavior. Figure 25 shows how filtering may be used to prevent this message from returning to the source.

Figure 25. Suppressing Destination Administratively Prohibited Messages

From the security view, returning the Destination Administratively Prohibited error message reveals to a potential attacker that there is something the router administrator has gone to the effort of protecting. This may make things interesting to the attacker, whereas returning a destination unreachable or simply timing out does not reveal the protected resource.

Time to Live Exceeded

During the forwarding process, your router may detect a packet whose time to live (TTL) has expired. I have always liked this condition, as it sounds so much like a line from a movie about the Mob telling the router "Do what ya gotta do." The reasons for sending TTL exceeded are much more mundane.

• Routers send Time to Live Exceeded messages when an outgoing IP header is being constructed and the TTL field is decremented and hits zero. TTL reaching zero is assumed to mean the packet is in an infinite loop.

• Failure to reassemble all fragments after a packet has been fragmented is another reason to receive a Time to Live Exceeded message. This comes from end hosts, not routers, when a fragment reassembly timer expires. The timer is started after any fragment of the packet is received.

Don't fall into the trap of assuming that TTL expiration is always due to loops. Especially in routing protocols, setting the TTL to 1 is a perfectly good way to control the propagation of multicasts, keeping them link-local.

Basic ICMP Redirection

Available path information may cause a host to direct outgoing traffic to some specific router, but the router may know better and want the host to send subsequent traffic to some other router. In practice, this means that if the router realizes it is sending traffic back out the same interface on which it received the packet, it should redirect.

Redirection functions, as seen in Figure 26, allow network relays to send traffic to a different router.

Figure 26. Basic Redirection

That next router is accessible to the sending router because it is on the same medium as defined by the prefix. Since that second router is a better path to the destination than the original receiving router, the first router will send a redirect to the host informing it of the second path.

Note that redirection makes no sense on a point-to-point medium. It is most commonly used on broadcast media, but potentially could be used on nonbroadcast multiaccess media.

Redirection is on by default. If you know that there is no other router on the medium or you otherwise do not want redirection, you must disable it.

interface e0/0
no ip redirects

Until recently, redirection was incompatible with the Cisco Hot Standby Router Protocol (HSRP). Configuring HSRP on an interface still disables IP redirect, although there now is a way to make the two mechanisms work together.

ICMP Redirection with HSRP

In the interaction between standard ICMP and HSRP, the key problem is that ICMP must redirect to the virtual MAC address, not the real one of the currently active HSRP router. If that real address were used, and the HSRP router went down, the redirected packets would go into a black hole.

The HSRP support for the ICMP redirect feature intercepts ICMP redirects originated in a router before they actually leave the router. It examines the new next-hop feature and compares it to a list of active HSRP router real IP addresses. If the feature finds that the proposed next-hop address belongs to a real interface of an HSRP router, it changes the next-hop address to the virtual next hop associated with the HSRP group.

If there is no match, IOS next compares the destination address to the list of remaining routers. It will forward the packet to another router if, and only if, that router is not running HSRP. In other words, it will not redirect to an HSRP-enabled router that is in HSRP standby. For this reason, the most efficient design is one in which every router on the subnet is the active router in at least one HSRP group.

ICMPv6 and Neighbor Discovery

IPv6 has its own version of ICMP, which includes some extremely important new types used for neighbor discovery.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Message Body                          +
      |                                                               |

Figure 27. ICMPv6 Header

Notice that the ICMPv6 header does have a checksum, while the IPv6 header does not. ICMPv6 is Option Type 58.

Table 24. ICMPv6 Message Types

Discovery Mechanisms

IPv6 no longer uses an explicit ARP. Instead, it has a set of five ICMPv6 messages that cover the IPv4 functions of ARP, IRDP, and redirect [RFC 2461]. These mechanisms, generically called discovery, provide a new way to detect if a neighbor on the same subnet is down. This neighbor unreachability mechanism also provides a fast way to learn if a router is down.

Table 25. IPv6 Discovery Messages

Address Resolution in IPv6

IPv6 replaces ARP and certain uses of Echo with the Neighbor Solicitation message. This is multicast to the solicited-node multicast address associated with the target address. It includes the sender's Link Layer address, so the recipient can resolve the IPv6 address of the sender.

The recipient, when present, returns a unicast Neighbor Advertisement that contains its Link Layer address.

Because the Neighbor Solicitation is multicast, it can detect whether multiple nodes have been assigned the same address. In IPv4, this requires pinging the address with echo packets.

Discovery uses only the low-order, link-local part of IPv6 addresses, so site-level renumbering will not affect any current address caches.

Half-Link Handling in IPv6: Neighbor Unreachability Detection

An upper-layer protocol, if it has the necessary interface to IPv6, can start Neighbor Unreachability Detection by hinting to IPv6 that it isn't hearing acknowledgements or other traffic that would suggest a node is up. If IPv6 receives higher-layer confirmation, it doesn't attempt Neighbor Unreachability Detection.

If there are no such hints, the node periodically sends unicast Neighbor Solicitations to all the neighbors to which it is actively sending traffic. Failure to receive the corresponding Neighbor Advertisement indicates a problem. By comparing the unreachability detection of the two nodes, you will quickly find out if one node is dead, if the solicitations are not getting to the target, or if the advertisements are not getting to the originator.

Table 26. Link-Local Control Mechanisms in IPv4 and IPv6

[1]Other than DHCP.

[2]Multiple prefixes can be associated with the same link. By default, hosts learn all on-link prefixes from Router Advertisements. However, routers may be configured to omit some or all prefixes from Router Advertisements. In such cases hosts assume that destinations are off-link and send traffic to routers. A router can then issue redirects as appropriate. Unlike the case for IPv4, the recipient of an IPv6 redirect assumes that the new next hop is on-link. In IPv4, a host ignores redirects specifying a next hop that is not on-link according to the link's network mask. It is expected to be useful on nonbroadcast and shared media links in which it is undesirable or not possible for nodes to know all prefixes for on-link destinations [RFC 2461].

[3]Neighbor Unreachability Detection is part of the base significantly improving the robustness of packet delivery in the presence of failing routers, partially failing or partitioned links, and nodes that change their Link Layer addresses. For instance, mobile nodes can move off-link without losing any connectivity due to stale ARP caches [RFC 2461].

Dynamically Acquiring an IP address for Your Own Machine

BOOTP/DHCP

DHCP is the descendant of BOOTP, which is obsolete. DHCP servers have typically been on hosts, but as of IOS 12.0(1)T, Cisco routers can act as DHCP servers. Check to see if your specific router platform has this capability.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   +-------------------------------+-------------------------------+
   |           secs (2)            |           flags (2)           |
   +-------------------------------+-------------------------------+
   |                          ciaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          yiaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          siaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          giaddr  (4)                          |
   +---------------------------------------------------------------+
   |                                                               |
   |                          chaddr  (16)                         |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   |                          sname   (64)                         |
   +---------------------------------------------------------------+
   |                                                               |
   |                          file    (128)                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                          options (variable)                   |
   +---------------------------------------------------------------+

Figure 28. DHCP Message

What do these fields mean, especially those with rather cryptic names like giaddr?

Table27. DHCP Packet Field Usage

DHCP Protocol Operation

Figure 29 shows the basic timeline of DHCP operation.

                Server          Client          Server
            (not selected)                    (selected)
                  v               v               v
                  |               |               |
                  |     Begins initialization     |
                  |               |               |
                  | _____________/|\____________  |
                  |/DHCPDISCOVER | DHCPDISCOVER  \|
                  |               |               |
              Determines          |          Determines
             configuration        |         configuration
                  |               |               |
                  |\             |  ____________/ |
                  | \________    | /DHCPOFFER     |
                  | DHCPOFFER\   |/               |
                  |           \  |                |
                  |       Collects replies        |
                  |             \|                |
                  |     Selects configuration     |
                  |               |               |
                  | _____________/|\____________  |
                  |/ DHCPREQUEST  |  DHCPREQUEST\ |
                  |               |               |
                  |               |     Commits configuration
                  |               |               |
                  |               | _____________/|
                  |               |/ DHCPACK      |
                  |               |               |
                  |    Initialization complete    |
                  |               |               |
                  .               .               .
                  .               .               .
                  |               |               |
                  |      Graceful shutdown        |
                  |               |               |
                  |               |\ ____________ |
                  |               | DHCPRELEASE  \|
                  |               |               |
                  |               |        Discards lease
                  |               |               |
                  v               v               v

Figure 29. DHCP Operational Timeline

Most DHCP servers support two modes of operation. In the first, more common mode, the address is automatically assigned and has a lease time. In other words, it is a soft-state protocol. It is possible to make this semi-soft by specifying an infinite lease time for certain client IDs.

The other mode of operation, typically used for servers, ensures that a given client ID will always get the same address, either with a very long-term or infinite lease. While such hosts could be manually configured, it's simpler to administer all your servers if you centralize their address assignment onto the DHCP server.

IOS-Based DHCP Servers and Their Capabilities

Router-based DHCP servers may need access to address binding information on another machine, which is retrieved with FTP, RCP, or TFTP. You can have more than one such database agent. When you configure Cisco DHCP, you need to decide if you will use a DHCP database agent. If so, enter the command

ip dhcp database url
   [timeout seconds | write-delay seconds]

If you will not use a database agent but will keep all information on the router, turn off conflict logging.

no ip dhcp conflict logging

DHCP, of course, can provide more than just the client's own address.

Table 28. Cisco-Supported DHCP Options

Setting Up Dynamic Address Pools

The mandatory parts of setting up an address pool are:

ip dhcp excluded-address low-address [high-address]
ip dhcp pool name

You are now in DHCP configure-pool mode. It is mandatory to establish the address pool from which assignments are made.

network network-number [mask | /prefix-length]

You will probably want to configure the lease time, but if you don't, the lease time will default to one day.

lease {days [hours][minutes] | infinite}

While you are still in DHCP address pool configuration mode, you can specify optional parameters for DHCP to send to the client.

domain-name domain
dns-server address [address2 ... address8]
netbios-name-server address [address2 ... address8]
netbios-node-type type
default-router address [address2 ... address8]

Setting Up Static Address Assignment from DHCP

What if you want to set up fixed rather than dynamic addresses?

ip dhcp pool name
host address [mask | /prefix-length]

Now specify the way the server will identify the specific host requesting the address. You can use either its MAC address or a unique identifier programmed into the host.

hardware-address hardware-address type
! or
client-identifier unique-identifier

You can set optional parameters, such as domain name, as you did for dynamic assignment. Optionally, specify the client name, which will become the low-order part of the fully qualified domain name. For example, if you specified the default domain as certificationzone.com, and if you put lab as the parameter of the client name command, the host would have the FQDN of lab.certificationzone.com.

client-name name

DHCP Relay Agents: General and IOS Implementation

DHCP relay agents forward DHCP client requests received on one of their interfaces toward a DHCP server. DHCP proxies are themselves clients that work through an intermediate Layer 1/2 facility such as a cable modem or PPP dial-up to obtain an address for the router itself.

Let's talk first about the basic behavior of a DHCP relay -- or, more precisely, a BOOTP relay, since that is where the mechanism was first defined [RFC 1542]. I'll describe the most common usage; there are special cases you can see in the RFC, such as a device that has an IP address but still uses the DHCP server to obtain option information.

You enable relaying by configuring an appropriate ip helper statement on the interface.

When the relay agent sees a DHCPREQUEST with a broadcast destination address, it first examines the Gateway Address field (giaddr) and fills it with the IP address of the interface on which the broadcast DHCPREQUEST was received. This will let the DHCP server return it to the relay interface. The DHCPREQUEST packet is now forwarded to the destination address in the IP helper.

The DHCP server fills in the yiaddr field with the assigned IP address of the requesting client, and adds Option fields as required.

After the router containing the relay agent receives the DHCPREPLY, it uses the giaddr field to tell which internal interface should receive the packet. At that interface, the relay examines the Layer 2 address information in the combination of htype, hlen, and chaddr fields. It constructs a Layer 2 frame using chaddr as the destination address and its own Layer 2 address as the frame-level source address, and unicasts it to the requesting client.

The DHCP server in IOS has no mass storage and can service only a limited number of requests. It can, however, forward unsatisfied requests to secondary, host-based DHCP servers listed in ip helper commands.

When the Cisco DHCP relay agent observes several DHCP requests being retransmitted by the same client, it assumes the request is not being satisfied because the DHCP server being used is out of addresses. It will then change the Gateway Address (giaddr) field in the DHCP request and forward the request again. With a different giaddr, if the server has secondary address pools, the server will try to satisfy the request from a different pool. You can set up secondary pools on the IOS servers as well as on the database agents.

If all address pools in the router and on the agents are exhausted, the IOS DHCP server silently drops the address request.

Before the actual address is assigned, the DHCP server pings the address to be sure it is not already present, producing an error message if this takes place. Most DHCP clients, as a final check, issue an ARP to their assigned address to see if anyone else answers.

PPP/IPCP

You can either propose an address to use or request dynamic assignment of an address during PPP setup, specifically in the IP control protocol phase. After validation by CHAP (preferably) or PPP, the calling host can send a configuration request option on its IPCP message. If the calling host wants the called host to assign an IP address, the caller fills the Address field with zeroes. Otherwise, if the calling host wants to use a specific IP address, it puts that in the Address field, aware that it can be rejected.

The router can either directly allocate an address from a local pool or act as proxy to RADIUS or DHCP. A RADIUS server used in this manner can apply additional validation criteria.

Figure 30. IPCP Address Sources: Alternatives in Obtaining an Address for a PPP Client

IPv6 Stateless Autoconfiguration

IPv6 provides a way for interfaces to learn addresses dynamically, without an explicit address server. If you are familiar with the way addresses are assigned in AppleTalk or in the OSI Connectionless Network Protocol (CLNP), you will see distinct similarities.

You can use stateless configuration only on multicast-capable media.

1. Generate a link-local address by prefixing the well-known link-local prefix (FE80::/10) to its own identifier, which is usually the MAC address. The host is allowed to send a Router Solicitation in parallel with generating the address and to listen for the Router Advertisement in response. Parallel operation usually saves time in configuration.

2. Check that the same address is not already in use by sending a Neighbor Solicitation message to the tentative address. Typically, a host will retransmit that solicitation several times to be sure it is heard. If the address is in use, the neighbor will respond with a Neighbor Advertisement. On receipt of such an advertisement, the host is unable to autoconfigure under the standard protocol rules. It must be configured manually or by DHCPv6, unless implementation-specific steps have been taken to give the host an alternate identifier.

3. Assuming the tentative address is unique, the host now can communicate with other hosts on the same link. If no communication off the link is necessary, autoconfiguration is done.

4. If the host does expect to communicate with non-local addresses, it must find routers and change its prefix to one known within a wider scope. The information to do this is contained in Router Advertisement messages. These are multicast periodically, and the host may listen briefly to use one that is transmitted in a timely way. Otherwise, the host sends a Router Solicitation to the all-routers multicast group to trigger a new set of Router Advertisements.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

Figure 31. Router Advertisement

A Router Advertisement is an ICMPv6 message and has the usual ICMP header with type code 134.

Table 29. Fields in Neighbor Advertisement Fixed Header

Table 30. IPv6 Options Used in Discovery

[IE-IPAS-WP1-F03]
[2006-02-14-00]