draft-ietf-6renum-enterprise-00.txt   draft-ietf-6renum-enterprise-01.txt 
Network Working Group S. Jiang Network Working Group S. Jiang
Internet Draft B. Liu Internet Draft B. Liu
Intended status: Informational Huawei Technologies Co., Ltd Intended status: Informational Huawei Technologies Co., Ltd
Expires: August 9, 2012 B. Carpenter Expires: January 14, 2013 B. Carpenter
University of Auckland University of Auckland
February 6, 2012 July 16, 2012
IPv6 Enterprise Network Renumbering Scenarios and Guidelines IPv6 Enterprise Network Renumbering Scenarios and Guidelines
draft-ietf-6renum-enterprise-00.txt draft-ietf-6renum-enterprise-01.txt
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 working Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/. 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 August 9, 2012. This Internet-Draft will expire on January 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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.
Abstract Abstract
This document analyzes enterprise renumbering events and describes This document analyzes enterprise renumbering events and describes
the best current practice among the existing renumbering mechanisms. the best current practice among the existing renumbering mechanisms.
According to the different stages of renumbering events, According to the different stages of renumbering events,
considerations and best current practices are described in three considerations and best current practices are described in three
categories: during network design, for preparation of renumbering, categories: during network design, for preparation of renumbering,
and during a renumbering operation. A gap inventory is listed at the and during a renumbering operation.
end of this document.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction ................................................. 3
2. Enterprise Network Illustration for Renumbering .............. 3 2. Enterprise Network Illustration for Renumbering .............. 3
3. Enterprise Network Renumbering Scenario Categories ........... 4 3. Enterprise Network Renumbering Scenario Categories ........... 4
3.1. Renumbering caused by External Network Factors........... 5 3.1. Renumbering caused by External Network Factors........... 5
3.2. Renumbering caused by Internal Network Factors........... 5 3.2. Renumbering caused by Internal Network Factors........... 5
4. Network Renumbering Considerations and Best Current Practise . 5 4. Network Renumbering Considerations and Best Current Practices. 5
4.1. Considerations and Best Current Practice during Network 4.1. Considerations and Best Current Practices during Network
Design ...................................................... .6 Design ....................................................... 6
4.2. Considerations and Best Current Practice for the Preparation 4.2. Considerations and Best Current Practices for the Preparation
of Renumbering ............................................... 9 of Renumbering ............................................... 9
4.3. Considerations and Best Current Practice during Renumbering 4.3. Considerations and Best Current Practices during Renumbering
Operation ................................................... 10 Operation ................................................... 10
5. Gap Inventory ............................................... 12 5. Security Considerations ..................................... 12
6. Security Considerations ..................................... 13 6. IANA Considerations ......................................... 13
7. IANA Considerations ......................................... 13 7. Acknowledgements ............................................ 13
8. Acknowledgements ............................................ 13 8. Change Log [RFC Editor please remove] ....................... 13
9. Change Log [RFC Editor please remove] ....................... 14 9. References .................................................. 13
10. References ................................................. 14 9.1. Normative References ................................... 13
10.1. Normative References .................................. 14 9.2. Informative References ................................. 14
10.2. Informative References ................................ 15 Author's Addresses ............................................. 16
Author's Addresses ............................................. 17
1. Introduction 1. Introduction
IPv6 site renumbering is considered difficult. Network managers IPv6 site renumbering is considered difficult. Network managers
currently prefer to use Provider Independent (PI) addressing for IPv6 currently prefer to use Provider Independent (PI) addressing for IPv6
to attempt to minimize the need for future renumbering. However, to attempt to minimize the need for future renumbering. However,
widespread use of PI may create very serious BGP4 scaling problems widespread use of PI may create very serious BGP4 scaling problems
and PI space is not always available for enterprise according to the and PI space is not always available for enterprise according to the
RIR (Regional Internet Registry) policies. It is thus desirable to RIR (Regional Internet Registry) policies. It is thus desirable to
develop tools and practices that may make renumbering a simpler develop tools and practices that may make renumbering a simpler
skipping to change at page 6, line 24 skipping to change at page 6, line 24
renumbering that a network architect should carefully plan when renumbering that a network architect should carefully plan when
building or designing a new network. building or designing a new network.
- Prefix Delegation - Prefix Delegation
In a large or a multi-site enterprise network, the prefix should In a large or a multi-site enterprise network, the prefix should
be carefully managed, particularly during renumbering events. be carefully managed, particularly during renumbering events.
Prefix information needs to be delegated from router to router. Prefix information needs to be delegated from router to router.
The DHCPv6 Prefix Delegation options [RFC3633] [I-D.ietf-dhc-pd- The DHCPv6 Prefix Delegation options [RFC3633] [I-D.ietf-dhc-pd-
exclude] provide a mechanism for automated delegation of IPv6 exclude] provide a mechanism for automated delegation of IPv6
prefixes. DHCPv6 PD options may also be used between the prefixes. Normally, DHCPv6 PD options are used between the
enterprise routers and their upstream ISPs. internal enterprise routers.
- Usage of FQDN - Usage of FQDN
In general, Fully-Qualified Domain Names (FQDNs) are recommended In general, Fully-Qualified Domain Names (FQDNs) are recommended
to be used to configure network connectivity, such as tunnels, to be used to configure network connectivity, such as tunnels,
whenever possible. The capability to use FQDNs as endpoint names whenever possible. The capability to use FQDNs as endpoint names
has been standardized in several RFCs, such as [RFC5996], although has been standardized in several RFCs, such as [RFC5996], although
many system/network administrators do not realize that it is there many system/network administrators do not realize that it is there
and works well as a way to avoid manual modification during and works well as a way to avoid manual modification during
renumbering. renumbering.
Service Location Protocol [RFC2608] and multicast DNS with SRV Service Location Protocol [RFC2608] and multicast DNS with SRV
records for service discovery can reduce the number of places that records for service discovery can reduce the number of places that
IP addresses need to be configured. But it should be noted that IP addresses need to be configured. But it should be noted that
multicast DNS is link-local only. multicast DNS is link-local only.
- Usage of ULA
Unique Local Addresses (ULAs) are defined in [RFC4193] as
provider-independent prefixes, and they are globally unique to
avoid collision. For enterprise networks, using ULA along with PA
can provide a logically local routing plane separated from the
globally routing plane. The benefit is to ensure stable and
specific local communication regardless of the ISP uplink failure.
This benefit is especially meaningful for renumbering. It mainly
includes three use cases as the following.
When renumbering, as RFC4192 suggested, it has a period to keep
using the old prefix(es) before the new prefix(es) is(are) stable.
In the process of adding new prefix(es) and deprecating old
prefix(es), it is not easy to keep the local communication immune
of global routing plane change. If we use ULA for the local
communication, the separated local routing plane can isolate the
affecting by global routing change.
Enterprise administrators may want to avoid the need to renumber
their internal-only, private nodes when they have to renumber the
PA addresses of the whole network because of changing ISPs, ISPs
restructure their address allocations, or any other reasons. In
these situations, ULA is an effective tool for the internal-only
nodes.
For multicast, ULA may be a way of avoiding renumbering from
having an impact on multicast. In most deployments multicast is
only used internally (intra-domain), and the addresses used for
multicast sources and Rendezvous-Points need not be reachable nor
routable externally. Hence one may at least internally make use of
ULA for multicast specific infrastructure.
- Address Types - Address Types
This document focuses on the dynamically-configured global unicast This document focuses on the dynamically-configured global unicast
addresses in enterprise networks. They are the targets of addresses in enterprise networks. They are the targets of
renumbering events. renumbering events.
Manual-configured addresses are not scalable in medium to large Manual-configured addresses are not scalable in medium to large
sites, hence are out of scope. Manual-configured addresses/hosts sites, hence are out of scope. Manual-configured addresses/hosts
should be avoided as much as possible. should be avoided as much as possible.
Unique Local Addresses (ULA, [RFC4193]) may be used for local
communications, usually inside of enterprise networks. They can be
sufficient for any host that is accessible only inside the
enterprise network and has no need for external communication
[RFC4864]. Normally, they do not need to be changed during a
global prefix renumbering event. However, they may need to be
renumbered in some rare scenarios, quite separate from the global
prefix renumbering.
- Address configuration models - Address configuration models
In IPv6 networks, there are two auto-configuration models for In IPv6 networks, there are two auto-configuration models for
address assignment: Stateless Address Auto-Configuration (SLAAC) address assignment: Stateless Address Auto-Configuration (SLAAC)
by Neighbor Discovery (ND, [RFC4861, RFC4862]) and stateful by Neighbor Discovery (ND, [RFC4861, RFC4862]) and stateful
address configuration by Dynamic Host Configuration Protocol for address configuration by Dynamic Host Configuration Protocol for
IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also
support host-generated address model by assigning a prefix through support host-generated address model by assigning a prefix through
DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. DHCPv6 messages [I-D.ietf-dhc-host-gen-id].
skipping to change at page 7, line 38 skipping to change at page 8, line 13
and DHCPv6 server. and DHCPv6 server.
This document has no preference between ND and DHCPv6 address This document has no preference between ND and DHCPv6 address
configuration models. It is network architects' job to decide configuration models. It is network architects' job to decide
which configuration model is employed. But it should be noticed which configuration model is employed. But it should be noticed
that using DHCPv6 and ND together within one network, especially that using DHCPv6 and ND together within one network, especially
in one subnet, may cause operational issues. For example, some in one subnet, may cause operational issues. For example, some
hosts use DHCPv6 as the default configuration model while some use hosts use DHCPv6 as the default configuration model while some use
ND. Then the hosts' address configuration model depends on the ND. Then the hosts' address configuration model depends on the
policies of operating systems and cannot be controlled by the policies of operating systems and cannot be controlled by the
network. Section 5.1 of [I-D.liu-6renum-gap-analysis] discusses network. Section 5.1 of [I-D.ietf-6renum-gap-analysis] discusses
more details on this topic. So, in general, this document more details on this topic. So, in general, this document
recommends using DHCPv6/SLAAC independently in different subnets. recommends using DHCPv6/SLAAC independently in different subnets.
However, since DHCPv6 is also used to configure many other network However, since DHCPv6 is also used to configure many other network
parameters, there are ND and DHCPv6 co-existence scenarios. parameters, there are ND and DHCPv6 co-existence scenarios.
Combinations of address configuration models may coexist within a Combinations of address configuration models may coexist within a
single enterprise network. [I-D.ietf-savi-mix] provides single enterprise network. [I-D.ietf-savi-mix] provides
recommendations to avoid collisions and to review collision recommendations to avoid collisions and to review collision
handling in such scenarios. handling in such scenarios.
skipping to change at page 8, line 4 skipping to change at page 8, line 25
recommends using DHCPv6/SLAAC independently in different subnets. recommends using DHCPv6/SLAAC independently in different subnets.
However, since DHCPv6 is also used to configure many other network However, since DHCPv6 is also used to configure many other network
parameters, there are ND and DHCPv6 co-existence scenarios. parameters, there are ND and DHCPv6 co-existence scenarios.
Combinations of address configuration models may coexist within a Combinations of address configuration models may coexist within a
single enterprise network. [I-D.ietf-savi-mix] provides single enterprise network. [I-D.ietf-savi-mix] provides
recommendations to avoid collisions and to review collision recommendations to avoid collisions and to review collision
handling in such scenarios. handling in such scenarios.
- DNS - DNS
It is recommended that the site have an automatic and systematic It is recommended that the site have an automatic and systematic
procedure for updating/synchronising its DNS records, including procedure for updating/synchronising its DNS records, including
both forward and reverse mapping [RFC2874]. A manual on-demand both forward and reverse mapping [RFC2874]. A manual on-demand
updating model does not scale, and increases the chance of errors. updating model does not scale, and increases the chance of errors.
Although the A6 DNS record model [RFC2874] was designed for easier Although the A6 DNS record model [RFC2874] was designed for easier
renumbering, it has a lot of unsolved technical issues [RFC3364]. renumbering, it has a lot of unsolved technical issues [RFC3364].
Therefore, it has been moved to experimental status [RFC3363], and Therefore, it has been moved to experimental status [RFC3363], and
will move to historic status by [I-D.jiang-dnsext-a6-to-historic] will move to historic status by [RFC6563] (Moving A6 to Historic
(It is currently in RFC Editor Queue already). So A6 is not Status). So A6 is not recommended.
recommended.
In order to simplify the operation procedure, the network In order to simplify the operation procedure, the network
architect should combine the forward and reverse DNS updates in a architect should combine the forward and reverse DNS updates in a
single procedure. single procedure.
Often, a small site depends on its ISP's DNS system rather than Often, a small site depends on its ISP's DNS system rather than
maintaining its own. When renumbering, this requires maintaining its own. When renumbering, this requires
administrative coordination between the site and its ISP. administrative coordination between the site and its ISP.
The DNS synchronization may be completed through the Secure DNS The DNS synchronization may be completed through the Secure DNS
Dynamic Update [RFC3007]. Normally, the dynamic DNS update is Dynamic Update [RFC3007]. Dynamic DNS update can be provided by
achieved by DHCPv6 server on behalf of individual hosts. [RFC4704] the DHCPv6 client or by the server on behalf of individual hosts.
defined a DHCPv6 option to be used by DHCPv6 clients and servers [RFC4704] defined a DHCPv6 option to be used by DHCPv6 clients and
to exchange information about the client's FQDN and about who has servers to exchange information about the client's FQDN and about
the responsibility for updating the DNS with the associated AAAA who has the responsibility for updating the DNS with the
and PTR RRs. For example, if a client wants the server to update associated AAAA and PTR RRs. For example, if a client wants the
the FQDN-address mapping in the DNS server, it can include the server to update the FQDN-address mapping in the DNS server, it
Client FQDN option with proper settings in the SOLICIT with Rapid can include the Client FQDN option with proper settings in the
Commit, REQUEST, RENEW, and REBIND message originated by the SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message
client. When DHCPv6 server gets this option, it can use the originated by the client. When DHCPv6 server gets this option, it
dynamic DNS update on behalf of the client. In this document, we can use the dynamic DNS update on behalf of the client. In this
promote to support this FQDN option. But since it's a DHCPv6 document, we promote to support this FQDN option. But since it's a
option, it implies that only the DHCP-managed networks are DHCPv6 option, it implies that only the DHCP-managed networks are
suitable for this operation. In a model including SLAAC, host suitable for this operation. In SLAAC mode, sometimes hosts also
addresses may be registered on an address registration server, need to register addresses on a registration server, which could
which could in fact be a DHCPv6 server; then the server would in fact be a DHCPv6 server (as described in [I-D.ietf-dhc-addr-
update corresponding DNS records. registration]); then the server would update corresponding DNS
records.
- Security - Security
Any automatic renumbering scheme has a potential exposure to Any automatic renumbering scheme has a potential exposure to
hijacking. Malicious entity in the network can forge prefixes to hijacking. Malicious entity in the network can forge prefixes to
renumber the hosts. So proper network security mechanisms are renumber the hosts. So proper network security mechanisms are
needed. needed.
For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible
solution, but it is complex and there's almost no real deployment solution, but it is complex and there's almost no real deployment
skipping to change at page 11, line 12 skipping to change at page 11, line 33
be the DHCPv6 server or Router Advertisement itself that be the DHCPv6 server or Router Advertisement itself that
automatically accomplishes client renumbering. automatically accomplishes client renumbering.
Address deprecation should be associated with the deprecation of Address deprecation should be associated with the deprecation of
associated DNS records. The DNS records should be deprecated as associated DNS records. The DNS records should be deprecated as
early as possible, before the addresses themselves. early as possible, before the addresses themselves.
- Network initiative enforced renumbering - Network initiative enforced renumbering
If the network has to enforce renumbering before address leases If the network has to enforce renumbering before address leases
expire, the network should initiate enforcement messages, either expire, the network should initiate DHCPv6 RECONFIGURE messages.
in Router Advertisement messages or DHCPv6 RECONFIGURE messages. For some operating systems such as Windows 7, if the hosts receive
RA messages with ManagedFlag=0, they'll release the DHCPv6
addresses and do SLAAC according to the prefix information in the
RA messages, so this could be another enforcement method for some
specific scenarios.
- Impact to branch/main sites - Impact to branch/main sites
Renumbering in main/branch site may cause impact on branch/main Renumbering in main/branch site may cause impact on branch/main
site communication. The routes, ingress filtering of site's site communication. The routes, ingress filtering of site's
gateways, and DNS may need to be updated. This needs careful gateways, and DNS may need to be updated. This needs careful
planning and organizing. planning and organizing.
- DNS record update and DNS configuration on hosts - DNS record update and DNS configuration on hosts
skipping to change at page 11, line 40 skipping to change at page 12, line 18
DNS configuration on hosts should be updated if local recursive DNS configuration on hosts should be updated if local recursive
DNS servers are renumbered. During the transition period, both old DNS servers are renumbered. During the transition period, both old
and new DNS server addresses may co-exist on the hosts. If the and new DNS server addresses may co-exist on the hosts. If the
lifetime of DNS configuration is shorter than the transition lifetime of DNS configuration is shorter than the transition
period, name resolving failure may be reduced to minimum. A period, name resolving failure may be reduced to minimum. A
notification mechanism may be needed to indicate to the hosts that notification mechanism may be needed to indicate to the hosts that
a renumbering event of local recursive DNS happens or is going to a renumbering event of local recursive DNS happens or is going to
take place. take place.
- Router awareness [Bing] Gap 7.1
In a site with multiple border routers, all border routers should
be aware of partial renumbering in order to correctly handle
inbound packets. Internal forwarding tables need to be updated.
- Border filtering
In a multihomed site, an egress router to ISP A could normally
filter packets with source addresses from other ISPs. The egress
router connecting to ISP A should be notified if the egress router
connecting to ISP B initiates a renumbering event in order to
properly update its filter function.
- Tunnel concentrator renumbering - Tunnel concentrator renumbering
A tunnel concentrator itself might be renumbered. This change A tunnel concentrator itself might be renumbered. This change
should be reconfigured in relevant hosts or routers, unless the should be reconfigured in relevant hosts or routers, unless the
configuration of tunnel concentrator was based on FQDN. configuration of tunnel concentrator was based on FQDN.
- Connectivity session survivability - Connectivity session survivability
During the renumbering operations, connectivity sessions in IP During the renumbering operations, connectivity sessions in IP
layer would break if the old address is deprecated before the layer would break if the old address is deprecated before the
session ends. However, the upper layer sessions may survive by session ends. However, the upper layer sessions may survive by
using session survivability technologies, such as SHIM6 [RFC5533]. using session survivability technologies, such as SHIM6 [RFC5533].
As mentioned above, some long-living applications may need to be As mentioned above, some long-living applications may need to be
handled specially. handled specially.
5. Gap Inventory 5. Security Considerations
This section lists a few issues that still appear to remain
unsolvable (also see [I-D.liu-6renum-gap-analysis]). Some of them may
be inherently unsolvable.
- Some environments like embedded systems might not use DHCPv6 or
SLAAC and even configuration scripts might not be an option.
This creates special problems that no general-purpose solution
is likely to address.
- TCP and UDP flows can't survive a renumbering event at either
end.
- The embedding of IPv6 unicast addresses into multicast
addresses and the embedded-RP (Rendezvous Point) [RFC3956] will
cause issues when renumbering.
- Changing the unicast source address of a multicast sender might
also be an issue for receivers.
- When a renumbering event takes place, entries in the state
table of tunnel concentrator that happen to contain the old
addresses will become invalid and will eventually time out.
However, this can be considered as harmless though it takes
resources on these devices for a while.
- A site that is listed in an IP black list can escape that list
by renumbering itself. The site itself of course will not
report its renumbering and the black list may not be able to
monitor or discover the renumbering event.
- Multihomed sites, using SLAAC for one address prefix and DHCPv6
for another, would clearly create a risk of inconsistent host
behaviour and operational confusion.
6. Security Considerations
As noted, a site that is listed by IP address in a black list can As noted, a site that is listed by IP address in a black list can
escape that list by renumbering itself. escape that list by renumbering itself.
Any automatic renumbering scheme has a potential exposure to Any automatic renumbering scheme has a potential exposure to
hijacking. Proper network security mechanisms are needed. Although hijacking. Proper network security mechanisms are needed. Although
there are existing security mechanisms such as SEND, RA guard, secure there are existing security mechanisms such as SEND, RA guard, secure
DHCPv6 etc., they haven't been widely deployed and haven't been DHCPv6 etc., they haven't been widely deployed and haven't been
verified whether they are suitable for ensuring security while not verified whether they are suitable for ensuring security while not
bringing too much operational complexity and cost. bringing too much operational complexity and cost.
skipping to change at page 13, line 37 skipping to change at page 13, line 15
The "make-before-break" approach of [RFC4192] requires the routers The "make-before-break" approach of [RFC4192] requires the routers
keep advertising the old prefixes for some time. But if the ISP keep advertising the old prefixes for some time. But if the ISP
changes the prefixes very frequently, the co-existence of old and new changes the prefixes very frequently, the co-existence of old and new
prefixes may cause potential risk to the enterprise routing system. prefixes may cause potential risk to the enterprise routing system.
However, enterprise scenarios may not involve the extreme situation; However, enterprise scenarios may not involve the extreme situation;
this issue needs to be identified in the future. this issue needs to be identified in the future.
The security configuration updates will need to be made in two stages The security configuration updates will need to be made in two stages
(immediately before and immediately after the event). (immediately before and immediately after the event).
7. IANA Considerations 6. IANA Considerations
This draft does not request any IANA action. This draft does not request any IANA action.
8. Acknowledgements 7. Acknowledgements
This work is illuminated by RFC 5887, so thank for RFC 5887 authors, This work is illuminated by RFC5887, so thank for RFC 5887 authors,
Randall Atkinson and Hannu Flinck. Useful ideas were also presented Randall Atkinson and Hannu Flinck. Useful ideas were also presented
in by documents from Tim Chown and Fred Baker. The authors also want in by documents from Tim Chown and Fred Baker. The authors also want
to thank Wesley George, Olivier Bonaventure and other 6renum members to thank Wesley George, Olivier Bonaventure and other 6renum members
for valuable comments. for valuable comments.
9. Change Log [RFC Editor please remove] 8. Change Log [RFC Editor please remove]
draft-jiang-6renum-enterprise-00, original version, 2011-07-01 draft-jiang-6renum-enterprise-00, original version, 2011-07-01
draft-jiang-6renum-enterprise-01, Update according to IETF81 and mail draft-jiang-6renum-enterprise-01, Update according to IETF81 and mail
list discussions, 2011-10-09 list discussions, 2011-10-09
draft-jiang-6renum-enterprise-02, Update according to IETF82 draft-jiang-6renum-enterprise-02, Update according to IETF82
discussions, 2011-12-06 discussions, 2011-12-06
draft-ietf-6renum-enterprise-00, Update according to mail list draft-ietf-6renum-enterprise-00, Update according to mail list
discussions, 2012-02-06 discussions, 2012-02-06
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service
Location Protocol, Version 2", RFC 2608, June 1999. Location Protocol, Version 2", RFC 2608, June 1999.
[RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, November 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
skipping to change at page 15, line 24 skipping to change at page 14, line 46
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet
Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,
September 2010. September 2010.
[RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli
"IPv6 Router Advertisement Option for DNS Configuration", "IPv6 Router Advertisement Option for DNS Configuration",
RFC 6106, November 2011. RFC 6106, November 2011.
10.2. Informative References 9.2. Informative References
[RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000. 2000.
[RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain, [RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain,
"Representing Internet Protocol version 6 (IPv6) Addresses "Representing Internet Protocol version 6 (IPv6) Addresses
in the Domain Name System (DNS)", RFC 3363, August 2002. in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support
skipping to change at page 16, line 12 skipping to change at page 15, line 33
[RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010. Still Needs Work", RFC 5887, May 2010.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
[RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to
Historic Status", RFC 6563, May 2012.
[I-D.ietf-dhc-secure-dhcpv6] [I-D.ietf-dhc-secure-dhcpv6]
Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working
in progress. in progress.
[I-D.ietf-dhc-host-gen-id] [I-D.ietf-dhc-host-gen-id]
S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in
DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), DHCPv6", draft-ietf-dhc-host-gen-id (work in progress),
April, 2011. April, 2011.
[I-D.ietf-savi-mix] [I-D.ietf-savi-mix]
Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI
for Mixed Address Assignment Methods Scenario", working in for Mixed Address Assignment Methods Scenario", working in
progress. progress.
[I-D.ietf-dhc-pd-exclude] [I-D.ietf-dhc-pd-exclude]
J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix
Exclude Option for DHCPv6-based Prefix Delegation", working Exclude Option for DHCPv6-based Prefix Delegation", working
in progress. in progress.
[I-D.ietf-dhc-addr-registration]
Jiang, S., Chen, G., "A Generic IPv6 Addresses Registration
Solution Using DHCPv6", working in progress.
[I-D.ietf-6renum-gap-analysis] [I-D.ietf-6renum-gap-analysis]
Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap
Analysis", working in progress. Analysis", working in progress.
[I-D.jiang-dnsext-a6-to-historic] [I-D.carpenter-6renum-static-problem]
Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to
Historic Status", working in progress.
[I-D.carpenter-6renum-static-problem]
Carpenter, B. and S. Jiang., "Problem Statement for Carpenter, B. and S. Jiang., "Problem Statement for
Renumbering IPv6 Hosts with Static Addresses", working in Renumbering IPv6 Hosts with Static Addresses", working in
progress. progress.
Author's Addresses Author's Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Q14 Building, No.156 Beiqing Rd., Huawei Q14 Building, No.156 Beiqing Rd.,
Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District
EMail: jiangsheng@huawei.com EMail: jiangsheng@huawei.com
Bing Liu Bing Liu
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Q14 Building, No.156 Beiqing Rd., Huawei Q14 Building, No.156 Beiqing Rd.,
Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District
EMail: leo.liubing@huawei.com EMail: leo.liubing@huawei.com
Brian Carpenter Brian Carpenter
Department of Computer Science D
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: brian.e.carpenter@gmail.com
 End of changes. 29 change blocks. 
119 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/