< draft-schoenw-opsawg-nm-dhc-03.txt   draft-schoenw-opsawg-nm-dhc-04.txt >
Internet Engineering Task Force J. Schoenwaelder Internet Engineering Task Force J. Schoenwaelder
Internet-Draft Jacobs University Bremen Internet-Draft Jacobs University Bremen
Intended status: Informational T. Tsou Intended status: Standards Track T. Tsou
Expires: September 13, 2012 C. Zhou Expires: December 07, 2013 C. Zhou
T. Taylor
Huawei Technologies Huawei Technologies
March 12, 2012 June 05, 2013
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
Network Management Protocols Network Management Protocols
draft-schoenw-opsawg-nm-dhc-03 draft-schoenw-opsawg-nm-dhc-04
Abstract Abstract
This document defines new Dynamic Host Configuration Protocol (DHCPv4 This document defines new Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) options providing lists of IP addresses that can be used and DHCPv6) options providing lists of IP addresses that can be used
to locate network management services. to locate network management services, specifically for the
collection of logs and of Simple Network Management Protocol (SNMP)
notifications.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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."
This Internet-Draft will expire on September 13, 2012. This Internet-Draft will expire on December 07, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DHC Options for SYSLOG . . . . . . . . . . . . . . . . . . . . 3 2. DHC Options for SYSLOG . . . . . . . . . . . . . . . . . . . 3
2.1. SYSLOG Collector Address Option for DHCPv4 . . . . . . . . 3 2.1. SYSLOG Collector Address Option for DHCPv4 . . . . . . . 3
2.2. SYSLOG Collector Address Option for DHCPv6 . . . . . . . . 4 2.2. SYSLOG Collector Address Option for DHCPv6 . . . . . . . 4
3. DHC Options for SNMP . . . . . . . . . . . . . . . . . . . . . 5 3. DHC Options for SNMP . . . . . . . . . . . . . . . . . . . . 5
3.1. SNMP Notification Receiver Address Option for DHCPv4 . . . 5 3.1. SNMP Notification Receiver Address Option for DHCPv4 . . 5
3.2. SNMP Notification Receiver Address Option for DHCPv6 . . . 6 3.2. SNMP Notification Receiver Address Option for DHCPv6 . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informational References . . . . . . . . . . . . . . . . . 8 7.2. Informational References . . . . . . . . . . . . . . . . 9
Appendix A. Relationship to the SNMP Configuration MIB Modules . 9 Appendix A. Relationship to the SNMP Configuration MIB Modules . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document defines new Dynamic Host Configuration Protocol (DHCPv4 New networks such as 3GPP Long Term Evolution (LTE) are being
[RFC2131] and DHCPv6 [RFC3315]) options providing lists of IP deployed today with tens of thousands of network nodes. All of these
addresses that can be used to locate network management services. nodes have to be configured and monitored for the network to operate
The Dynamic Host Configuration (DHC) options defined in this memo correctly. Any steps to automate this process will be helpful to
address some gaps identified for the automated configuration of large reduce the cost of deployment.
IP networks [I-D.ietf-opsawg-automated-network-configuration].
The Dynamic Host Configuration Protocol (DHCPv4 [RFC2131] and DHCPv6
[RFC3315]) is a relevant tool for this purpose. It provides a number
of existing options to allow a node to acquire its configuration file
and to locate key servers in the network. However, the existing
options have been defined more with end hosts than with network nodes
in mind. Network nodes require active management, and therefore need
to acquire the addresses of their management servers.
This document is specifically focussed on the requirement for event
reporting. To that end, it defines new DHCP options capable of
listing:
o one or more addresses of SYSLOG [RFC5424] collectors;
o one or more addresses of SNMP [RFC3410] entities hosting
Notification Receiver applications.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. DHC Options for SYSLOG 2. DHC Options for SYSLOG
The SYSLOG protocol [RFC5424] supports several transport mappings. The SYSLOG protocol [RFC5424] supports several transport mappings.
According to RFC 5424, implementations MUST support the TLS/TCP-based According to RFC 5424, implementations MUST support the TLS/TCP-based
transport defined in [RFC5425] and they SHOULD also support the UDP- transport defined in [RFC5425] and they SHOULD also support the UDP-
skipping to change at page 4, line 15 skipping to change at page 4, line 11
client wants to receive this information from the server, it needs to client wants to receive this information from the server, it needs to
include the number [IANA: TBD1] in the "DHCP Parameter Request List" include the number [IANA: TBD1] in the "DHCP Parameter Request List"
option (55). option (55).
Server addresses SHOULD be listed in order of preference, and the Server addresses SHOULD be listed in order of preference, and the
client SHOULD use the addresses sequentially but may be configured to client SHOULD use the addresses sequentially but may be configured to
use addresses in a different order according to some local policy use addresses in a different order according to some local policy
(e.g., the client prefers secure and/or congestion aware transports (e.g., the client prefers secure and/or congestion aware transports
as described above). as described above).
Historical note: DHCPv4 option 7 was originally defined
(Section 3.9 of [RFC2132]) to provide the addresses of one or more
log servers. However, the logging technology concerned was
specified to be "MIT-LCS UDP log servers". It seems preferable to
define a new option for SYSLOG collectors.
2.2. SYSLOG Collector Address Option for DHCPv6 2.2. SYSLOG Collector Address Option for DHCPv6
This section describes the SYSLOG IPv6 Address Option for DHCPv6. This section describes the SYSLOG IPv6 Address Option for DHCPv6.
The SYSLOG IPv6 Address Option begins with an option-code followed by The SYSLOG IPv6 Address Option begins with an option-code followed by
the option-len. The value of the option-len does not include itself the option-len. The value of the option-len does not include itself
or the option-code. The option layout is depicted below: or the option-code. The option layout is depicted below:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
IPv6 address of SYSLOG collector | IPv6 address of SYSLOG collector |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
skipping to change at page 7, line 15 skipping to change at page 7, line 15
In IPv6 networks using DHCPv6, it is recommended that clients use In IPv6 networks using DHCPv6, it is recommended that clients use
authentication of DHCPv6 messages as described in Section 21 of authentication of DHCPv6 messages as described in Section 21 of
[RFC3315]. [RFC3315].
In deployments where DHCPv4 or DHCPv6 authentication is not In deployments where DHCPv4 or DHCPv6 authentication is not
available, lower-layer security services may be sufficient to protect available, lower-layer security services may be sufficient to protect
DHCPv4 and DHCPv6 messages. DHCPv4 and DHCPv6 messages.
5. IANA Considerations 5. IANA Considerations
IANA is requested to assign [IANA: TBD1] as an option code from the IANA is requested to assign [IANA: TBD1] and [IANA: TBD3] as option
"DHCP Option Codes" registry. codes in the "DHCP Option Codes" registry. The desired entries are
shown in Table 1.
IANA is requested to assign [IANA: TBD2] as an option code from the +------+------------------+----------+------------------+-----------+
"DHCPv6 Options Codes" registry for OPTION_SYSLOG_COLLECTOR. | Tag | Name | Data | Meaning | Reference |
| | | Length | | |
+------+------------------+----------+------------------+-----------+
| TBD1 | SYSLOG Collector | N | N/4 SYSLOG | RFCxxxx |
| | Address | | collector | |
| | | | addresses | |
| TBD3 | SNMP | N | N/4 SNMP | RFCxxxx |
| | Notification | | Notification | |
| | Receiver Address | | Receiver | |
| | | | addresses | |
+------+------------------+----------+------------------+-----------+
IANA is requested to assign [IANA: TBD3] as an option code from the Table 1: DHCPv4 Option Codes For Network Management Servers
"DHCP Option Codes" registry.
IANA is requested to assign [IANA: TBD2] as an option code from the
"DHCPv6 Options Codes" registry for OPTION_SYSLOG_COLLECTOR, with
reference RFCxxxx.
IANA is requested to assign [IANA: TBD4] as an option code from the IANA is requested to assign [IANA: TBD4] as an option code from the
"DHCPv6 Options Codes" registry for OPTION_SNMP_NOT_RECEIVER. "DHCPv6 Options Codes" registry for OPTION_SNMP_NOT_RECEIVER, with
reference RFCxxxx.
RFC Editor's Note: RFCxxxx denotes the present document.
6. Acknowledgements 6. Acknowledgements
The authors like to thank Ralf Droms, Ted Lemon and Bernie Volz for The authors like to thank Ralf Droms, Ted Lemon and Bernie Volz for
their helpful comments. their helpful comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
RFC 2131, March 1997. 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, Management Protocol (SNMP) Applications", STD 62, RFC
RFC 3413, December 2002. 3413, December 2002.
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, Management Protocol (SNMP)", STD 62, RFC 3417, December
December 2002. 2002.
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol
Over Transmission Control Protocol Transport Mapping", Over Transmission Control Protocol Transport Mapping", RFC
RFC 3430, December 2002. 3430, December 2002.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer
Security (TLS) Transport Mapping for Syslog", RFC 5425, Security (TLS) Transport Mapping for Syslog", RFC 5425,
March 2009. March 2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
RFC 5426, March 2009. RFC 5426, March 2009.
skipping to change at page 8, line 38 skipping to change at page 9, line 7
[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng,
"Datagram Transport Layer Security (DTLS) Transport "Datagram Transport Layer Security (DTLS) Transport
Mapping for Syslog", RFC 6012, October 2010. Mapping for Syslog", RFC 6012, October 2010.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)", Model for the Simple Network Management Protocol (SNMP)",
RFC 6353, July 2011. RFC 6353, July 2011.
7.2. Informational References 7.2. Informational References
[I-D.ietf-opsawg-automated-network-configuration]
Tsou, T., Schoenwaelder, J., Shi, Y., and T. Taylor,
"Problem Statement for the Automated Configuration of
Large IP Networks",
draft-ietf-opsawg-automated-network-configuration-02 (work
in progress), October 2011.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
Appendix A. Relationship to the SNMP Configuration MIB Modules Appendix A. Relationship to the SNMP Configuration MIB Modules
The SNMP notification receiver address DHCPv4 and DHCPv6 options The SNMP notification receiver address DHCPv4 and DHCPv6 options
defined in Section 3.1 and Section 3.2 provide the basic information defined in Section 3.1 and Section 3.2 provide the basic information
to setup a target in the SNMP-TARGET-MIB and the SNMP-NOTIFICATION- to setup a target in the SNMP-TARGET-MIB and the SNMP-NOTIFICATION-
MIB [RFC3413]. After selecting the transport (e.g., by probing the MIB [RFC3413]. After selecting the transport (e.g., by probing the
skipping to change at page 9, line 46 skipping to change at page 10, line 13
structure for SNMPv3/USM user "joe" is as follows: structure for SNMPv3/USM user "joe" is as follows:
snmpTargetParamsName = "dhcp-xyz-param" (INDEX) snmpTargetParamsName = "dhcp-xyz-param" (INDEX)
snmpTargetParamsMPModel = 3 (SNMPv3) snmpTargetParamsMPModel = 3 (SNMPv3)
snmpTargetParamsSecurityModel = 3 (USM) snmpTargetParamsSecurityModel = 3 (USM)
snmpTargetParamsSecurityName = "joe" snmpTargetParamsSecurityName = "joe"
snmpTargetParamsSecurityLevel = authNoPriv(2) snmpTargetParamsSecurityLevel = authNoPriv(2)
snmpTargetParamsStorageType = volatile(2) snmpTargetParamsStorageType = volatile(2)
snmpTargetParamsRowStatus = active(1) snmpTargetParamsRowStatus = active(1)
Creating of a suitable entry in the snmpTargetParamsTable requires Creation of a suitable entry in the snmpTargetParamsTable requires
local information. Depending on the security model, additional local information. Depending on the security model, additional
information will be necessary. information will be necessary.
The creation of a suitable snmpTargetParamsTable entry may either be The creation of a suitable snmpTargetParamsTable entry may either be
dynamic (i.e., the entry is created upon receipt of a DHC lease using dynamic (i.e., the entry is created upon receipt of a DHC lease using
some local policy information and deleted when the DHC lease expires) some local policy information and deleted when the DHC lease expires)
or suitable snmpTargetParamsTable entries may be pre-provisioned or suitable snmpTargetParamsTable entries may be pre-provisioned
based on the expected naming of the target entries that are created based on the expected naming of the target entries that are created
dynamically. Implementations may also pre-provision dynamically. Implementations may also pre-provision
snmpTargetAddrTable entries and only dynamically create suitable snmpTargetAddrTable entries and only dynamically create suitable
skipping to change at page 10, line 22 skipping to change at page 10, line 38
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
Bremen 28759 Bremen 28759
Germany Germany
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
Tina Tsou Tina Tsou
Huawei Technologies Huawei Technologies
Bantian, Longgang District 2330 Central Expressway
Shenzhen 518129 Santa Clara CA 95050
P.R. China USA
Email: tena@huawei.com
Email: Tina.Tsou.Zouting@huawei.com
Cathy Zhou Cathy Zhou
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China P.R. China
Email: cathyzhou@huawei.com Email: cathyzhou@huawei.com
Tom Taylor
Huawei Technologies
Ottawa
Canada
Email: tom.taylor.stds@gmail.com
 End of changes. 24 change blocks. 
57 lines changed or deleted 95 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/