IPv6 in the IPSec MIB
Mike Daniele <daniele@zk3.dec.com> Thu, 19 November 1998 15:16 UTC
Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA22960 for ipsec-outgoing; Thu, 19 Nov 1998 10:16:22 -0500 (EST)
Message-ID: <365437CC.228C9C4B@zk3.dec.com>
Date: Thu, 19 Nov 1998 10:22:53 -0500
From: Mike Daniele <daniele@zk3.dec.com>
Organization: Compaq 64-bit UNIX networking
X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 X5.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@tis.com
Subject: IPv6 in the IPSec MIB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
John Shriver <jas@shiva.com> wrote: > As for IPv6, I think it should be in a seperate MIB. That is, what > you are presently working on is really IPSEC-IPV4-MIB. There will be > a seperate IPSEC-IPV6-MIB. This will prevent RFC publication of > IPSEC-IPV4-MIB from being held up because IPV6-TC isn't published as > an RFC yet. (You cannot publish an RFC with a reference to an > Internet-Draft...) There is no issue with your WG delivering a MIB that IMPORTS from IPV6-TC or any other v6-related module. They have already all been approved as Proposed Standards, so can't gate your work. For example, the TCP over IPv6 MIB (draft-ietf-ipngwg-ipv6-tcp-mib-02.txt) IMPORTS from IPV6-TC, and has itself been approved as a Proposed Standard. The reason we had to do separate MIBs for TCP and UDP over IPv6 was because 1) IP addresses are used to index tables, so we needed separate tables for TCP connections and UDP listeners over v6 vs over v4. 2) We didn't want to have to change the existing TCP and UDP MIB RFCs (2012 and 2013), since that would have taken much longer. The ultimate goal however is to have 1 TCP MIB and 1 UDP MIB, with the necessary objects to support both IPv4 and IPv6. You don't have this baggage of existing MIBs, and can do the right thing immediately. The real issue is this: Is "IPSec over v4" a different protocol entity than "IPSec over v6"? If so, then by all means produce 2 MIB specs. If not, and the only difference between the two MIBs would be a few objects change their syntax from IpAddress to Ipv6Address, that would be a real waste. You'd end up with many duplicated objects, and would unnecessarily delay an IPSec MIB that works with IPv6 endpoints. > > Further, as conformance statements are developed for IPSEC-IPV4-MIB, > perhaps they should be carefully constructed so as not to require IPv4 > specific variables unless the IPsec implementation implements IPv4. > Someday, there may be IPv6-only hosts... Using conformance statements is a good idea. When we have a unified TCP MIB that's what we'll do. But it may not even be required for the IPSec MIB. You could define pairs of address objects, and simply state in the object descriptions that a peer, or a tunnel endpoint, is either v4 or v6. If it's v4 the v6 object is not instantiated, etc. Or you could use the TDomain/TAddress mechanism from RFC 1903. Many MIBs that support multiple address families do this. (For reference, we've already defined some for IPv6 , among others, in draft-daniele-iana-addr-mib-00.txt.) This way you'd have a single object for a generic address, and be able to load either v4 or v6 addresses in it. In any event, I don't think it would be a lot of work to emit a draft that supports both v4 and v6. (I'd be glad to help if needed.) And in my opinion the resulting product would be much more useful, timely, and concise. Regards, Mike
- IPv6 in the IPSec MIB Mike Daniele
- Re: IPv6 in the IPSec MIB John Shriver