Re: Possible problem with zoned address prefixes in RFC 3291

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

On Mon, 2 Feb 2004, Juergen Schoenwaelder wrote:
> On Sun, Feb 01, 2004 at 11:44:16PM -0800, C. M. Heard wrote:
> > The upshot is that the zone index is not included in a mask defined
> > by an <InetAddressType, InetAddress, InetAddressPrefixLength>
> > triple.  It follows that such a triple cannot unambiguously
> > represent a destination, and so does not serve the needs of the IP
> > Forwarding Table MIB.
> 
> 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.

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.

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 2 }

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.

Do you see the problem now?

//cmh