Internet DRAFT - draft-chen-ntps-ra-opt
draft-chen-ntps-ra-opt
Network Working Group Xu Chen
Internet Draft DaCheng Zhang
Intended status: Standard Huawei Technologies Co., Ltd.
Expires: August 2010 February 25, 2010
The IPv6 Router Advertisement Option for NTP Configuration
draft-chen-ntps-ra-opt-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 25, 2010.
Chen Expires August 25, 2010 [Page 1]
Internet-Draft The IPv6 Router Advertisement Option February 2010
for NTP Configuration
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.
Abstract
This document defines a new ND option, called the NTPS option, that
contains the Server location information of Network Time Protocol
version 4[draft-ntpv4] or greater. Therefore, hosts can get such
information in the same RA message transporting the information of IP
address configuration. In this spec, both ND transport mechanisms
(i.e., advertisements and solicitations) are considered.
Table of Contents
1. Introduction................................................3
2. Definitions.................................................3
3. Terminologies...............................................3
4. Requirement for an NTP Server option........................4
5. Neighbor Discovery Extension................................5
6. Interworking among IPv6 NTP Configuration Approaches........5
7. Security Considerations.....................................6
8. IANA Considerations.........................................6
9. References..................................................7
9.1. Normative References...................................7
9.2. Informative References.................................7
10. Acknowledgments............................................7
Chen Expires August 25, 2010 [Page 2]
Internet-Draft The IPv6 Router Advertisement Option February 2010
for NTP Configuration
1. Introduction
Beside manual address assignment, several mechanisms have been
developed to facilitate IPv6 address assignment. One of the most
convenient methods is Stateless Address Autoconfiguration (SLAAC)
[RFC2462]. SLAAC use Neighbor Discovery [RFC4861] as an underlining
protocol. IPv6 host need only connect to a network with an
advertisement router and periodically receive multicast Router
Advertisement (RA) on the link. This RA message contains address and
link information, like IPv6 prefix and link MTU, to configure a
global unicast address. As a complementary method to provide
necessary material for an IPv6 host connection to internet and ISP
management requirement, DNS Server extension has been defined in
[RFC5006].
Another address assignment is based on Dynamic Host Configuration
Protocol for IPv6 (DHCPv6). It has been standardized in [RFC3315].
Necessary configuration parameters pass from DHCP Server to DHCP
enabled IPv6 host. This protocol can be used in a stateful way which
provides address assignment separately or in a stateless way that is
combination of DHCPv6 and SLAAC. The later case has been specified in
[RFC3736]. IPv6 Host first configures one or more interfaces through
SLAAC and then reach stateless DHCP server for additional parameters.
At the time of writing this spec, the stateless and stateful address
assignment mechanisms are deployed over networks in an ad hoc way.
Therefore, an extension in SLAAC normally has an analogue which
provides similar functionality in DHCP. For instance, Deployment
scenarios for DNS server address configuration with stateless and
stateful methods have been compared in [RFC4339]. NTP server
addresses, just same as DNS server addresses, are common information
to all IPv6 host in a subnet. [DHCPv6-NTP-Option] proposes a DHCP
based solution in order to facilitate hosts to access NTP server
accessing information. The spec introduces an analogue of this
solution in SLAAC.
2. Definitions
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.
Chen Expires August 25, 2010 [Page 3]
Internet-Draft The IPv6 Router Advertisement Option February 2010
for NTP Configuration
3. Terminologies
RA: Router Advertisement
RS: Router Solicitation
NTP: Network Time Protocol
ND: Neighbor Discovery
NTPS: NTP Server
SNTP: Simple Network Time Protocol
4. Requirement for an NTP Server option
When newly attaching to a network, a host can get essential knowledge
to configure its IP address via RA messages advertised by a local
router. Typically, a router advertises RA messages periodically. Also,
hosts can query RAs using Router Solicitations (RSs). Apart from the
instruction of IP address configuration, RAs are also used to
transport other useful information (e.g., IP addresses of DNS
servers). Same as DNS servers, NTP servers are core components of the
Internet infrastructure. A NTP server can provide time and
synchronization services for hosts in the network, which are critical
for many applications (e.g., security mechanisms). The reasons of
using RAs to transport the prefix information option based on the ND
protocol [RFC4861] are very similar with those of using RAs to
transport the information of DNS servers [RFC5006]:
1. It is possible for a host to access the nearest NTP server so as
to reduce the latency imposed by transporting packets.
2. NTPS option is an extension of RA. This does not change the base
functions of existing ND/SLAAC mechanism.
3. All the information a host needs to run the basic Internet
applications (such as the clock synchronization, timestamp
verification, certificate expiration check, etc.) can be obtained
with the addition of this option to ND and address
autoconfiguration.
4. The use of a single mechanism is more reliable and easier to
provide. Debugging problems when multiple protocol mechanisms are
being used is harder and much more complex.
Chen Expires August 25, 2010 [Page 4]
Internet-Draft The IPv6 Router Advertisement Option February 2010
for NTP Configuration
5. This mechanism works over a broad range of scenarios and leverages
IPv6 ND. This works well on links that are high performance (e.g.,
Ethernet LANs) and low performance (e.g., cellular networks). In the
latter case, by combining the NTPS information with the other
information in the RA, the host can learn all the information needed
to use most Internet applications in a single packet. This not only
saves bandwidth, but also minimizes the delay needed to learn the
NTPS information.
The following figure shows an example topology from this scenario.
+------------------------------------------------+
| |
| Router NTP Server |
| | |
| | |
| +----+----+-------+--------+----+-----+ |
| | | | | |
| Host Host Host Host |
| |
| |
+------------------------------------------------+
Figure 1 Topology.
5. Neighbor Discovery Extension
The proposed IPv6 NTP Server configuration mechanism introduces a new
ND option in Neighbor Discovery called the NTP Server (NTPS) option
which serves as a container for the Server location information
related to a NTP Server or a SNTP Server. The analogue of this
mechanism is proposed in DHCPv6 [DHCPv6-NTP-Option]. The NTPS
extension option in [DHCPv6-NTP-Option] holds the NTP server address
information and performs a similar function with the NTPS option in
this spec. In the future version of this draft, it will reference
section 6, [DHCPv6-NTP-Option] and include detailed format of NTPS
option.
6. Interworking among IPv6 NTP Configuration Approaches
The NTPS (NTP Server) option and DHCP option can be used together. To
order the RA and DHCP approaches, the O (Other stateful configuration)
flag can be used in the RA message [RFC4861]. If no NTPS option is
included in the RA messages, an IPv6 host may perform NTP
configuration through DHCPv6 [DHCPv6-NTP-Config] regardless of
whether the O flag is set or not.
Chen Expires August 25, 2010 [Page 5]
Internet-Draft The IPv6 Router Advertisement Option February 2010
for NTP Configuration
7. Security Considerations
Because NTPS option does not change the base functions of existing
ND/SLAAC mechanism, it can be claimed that the RA option for NTPS has
vulnerabilities similar to those existing in current mechanisms. If
the Secure Neighbor Discovery (SEND) protocol is used as a security
mechanism for ND, all the ND options including the NTPS option are
automatically included in the signatures [RFC3971], so the NTPS
transport is integrity-protected.
8. IANA Considerations
The IANA need assign a new IPv6 Neighbor Discovery Option type for
NTPS option.
Chen Expires August 25, 2010 [Page 6]
Internet-Draft The IPv6 Router Advertisement Option February 2010
for NTP Configuration
9. References
9.1. Normative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4339] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC
3971, March 2005.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[DRAFT-NTPv4] Burbank, Kasch, Ed., Mills, Delaware, "Network Time
Protocol Version 4 Protocol And Algorithms Specification",
draft-ietf-ntp-ntpv4-proto-13, October 9, 2009.
[DHCPv6-NTP-Option] Gayraud, Lourdelet, "Network Time Protocol (NTP)
Server Option for DHCPv6", January 7, 2010
9.2. Informative References
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC5006] Jeong, Park, Beloeil, Madanapalli, " IPv6 Router
Advertisement Option for DNS Configuration", RFC 5006,
September 2007.
[RFC3315] Droms, R., Ed., "Dynamic Host Configuration Protocol for
IPv6(DHCPv6)", RFC 3315, July 2003.
10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Chen Expires August 25, 2010 [Page 7]
Internet-Draft The IPv6 Router Advertisement Option February 2010
for NTP Configuration
Authors' Addresses
Xu Chen
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-82836074
Email: chenxu0128@huawei.com
DaCheng Zhang
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-82836072
Email: zhangdacheng@huawei.com
Chen Expires August 25, 2010 [Page 8]
