Re: Possible problem with zoned address prefixes in RFC 3291

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

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

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany