rfc4001.txt

用于snmp协议的mib管理软件

       SYNTAX  InetAddressType { ipv4(1), ipv6(2) }
       DESCRIPTION
           "An implementation is only required to support IPv4
            and IPv6 addresses without zone indices."

       ::= { somewhere 2 }

   Note that the SMIv2 does not permit inclusion of objects that are not
   accessible in an object group (see section 3.1 in STD 58, RFC 2580
   [RFC2580]).  It is therefore not possible to refine the syntax of
   auxiliary objects that are not accessible.  It is suggested that the
   refinement be expressed informally in the DESCRIPTION clause of the
   MODULE-COMPLIANCE macro invocation.

6.  Security Considerations

   This module does not define any management objects.  Instead, it
   defines a set of textual conventions which may be used by other MIB
   modules to define management objects.







Daniele, et al.             Standards Track                    [Page 17]

RFC 4001          Internet Network Address Conventions     February 2005


   Meaningful security considerations can only be written in the MIB
   modules that define management objects.  This document has therefore
   no impact on the security of the Internet.

7.  Acknowledgments

   This document was produced by the Operations and Management Area
   "IPv6MIB" design team.  For their comments and suggestions, the
   authors would like to thank Fred Baker, Randy Bush, Richard Draves,
   Mark Ellison, Bill Fenner, Jun-ichiro Hagino, Mike Heard, Tim
   Jenkins, Allison Mankin, Glenn Mansfield, Keith McCloghrie, Thomas
   Narten, Erik Nordmark, Peder Chr.  Norgaard, Randy Presuhn, Andrew
   Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill.

8.  Changes from RFC 3291 to RFC 4001

   The following changes have been made relative to RFC 3291:

   o  Added a range restriction to the InetAddressPrefixLength textual
      convention.

   o  Added new textual conventions InetZoneIndex, InetScopeType, and
      InetVersion.

   o  Added explicit "d" DISPLAY-HINTs for textual conventions that did
      not have them.

   o  Updated boilerplate text and references.

9.  Changes from RFC 2851 to RFC 3291

   The following changes have been made relative to RFC 2851:

   o  Added new textual conventions InetAddressPrefixLength,
      InetPortNumber, and InetAutonomousSystemNumber.

   o  Rewrote the introduction to say clearly that, in general, one
      should define MIB tables that work with all versions of IP.  The
      other approach of multiple tables for different IP versions is
      strongly discouraged.

   o  Added text to the InetAddressType and InetAddress descriptions
      requiring that implementations must reject set operations with an
      inconsistentValue error if they lead to inconsistencies.

   o  Removed the strict ordering constraints.  Description clauses now
      must explain which InetAddressType object provides the context for
      an InetAddress or InetAddressPrefixLength object.



Daniele, et al.             Standards Track                    [Page 18]

RFC 4001          Internet Network Address Conventions     February 2005


   o  Aligned wordings with the IPv6 scoping architecture document.

   o  Split the InetAddressIPv6 textual convention into the two textual
      conventions (InetAddressIPv6 and InetAddressIPv6z) and introduced
      a new textual convention InetAddressIPv4z.  Added ipv4z(3) and
      ipv6z(4) named numbers to the InetAddressType enumeration.
      Motivations for this change: (i) to enable the introduction of a
      textual conventions for non-global IPv4 addresses, (ii) alignment
      with the textual conventions for transport addresses, (iii)
      simpler compliance statements in cases where support for IPv6
      addresses with zone indices is not required, and (iv) to simplify
      implementations for host systems that will never have to report
      zone indices.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Structure of Management Information Version 2 (SMIv2)",
              STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Textual Conventions for SMIv2", STD 58, RFC 2579, April
              1999.

   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
              B.  Zill, "IPv6 Scoped Address Architecture", RFC 4007,
              February 2005.












Daniele, et al.             Standards Track                    [Page 19]

RFC 4001          Internet Network Address Conventions     February 2005


10.2.  Informative References

   [RFC2553]  Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
              "Basic Socket Interface Extensions for IPv6", RFC 2553,
              March 1999.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, June 2000.

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

   [RFC3419]  Daniele, M. and J. Schoenwaelder, "Textual Conventions for
              Transport Addresses", RFC 3419, December 2002.




































Daniele, et al.             Standards Track                    [Page 20]

RFC 4001          Internet Network Address Conventions     February 2005


Authors' Addresses

   Michael Daniele
   SyAM Software, Inc.
   1 Chestnut St, Suite 3-I
   Nashua, NH 03060
   USA

   Phone: [phone]
   EMail: [e-mail]


   Brian Haberman
   Johns Hopkins University Applied Physics Laboratory
   11100 Johns Hopkins Road
   Laurel, MD  20723-6099
   USA

   Phone: [phone]
   EMail: [e-mail]


   Shawn A. Routhier
   Wind River Systems, Inc.
   500 Wind River Way
   Alameda, CA  94501
   USA

   Phone: [phone]
   EMail: [e-mail]


   Juergen Schoenwaelder
   International University Bremen
   P.O. Box 750 561
   28725 Bremen
   Germany

   Phone: [phone]
   EMail: [e-mail]











Daniele, et al.             Standards Track                    [Page 21]

RFC 4001          Internet Network Address Conventions     February 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and at www.rfc-editor.org, and except as set
   forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the ISOC's procedures with respect to rights in ISOC Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Daniele, et al.             Standards Track                    [Page 22]