HP-UX Reference (11i v2 03/08) - 4 File Formats (vol 8)

g
gated.conf(4) gated.conf(4)
Next hop
The primary ones are the ability to advertise a next hop to use other than the router supplying the
routing update. This is quite useful when advertising a static route to a dumb router that does not
run RIP as it avoids having packets destined through the dumb router from having to cross a net-
work twice.
RIP I routers will ignore next hop information in RIP II packets. This may result in packets cross-
ing a network twice, which is exactly what happens with RIP I. So this information is provided in
RIP I compatible RIP II packets.
Network Mask
RIP I assumes that all subnetworks of a given network have the same network mask. It uses this
assumption to calculate the network masks for all routes received. This assumption prevents sub-
nets with different netmasks from being included in RIP packets. RIP II adds the ability to explicitly
specify the network mask with each network in a packet.
While RIP I routers will ignore the network mask in RIP II packets, their calculation of the network
mask will quite possibly be wrong. For this reason, RIP I compatible RIP II packets must not con-
tain networks that would be mis-interpreted. These network must only be provided in native RIP II
packets that are multicast.
Authentication
RIP II packets may also contain one of two types of authentication string that may be used to verify
the validity of the supplied routing data. Authentication may be used in RIP I compatible RIP II
packets, but be aware that RIP I routers will ignore it.
The first method is a simple password in which an authentication key of up to 16 characters is
included in the packet. If this does not match what is expected, the packet will be discarded. This
method provides very little security as it is possible to learn the authentication key by watching RIP
packets.
The second method is still experimental and may change in incompatible ways in future releases.
This method uses the MD5 algorithm to create a crypto-checksum of a RIP packet and an authenti-
cation key of up to 16 characters. The transmitted packet does not contain the authentication key
itself, instead it contains a crypto-checksum, called the digest. The receiving router will perform a
calculation using the correct authentication key and discard the packet if the digest does not match.
In addition, a sequence number is maintained to prevent the replay of older packets. This method
provides a much stronger assurance that routing data originated from a router with a valid authen-
tication key.
Two authentication methods can be specified per interface. Packets are always sent using the pri-
mary method, but received packets are checked with both the primary and secondary methods
before being discarded. In addition, a separate authentication key is used for non-router queries.
RIP-I and network masks
RIP-I derives the network mask of received networks and hosts from the network mask of the interface
the packet via which the packet was received. If a received network or host is on the same natural net-
work as the interface over which it was received and that network is subnetted (the specified mask is
more specific than the natural netmask), the subnet mask is applied to the destination. If bits outside the
mask are set, it is assumed to be a host. Otherwise it is assumed to be a subnet.
On point-to-point interfaces, the netmask is applied to the remote address. The netmask on these inter-
faces is ignored if it matches the natural network of the remote address or is all ones.
Unlike in previous releases, the zero subnet mask (a network that matches the natural network of the
interface, but has a more specific, or longer, network mask) is ignored. If this is not desirable, a route
filter may be used to reject it.
The RIP Statement
rip yes | no | on | off [ {
broadcast ;
nobroadcast ;
nocheckzero ;
preference preference ;
defaultmetric metric ;
query authentication [none |[[simple|md5] password]] ;
interface interface_list
HP-UX 11i Version 2: August 2003 13 Hewlett-Packard Company Section 489