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

Re: Bugs in UDP-MIB and TCP-MIB (was: RE: MIB DOctor review of: draft-ietf-ipv6-inet-tunnel-mib-01.txt)

Hi Mike,

Thanks for the heads up on the issue! Dave was kind enough to
forward this mail a couple of days back, so we were aware of
this thread. It is indeed a good catch!

There are a two places in the TCP-MIB where this issue arises.
I've got the original/old descriptions snippets and the proposed
modifications listed below.

tcpListenerTable
=====================

OLD
----
            2. An application which is willing to accept only IPv4 or
               IPv6 datagrams is represented by a
               tcpListenerLocalAddressType of the appropriate address
               type and tcpListenerLocalAddress of ''h (a zero-length
               octet-string).

PROPOSED MODIFICATION
-----------------------

            2. An application which is willing to accept only IPv4 or
               IPv6 datagrams is represented by a
               tcpListenerLocalAddressType of the appropriate address
               type and tcpListenerLocalAddress of '0.0.0.0' or '::'
               respectively.

tcpListenerLocalAddress
=========================

OLD
----

            The local IP address for this TCP connection.  In the case
            of a listener which is willing to accept connections for
            any IP interface associated with the node, a value of ''h
            (zero-length octet-string) is used.  The type of this
            address is determined by the value of
            tcpListenerLocalAddressType.

PROPOSED MODIFICATION
-----------------------

            The local IP address for this TCP connection.

            The value of this object can be represented in three
            possible ways, depending on the characteristics of the
            listening application:

            1. For an application that is willing to accept both
               IPv4 and IPv6 datagrams, the value of this object
               must be ''h (a zero-length octet-string), with
               the value of the corresponding
               tcpListenerLocalAddressType object being unknown (0).

            2. For an application which is willing to accept only
               IPv4 or IPv6 datagrams, the value of this object
               must be '0.0.0.0' or '::' respectively, while
               tcpListenerLocalAddressType represents the
               appropriate address type.

            3. For an application which is a listening for data
               destined only to a specific IP address, the value
               of this object is the specific local address, with
               tcpListenerLocalAddressType representing the
               appropriate address type.

As to the impact of this change, any implementation of this
draft would need to accordingly incorporate this change! I am
not certain as to the extent of the implementation, though.
But if required, we could run this by on the ipv6 and tcp
mailing lists to get some feedback.

Does this qualify for an AUTH48 change?

Thanks,
Rajiv.

C. M. Heard wrote: 
Bert,

In the case of the UDP MIB it should not be necessary to make the
corrections in AUTH48 because draft-ietf-ipv6-rfc2013-update-03.txt
is still in last call.  It is necessary to do any corrections to the
TCP MIB in that way since draft-ietf-ipv6-rfc2012-update-06.txt was
already approved.

I've cc:'d the document authors since they are probably in the best
position to evaluate the impact of the required changes.  For their
benefit, the issue is that RFC3291bis does not permit using a
zero-length octet string for an InetAddress object when the
corresponding InetAddressType object has a value other than
unknown(0), but both of those MIB modules use that combination to
indicate an IPv4 or IPv6 wildcard address.  There are more details
in the discussion below.

For IPv4 the problem could be solved by using the all-zeroes
address;  that indeed is what the older IPv4-specific modules did.
However, I don't know enough about IPv6 to know if that would be a
viable solution for that case.

Mike Heard


On Thu, 19 Aug 2004, Wijnen, Bert (Bert) wrote:

It would be good to prepare the fix to UDP and TCP MIB documents
in the form of RFC-Editor instructions aka

- on page x pls change
 OLD:
   ....
 NEW:
   ...

So that we can make the change when we see the AUTH48.
I need to check the impact a bit though... (I am in the process of recovering from a broken laptop... so I do not have verything handy at the
moment).

Thanks, Bert



-----Original Message-----
From: C. M. Heard [mailto:heard@pobox.com]
Sent: Friday, August 13, 2004 05:34
To: Mreview (E-mail)
Cc: Wijnen, Bert (Bert); Margaret Wasserman (E-mail)
Subject: Bugs in UDP-MIB and TCP-MIB (was: RE: MIB DOctor review of:
draft-ietf-ipv6-inet-tunnel-mib-01.txt)


On Thu, 12 Aug 2004, Dave Thaler wrote:

 3. According to RFC3291, if the address is unknown, then the
    value should be the zero-length octet string

My reading of 3291 is that the zero-length octet string is

only used if

the InetAddressType is unknown. 

http://www1.ietf.org/internet-drafts/draft-ietf-ops-rfc3291bis-05.txt
says something a little bit different -- an InetAddressType object
must assume the value unknown(0) if the corresponding InetAddress
object has zero length, but the reverse is not necessarily true,
per the following excerpt from the InetAddressType DESCRIPTION clause:

  unknown(0)  An unknown address type. This value MUST
              be used if the value of the corresponding
              InetAddress object is a zero-length string.
              It may also be used to indicate an IP address
              which is not in one of the formats defined
              below.


If the type is known to be IPv4 or IPv6, then the zero-length
octet string is not used.


That, however, is certainly true.



[... ] The new UDP MIB says [ ... ] (and the TCP MIB has
similar text):
     an application which is willing to accept only IPv4
     or only IPv6 datagrams is represented by a
     udpEndpointLocalAddressType of the appropriate
     address type, and udpEndpointLocalAddress of ''h (a
     zero-length octet-string).

However, from RFC 3291 (unchanged in

draft-ietf-ops-rfc3291bis-05.txt), 

the definition of the InetAddressType says
        ipv4(1)     An IPv4 address as defined by the
                    InetAddressIPv4 textual convention.

        ipv6(2)     A global IPv6 address as defined by the
                    InetAddressIPv6 textual convention.

And the SYNTAX clauses of those are:
InetAddressIPv4 ::= TEXTUAL-CONVENTION
   SYNTAX       OCTET STRING (SIZE (4))

InetAddressIPv6 ::= TEXTUAL-CONVENTION
   SYNTAX       OCTET STRING (SIZE (16))

Since the 0-length string is not legal in those SYNTAX clauses,
my reading is that the UDP-MIB (which is in IETF last call) and TCP-MIB (which is in the RFC editors queue)
interpretation is not legal, and the existing TUNNEL-MIB interpretation is correct.

Or am I missing something? 

IMHO, you are not.  I think that both of those documents need to be
corrected.  Fortunately, they are both blocked waiting for 3291bis,
since it is a normative reference in both.

I guess we would be covered by a Last Call comment on the UDP-MIB,
but we will have to ask for help from Bert and Margaret for the
TCP-MIB.

Mike