INTERNET-DRAFT B.Liu
Intended Status: Standard Track S.Jiang
Expires: September 8, 2011 Huawei Technologies Co., Ltd
March 7, 2011
SLAAC/DHCPv6 conflicts diagnostic during site renumbering
draft-liu-ipv6-renum-conflicts-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.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2011 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
B.Liu & S.Jiang Expires September 8, 2011 [Page 1]
INTERNET DRAFT draft-liu-ipv6-renum-conflicts-00 March 7, 2011
Abstract
While an IPv6 site is being renumbered, both DHCPv6 and ND may be
used to reconfigure the host addresses. This may cause potential
address configuration conflicts during renumbering procedure. The
issue mainly include two situations: a) Address configuration method
conflict, which means a host receives a new prefix comes from another
address configuration protocol. b) Address prefix conflict, a host
receives both DHCPv6 and ND address configuration messages which
assign different address prefixes. This documents analyzes the
conflict issues and proposes a conflict report mechanism for hosts to
report the conflicts to DHCPv6 servers.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 IPv6 renumbering . . . . . . . . . . . . . . . . . . . . . 3
1.2 DHCPv6/ND address configuration conflict . . . . . . . . . 3
2 Terminolog . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Conflict Report Mechanism . . . . . . . . . . . . . . . . . . . 5
3.1 Host behavior . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Conflict Report Trigger . . . . . . . . . . . . . . . . . . 5
3.3 DHCPv6 Reconfiguration Conflict Options . . . . . . . . . . 6
3.4 Report processing by DHCPv6 server . . . . . . . . . . . . 6
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1 Normative References . . . . . . . . . . . . . . . . . . . 7
7.2 Informative References . . . . . . . . . . . . . . . . . . 7
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
B.Liu & S.Jiang Expires September 8, 2011 [Page 2]
INTERNET DRAFT draft-liu-ipv6-renum-conflicts-00 March 7, 2011
1 Introduction
1.1 IPv6 renumbering
"Renumbering" is an event of changing in IP addressing information
associated with a host or subnet [RFC1900]. [RFC5887] and
[I-D.chown-v6ops-renumber-thinkabout] described numerous reasons why
such sites might need to renumber in a planned fashion, for example,
change of site topology, change of service provider etc.
[RFC4192] provided a general procedure of renumbering in an IPv6
network, which is achieved by changing address prefix. Before the old
prefix is withdrawn, the hosts are assigned a new prefix. Both the
old and the new prefixes may be usable till the new prefix is stable
in the site systems, such as DNS, ACL .etc. Then the old prefix will
be withdrawn. The transition periods are variable according to
different network management settings.
[RFC4192] also mentioned several methods to reconfigure addresses
while renumbering:
o Stateful address configuration through Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) protocol [RFC3315]
o Stateless address configuration through Neighbor Discovery
Protocol[RFC4861] (SLAAC) [RFC4862]
o Manual configuration
This document focuses on the address reconfiguration problem and
there is a specific issue of IPv6 site renumbering described as the
following.
1.2 DHCPv6/ND address configuration conflict
Both of the DHCPv6 and ND protocols have IP address configuration
function. They are suitable for different scenarios respectively.
During renumbering, the SLAAC-configured hosts can reconfigure IP
addresses by receiving ND Router Advertisement (RA) messages
containing new prefix information. The DHCPv6-configured hosts can
reconfigure addresses by initialing RENEW sessions when the current
addresses' lease time is expired or receiving the reconfiguration
messages initialed by the DHCPv6 servers.
But DHCPv6 and ND address configuration may overlap and cause
conflict on a host. The issue includes two situations:
- A DHCPv6-configured host receives RA messages containing new
B.Liu & S.Jiang Expires September 8, 2011 [Page 3]
INTERNET DRAFT draft-liu-ipv6-renum-conflicts-00 March 7, 2011
prefix
Ideally, hosts in a DHCPv6-managed network should not receive any ND
address configuration messages to avoid potential confusion. But some
factors may cause this happen. For example, a sub-net of a DHCPv6-
managed network may be mis-configured to use SLAAC for address
configuration; or a DHCPv6-managed network contains hosts (some
specific types of Apple Mac computers, e.g.) that don't support
DHCPv6 as the default so that SLAAC will be used along with DHCPv6 as
a necessary supplement.
There are no standards specifying what approach should be taken by a
DHCPv6-configured host when it receives RA messages containing new
prefix. It depends on the operation system of the host and cannot be
predicted or controlled by the network. If the host accepts the new
prefix in RA, it may violet the DHCPv6-managed policies. But if it
ignores the RA messages and there are no DHCPv6 reconfiguration
messages received either, the renumbering would fail. What is worse,
the host may even receive both the RA messages and DHCP-v6
reconfiguration messages and finds the prefixes in the two protocols
are different. This means serious network configuration error
occurring.
- A SLAAC-configured finds DHCPv6 is in use
[RFC5887] and [I-D.jiang-ipv6-site-renum-guideline] mentioned RA
message of ND protocol contains a "Managed Configuration" flag to
indicate DHCPv6 is in use. But it is unspecified what behavior should
be taken when the host receives RA messages with "M" set to 1. The
gap of standard will cause ambiguous host behavior because it depends
on the operation system of the host.
The host may start a DHCPv6 session and receives the DHCPv6 address
configuration. It is also possible that the host finds the DHCPv6
assigned prefix is different from the prefix in the RA messages,
which means there is a serious network configuration error.
Another possibility is that the host may receive no response from any
DHCPv6 servers, which means the DHCPv6 service is not available and
the "Managed Configuration" flag was mis-configured.
These potential conflicts described above need to be addressed. This
document proposes a report mechanism for hosts to report the
conflicts to DHCPv6 servers. (The mis-configured "Managed
Configuration" flag issue described above is not addressed in this
document because there are no DHCPv6 servers available in that
circumstance. Whether it needs to report the conflict to routers or
some other servers such as network management systems needs further
B.Liu & S.Jiang Expires September 8, 2011 [Page 4]
INTERNET DRAFT draft-liu-ipv6-renum-conflicts-00 March 7, 2011
study.)
2 Terminolog
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 [RFC2119].
3 Conflict Report Mechanism
As analyzed above, while renumbering, hosts received address
configuration messages (either ND or DHCP protocol messages), if the
messages conflict with existing/previous configuration mechanism,
hosts report address configuration policy conflict information to the
network. And then they accept the address configuration indication
from the network.
The conflicts can be outlined as two types:
- Prefix conflict, which means prefixes in DHCPv6 and ND messages
are different.
- Address configuration method conflict, which means a host
receives a new prefix comes from another address configuration
protocol.
There are several approaches of the mechanism as the following
clauses.
3.1 Host behavior
For the DHCPv6-configured hosts, it assumes that they will monitor
the RA messages after being configured by DHCPv6.
For the SLAAC-configured hosts, it assumes that the hosts initially
explored the DHCPv6 servers based on having already chosen DHCPv6 as
high priority of address configuration protocol when it finds the
"Managed Configuration" flag is set.
3.2 Conflict Report Trigger
Rules for the hosts to trigger conflict reports are as the following:
- Prefix conflict trigger, a host will trigger the report when it
finds the prefixes are different in DHCPv6 and ND messages.
B.Liu & S.Jiang Expires September 8, 2011 [Page 5]
INTERNET DRAFT draft-liu-ipv6-renum-conflicts-00 March 7, 2011
- Address configuration method conflict trigger, a DHCPv6-managed
host receives a new prefix comes from RA messages.
3.3 DHCPv6 Reconfiguration Conflict Options
New DHCPv6 options could be defined respectively for the clients to
report conflicts to servers and for servers to response according to
analysis of the reported conflict details.
- Option_ReconfigConflict_Report
It is possible to include this option into the renew message. The
content of the option could be:
a) New available address prefix (prefix in RA e.g.).
b) Serious error of prefix conflict.
- Option_ReconfigConflict_Response
DHCPv6 server could response as the following possibilities
according to information got from the option:
a) Directly assigns new addresses to the hosts who report
conflicts.
b) Indicates hosts to make SLAAC according to RA messages
received.
c) Report the prefixes conflict to network management system.
3.4 Report processing by DHCPv6 server
When a DHCPv6 server receives the conflict reports, it should analyze
the report and decides whether to forward the report to relative
network management systems or indicate what approach should be taken
to the hosts through DHCPv6 messages defined in section 3.3, however,
the analysis processing of DHCPv6 servers is not in the scope of this
memo.
B.Liu & S.Jiang Expires September 8, 2011 [Page 6]
INTERNET DRAFT draft-liu-ipv6-renum-conflicts-00 March 7, 2011
4 Security Considerations
This document doesn't provide additional security considerations for
IPv6 site renumbering more than [RFC5887], [RFC4192] and other
relative documents.
For the conflict report mechanism, there is a potential threat that
any malicious host can fake conflict reports to DHCPv6 servers which
may disturb the network manager when the report is prefix conflict,
however, it cannot directly break the availability of the network.
5 IANA Considerations
This document requests IANA to assign new DHCPv6 option number.(TBD)
6 Acknowledgements
This document inherits various previous work. Thanks for Brian
Carpenter, Randall Atkinson, Hannu Flinck, Fred Baker, Eliot Lear,
Ralph Droms, Tim J. Chown, Mark K. Thompson, Alan Ford, and Stig
Venaas.
7 References
7.1 Normative References
[RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6(DHCPv6)", RFC 3315, July 2003.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
Soliman,"Neighbor Discovery for IP version 6 (IPv6)", RFC
4861,September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
7.2 Informative References
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck,"Renumbering
Still Needs Work", RFC 5887, May 2010.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC
4192, September 2005.
[I-D.jiang-ipv6-site-renum-guideline]
Jiang, S., and Liu B., "IPv6 Site Renumbering Guidelines
B.Liu & S.Jiang Expires September 8, 2011 [Page 7]
INTERNET DRAFT draft-liu-ipv6-renum-conflicts-00 March 7, 2011
and Further Works", working in progress.
[I-D.chown-v6ops-renumber-thinkabout]
Chown, T., and Thompson, M., "Things to think about when
Renumbering an IPv6 network", September 2006.
Author's Addresses
Bing Liu
Huawei Technologies Co., Ltd
Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Email: leo.liubing@huawei.com
Sheng Jiang
Huawei Technologies Co., Ltd
Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Email: jiangsheng@huawei.com
B.Liu & S.Jiang Expires September 8, 2011 [Page 8]