Possible problem with zoned address prefixes in RFC 3291

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

Greetings,

While reviewing recent changes in the IP Forwarding Table MIB
document <draft-ietf-ipv6-rfc2096-update-06.txt> I noticed what
appears to me to be a problem with the definitions of zoned address
prefixes in RFC 3291 (and also in its proposed replacement
<draft-ietf-ops-rfc3291bis-03.txt>).

Specifically:  the zoned address types InetAddressIPv4z and
InetAddressIPv6z have the zone information in the last four octets
of the address:

   InetAddressIPv4z ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "1d.1d.1d.1d%4d"
       STATUS       current
       DESCRIPTION
           "Represents a non-global IPv4 network address together
            with its zone index:

              octets   contents         encoding
               1-4     IPv4 address     network-byte order
               5-8     zone index       network-byte order

            [ ... ]


   InetAddressIPv6z ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
       STATUS       current
       DESCRIPTION
           "Represents a non-global IPv6 network address together
            with its zone index:

              octets   contents         encoding
               1-16    IPv6 address     network-byte order
              17-20    zone index       network-byte order

            [ ... ]

The InetAddressPrefixLength convention, on the other hand, defines
address masks that consist only of bits from the leading octets of
an address, and explicitly excludes the zone:

   InetAddressPrefixLength ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS       current
       DESCRIPTION
           "Denotes the length of a generic Internet network address
            prefix. A value of n corresponds to an IP address mask
            which has n contiguous 1-bits from the most significant
            bit (MSB) and all other bits set to 0.

            [ ... ]

            InetAddressPrefixLength values that are larger than
            the maximum length of an IP address for a specific
            InetAddressType are treated as the maximum significant
            value applicable for the InetAddressType. The maximum
            significant value is 32 for the InetAddressType
            'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType
            'ipv6(2)' and 'ipv6z(4)'. The maximum significant value
            for the InetAddressType 'dns(16)' is 0.

            [ ... ]

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.  In fact, the address consistency requirements
in that MIB module won't allow a value of the triple
<inetCidrRouteDestType, inetCidrRouteDest, inetCidrRoutePfxLen> to
include a zoned address type unless the zone index is zero,

Unless I am missing something, it sure seems that we have a problem
here.  Comments, anyone?

Mike Heard