[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RFC 4001 TC Question
Thanks for the reply,
I agree with your comments,
Definitely I can use IPv6 TC to set an IPv4 mapped to IPv6 address
I though a more precise variation of InetAddresIPv6 TC that covers both
IPv6 and IPv4 (the last one in the format of an IPv6 addresses) could
provide more exposure to designers to select the appropriate alternative
between InetAddress, InetAddressIPv6 and this new TC based on their
needs, as well as their application design object.
From the management perspective I looked at an analogy with RFC 4038
scenarios where the application is designed to be IPv6 only (
configuration, setup, etc, ) but the application has a switch to the
IPv4 stack for IPv4 connections- the OS is dual stack in this case
The Network Management analogous situation is:
The Management application is targeting IPv6 syntax but IPv4 entries are
supported as well.
Areas of applications are for example introduction of IPv6 and support
legacy IPv4 devices with 5-6 years migration path to only IPv6 devices.
Including millions of records per collection interval.
In those cases the application is predicting only IPv4 and IPv6
addresses then the expense of field size or type context parsing per
object/instance (as InetAddres requires) could be minimized with APIs at
the specific application function call for display, retrieval, or
storage.
In summary, in my view I see a need for IPv4orIPv6 only objects with
optimization in mind; I guessed IPv4 mapped to IPv6 is a good
operational practice. - Just my view
Thanks
Eduardo
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]
Sent: Tuesday, July 18, 2006 2:22 PM
To: Eduardo Cardona
Cc: ietfmibs@ops.ietf.org
Subject: Re: RFC 4001 TC Question
On Tue, Jul 18, 2006 at 08:14:26AM -0600, Eduardo Cardona wrote:
> I am curious if there would be any interest (or merit) to include a TC
> to represent "IPv4-Mapped IPv6 Address" [RFC 4291] and part of the
> transition models described in [RFC 4038]. Or maybe it was discussed
> prior and discarded.
>
> The TC will be for IPv6 and IPv4 addressed mapped as an IPv6 as
defined
> in RFC 4291
>
> Maybe my perception, but the generality of InetAddressType/Address
seems
> to add too much burn to manager applications that need to place the
> inetaddr in the context of the type: (something t hat didn't happen
with
> IPAddress but unavoidable with two IP types, however, that can be
> minimized.
Even with your proposal, you interpret IPv4 in the context of a type.
If you use ipv4-mapped-ipv6 addresses, the type is basically given by
the first 96 bits in the IPv6 address. When we wrote the
INET-ADDRESS-MIB,
we decided to make the type explicit in order to be flexible.
> The advantage I see that even though the representation is an IPv6
> address, the semantics are of a IPv4 address and those address are
> handle by an IPv4 stack.
>
> This is intended for representing IPv4 or IPv6 address, which I guess
is
> the majority of the cases, dns as a type is used in limited cases and
I
> would think that in other cases IP address + dns is desirable instead.
> Zone Scope addresses is another non-very common case for MIB reporting
> perspective,
There are second order issues which led to the design of the
INET-ADDRESS-MIB. For example, it is still very common that IP
addresses are rendered differently and this might go wrong and lead to
surprises of operators (who might run an IPv4 only network but
suddenly see their IPv4 addresses rendered as IPv6 addresses).
> For applications that deals with many IP data records (e.g. ISPs), I
> believe simplifying the algorithms to deal with IPv4 and IPv6
> representations is worth (InetAddress variable length is evil). Also
the
> suppression of 40+ octets per InetAddressType varbind PDU covers the
> expenses of additional 12 octets per IPv4 object. ( assume that in
> general InetAddressType is share by 2 InetAddress objects in general
>
> - This is the best approximation to an IPv4OrIPv6 TC that will be
> probably more controversial.
You seem to ask for a new TC. I am not sure this is needed. I think
nothing stops you from reporting your IPv4 addresses as mapped IPv6
addresses (except perhaps operator feedback on IPv4 only networks, see
my comment above).
Yes, the InetAddressType introduces some overhead (which also depends
on the depths of the OID). But SNMP never has been efficient in terms
of OID overhead and the approach to merge multiple objects into some
opaque format usually has been avoided in the past.
> I believe it makes also database indexing easier as more standard
> handling of "::FFFF.A.B.C.D" can be added to transition applications
> to support IPv4 and IPv6
I believe this is really a matter of implementation choice. If you
want to use mapped addresses in some databases, then the translation
is rather straight forward from what we have.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen,
Germany