draft-ietf-v6ops-nap-00.txt   draft-ietf-v6ops-nap-01.txt 
Network Working Group G. Van de Velde Network Working Group G. Van de Velde
Internet-Draft T. Hain Internet-Draft T. Hain
Expires: September 28, 2005 R. Droms Expires: December 3, 2005 R. Droms
Cisco Systems Cisco Systems
B. Carpenter B. Carpenter
IBM Corporation IBM Corporation
E. Klein E. Klein
TTI Telecom Tel Aviv University
March 27, 2005 june 2005
IPv6 Network Architecture Protection IPv6 Network Architecture Protection
<draft-ietf-v6ops-nap-00.txt> <draft-ietf-v6ops-nap-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 28, 2005. This Internet-Draft will expire on December 3, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Although there are many perceived benefits to Network Address Although there are many perceived benefits to Network Address
Translation (NAT), its primary benefit of "amplifying" available Translation (NAT), its primary benefit of "amplifying" available
address space is not needed in IPv6. In addition to NAT's many address space is not needed in IPv6. In addition to NAT's many
skipping to change at page 2, line 20 skipping to change at page 2, line 18
Protection (NAP) using IPv6 can provide the same or more benefits Protection (NAP) using IPv6 can provide the same or more benefits
without the need for NAT. without the need for NAT.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Perceived benefits of NAT and its impact on IPv4 . . . . . . 6 2. Perceived benefits of NAT and its impact on IPv4 . . . . . . 6
2.1 Simple gateway between Internet and internal network . . . 6 2.1 Simple gateway between Internet and internal network . . . 6
2.2 Simple security due to stateful filter implementation . . 6 2.2 Simple security due to stateful filter implementation . . 6
2.3 User/Application tracking . . . . . . . . . . . . . . . . 7 2.3 User/Application tracking . . . . . . . . . . . . . . . . 7
2.4 Privacy and topology hiding . . . . . . . . . . . . . . . 7 2.4 Privacy and topology hiding . . . . . . . . . . . . . . . 8
2.5 Independent control of addressing in a private network . . 8 2.5 Independent control of addressing in a private network . . 9
2.6 Global address pool conservation . . . . . . . . . . . . . 8 2.6 Global address pool conservation . . . . . . . . . . . . . 9
2.7 Multihoming and renumbering with NAT . . . . . . . . . . . 9 2.7 Multihoming and renumbering with NAT . . . . . . . . . . . 9
3. Description of the IPv6 tools . . . . . . . . . . . . . . . 9 3. Description of the IPv6 tools . . . . . . . . . . . . . . . 10
3.1 Privacy addresses (RFC 3041) . . . . . . . . . . . . . . . 9 3.1 Privacy addresses (RFC 3041) . . . . . . . . . . . . . . . 10
3.2 Unique Local Addresses . . . . . . . . . . . . . . . . . . 10 3.2 Unique Local Addresses . . . . . . . . . . . . . . . . . . 11
3.3 DHCPv6 prefix delegation . . . . . . . . . . . . . . . . . 11 3.3 DHCPv6 prefix delegation . . . . . . . . . . . . . . . . . 11
3.4 Untraceable IPv6 addresses . . . . . . . . . . . . . . . . 11 3.4 Untraceable IPv6 addresses . . . . . . . . . . . . . . . . 12
4. Using IPv6 technology to provide the market perceived 4. Using IPv6 technology to provide the market perceived
benefits of NAT . . . . . . . . . . . . . . . . . . . . . . 12 benefits of NAT . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Simple gateway between Internet and internal network . . . 12 4.1 Simple gateway between Internet and internal network . . . 12
4.2 IPv6 and Simple security . . . . . . . . . . . . . . . . . 12 4.2 IPv6 and Simple security . . . . . . . . . . . . . . . . . 13
4.3 User/Application tracking . . . . . . . . . . . . . . . . 14 4.3 User/Application tracking . . . . . . . . . . . . . . . . 14
4.4 Privacy and topology hiding using IPv6 . . . . . . . . . . 14 4.4 Privacy and topology hiding using IPv6 . . . . . . . . . . 15
4.5 Independent control of addressing in a private network . . 15 4.5 Independent control of addressing in a private network . . 15
4.6 Global address pool conservation . . . . . . . . . . . . . 15 4.6 Global address pool conservation . . . . . . . . . . . . . 16
4.7 Multihoming and renumbering . . . . . . . . . . . . . . . 16 4.7 Multihoming and renumbering . . . . . . . . . . . . . . . 16
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Medium/large private networks . . . . . . . . . . . . . . 17 5.1 Medium/large private networks . . . . . . . . . . . . . . 17
5.2 Small private networks . . . . . . . . . . . . . . . . . . 18 5.2 Small private networks . . . . . . . . . . . . . . . . . . 19
5.3 Single user connection . . . . . . . . . . . . . . . . . . 20 5.3 Single user connection . . . . . . . . . . . . . . . . . . 20
5.4 ISP/Carrier customer networks . . . . . . . . . . . . . . 20 5.4 ISP/Carrier customer networks . . . . . . . . . . . . . . 21
6. IPv6 gap analysis . . . . . . . . . . . . . . . . . . . . . 21 6. IPv6 gap analysis . . . . . . . . . . . . . . . . . . . . . 22
6.1 Completion of work on ULAs . . . . . . . . . . . . . . . . 21 6.1 Completion of work on ULAs . . . . . . . . . . . . . . . . 22
6.2 Subnet topology masking . . . . . . . . . . . . . . . . . 22 6.2 Subnet topology masking . . . . . . . . . . . . . . . . . 22
6.3 Minimal traceability of privacy addresses . . . . . . . . 22 6.3 Minimal traceability of privacy addresses . . . . . . . . 23
6.4 Renumbering procedure . . . . . . . . . . . . . . . . . . 22 6.4 Renumbering procedure . . . . . . . . . . . . . . . . . . 23
6.5 Site multihoming . . . . . . . . . . . . . . . . . . . . . 22 6.5 Site multihoming . . . . . . . . . . . . . . . . . . . . . 23
6.6 Untraceable addresses . . . . . . . . . . . . . . . . . . 22 6.6 Untraceable addresses . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . 23
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1 Normative References . . . . . . . . . . . . . . . . . . 24 11.1 Normative References . . . . . . . . . . . . . . . . . . 24
11.2 Informative References . . . . . . . . . . . . . . . . . 25 11.2 Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
A. Additional benefits due to Native IPv6 and universal A. Additional benefits due to Native IPv6 and universal
unique addressing . . . . . . . . . . . . . . . . . . . . . 26 unique addressing . . . . . . . . . . . . . . . . . . . . . 27
A.1 Universal any-to-any connectivity . . . . . . . . . . . . 26 A.1 Universal any-to-any connectivity . . . . . . . . . . . . 27
A.2 Auto-configuration . . . . . . . . . . . . . . . . . . . . 27 A.2 Auto-configuration . . . . . . . . . . . . . . . . . . . . 27
A.3 Native Multicast services . . . . . . . . . . . . . . . . 27 A.3 Native Multicast services . . . . . . . . . . . . . . . . 28
A.4 Increased security protection . . . . . . . . . . . . . . 27 A.4 Increased security protection . . . . . . . . . . . . . . 28
A.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.6 Merging networks . . . . . . . . . . . . . . . . . . . . . 28 A.6 Merging networks . . . . . . . . . . . . . . . . . . . . . 29
A.7 Community of interest . . . . . . . . . . . . . . . . . . 29 A.7 Community of interest . . . . . . . . . . . . . . . . . . 29
B. Revision history . . . . . . . . . . . . . . . . . . . . . . 29 B. Revision history . . . . . . . . . . . . . . . . . . . . . . 30
B.1 Changes from *-vandevelde-v6ops-nap-00 to B.1 Changes from *-vandevelde-v6ops-nap-00 to
*-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 29 *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 30
B.2 Changes from *-vandevelde-v6ops-nap-01 to B.2 Changes from *-vandevelde-v6ops-nap-01 to
ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . . 29 *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 30 B.3 Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 30
Intellectual Property and Copyright Statements . . . . . . . 31
1. Introduction 1. Introduction
Although there are many perceived benefits to Network Address Although there are many perceived benefits to Network Address
Translation (NAT), its primary benefit of "amplifying" available Translation (NAT), its primary benefit of "amplifying" available
address space is not needed in IPv6. The serious disadvantages of address space is not needed in IPv6. The serious disadvantages of
ambiguous "private" address space and of Network Address Translation ambiguous "private" address space and of Network Address Translation
(NAT) [1][5] have been well documented [4][6]. However, given its (NAT) [1][5] have been well documented [4][6]. However, given its
wide market acceptance NAT undoubtedly has some perceived benefits. wide market acceptance NAT undoubtedly has some perceived benefits.
Indeed, in an Internet model based on universal any-to-any Indeed, in an Internet model based on universal any-to-any
skipping to change at page 6, line 28 skipping to change at page 6, line 28
A NAT device can connect a private network with any kind of address A NAT device can connect a private network with any kind of address
(ambiguous [RFC 1918] or global registered address) towards the (ambiguous [RFC 1918] or global registered address) towards the
Internet. The address space of the private network can be built from Internet. The address space of the private network can be built from
globally unique addresses, from ambiguous address space or from both globally unique addresses, from ambiguous address space or from both
simultaneously. Without specific configuration from public to simultaneously. Without specific configuration from public to
private, the NAT device enables access between the client side of an private, the NAT device enables access between the client side of an
application in the private network with the server side in the public application in the private network with the server side in the public
Internet. Internet.
Wide-scale deployments have shown that using NAT to attach a private Wide-scale deployments have shown that using NAT to attach a private
IPv4 network to the Internet is simple and practical for the IPv4 network to the Internet is simple and practical for the non-
non-technical end user. Frequently a simple user interface is technical end user. Frequently a simple user interface is sufficient
sufficient for configuring both device and application access rights. for configuring both device and application access rights.
Additionally, thanks to successful marketing campaigns it is Additionally, thanks to successful marketing campaigns it is
perceived by end users that their equipment is protected from the bad perceived by end users that their equipment is protected from the bad
elements and attackers on the public IPv4 Internet. elements and attackers on the public IPv4 Internet.
2.2 Simple security due to stateful filter implementation 2.2 Simple security due to stateful filter implementation
It is frequently believed that a NAT device puts in an extra barrier A firewall doesn't fully secure a network, because many attacks come
to keep the private network protected from evil outside influences from inside or are at a layer higher than the firewall can protect
due to the session-oriented character of NAT technology. Since a NAT against. In the final analysis, every system has to be responsible
typically keeps state only for individual sessions, attackers, worms, for its own security, and every process running on a system has to be
etc. cannot exploit this state to attack a host in general and on robust in the face of challenges like stack overflows etc. What a
any port. This benefit may be partially real; however, experienced firewall does is prevent a network administration from having to pay
for bandwidth to carry unauthorized traffic, and in so doing reduce
the probability of certain kinds of attacks across the protected
boundary.
A distributed security mechanism to protect the end-systems may help
in the above situation; however, to deploy such a system is quite
complex and may depend upon behaviour per operating system and
release version. As a result it will probably not be available in
the next couple of years for end-user organizations. End-system-only
security mechanisms don't protect the network infrastructure from
being misused for transit, or against DDOS attacks against individual
systems inside, and this is the area where a NAT device is perceived
to provide some relief.
It is frequently believed that through its session-oriented
operation, NAT puts in an extra barrier to keep the private network
protected from evil outside influences. Since a NAT device typically
keeps state only for individual sessions, attackers, worms, etc.
cannot exploit this state to attack a host in general and on any
port. This benefit may be partially real, however, experienced
hackers are well aware of NAT devices and are very familiar with hackers are well aware of NAT devices and are very familiar with
private address space, and have devised methods of attack (such as private address space, and have devised methods of attack (such as
trojan horses) that readily penetrate NAT boundaries. The secure trojan horses) that readily penetrate NAT boundaries. For these
feeling is in vain. reasons the sense of security provided by NAT are actually false.
Address translation does not provide security in itself; for example, Address translation does not provide security in itself; for example,
consider a configuration with static NAT translation and all inbound consider a configuration with static NAT translation and all inbound
ports translating to a single machine. In such a scenario the ports translating to a single machine. In such a scenario the
security risk for that machine is identical to the case with no NAT security risk for that machine is identical to the case with no NAT
device in the communication path. As result there is no specific device in the communication path. As result there is no specific
security value in the address translation function. The perceived security value in the address translation function. The perceived
security comes from the lack of pre-established or permanent mapping security comes from the lack of pre-established or permanent mapping
state. Dynamically establishing state in response to internal state. Dynamically establishing state in response to internal
requests reduces the threat of unexpected external connections to requests reduces the threat of unexpected external connections to
skipping to change at page 12, line 38 skipping to change at page 13, line 11
out to the global Internet. A slightly more complex case might out to the global Internet. A slightly more complex case might
involve local routing protocols, but with the entire local network involve local routing protocols, but with the entire local network
sharing a common global prefix there would still not be a need for an sharing a common global prefix there would still not be a need for an
external routing protocol as a default route would continue to be external routing protocol as a default route would continue to be
consistent with the connectivity. consistent with the connectivity.
4.2 IPv6 and Simple security 4.2 IPv6 and Simple security
The vulnerability of an IPv6 host is similar as for an IPv4 host The vulnerability of an IPv6 host is similar as for an IPv4 host
directly connected towards the Internet, and firewall and IDS systems directly connected towards the Internet, and firewall and IDS systems
are recommended. However, with IPv6, the following protections are are recommended. A proxy may be used for certain applications, but
available without the use of NAT: has the caveat that the end to end transparancy is broken. However,
with IPv6, the following protections are available without the use of
NAT while maintaining end-to-end reachability:
1. Short lifetimes on privacy extension suffixes reduce the attack 1. Short lifetimes on privacy extension suffixes reduce the attack
profile since the node will not respond to the address once the profile since the node will not respond to the address once the
address is no longer valid. address is no longer valid.
2. IPsec is a mandatory service for IPv6 implementations. IPsec 2. IPsec is a mandatory service for IPv6 implementations. IPsec
functions to prevent session hijacking, prevent content functions to prevent session hijacking, prevent content
tampering, and optionally masks the packet contents. While IPsec tampering, and optionally masks the packet contents. While IPsec
might be available in IPv4 implementations, deployment in NAT might be available in IPv4 implementations, deployment in NAT
environments either breaks the protocol or requires complex environments either breaks the protocol or requires complex
helper services with limited functionality or efficiency. helper services with limited functionality or efficiency.
3. The size of the typical subnet ::/64 will make a network ping 3. The size of the typical subnet ::/64 will make a network ping
skipping to change at page 13, line 43 skipping to change at page 14, line 28
External network -> internal network External network -> internal network
Actions: Actions:
If the session had reflective 'true'-state, If the session had reflective 'true'-state,
then allow the inbound traffic then allow the inbound traffic
If the session had reflective 'false' state, If the session had reflective 'false' state,
then drop the traffic then drop the traffic
This simple rule would create similar protection and security holes This simple rule would create similar protection and security holes
the typical IPv4 NAT device will offer and may for example be enabled the typical IPv4 NAT device will offer and may for example be enabled
by default on all broadband edge-routers,with that difference that by a simple user-interface and should provide the facility with a
the security caveats will be documented, and may hence be removed simple mechanism to create holes in the rules to serve certain
with the next revision of the rule. The goal is that at every applications on edge-routers, with that difference that the security
iteration, the IPv6 internet will become more secure for the caveats will be documented, and may hence be removed with the next
oblivious users. revision of the rule. The goal is that at every iteration, the IPv6
internet will become more secure for the oblivious users.
Assuming the network administrator is aware of [17] the increased Assuming the network administrator is aware of [17] the increased
size of the IPv6 address will make topology probing much harder, and size of the IPv6 address will make topology probing much harder, and
almost impossible for IPv6 devices. What one does when topology almost impossible for IPv6 devices. What one does when topology
probing is to get an idea of the available hosts inside an probing is to get an idea of the available hosts inside an
enterprise. This mostly starts with a ping-sweep. This is an enterprise. This mostly starts with a ping-sweep. This is an
automated procedure of sending Internet Control Message Protocol automated procedure of sending Internet Control Message Protocol
(ICMP) echo requests (also known as PINGs) to a range of IP addresses (ICMP) echo requests (also known as PINGs) to a range of IP addresses
and recording replies. This can enable an attacker to map the and recording replies. This can enable an attacker to map the
network. Since the IPv6 subnets are 64 bits worth of address space, network. Since the IPv6 subnets are 64 bits worth of address space,
skipping to change at page 18, line 9 skipping to change at page 18, line 40
If there is need to mask the internal structure towards the external If there is need to mask the internal structure towards the external
IPv6 internet, then some form of 'Untraceable' addresses may be used. IPv6 internet, then some form of 'Untraceable' addresses may be used.
These addresses will be derived from a local pool, and may be These addresses will be derived from a local pool, and may be
assigned to those hosts for which topology masking is required or assigned to those hosts for which topology masking is required or
which want to reach the IPv6 Internet or other external networks. which want to reach the IPv6 Internet or other external networks.
The technology to assign these addresses to the hosts could be based The technology to assign these addresses to the hosts could be based
on DHCPv6. To complement the 'Untraceable' addresses it is needed to on DHCPv6. To complement the 'Untraceable' addresses it is needed to
have at least awareness of the IPv6 address location when routing an have at least awareness of the IPv6 address location when routing an
IPv6 packet through the internal network. This could be achieved by IPv6 packet through the internal network. This could be achieved by
'route-injection' in the network infrastructure. This 'route-injection' in the network infrastructure. This route-
route-injection could be done based on /128 host-routes to each injection could be done based on /128 host-routes to each device that
device that wants to connect to the Internet using an untraceable wants to connect to the Internet using an untraceable address. This
address. This will provide the most dynamic masking, but will have a will provide the most dynamic masking, but will have a scalability
scalability limitation, as an IGP is typically not designed to carry limitation, as an IGP is typically not designed to carry many
many thousands of IPv6 prefixes. A large enterprise may have thousands of IPv6 prefixes. A large enterprise may have thousands of
thousands of hosts willing to connect to the Internet. Less flexible hosts willing to connect to the Internet. Less flexible masking
masking could be to have time-based IPv6 prefixes per link or subnet. could be to have time-based IPv6 prefixes per link or subnet. This
This may reduce the amount of route entries in the IGP by a may reduce the amount of route entries in the IGP by a significant
significant factor, but has as trade-off that masking is time and factor, but has as trade-off that masking is time and subnet based.
subnet based.
The dynamic allocation of 'Untraceable' addresses can also limit the The dynamic allocation of 'Untraceable' addresses can also limit the
IPv6 access between local and external hosts to those local hosts IPv6 access between local and external hosts to those local hosts
being authorized for this capability. Dynamically allocated being authorized for this capability. Dynamically allocated
'Untraceable' addresses may also facilitate and simplify the 'Untraceable' addresses may also facilitate and simplify the
connectivity to the outside networks during renumbering, because the connectivity to the outside networks during renumbering, because the
existing IPv6 central address pool could be swapped for the newly existing IPv6 central address pool could be swapped for the newly
allocated IPv6 address pool. allocated IPv6 address pool.
The use of permanent ULA addresses on a site provides the benefit The use of permanent ULA addresses on a site provides the benefit
skipping to change at page 21, line 27 skipping to change at page 22, line 10
will be possible for the ISP to provide global routable IPv6 prefixes will be possible for the ISP to provide global routable IPv6 prefixes
without a requirement for address translation. An ISP may for without a requirement for address translation. An ISP may for
commercial reasons still decide to restrict the capabilities of the commercial reasons still decide to restrict the capabilities of the
end users by other means like traffic and/or route filtering etc. end users by other means like traffic and/or route filtering etc.
If the carrier network is a mobile provider, then IPv6 is encouraged If the carrier network is a mobile provider, then IPv6 is encouraged
in comparison with the combination of IPv4+NAT for 3GPP attached in comparison with the combination of IPv4+NAT for 3GPP attached
devices. When looking in chapter 2.3 of RFC3314 'Recommendations for devices. When looking in chapter 2.3 of RFC3314 'Recommendations for
IPv6 in 3GPP Standards' [14] it is found that the IPv6 WG recommends IPv6 in 3GPP Standards' [14] it is found that the IPv6 WG recommends
that one or more /64 prefixes should be assigned to each primary PDP that one or more /64 prefixes should be assigned to each primary PDP
context. This will allow sufficient address space for a context. This will allow sufficient address space for a 3GPP-
3GPP-attached node to allocate privacy addresses and/or route to a attached node to allocate privacy addresses and/or route to a multi-
multi-link subnet, and will discourage the use of NAT within link subnet, and will discourage the use of NAT within 3GPP-attached
3GPP-attached devices. devices.
6. IPv6 gap analysis 6. IPv6 gap analysis
Like IPv4 and any major standards effort, IPv6 standardization Like IPv4 and any major standards effort, IPv6 standardization
work continues as deployments are ongoing. This section discusses work continues as deployments are ongoing. This section discusses
several topics for which additional standardization, or documentation several topics for which additional standardization, or documentation
of best practice, is required to fully realize the benefits of NAP. of best practice, is required to fully realize the benefits of NAP.
None of these items are show-stoppers for immediate usage of NAP in None of these items are show-stoppers for immediate usage of NAP in
roles where there are no current gaps. roles where there are no current gaps.
skipping to change at page 24, line 4 skipping to change at page 24, line 36
The document has also identified a few ongoing IETF work items that The document has also identified a few ongoing IETF work items that
are needed to realize 100% of the benefits of NAP. are needed to realize 100% of the benefits of NAP.
10. Acknowledgements 10. Acknowledgements
Christian Huitema has contributed during the initial round table to Christian Huitema has contributed during the initial round table to
discuss the scope and goal of the document, while the European Union discuss the scope and goal of the document, while the European Union
IST 6NET project acted as a catalyst for the work documented in this IST 6NET project acted as a catalyst for the work documented in this
draft. Editorial comments and contributions have been received from: draft. Editorial comments and contributions have been received from:
Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar, Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar,
Salman Asadullah, Patrick Grossetete and other members of the v6ops Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark
WG. Smith, Alain Durand, John Spence, Christian Huitema and other members
of the v6ops WG.
11. References 11. References
11.1 Normative References 11.1 Normative References
[1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5, Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996. RFC 1918, February 1996.
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator [2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999. (NAT) Terminology and Considerations", RFC 2663, August 1999.
[3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Hain, T., "Architectural Implications of NAT", RFC 2993, [4] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address [5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[6] Holdrege, M. and P. Srisuresh, "Protocol Complications with the [6] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC 3027, January 2001. IP Network Address Translator", RFC 3027, January 2001.
[7] Narten, T. and R. Draves, "Privacy Extensions for Stateless [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. [8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[9] Draves, R., "Default Address Selection for Internet Protocol [9] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[10] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host [10] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, December Configuration Protocol (DHCP) version 6", RFC 3633,
2003. December 2003.
[11] Baker, F., "Procedures for Renumbering an IPv6 Network without [11] Baker, F., "Procedures for Renumbering an IPv6 Network without
a Flag Day", a Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work in
Internet-Draft draft-ietf-v6ops-renumbering-procedure-05, March progress), March 2005.
2005.
[12] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [12] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
Internet-Draft draft-ietf-ipv6-unique-local-addr-09, January progress), January 2005.
2005.
11.2 Informative References 11.2 Informative References
[13] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless [13] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Inter-Domain Routing (CIDR): an Address Assignment and Domain Routing (CIDR): an Address Assignment and Aggregation
Aggregation Strategy", RFC 1519, September 1993. Strategy", RFC 1519, September 1993.
[14] Wasserman, M., "Recommendations for IPv6 in Third Generation [14] Wasserman, M., "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314, September Partnership Project (3GPP) Standards", RFC 3314,
2002. September 2002.
[15] Savola, P. and B. Haberman, "Embedding the Rendezvous Point [15] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
(RP) Address in an IPv6 Multicast Address", RFC 3956, November (RP) Address in an IPv6 Multicast Address", RFC 3956,
2004. November 2004.
[16] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful [16] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful
(draft-dupont-ipv6- rfc3041harmful-05.txt)", June 2004. (draft-dupont-ipv6- rfc3041harmful-05.txt)", June 2004.
[17] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning [17] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown-
(chown-v6ops- port-scanning-implications-01.txt)", July 2004. v6ops- port-scanning-implications-01.txt)", July 2004.
[18] Chown, T., Tompson, M. and A. Ford, "Things to think about when [18] Chown, T., Tompson, M., and A. Ford, "Things to think about
Renumbering an IPv6 network when Renumbering an IPv6 network
(draft-chown-v6ops-renumber-thinkabout-00)", October 2004. (draft-chown-v6ops-renumber-thinkabout-00)", October 2004.
Authors' Addresses Authors' Addresses
Gunter Van de Velde Gunter Van de Velde
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
skipping to change at page 26, line 19 skipping to change at page 27, line 4
Email: rdroms@cisco.com Email: rdroms@cisco.com
Brian Carpenter Brian Carpenter
IBM Corporation IBM Corporation
Sauemerstrasse 4 Sauemerstrasse 4
Rueschlikon, 8803 Rueschlikon, 8803
Switzerland Switzerland
Email: brc@zurich.ibm.com Email: brc@zurich.ibm.com
Eric Klein Eric Klein
TTI Telecom Leon Recanati Graduate School of Business Administration at Tel
Petach Tikvah, Aviv University
Tel Aviv,
Israel Israel
Phone: +972 3 926-9130 Email: ericlklein@softhome.net
Email: erick@tti-telecom.com
Appendix A. Additional benefits due to Native IPv6 and universal unique Appendix A. Additional benefits due to Native IPv6 and universal unique
addressing addressing
The users of native IPv6 technology and global unique IPv6 addresses The users of native IPv6 technology and global unique IPv6 addresses
have the potential to make use of the enhanced IPv6 capabilities, in have the potential to make use of the enhanced IPv6 capabilities, in
addition to the benefits offered by the IPv4 technology. addition to the benefits offered by the IPv4 technology.
A.1 Universal any-to-any connectivity A.1 Universal any-to-any connectivity
skipping to change at page 28, line 28 skipping to change at page 29, line 8
and avoid illegal access to network resources by simpler traffic and avoid illegal access to network resources by simpler traffic
filtering. filtering.
o The usage of private address-space in IPv6 is now provided by o The usage of private address-space in IPv6 is now provided by
Unique Local Addresses, which will avoid conflict situations when Unique Local Addresses, which will avoid conflict situations when
merging networks and securing the internal communication on a merging networks and securing the internal communication on a
local network infrastructure due to simpler traffic filtering local network infrastructure due to simpler traffic filtering
policy. policy.
o The technology to enable source-routing on a network o The technology to enable source-routing on a network
infrastructure has been enhanced to allow this feature to infrastructure has been enhanced to allow this feature to
function, without impacting the processing power of intermediate function, without impacting the processing power of intermediate
network devices. The only devices impacted with the network devices. The only devices impacted with the source-
source-routing will be the source and destination node and the routing will be the source and destination node and the
intermediate source-routed nodes. This impact behavior is intermediate source-routed nodes. This impact behavior is
different if IPv4 is used, because then all intermediate devices different if IPv4 is used, because then all intermediate devices
would have had to look into the source-route header. would have had to look into the source-route header.
A.5 Mobility A.5 Mobility
Anytime, anywhere, universal access requires MIPv6 services in Anytime, anywhere, universal access requires MIPv6 services in
support of mobile nodes. While a Home Agent is required for initial support of mobile nodes. While a Home Agent is required for initial
connection establishment in either protocol version, IPv6 mobile connection establishment in either protocol version, IPv6 mobile
nodes are able to optimize the path between them using the MIPv6 nodes are able to optimize the path between them using the MIPv6
skipping to change at page 28, line 51 skipping to change at page 29, line 31
all packets. In general terms this will minimize the network all packets. In general terms this will minimize the network
resources used and maximize the quality of the communication. resources used and maximize the quality of the communication.
A.6 Merging networks A.6 Merging networks
When two IPv4 networks want to merge it is not guaranteed that both When two IPv4 networks want to merge it is not guaranteed that both
networks would be using different address-ranges on some parts of the networks would be using different address-ranges on some parts of the
network infrastructure due to the legitimate usage of RFC 1918 network infrastructure due to the legitimate usage of RFC 1918
private addressing. This potential overlap in address space may private addressing. This potential overlap in address space may
complicate a merge of two and more networks dramatically due to the complicate a merge of two and more networks dramatically due to the
additional IPv4 renumbering effort. i.e. when the first network has additional IPv4 renumbering effort. i.e. when the first network has a
a service running (NTP, DNS, DHCP, HTTP, etc..) which need to be service running (NTP, DNS, DHCP, HTTP, etc..) which need to be
accessed by the 2nd merging network. Similar address conflicts can accessed by the 2nd merging network. Similar address conflicts can
happen when two network devices from these merging networks want to happen when two network devices from these merging networks want to
communicate. communicate.
With the usage of IPv6 the addressing overlap will not exist because With the usage of IPv6 the addressing overlap will not exist because
of the existence of the Unique Local Address usage for private and of the existence of the Unique Local Address usage for private and
local addressing. local addressing.
A.7 Community of interest A.7 Community of interest
skipping to change at page 29, line 42 skipping to change at page 30, line 23
o Document introduction has been revised and overview table added o Document introduction has been revised and overview table added
o Comments and suggestions from nap-00 draft have been included. o Comments and suggestions from nap-00 draft have been included.
o Initial section of -00 draft 2.6 and 4.6 have been aggregated into o Initial section of -00 draft 2.6 and 4.6 have been aggregated into
a new case study section 5. a new case study section 5.
o The list of additional IPv6 benefits has been been placed into o The list of additional IPv6 benefits has been been placed into
appendix. appendix.
o new security considerations section added. o new security considerations section added.
o GAP analysis revised. o GAP analysis revised.
o Section 2.6 and 4.6 have been included. o Section 2.6 and 4.6 have been included.
B.2 Changes from *-vandevelde-v6ops-nap-01 to ietf-v6ops-nap-00 B.2 Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00
o Change of Draft name from draft-vandevelde-v6ops-nap-01.txt to o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *-ietf-
draft-ietf-v6ops-nap-00.txt. v6ops-nap-00.txt.
o Editorial changes. o Editorial changes.
B.3 Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01
o Added text in Chapter 2.2 and 4.2 to address more details on
firewall and proxy
o Revised Eric Klein contact details
o Added note in 4.2 that control over the proposed statefull-filter
should be by a simple user-interface
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/