[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)


I have placed draft-ietf-ipv6-rfc2013-update-03.txt into the "Revised ID Needed" state, as I believe that an update will be required to address this issue.

Do others agree? If so, I will wait for an update before sending the document to IESG review.

Thanks,
Margaret

At 10:54 AM -0700 8/19/04, 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
 >
 >
 >