RE: [ipcdn] InetAddress or PrefixLength as a mask

["Woundy, Richard" <[e-mail]>]

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:[e-mail]]
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 

_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn