Mike,
Comments in-line. I also added Alex Z. to the distribution for
his thoughts as Routing AD.On Mon, Feb 02, 2004 at 07:27:35AM -0800, C. M. Heard wrote:
I do not yet see the problem - why do you think it is necessary to mask the zone index? Is it possible to show me a concrete example where the triple does not work?
Yes. Let's take the simplest case of all: let's suppose that an ipv4 or ipv6 host uses link-local prefix on two (or more) different interfaces. The ipv4 link-local prefix is 169.254/16 while the ipv6 link-local prefix is FE80::/64. Obviously, these prefixes are unique only when disambiguated by a zone index, e.g., the ifIndex of the link. So to represent link-local route destinations I need to have a zone index as well as the prefix.
So far I can follow. Note that the zone index is available as part of
the InetAddress...
To provide a little more detail, the usual way I figure out if a destination address matches a particular route destination is to take the subnet mask associated with that link, apply it to the destination address, and see if the result matches the route destination. This of course requires that the route destination have zeroes in the bit positions where the mask is zero. If I use an address mask that is contiguous -- which is all that the InetAddressPrefixLength can represent, if we take its DESCRIPTION clause at face value -- then there is no way that I can include the zone in the route destination. So, it seems that I either need to have the zone index at the front of the destination address (rather than the end) or else I need to have a non-contiguous address mask that has 1 bits in the link-local prefix and zone index positions.
I think you are trying to use a model for something where the model
does not apply. A "normal" routing table lookup is just a longest
prefix match. So you need the target address plus the prefix length
(or a mask in the old days). Scopes and zones I think come in as a
new concept and I do not expect that you use the same prefix matching
algorithm to implement them. But since I have not written such code
myself, I like to hear from others who have first hand experience
how they deal with this situation.
I think the issue here is whether or not a route table would be structured in the same manner as the MIB table. For the most part, I don't think they are. When I wrote a distributed forwarding engine that supported scoped addresses, I added a zone ID to the rt_entry structure in front of the prefix. That way, the LPM could include a zone ID in the lookup. However, the route table on the control plane maintained a mapping from rt_entry to inetCidrRouteEntry that put the zone ID in the correct location.
When doing a lookup from a particular table (e.g. on a linecard) the zone ID comes from the ingress interface. And in the case of link-local IPv6 addresses, you "short circuit" the lookup since they can't be forwarded.
The IP Forwarding Table MIB adheres to the model I just described; here are the objects it uses to represent a route destination:
inetCidrRouteDestType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the inetCidrRouteDest address, as defined in the InetAddress MIB.
Only those address types that may appear in an actual routing table are allowed as values of this object." REFERENCE "RFC 3291" ::= { inetCidrRouteEntry 1 }
inetCidrRouteDest OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination IP address of this route.
The type of this address is determined by the value of the inetCidrRouteDestType object.
The values for the index objects inetCidrRouteDest and inetCidrRoutePfxLen must be consistent. When the value of inetCidrRouteDest is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object inetCidrRoutePfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." ::= { inetCidrRouteEntry 3 }
The last paragraph in the description definately needs to change if my
model how to deal with scoped routing is right.
The DESCRIPTION relates specifically to the address and I have no problems with that text. Perhaps some mention of a need to check the zone ID for less-than-global addresses?
Note that for non-global addresses, the route destination's
zone ID MUST match the zone ID associated with the ingress
interface.
inetCidrRoutePfxLen OBJECT-TYPE SYNTAX InetAddressPrefixLength (0..128) -- this subrange -- may be removed -- but agrees with -- ipv4/ipv6 max -- values in RFC3291 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the number of leading one bits which form the mask to be logical-ANDed with the destination address before being compared to the value in the inetCidrRouteDest field.
The values for the index objects inetCidrRouteDest and inetCidrRoutePfxLen must be consistent. When the value of inetCidrRouteDest is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object inetCidrRoutePfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." ::= { inetCidrRouteEntry 3 }
It seems clear to me that the above objects will not work for zoned addresses, unless the zone index is always zero.
I think the description of these objects can be improved. Personally, I would like to avoid to talk about masks at all - but that is perhaps a matter of style as well.
Perhaps a similar comment that the prefix length does not cover the zone ID?
Regards, Brian