< draft-ops-endpoint-mib-06.txt		draft-ops-endpoint-mib-07.txt >
	Network Working Group M. Daniele		Network Working Group M. Daniele
	Internet-Draft Compaq Computer Corporation		Internet-Draft Compaq Computer Corporation
	Expires: July 1, 2000 B. Haberman		Expires: August 17, 2000 B. Haberman
	Nortel Networks		Nortel Networks
	S. Routhier		S. Routhier
	Integrated Systems, Inc.		Integrated Systems, Inc.
	J. Schoenwaelder		J. Schoenwaelder
	TU Braunschweig		TU Braunschweig
	January 2000		February 17, 2000
	Textual Conventions for Internet Network Addresses		Textual Conventions for Internet Network Addresses
	draft-ops-endpoint-mib-06.txt		draft-ops-endpoint-mib-07.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference		at any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	To view the entire list of Internet-Draft Shadow Directories, see		To view the entire list of Internet-Draft Shadow Directories, see
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/iid-abstracts.txt		http://www.ietf.org/ietf/iid-abstracts.txt
	This Internet-Draft will expire on July 1, 2000.		This Internet-Draft will expire on August 17, 2000.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	Abstract		Abstract
	This MIB module defines textual conventions to represent commonly		This MIB module defines textual conventions to represent commonly
	used Internet network layer addressing information. The intent is		used Internet network layer addressing information. The intent is
	that these definitions will be imported and used in MIBs that would		that these definitions will be imported and used in MIBs that would
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The SNMP Management Framework . . . . . . . . . . . . . . . . 5		2. The SNMP Management Framework . . . . . . . . . . . . . . . . 5
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . . 10		4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . . 11		4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . . 11
	4.3 Multiple InetAddresses per Host . . . . . . . . . . . . . . . 11		4.3 Multiple InetAddresses per Host . . . . . . . . . . . . . . . 11
	4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . . 11		4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . . 11
	5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 12		5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	7. Intellectual Property Notice . . . . . . . . . . . . . . . . . 15		7. Intellectual Property Notice . . . . . . . . . . . . . . . . . 16
	References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19		Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	Several standard-track MIB modules use the IpAddress SMIv2 base		Several standard-track MIB modules use the IpAddress SMIv2 base
	type. This limits the applicability of these MIB modules to IP		type. This limits the applicability of these MIB modules to IP
	Version 4 (IPv4) since the IpAddress SMIv2 base type can only		Version 4 (IPv4) since the IpAddress SMIv2 base type can only
	contain 4 byte IPv4 addresses. The IpAddress SMIv2 base type has		contain 4 byte IPv4 addresses. The IpAddress SMIv2 base type has
	become problematic with the introduction of IP Version 6 (IPv6)		become problematic with the introduction of IP Version 6 (IPv6)
	addresses [21].		addresses [21].
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	and a new table was added for TCP connections over IPv6 in the		and a new table was added for TCP connections over IPv6 in the
	IPV6-TCP-MIB [19]. Note that even in this case, the MIBs SHOULD use		IPV6-TCP-MIB [19]. Note that even in this case, the MIBs SHOULD use
	the textual conventions defined in this memo.		the textual conventions defined in this memo.
	Note that MIB developers SHOULD NOT use the textual conventions		Note that MIB developers SHOULD NOT use the textual conventions
	defined in this document to represent transport layer addresses.		defined in this document to represent transport layer addresses.
	Instead the SMIv2 TAddress textual convention and associated		Instead the SMIv2 TAddress textual convention and associated
	definitions should be used for transport layer addresses.		definitions should be used for transport layer addresses.
	The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"		The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
	in this document are to be interpreted as described in RFC 2119 [1].		in this document are to be interpreted as described in RFC 2119 [1].
	2. The SNMP Management Framework		2. The SNMP Management Framework
	The SNMP Management Framework presently consists of five major		The SNMP Management Framework presently consists of five major
	components:		components:
	o An overall architecture, described in RFC 2571 [2].		o An overall architecture, described in RFC 2571 [2].
	o Mechanisms for describing and naming objects and events for the		o Mechanisms for describing and naming objects and events for the
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	3. Definitions		3. Definitions
	INET-ADDRESS-MIB DEFINITIONS ::= BEGIN		INET-ADDRESS-MIB DEFINITIONS ::= BEGIN
	IMPORTS		IMPORTS
	MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI		MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI
	TEXTUAL-CONVENTION FROM SNMPv2-TC;		TEXTUAL-CONVENTION FROM SNMPv2-TC;
	inetAddressMIB MODULE-IDENTITY		inetAddressMIB MODULE-IDENTITY
	LAST-UPDATED "200001210000Z"		LAST-UPDATED "200002170000Z"
	ORGANIZATION		ORGANIZATION
	"IETF Operations and Management Area"		"IETF Operations and Management Area"
	CONTACT-INFO		CONTACT-INFO
	"Mike Daniele		"Mike Daniele
	Compaq Computer Corporation		Compaq Computer Corporation
	110 Spit Brook Rd		110 Spit Brook Rd
	Nashua, NH 03062, USA		Nashua, NH 03062, USA
	Phone: +1 603 884-1423		Phone: +1 603 884-1423
	EMail: daniele@zk3.dec.com		EMail: daniele@zk3.dec.com
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	EMail: schoenw@ibr.cs.tu-bs.de		EMail: schoenw@ibr.cs.tu-bs.de
	Send comments to mibs@ops.ietf.org."		Send comments to mibs@ops.ietf.org."
	DESCRIPTION		DESCRIPTION
	"This MIB module defines textual conventions for		"This MIB module defines textual conventions for
	representing Internet addresses. An Internet		representing Internet addresses. An Internet
	address can be an IPv4 address, an IPv6 address		address can be an IPv4 address, an IPv6 address
	or a DNS domain name."		or a DNS domain name."
	REVISION "200001210000Z"		REVISION "200002170000Z"
	DESCRIPTION		DESCRIPTION
	"Initial version, published as RFC XXXX."		"Initial version, published as RFC XXXX."
	::= { mib-2 XXXX } -- to be assigned by IANA		::= { mib-2 XXXX } -- to be assigned by IANA
	InetAddressType ::= TEXTUAL-CONVENTION		InetAddressType ::= TEXTUAL-CONVENTION
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A value that represents a type of Internet address.		"A value that represents a type of Internet address.
	unknown(0) An unknown address type. This value MUST		unknown(0) An unknown address type. This value MUST
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	ipv4(1),		ipv4(1),
	ipv6(2),		ipv6(2),
	dns(16) -- align with AddressFamilyNumbers in		dns(16) -- align with AddressFamilyNumbers in
	} -- IANA-ADDRESS-FAMILY-NUMBERS-MIB		} -- IANA-ADDRESS-FAMILY-NUMBERS-MIB
	InetAddress ::= TEXTUAL-CONVENTION		InetAddress ::= TEXTUAL-CONVENTION
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Denotes a generic Internet address.		"Denotes a generic Internet address.
	An InetAddress value is always interpreted within the context		An InetAddress value is always interpreted within the
	of an InetAddressType value. When this Textual Convention is		context of an InetAddressType value. The InetAddressType
	used, then the DESCRIPTION clause MUST specify which		object which defines the context must be registered
	associated object specifies the context for the InetAddress		immediately before the object which uses the InetAddress
	value.		textual convention. In other words, the object identifiers
			for the InetAddressType object and the InetAddress object
			MUST have the same length and the last sub-identifier of
			the InetAddressType object MUST be 1 less than the last
			sub-identifier of the InetAddress object.
	When this Textual Convention is used as the syntax of an		When this textual convention is used as the syntax of an
	index object, there may be issues with the limit of 128		index object, there may be issues with the limit of 128
	sub-identifiers specified in SMIv2, STD 58. In this case,		sub-identifiers specified in SMIv2, STD 58. In this case,
	the OBJECT-TYPE declaration MUST include a 'SIZE' clause		the OBJECT-TYPE declaration MUST include a 'SIZE' clause
	to limit the number of potential instance sub-identifiers."		to limit the number of potential instance sub-identifiers."
	SYNTAX OCTET STRING (SIZE (0..255))		SYNTAX OCTET STRING (SIZE (0..255))
	InetAddressIPv4 ::= TEXTUAL-CONVENTION		InetAddressIPv4 ::= TEXTUAL-CONVENTION
	DISPLAY-HINT "1d.1d.1d.1d"		DISPLAY-HINT "1d.1d.1d.1d"
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Represents an IPv4 network address:		"Represents an IPv4 network address:
	octets contents encoding		octets contents encoding
	1-4 IP address network-byte order		1-4 IP address network-byte order
	The corresponding InetAddressType value is ipv4(1)."		The corresponding InetAddressType value is ipv4(1)."
	SYNTAX OCTET STRING (SIZE (4))		SYNTAX OCTET STRING (SIZE (4))
	InetAddressIPv6 ::= TEXTUAL-CONVENTION		InetAddressIPv6 ::= TEXTUAL-CONVENTION
	DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x@4d"		DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Represents an IPv6 network address:		"Represents an IPv6 network address:
	octets contents encoding		octets contents encoding
	1-16 IPv6 address network-byte order		1-16 IPv6 address network-byte order
	17-20 scope identifier network-byte order		17-20 scope identifier network-byte order
	The corresponding InetAddressType value is ipv6(2).		The corresponding InetAddressType value is ipv6(2).
	The scope identifier (bytes 17-20) MUST NOT be present		The scope identifier (bytes 17-20) MUST NOT be present
	for global IPv6 addresses. For non-global IPv6 addresses		for global IPv6 addresses. For non-global IPv6 addresses
	(e.g. link-local or site-local addresses), the scope		(e.g. link-local or site-local addresses), the scope
	identifier MUST always be present.		identifier MUST always be present. It contains a link
			identifier for link-local and a site identifier for
			site-local IPv6 addresses.
	The scope identifier contains an interface index value		The scope identifier MUST disambiguate identical address
	(ifIndex) for the interface on which the address is		values. For link-local addresses, the scope identifier will
	configured for link-local IPv6 addresses. The ifIndex		typically be the interface index (ifIndex as defined in the
	value MUST conform to the InterfaceIndex textual		IF-MIB, RFC 2233) of the interface on which the address is
	convention defined in the IF-MIB (RFC 2233).		configured.
	The scope identifier contains a site identifier for		The scope identifier may contain the special value 0
	site-local IPv6 addresses."		which refers to the default scope. The default scope
			may be used in cases where e.g. a management application
			needs to write a site-local InetAddressIPv6 address
			without knowing the site identifier value. The default
			scope SHOULD NOT be used as an easy way out in cases
			where the scope identifier for a non-global IPv6 is
			known."
	SYNTAX OCTET STRING (SIZE (16|20))		SYNTAX OCTET STRING (SIZE (16|20))
	InetAddressDNS ::= TEXTUAL-CONVENTION		InetAddressDNS ::= TEXTUAL-CONVENTION
	DISPLAY-HINT "255a"		DISPLAY-HINT "255a"
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Represents a DNS domain name. The name SHOULD be		"Represents a DNS domain name. The name SHOULD be
	fully qualified whenever possible.		fully qualified whenever possible.
	The corresponding InetAddressType is dns(16).		The corresponding InetAddressType is dns(16).
	skipping to change at page 10, line 23 ¶		skipping to change at page 10, line 23 ¶
	Subtyping binds the MIB module to specific address formats, which		Subtyping binds the MIB module to specific address formats, which
	may cause serious problems if new address formats need to be		may cause serious problems if new address formats need to be
	introduced. Note that it is possible to write compliance statements		introduced. Note that it is possible to write compliance statements
	in order to express that only a subset of the defined address types		in order to express that only a subset of the defined address types
	must be implemented to be compliant.		must be implemented to be compliant.
	Internet addresses MUST always be represented by a pair of		Internet addresses MUST always be represented by a pair of
	InetAddressType/InetAddress objects. It is not allowed to "share" an		InetAddressType/InetAddress objects. It is not allowed to "share" an
	InetAddressType between multiple InetAddress objects. Furthermore,		InetAddressType between multiple InetAddress objects. Furthermore,
	the InetAddressType object must be registered immediately before the		the InetAddressType object must be registered immediately before the
	InetAddress object. In other words, the OIDs for the InetAddressType		InetAddress object. In other words, the object identifiers for the
	object and the InetAddress object MUST have the same length and the		InetAddressType object and the InetAddress object MUST have the same
	last sub-identifier of the InetAddressType object MUST be 1 less		length and the last sub-identifier of the InetAddressType object
	than the last sub-identifier of the InetAddress object.		MUST be 1 less than the last sub-identifier of the InetAddress
			object.
	4.1 Table Indexing		4.1 Table Indexing
	When a generic Internet address is used as an index, both the		When a generic Internet address is used as an index, both the
	InetAddressType and InetAddress objects MUST be used. The		InetAddressType and InetAddress objects MUST be used. The
	InetAddressType object MUST come immediately before the InetAddress		InetAddressType object MUST come immediately before the InetAddress
	object in the INDEX clause. If multiple Internet addresses are used		object in the INDEX clause. If multiple Internet addresses are used
	in the INDEX clause, then every Internet address must be represented		in the INDEX clause, then every Internet address must be represented
	by a pair of InetAddressType and InetAddress objects.		by a pair of InetAddressType and InetAddress objects.
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 12 ¶
	o issue GetNext requests for specific type and address prefix.		o issue GetNext requests for specific type and address prefix.
	4.2 Uniqueness of Addresses		4.2 Uniqueness of Addresses
	IPv4 addresses were intended to be globally unique, current usage		IPv4 addresses were intended to be globally unique, current usage
	notwithstanding. IPv6 addresses were architected to have different		notwithstanding. IPv6 addresses were architected to have different
	scopes and hence uniqueness [21]. In particular, IPv6 "link-local"		scopes and hence uniqueness [21]. In particular, IPv6 "link-local"
	and "site-local" addresses are not guaranteed to be unique on any		and "site-local" addresses are not guaranteed to be unique on any
	particular node. In such cases, the duplicate addresses must be		particular node. In such cases, the duplicate addresses must be
	configured on different interfaces, so the combination of an IPv6		configured on different interfaces. So the combination of an IPv6
	address and an interface number is unique.		address and an interface number is unique. The interface number may
			therefore be used as a scope identifier.
	The InetAddressIPv6 textual convention has been defined to represent		The InetAddressIPv6 textual convention has been defined to represent
	global and non-global IPv6 addresses. MIB designers who use		global and non-global IPv6 addresses. MIB designers who use
	InetAddressType/InetAddress pairs therefore do not need to worry		InetAddressType/InetAddress pairs therefore do not need to worry
	about link-local or site-local addresses.		about link-local or site-local addresses.
	The size of the scope identifier has been choosen so that it matches		The size of the scope identifier has been choosen so that it matches
	the sin6_scope_id field of the sockaddr_in6 structure defined in RFC		the sin6_scope_id field of the sockaddr_in6 structure defined in RFC
	2553 [22].		2553 [22].
	skipping to change at page 14, line 5 ¶		skipping to change at page 13, line 48 ¶
	and IPv6 addresses."		and IPv6 addresses."
	OBJECT peerAddress		OBJECT peerAddress
	SYNTAX InetAddress (SIZE(4|16))		SYNTAX InetAddress (SIZE(4|16))
	DESCRIPTION		DESCRIPTION
	"An implementation is only required to support IPv4		"An implementation is only required to support IPv4
	and globally unique IPv6 addresses."		and globally unique IPv6 addresses."
	::= { somewhere 2 }		::= { somewhere 2 }
			Note that the SMIv2 does not allow to list not-accessible objects in
			an object group (see section 3.1 in STD 58, RFC 2580 [8]). It is
			therefore not possible to formally refine the syntax of auxiliary
			objects which are not-accessible. In such a case, it is suggested to
			express the refinement informally in the DESCRIPTION clause of the
			MODULE-COMPLIANCE macro invocation.
	6. Security Considerations		6. Security Considerations
	This module does not define any management objects. Instead, it		This module does not define any management objects. Instead, it
	defines a set of textual conventions which may be used by other MIB		defines a set of textual conventions which may be used by other MIB
	modules to define management objects.		modules to define management objects.
	Meaningful security considerations can only be written in the		Meaningful security considerations can only be written in the
	modules that define management objects.		modules that define management objects.
	7. Intellectual Property Notice		7. Intellectual Property Notice
End of changes. 17 change blocks.
	33 lines changed or deleted		54 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/