[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: d raft-ietf-ipv6-inet-tunnel-mib-01.txt)
Inline
> -----Original Message-----
> From: Rajiv Raghunarayan [mailto:raraghun@cisco.com]
> Sent: Friday, August 20, 2004 03:26
> To: C. M. Heard
> Cc: Wijnen, Bert (Bert); Mreview (E-mail); Margaret Wasserman
> (E-mail);
> Bill Fenner; John Flick
> Subject: 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
s/is a/is/
> 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?
>
I think this is OK for AUTH48 change.
But... can you (ASAP) post this to the IPv6 mailing list and the IPv6MIB
mailing list. Pls explain why this change is being proposed and indicate
that you plan to do so at AUTH48 time.
I guess it would be best if the WG chairs can make sure that WG is OK
with this and then pass that consensus information on to responsible AD
(Margaret), so we know everyone is fine with this. I'd appreciate a copy too.
Bert
> 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-rfc3291
> bis-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
> >>>
> >>>
> >>>
> >>
> >
> >
>
>
>