RE: Subranging InetAddressPrefixLength

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: zaterdag 31 januari 2004 8:30
> To: Mreview (E-mail)
> Subject: Subranging InetAddressPrefixLength
> 
> 
> Howdy,
> 
> In the just-announced draft draft-ietf-ipv6-rfc2096-update-06.txt
> this definition caugt my eye:
> 
>   inetCidrRoutePfxLen OBJECT-TYPE
>       SYNTAX     InetAddressPrefixLength (0..128)
>       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 }
> 
> If we discourage people from putting size constraints on InetAddress
> objects and from putting value constraints on InetAddressType
> objects, all in order to ensure future extensibility, it seems to
> me that we should similarly discurage putting range restrictions on
> InetAddressPrefixLength objects.
> 
I think that Shawn put it in cause I mentioned a WARNING from SMICng
that states that a range must be specified. we discussed a bit if 128
makes sense or if maybe a larger value (I can think of 1K, 32K, 64K,
4billion) makes sense. The response from Shawn was that if the 
length of an IP address gets longer than the 128 for IPv6, that
many more changes will be needed.  So I am kind of OK with128.

> Neither RFC 3291 nor draft-3291bis addresses this explicitly;
> maybe the next rev of 3291bis should do so.
> 
??

Bert
> Mike
> 
>