RE: InetAddress or PrefixLength as a mask
Woundy, Richard <Richard_Woundy <at> cable.comcast.com>
2003-03-03 20:11:43 GMT
Just curious if anyone had a reaction to my email response below -- about
the BPI+ MIB use of a netmask rather than a prefix for matching IPv6
multicast address...
-- Rich
-----Original Message-----
From: Woundy, Richard
Sent: Wednesday, February 19, 2003 10:04 AM
To: 'Wijnen, Bert (Bert)'; IPCDN WG (E-mail)
Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail)
Subject: RE: [ipcdn] InetAddress or PrefixLength as a mask
Bert,
Since I am the person that most likely influenced the BPI+ MIB's use of a
netmask rather than a prefix length, I suppose I should directly answer your
question. (Of course, that makes your suggestion about putting the
explanation in the DESCRIPTION clause all the wiser.)
The IPv6 addressing architecture is currently defined in RFC 2373. Section
2.7 describes the format of the IPv6 multicast addresses: 8 bits of
'11111111' for identification as multicast, 4 bits of 'flags', 4 bits of
'scope', and 112 bits of 'group ID'. Five scope values are defined for
node-local, link-local, site-local, organization-local, and global scopes.
Section 2.7.2 shows how new IPv6 multicast addresses can be assigned, making
reference to RFC 2375.
The draft draft-ietf-ipngwg-addr-arch-v3-11.txt, which updates RFC 2373,
defines six scope values: interface-local, link-local, admin-local,
site-local, organization-local, and global scopes.
Some of the permanently assigned IPv6 multicast addresses appear in RFC
2375. This RFC includes all-scope addresses in section 3.0 -- these
multicast address assignments apply for all IPv6 multicast scope contexts.
Typically, these assignments are written as "FF0X:...". These assignments
are referred to as "Variable Scope Multicast Addresses" by IANA,
<http://www.iana.org/assignments/ipv6-multicast-addresses>.
As an operator, I would strongly prefer to use one row in the BPI+ MIB table
to match each of these variable-scope permanently assigned addresses. I want
to avoid creating five to six rows (one per defined multicast scope) or
sixteen rows (one per potential multicast scope). Unfortunately, every
prefix of an IPv6 multicast address that contains at least one bit of the
'group ID' MUST contain the entire 'flags' and 'scope' components. The only
way to perform an address match based solely on 'group ID' while ignoring
the 'scope' is to use a non-contiguous netmask.
If there is a better way to accomplish this, I would love to learn about it.
-- Rich
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
Sent: Tuesday, February 18, 2003 7:13 AM
To: Ipcdn (E-mail)
Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail)
Subject: [ipcdn] InetAddress or PrefixLength as a mask
During the IPCDN WG interim meeting last week
I question why in
docsBpi2CmtsIpMulticastMask OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object represents the IP multicast address mask
for this row.
An IP multicast address matches this row if the logical
AND of the address with docsBpi2CmtsIpMulticastMask is
identical to the logical AND of
docsBpi2CmtsIpMulticastAddr with
docsBpi2CmtsIpMulticastMask."
::= { docsBpi2CmtsIpMulticastMapEntry 5 }
You specify the mask as an InetAddress and not as an
InetAddressPrefixLength. I was given some explanations,
but I am not 100% sure I understood and I am not 100% sure
they are valid.
Could the authors pls respond with an explanation (which I think
should also be inclued in the DESCRIPTION clause if it is accepted).
There may be other occurences of this in one ore more of your
MIB documents.
Thanks,
Bert
RSS Feed