[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPv6 in the IPSec MIB

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
Follow-Ups: