One document matched: draft-schoenw-opsawg-nm-dhc-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2132 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml">
<!ENTITY RFC3118 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml">
<!ENTITY RFC3315 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3410 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY RFC3413 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3413.xml">
<!ENTITY RFC3417 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3417.xml">
<!ENTITY RFC3430 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3430.xml">
<!ENTITY RFC5424 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY RFC5425 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5425.xml">
<!ENTITY RFC5426 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5426.xml">
<!ENTITY RFC5592 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5592.xml">
<!ENTITY RFC6012 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6012.xml">
<!ENTITY RFC6353 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6353.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-schoenw-opsawg-nm-dhc-04"
ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="DHC Options for Network Management">
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options
for Network Management Protocols
</title>
<author fullname="Juergen Schoenwaelder"
initials="J." surname="Schoenwaelder">
<organization>Jacobs University Bremen</organization>
<address>
<postal>
<street>Campus Ring 1</street>
<code>28759</code>
<city>Bremen</city>
<country>Germany</country>
</postal>
<email>j.schoenwaelder@jacobs-university.de</email>
</address>
</author>
<author fullname="Tina Tsou"
initials="T." surname="Tsou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>CA 95050</code>
<country>USA</country>
</postal>
<email>Tina.Tsou.Zouting@huawei.com</email>
</address>
</author>
<author fullname="Cathy Zhou"
initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<code>518129</code>
<city>Shenzhen</city>
<country>P.R. China</country>
</postal>
<email>cathyzhou@huawei.com</email>
</address>
</author>
<author initials="T." surname="Taylor" fullname="Tom Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<region></region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
</address>
</author>
<date year="2013"/>
<area>Operations and Management</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>
This document defines new Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) options providing lists of IP addresses
that can be used to locate network management services, specifically
for the collection of logs and of Simple Network Management Protocol
(SNMP) notifications.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
New networks such as 3GPP Long Term Evolution (LTE) are being deployed
today with tens of thousands of network nodes. All of these nodes have to
be configured and monitored for the network to operate correctly. Any
steps to automate this process will be helpful to reduce the cost of
deployment. </t>
<t>The Dynamic Host Configuration Protocol (<xref target="RFC2131">
DHCPv4 </xref> and <xref target="RFC3315"> DHCPv6 </xref>) 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. </t>
<t>This document is specifically focussed on the requirement for event
reporting. To that end, it defines new DHCP options capable of listing:
<list style="symbols">
<t>one or more addresses of SYSLOG <xref target="RFC5424"/> collectors;</t>
<t>one or more addresses of SNMP <xref target="RFC3410"/> entities
hosting Notification Receiver applications.</t>
</list>
</t>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 <xref target="RFC2119"></xref>.
</t>
</section>
<section anchor="syslog" title="DHC Options for SYSLOG">
<t>
The SYSLOG protocol <xref target="RFC5424"/> supports several
transport mappings. According to RFC 5424, implementations
MUST support the TLS/TCP-based transport defined in
<xref target="RFC5425"/> and they SHOULD also support the
UDP-based transport defined in <xref target="RFC5426"/> for
compatibility with traditional SYSLOG. An optional transport
of SYSLOG messages over DTLS/DCCP and DTLS/UDP is defined in
<xref target="RFC6012"/>.
</t>
<t>
The DHC options described below provide a list of IPv4 or IPv6
addresses of SYSLOG collectors in order of preference. The
client SHOULD use the addresses sequentially but may be
configured to try secure and/or congestion aware transports
before falling back to transports that are not congestion
aware or insecure. As such, the client may prefer to select an
address providing a secure congestion aware transport even if
it is listed with lower preference.
</t>
<section anchor="syslog-v4"
title="SYSLOG Collector Address Option for DHCPv4">
<t>
This section describes the SYSLOG IPv4 Address Option for
DHCPv4. The SYSLOG IPv4 Address Option begins with an
option code followed by a length octet. The value of the
length octet does not include itself or the option code.
The option layout is depicted below:
</t>
<figure>
<artwork>
Code Len IPv4 Address 1 IPv4 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| TBD1| n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
</artwork>
</figure>
<t>
The code for the SYSLOG DHCPv4 option is [IANA: TBD1]. The
minimum length of the option is 4 octets, and the length
MUST always be a multiple of 4.
</t>
<t>
The option MUST NOT be specified by the DHCPv4 client, as it
is intended only to be returned from the DHCPv4 server. If
the DHCPv4 client wants to receive this information from the
server, it needs to include the number [IANA: TBD1] in the
"DHCP Parameter Request List" option (55).
</t>
<t>
Server addresses SHOULD be listed in order of preference,
and the client SHOULD use the addresses sequentially but may
be configured to use addresses in a different order
according to some local policy (e.g., the client prefers
secure and/or congestion aware transports as described
above).
</t>
<t><list style="empty">
<t>Historical note: DHCPv4 option 7 was originally defined (Section 3.9 of
<xref target="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.</t>
</list></t>
</section>
<section anchor="syslog-v6"
title="SYSLOG Collector Address Option for DHCPv6">
<t>
This section describes the SYSLOG IPv6 Address Option for
DHCPv6. 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 or the option-code. The
option layout is depicted below:
</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
IPv6 address of SYSLOG collector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The option-code of the SYSLOG DHCPv6 option
OPTION_SYSLOG_COLLECTOR is [IANA: TBD2]. The minimum
option-len is 16 octets, and the length MUST always be a
multiple of 16.
</t>
<t>
The option MUST NOT appear in other than the following
messages: Solicit, Advertise, Request, Renew, Rebind,
Information-Request and Reply. The option number for these
options MAY appear in the Option Request Option (6) in the
following messages: Solicit, Request, Renew, Rebind,
Information-Request and Reconfigure.
</t>
<t>
The addresses SHOULD be listed in order of preference, and
the client SHOULD use the addresses sequentially but may be
configured to use addresses in a different order according
to some local policy (e.g., the client prefers secure and/or
congestion aware transports as described above).
</t>
</section>
</section>
<section anchor="snmp" title="DHC Options for SNMP">
<t>
The SNMP protocol <xref target="RFC3410"/> supports several
transport mappings. The preferred IP-based transport is SNMP
over UDP <xref target="RFC3417"/>. An experimental transport
of SNMP over TCP is defined in <xref target="RFC3430"/>. An
optional standards-track transport of SNMP over SSH is defined
in <xref target="RFC5592"/> while optional standards-track
transports over TLS and DTLS are defined in
<xref target="RFC6353"/>
</t>
<t>
The DHC options described below provide a list of IPv4 or IPv6
addresses of SNMP entities hosting Notification Receiver
applications in order of preference. The client SHOULD use the
addresses sequentially but may be configured to try secure
and/or congestion aware transports before falling back to
transports that are not congestion aware or insecure. As such,
the client may prefer to select an address providing a secure
congestion aware transport even if it is listed with lower
preference.
</t>
<section anchor="snmp-v4"
title="SNMP Notification Receiver Address Option for DHCPv4">
<t>
This section describes the SNMP IPv4 Address Option for
DHCPv4. The SNMP IPv4 Address Option begins with an option
code followed by a length octet. The value of the length
octet does not include itself or the option code. The
option layout is depicted below:
</t>
<figure>
<artwork>
Code Len IPv4 Address 1 IPv4 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| TBD3| n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
</artwork>
</figure>
<t>
The code for the SNMP notification receiver DHCPv4 option is
[IANA: TBD3]. The minimum length of the option is 4 octets,
and the length MUST always be a multiple of 4.
</t>
<t>
The option MUST NOT be specified by the DHCPv4 client, as it
is intended only to be returned from the DHCPv4 server. If
the DHCPv4 client wants to receive this information from the
server, it needs to include the number [IANA: TBD3] in the
"DHCP Parameter Request List" option (55).
</t>
<t>
The addresses SHOULD be listed in order of preference, and
the client SHOULD use the addresses sequentially but may be
configured to use addresses in a different order according
to some local policy (e.g., the client prefers secure and/or
congestion aware transports as described above).
</t>
</section>
<section anchor="snmp-v6"
title="SNMP Notification Receiver Address Option for DHCPv6">
<t>
This section describes the SNMP IPv6 Address Option for
DHCPv6. The SNMP IPv6 Address Option begins with an
option-code followed by the option-len. The value of the
option-len does not include itself or the option-code. The
option layout is depicted below:
</t>
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| IPv6 address of SNMP notification receiver |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The option-code of the SNMP notification receiver DHCPv6
option OPTION_SNMP_NOT_RECEIVER is [IANA: TBD4]. The minimum
option-len is 16 octets, and the length MUST always be a
multiple of 16.
</t>
<t>
The option MUST NOT appear in other than the following
messages: Solicit, Advertise, Request, Renew, Rebind,
Information-Request and Reply. The option number for these
options MAY appear in the Option Request Option (6) in the
following messages: Solicit, Request, Renew, Rebind,
Information-Request and Reconfigure.
</t>
<t>
Server addresses SHOULD be listed in order of preference,
and the client SHOULD use the addresses sequentially but may
be configured to use addresses in a different order
according to some local policy (e.g., the client prefers
secure and/or congestion aware transports as described
above).
</t>
</section>
</section>
<section anchor="sec" title="Security Considerations">
<t>
The security considerations in <xref target="RFC2131"/> and
<xref target="RFC3315"/>) apply. If an adversary manages to
modify the response from a DHCPv4 or DHCPv6 server or insert
its own response, a node could be led to contact a rogue
network management server.
</t>
<t>
It is recommended to use the DHCPv4 authentication option
described in <xref target="RFC3118"/> where available. This
will also protect against denial-of-service attacks to DHCP
servers. <xref target="RFC3118"/> provides mechanisms for
both entity authentication and message authentication.
</t>
<t>
In IPv6 networks using DHCPv6, it is recommended that clients
use authentication of DHCPv6 messages as described in Section
21 of <xref target="RFC3315"/>.
</t>
<t>
In deployments where DHCPv4 or DHCPv6 authentication is not
available, lower-layer security services may be sufficient to
protect DHCPv4 and DHCPv6 messages.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is requested to assign [IANA: TBD1] and [IANA: TBD3] as option codes
in the "DHCP Option Codes" registry. The desired entries are shown in
<xref target="tab_dhcpv4"/>.
</t>
<texttable anchor="tab_dhcpv4" title="DHCPv4 Option Codes For Network Management Servers">
<ttcol align="left">Tag</ttcol>
<ttcol align="center">Name</ttcol>
<ttcol align="left">Data Length</ttcol>
<ttcol align="center">Meaning</ttcol>
<ttcol align="center">Reference</ttcol>
<c>TBD1</c>
<c>SYSLOG Collector Address</c>
<c>N</c>
<c>N/4 SYSLOG collector addresses</c>
<c>RFCxxxx</c>
<c>TBD3</c>
<c>SNMP Notification Receiver Address</c>
<c>N</c>
<c>N/4 SNMP Notification Receiver addresses</c>
<c>RFCxxxx</c>
</texttable>
<t>
IANA is requested to assign [IANA: TBD2] as an option code
from the "DHCPv6 Options Codes" registry for
OPTION_SYSLOG_COLLECTOR, with reference RFCxxxx.
</t>
<t>
IANA is requested to assign [IANA: TBD4] as an option code
from the "DHCPv6 Options Codes" registry for
OPTION_SNMP_NOT_RECEIVER, with reference RFCxxxx.
</t>
<t>RFC Editor's Note: RFCxxxx denotes the present document.</t>
</section>
<section title="Acknowledgements">
<t>
The authors like to thank Ralf Droms, Ted Lemon and Bernie
Volz for their helpful comments.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC2131;
&RFC2132;
&RFC3118;
&RFC3315;
&RFC3413;
&RFC3417;
&RFC3430;
&RFC5424;
&RFC5425;
&RFC5426;
&RFC5592;
&RFC6012;
&RFC6353;
</references>
<references title="Informational References">
&RFC3410;
</references>
<section title="Relationship to the SNMP Configuration MIB Modules">
<t>
The SNMP notification receiver address DHCPv4 and DHCPv6
options defined in <xref target="snmp-v4"/> and
<xref target="snmp-v6"/> provide the basic information to
setup a target in the SNMP-TARGET-MIB and the
SNMP-NOTIFICATION-MIB <xref target="RFC3413"/>. After
selecting the transport (e.g., by probing the availability of
possible SNMP transport endpoints according to some local
policy, a volatile entry in the snmpTargetTable can be created
as follows (assuming xyz is some suitable unique handle for
the received DHCP option):
</t>
<figure>
<artwork>
snmpTargetAddrName = "dhcp-xyz" (INDEX)
snmpTargetAddrTDomain = snmpUDPDomain
snmpTargetAddrTAddress = "a.b.c.d"
snmpTargetAddrTimeout = 1500 (DEFVAL)
snmpTargetAddrRetryCount = 3 (DEFVAL)
snmpTargetAddrTagList = "dhcp-xyz-tag"
snmpTargetAddrParams = "dhcp-xyz-param"
snmpTargetAddrStorageType = volatile(2)
snmpTargetAddrRowStatus = active(1)
</artwork>
</figure>
<t>
A matching volatile entry in the snmpNotifyTable can also be
easily created:
</t>
<figure>
<artwork>
snmpNotifyName = "dhcp-xyz" (INDEX)
snmpNotifyTag = "dhcp-xyz-tag"
snmpNotifyType = trap(1) (DEFVAL)
snmpNotifyStorageType = volatile(2)
snmpNotifyRowStatus = active(1)
</artwork>
</figure>
<t>
In addition, an entry in the snmpTargetParamsTable is needed.
Its structure for SNMPv3/USM user "joe" is as follows:
</t>
<figure>
<artwork>
snmpTargetParamsName = "dhcp-xyz-param" (INDEX)
snmpTargetParamsMPModel = 3 (SNMPv3)
snmpTargetParamsSecurityModel = 3 (USM)
snmpTargetParamsSecurityName = "joe"
snmpTargetParamsSecurityLevel = authNoPriv(2)
snmpTargetParamsStorageType = volatile(2)
snmpTargetParamsRowStatus = active(1)
</artwork>
</figure>
<t>
Creation of a suitable entry in the snmpTargetParamsTable
requires local information. Depending on the security model,
additional information will be necessary.
</t>
<t>
The creation of a suitable snmpTargetParamsTable entry may
either be 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) or suitable snmpTargetParamsTable
entries may be pre-provisioned based on the expected naming of
the target entries that are created dynamically.
Implementations may also pre-provision snmpTargetAddrTable
entries and only dynamically create suitable snmpNotifyTable
entries.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:34:55 |