RE: [ipcdn] InetAddress or PrefixLength as a mask
"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Wed, 19 February 2003 15:04 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27003 for <ipcdn-archive@odin.ietf.org>; Wed, 19 Feb 2003 10:04:04 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JFAC317496 for ipcdn-archive@odin.ietf.org; Wed, 19 Feb 2003 10:10:12 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JF85p17375; Wed, 19 Feb 2003 10:08:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JF7Wp17326 for <ipcdn@optimus.ietf.org>; Wed, 19 Feb 2003 10:07:32 -0500
Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26806 for <ipcdn@ietf.org>; Wed, 19 Feb 2003 10:00:53 -0500 (EST)
Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h1JF4g84008299; Wed, 19 Feb 2003 08:04:42 -0700 (MST)
Received: from 147.191.90.11 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 19 Feb 2003 08:04:32 -0600
Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id <1RRPR3WG>; Wed, 19 Feb 2003 08:03:54 -0700
Message-ID: <6732623D2548D61193C90002A5C88DCC056636AF@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>, "IPCDN WG (E-mail)" <ipcdn@ietf.org>
cc: "Thomas Narten (E-mail)" <narten@us.ibm.com>, "Erik Nordmark (E-mail)" <Erik.Nordmark@sun.com>, "Randy Bush (E-mail)" <randy@psg.com>
Subject: RE: [ipcdn] InetAddress or PrefixLength as a mask
Date: Wed, 19 Feb 2003 08:04:29 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 124D428A1091004-01-01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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@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 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] InetAddress or PrefixLength as a mask Wijnen, Bert (Bert)
- RE: [ipcdn] InetAddress or PrefixLength as a mask Woundy, Richard
- RE: [ipcdn] InetAddress or PrefixLength as a mask Woundy, Richard