Subject: Auth48 update to TCP-MIB (draft-ietf-ipv6-rfc2012-update-06.txt)

From: Rajiv Raghunarayan <[email-masked]>
Date: Sat, 21 Aug 2004 23:48:25 -0700

Greetings folks,

[Bcced: Brian Haberman, Bob Hinden, Margaret Wasserman, Bert Wijnen]

During the IESG review of the UDP-MIB a small problem was
identified, resulting from the MIB being incompatible with
the definitions in draft-3291bis (draft-ietf-ops-rfc3291bis-06).
I've described the problem below, but the same problem plagues
the TCP-MIB as well.

The problem is in the following statement made in the TCP-MIB::
tcpListenerTable description clause:

<snip>
       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).
<snip>

However, RFC 3291 (& draft-ietf-ops-rfc3291bis-06.txt) allows
a zero-length octet-string to be specified only with an
InetAddressType 'unknown'. With address type IPv4 or IPv6 the
expected length of the address is 4 & 16 octets respectively.

A similar problem also exists in the definition of TCP-MIB::
tcpListenerLocalAddress.

The fix for this is to replace the requirement of the 0-length
octet string with an ip address 0.0.0.0 (for IPv4) and :: (for
IPv6). Detailed modification listed at the end of this mail.

We propose to make this modification at the AUTH48 time.
Appreciate if you could let me know if you see any issues with
this change.

Thanks,
Rajiv.

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 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.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Kristine Adamson <[email-masked]>
Date: Mon, 23 Aug 2004 04:04:57 -0600

> Appreciate if you could let me know if you see any issues with

Hello,
   In this case, would it be better to update draft-3291bis to permit 
zero-length octet-strings for InetAddress objects whose InetAddressType is 
IPv4 or IPv6?  We have already encountered problems with network 
management applications not being able to get as much SNMP data back in an 
SNMP response as they would like to be able to.  With an IPv6 address in 
an instance already taking up a lot of space in the SNMP response packet, 
it doesn't seem like a good use of response packet space to return 16 
bytes of zeros for the address. 

Thanks,  
Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:[email-masked] 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Aug 2004 15:36:43 +0200

> bytes of zeros for the address. 

While I do not really buy into the bandwidth argument, I am indeed
wondering whether the current rule is perhaps overly restrictive. At 
the moment (and that is unchanged from RFC 3291 and even from RFC 2851), 
we have the following implication:

	InetAddress zero-length  =>  InetAddressType == unknown

To change this (basically removing this rule), we would have to remove 
text from the 'unknown' definition and we would have to add text to the 
InetAddress TC that zero-length values can be legal subject to the 
semantics spelled out in the definition where the TC is being used
(with a statement that per default they are not legal if nothing is 
spelled out in the description clause (backwards compatibility)).

I am not sure which impact such a change will have. These TCs have 
seen quite some usage - not only in the IETF, but also in vendor
specific MIB modules. And this is the first time I can remember
(and that I could find in my mailing list archive) that a change
to generally allow zero-length InetAddress values has been proposed.

Unless I hear a strong move to change the rule above, I actually prefer 
to stay with what we have.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany