Re: Possible problem with zoned address prefixes in RFC 3291

["C. M. Heard" <heard@pobox.com>]

Brian/Juergen,

After re-reading the mail thread a couple of times I think I now
agree with Juergen that the problem is not with RFC 3291 but with
the usage in the IP Forwarding Table MIB.  More comments in-line.

Mike

On Tue, 3 Feb 2004, Brian Haberman wrote:
> Mike,
>       Comments in-line.  I also added Alex Z. to the distribution for
> his thoughts as Routing AD.
> 
> Juergen Schoenwaelder wrote:
> 
> > 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.
> > 
> 
> Let me chime in with some implementation experience. :)
> 
> 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.

Exactly so.  The IP Forwarding Table MIB -- again, if I understand
the intent correctly -- uses a consistent longest-match model for
_all_ routing table entries.  At least that's what I infer from
the DESCRIPTION clauses in the inetCidrRouteTable.  There is nothing
inherently wrong with that, even if implementations don't really
work that way.  But it does seem to be inconsistent with the way
the TCs in RFC 3291 were intended to be used.

> 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.

Right.  But you still can/should have an entry in the MIB table to
represent this process.  In this case what it wanted is a route with
inetCidrRouteNextHop set to a zero length string, and inetCidrRouteIfIndex
matching the zone index in inetCidrRouteDest (assuming that you use
ifIndex as the zone index).

> >>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?
> 
> Perhaps adding:
> 
>       Note that for non-global addresses, the route destination's
>       zone ID MUST match the zone ID associated with the ingress
>       interface.

I don't think that's enough, or even correct.  For one thing, this
this does not address the common case where a datagram with a
link-local address is originated with the node, rather than
forwarded.  That still requires an outgoing link selection, and it
should be possible to represent the link selection process via an
entry in the inetCidrRouteTable.  So the rule you would want is for
the zone index in inetCidrRouteDest to match with the value of
inetCidrRouteIfIndex, if you use ifIndex as the zone index.  But
even that's not enough, since there are types of zoned addresses
other than link-local (although they are now deprecated), and such
a rule would not handle them.

What you want is for the zone associated with the destination address
in a datagram  to match the zone associated with the route table
entry, which one would think should be the zone component of the
inetCidrRouteDest object.  But the way the DESCRIPTION clauses are
are now written it is not possible to put a non-zero zone index into
inetCidrRouteDest.  The reason why this is so is that the
bitwise logical-AND of the value of inetCidrRouteDest and the value
of the mask formed from the corresponding index object
inetCidrRoutePfxLen will necessarily have zeroes in the zone index
position, according to the DESCRIPTION clauses for inetCidrRouteDest,
inetCidrRoutePfxLen, and those for the corresponding TCs InetAddress
and InetAddressPrefixLength.

As for how to do the fix ...

> >>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?

... it seems that the consistency-checking parts of the DESCRIPTION
clauses for inetCidrRouteDest and inetCidrRoutePfxLen need to be
adjusted to specifically exclude the zone index from the check.

Mike