Response Validation
The rest of this function processes a RIPng response message.
Listing 1-33
1150—1154 If the source address of a response message is not a link-local address, it was likely to be sent in response to a RIPng request generated from an off-link router. The main purpose of such a request is that a management station conducts routing analysis within the autonomous system. Since the current route6d implementation does not send RIPng requests to off-link nodes, and the RIPng specification requires on-link routers to send both regular and triggered updates using a link-local address as the source address, the current route6d implementation ignores response packets that have non-link-local source addresses.
[RFC2080] also specifies that a valid response must be sent from the RIPng port (521) and that the hop limit of a regular or triggered update must be 255, but this implementation does not check these conditions, which is a bug.
Listing 1-34
1155 This line assumes that the index of the receiving interface was embedded in Listing 1-30 and retrieves it from the address. This code is actually pointless; if the index was given in ancillary data, it should simply be used here; otherwise, since the kernel does not embed the index,the retrieved value will not be a valid index.
1156—1166 As long as the valid index is available, it should match an ifc{} structure in the interface table. Otherwise the packet is ignored.
1161—1162 Depending on configuration, though less likely, outgoing multicast packets may be looped back. The packet is ignored if it was sent by the local router.
1163—1165 RIPng version 1 defines only the request and response commands. Any other command is invalid and causes the packet to be ignored (note that the request case was covered in Listing 1-32).
Listing 1-35
1169—1170 The -N option may be specified when invoking the route6d daemon. The arguments to the -N option is a list of interfaces, which specifies those interfaces that should be excluded from RIPng operation. Function iff_find() searches route6d’s interface table to determine if the given interface belongs to the exclusion list. Any RIPng packet received over these excluded interfaces is ignored.
The -N option allows a router running route6d to choose on which of the attached networks RIPng will be run.
Listing 1-36
1175—1176 The current time is stored in the variable t, which will be used to either set the time in a new route or update an existing entry. t_half_lifetime is used for deciding if a newly discovered equal cost route should replace an existing one. This heuristic is discussed in the description of Listing 1-45.
Process RTE: Reject Invalid Routes
Listing 1-37
1177 Each of the RTEs in the response is examined. An RTE carries the next hop address if the RTE has a metric value of 0xff. In this case, the next hop address must be a link-local address as required by the specification (see Section 1.4.1). If the next hop address is unspecified, or if the next hop is a non link-local address, then the source of the response packet should be taken as the next hop. In any case, the next hop address is saved in variable nh. Processing continues on to the next RTE.
Listing 1-38
1194—1211 The IPv6 prefix field in the RTE is being validated. The following three types of prefix are invalid. The RTE is ignored if the address part of the prefix is of these types.
• Multicast address
• Loopback address
• Link-local address
Technically, simply checking the address part is not enough because a short prefix length may effectively change the type of the address. For example, if rip6_dest is ::1 and rip6_plen is 0, it actually means ::/0 (the default route). A default route would usually be considered a valid route, but this implementation could reject it.
1213 By default the lflag is not set and route6d does not exchange site-local routes with other routers. See the description about Listing 1-23 for more details on the lflag.
Listing 1-39
1222 The route tag stored in rip6_tag is kept intact; it must be preserved by the receiving router and it is redistributed with the route. The route tag must have consistent semantics among all of the routers that run RIPng in the autonomous system. As explained in Section 1.4.1, the receiving router must preserve the tag and redistribute it unmodified.
Process RTE: Apply Inbound Filter
Listing 1-40
The -L option may be specified when invoking the route6d daemon.
The -L option can be specified multiple times to configure multiple filter entries. When filter entries are specified, only those prefixes that are covered by any of the filter entries will be accepted.
1235—1237 Each configured filter is examined to find the -L option.
1238—1240 If the prefix length of the advertised route is smaller than the prefix length of filter, the advertised prefix cannot match the filter prefix and is ignored.
1242—1243 The ::/0 prefix is a special prefix filter when it is given as an argument to the -L option. This prefix is the default route, which does not mean accepting all prefixes. The default route condition is checked here. The advertised prefix is filtered if the default route is expected but the advertised route is not.
1244—1249 Now the advertised prefix length is equal to or longer than the length of the filter prefix. The advertised prefix is accepted if it is covered by the filter prefix. This condition is confirmed by calling applyplen() to mask the advertised prefix so that the trailing bit will be zero-cleared and then comparing the whole 128 bits of the two prefixes by the IN6_ARE_ADDR_EQUAL() macro.
1251—1254 The ok variable indicates whether the advertised prefix can be ignored; if so, the function returns without further processing.
