draft-ietf-v6ops-security-overview-03.txt   draft-ietf-v6ops-security-overview-04.txt 
IPv6 Operations E. Davies IPv6 Operations E. Davies
Internet-Draft Consultant Internet-Draft Consultant
Expires: April 9, 2006 S. Krishnan Expires: September 7, 2006 S. Krishnan
Ericsson Ericsson
P. Savola P. Savola
CSC/Funet CSC/Funet
October 6, 2005 March 6, 2006
IPv6 Transition/Co-existence Security Considerations IPv6 Transition/Co-existence Security Considerations
draft-ietf-v6ops-security-overview-03.txt draft-ietf-v6ops-security-overview-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 April 9, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The transition from a pure IPv4 network to a network where IPv4 and The transition from a pure IPv4 network to a network where IPv4 and
IPv6 co-exist brings a number of extra security considerations that IPv6 co-exist brings a number of extra security considerations that
need to be taken into account when deploying IPv6 and operating the need to be taken into account when deploying IPv6 and operating the
dual-protocol network and the associated transition mechanisms. This dual-protocol network and the associated transition mechanisms. This
document attempts to give an overview of the various issues grouped document attempts to give an overview of the various issues grouped
into three categories: into three categories:
o issues due to the IPv6 protocol itself, o issues due to the IPv6 protocol itself,
o issues due to transition mechanisms, and o issues due to transition mechanisms, and
o issues due to IPv6 deployment. o issues due to IPv6 deployment.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4 2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 4 2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 4
2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 4 2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 4
2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 5 2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 5
2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 5 2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 6
2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 6 2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 6
2.1.5. Anycast Traffic Identification and Security . . . . . 7 2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 7
2.1.6. Address Privacy Extensions Interact with DDoS 2.1.6. Anycast Traffic Identification and Security . . . . . 7
Defenses . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.7. Address Privacy Extensions Interact with DDoS
2.1.7. Dynamic DNS: Stateless Address Auto-Configuration, Defenses . . . . . . . . . . . . . . . . . . . . . . . 8
Privacy Extensions and SEND . . . . . . . . . . . . . 8 2.1.8. Dynamic DNS: Stateless Address Auto-Configuration,
2.1.8. Extension Headers . . . . . . . . . . . . . . . . . . 8 Privacy Extensions and SEND . . . . . . . . . . . . . 9
2.1.9. Fragmentation: Reassembly and Deep Packet 2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 9
Inspection . . . . . . . . . . . . . . . . . . . . . . 11 2.1.10. Fragmentation: Reassembly and Deep Packet
2.1.10. Fragmentation Related DoS Attacks . . . . . . . . . . 11 Inspection . . . . . . . . . . . . . . . . . . . . . . 12
2.1.11. Link-Local Addresses and Securing Neighbor 2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 13
Discovery . . . . . . . . . . . . . . . . . . . . . . 12 2.1.12. Link-Local Addresses and Securing Neighbor
2.1.12. Securing Router Advertisements . . . . . . . . . . . . 13 Discovery . . . . . . . . . . . . . . . . . . . . . . 13
2.1.13. Host to Router Load Sharing . . . . . . . . . . . . . 13 2.1.13. Securing Router Advertisements . . . . . . . . . . . . 14
2.1.14. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 14 2.1.14. Host to Router Load Sharing . . . . . . . . . . . . . 15
2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 14 2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 15
2.3. Increased End-to-End Transparency . . . . . . . . . . . . 15 2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 15
2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 15 2.3. Increased End-to-End Transparency . . . . . . . . . . . . 16
2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 16 2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 16
3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 17 2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 17
3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 17 2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 18
3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 18 3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 18
3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 19
3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 19
3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4
Network Security Assumptions . . . . . . . . . . . . . . . 19 Network Security Assumptions . . . . . . . . . . . . . . . 20
4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 20 4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 21
4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 20 4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 21
4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 22 4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 23
4.3. Addressing Schemes and Securing Routers . . . . . . . . . 22 4.3. Addressing Schemes and Securing Routers . . . . . . . . . 23
4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 22 4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 24
4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 23 4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 25
4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 24 4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 25
4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 24 4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 25
4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 25 4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 26
4.8. Operational Factors when Enabling IPv6 in the Network . . 25 4.8. Operational Factors when Enabling IPv6 in the Network . . 26
4.9. Ingress Filtering Issues Due to Privacy Addresses . . . . 26 4.9. Ingress Filtering Issues Due to Privacy Addresses . . . . 27
4.10. Security Issues Due to ND Proxies . . . . . . . . . . . . 26 4.10. Security Issues Due to ND Proxies . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 32 Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 33
Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 33 Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 34
B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 33 B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 34
B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 33 B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 35
B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 34 B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
The transition from a pure IPv4 network to a network where IPv4 and The transition from a pure IPv4 network to a network where IPv4 and
IPv6 co-exist brings a number of extra security considerations that IPv6 co-exist brings a number of extra security considerations that
need to be taken into account when deploying IPv6 and operating the need to be taken into account when deploying IPv6 and operating the
dual-protocol network with its associated transition mechanisms. dual-protocol network with its associated transition mechanisms.
This document attempts to give an overview of the various issues This document attempts to give an overview of the various issues
grouped into three categories: grouped into three categories:
o issues due to the IPv6 protocol itself, o issues due to the IPv6 protocol itself,
o issues due to transition mechanisms, and o issues due to transition mechanisms, and
o issues due to IPv6 deployment. o issues due to IPv6 deployment.
It is important to understand that we have to be concerned not about It is important to understand that we have to be concerned not about
replacing IPv4 with IPv6 (in the short term), but with adding IPv6 to replacing IPv4 with IPv6 (in the short term), but with adding IPv6 to
be operated in parallel with IPv4 [I-D.savola-v6ops-transarch]. be operated in parallel with IPv4 [I-D.savola-v6ops-transarch].
This document also describes two matters which have been wrongly This document also describes two matters that have been wrongly
identified as potential security concerns for IPv6 in the past and identified as potential security concerns for IPv6 in the past and
explains why they are unlikely to cause problems: considerations explains why they are unlikely to cause problems: considerations
about probing/mapping IPv6 addresses (Appendix A), and considerations about probing/mapping IPv6 addresses (Appendix A), and considerations
with respect to privacy in IPv6 (Appendix B). with respect to privacy in IPv6 (Appendix B).
2. Issues Due to IPv6 Protocol 2. Issues Due to IPv6 Protocol
2.1. IPv6 Protocol-specific Issues 2.1. IPv6 Protocol-specific Issues
There are significant differences between the features of IPv6 and There are significant differences between the features of IPv6 and
IPv4: some of these specification changes may result in potential IPv4: some of these specification changes may result in potential
security issues. Several of these issues have been discussed in security issues. Several of these issues have been discussed in
separate drafts but are summarized here to avoid normative references separate drafts but are summarized here to avoid normative references
which may not become RFCs. The following specification-related that may not become RFCs. The following specification-related
problems have been identified, but this is not necessarily a complete problems have been identified, but this is not necessarily a complete
list: list:
2.1.1. Routing Headers and Hosts 2.1.1. Routing Headers and Hosts
All IPv6 nodes must be able to process Routing Headers [RFC2460]. All IPv6 nodes must be able to process Routing Headers [RFC2460].
This RFC can be interpreted, although it is not clearly stated, to This RFC can be interpreted, although it is not clearly stated, to
mean that all nodes (including hosts) must have this processing mean that all nodes (including hosts) must have this processing
enabled. This can result in hosts forwarding received traffic if enabled. This can result in hosts forwarding received traffic if
there are segments left in the Routing Header when it arrives at the there are segments left in the Routing Header when it arrives at the
skipping to change at page 5, line 5 skipping to change at page 5, line 5
mean that all nodes (including hosts) must have this processing mean that all nodes (including hosts) must have this processing
enabled. This can result in hosts forwarding received traffic if enabled. This can result in hosts forwarding received traffic if
there are segments left in the Routing Header when it arrives at the there are segments left in the Routing Header when it arrives at the
host. host.
A number of potential security issues associated with this behavior A number of potential security issues associated with this behavior
were documented in [I-D.savola-ipv6-rh-hosts]. Some of these issues were documented in [I-D.savola-ipv6-rh-hosts]. Some of these issues
have been resolved (a separate routing header type is now used for have been resolved (a separate routing header type is now used for
Mobile IPv6 [RFC3775] and ICMP Traceback has not been standardized), Mobile IPv6 [RFC3775] and ICMP Traceback has not been standardized),
but two issues remain: but two issues remain:
o Routing headers can be used to evade access controls based on o Routing headers can be used to evade access controls based on
destination addresses. This could be achieved by sending a packet destination addresses. This could be achieved by sending a packet
ostensibly to a publicly accessible host address but with a ostensibly to a publicly accessible host address but with a
routing header containing a 'forbidden' address. If the publicly routing header containing a 'forbidden' address. If the publicly
accessible host is processing routing headers it will forward the accessible host is processing routing headers it will forward the
packet to the destination address in the routing header which packet to the destination address in the routing header that would
would have been forbidden by the packet filters if the address had have been forbidden by the packet filters if the address had been
been in the destination field when the packet was checked. in the destination field when the packet was checked.
o If the packet source address in the previous case can be spoofed, o If the packet source address in the previous case can be spoofed,
any host could be used to mediate an anonymous reflection denial- any host could be used to mediate an anonymous reflection denial-
of-service attack by having any publicly accessible host redirect of-service attack by having any publicly accessible host redirect
the attack packets. the attack packets.
To counteract these threats, if a device is enforcing access controls
based on destination addresses, it needs to examine both the
destination address in the base IPv6 header and any way point
destinations in a routing header that have not yet been reached by
the packet at the point wher it is being checked.
Various forms of amplication attack on routers and firewalls using
the routing header could be envisaged. A simple form involves
repeating the address of a way point several times in the routing
header. More complex forms could involve alternating way point
addresses that would result in the packet re-transiting the router or
firewall. These attacks can be counteracted by ensuring that routing
headers do not contain the same way point address more than once, and
performing ingress/egress filtering to check that the source address
is appropriate to the destination: packets made to reverse their path
will fail this test.
2.1.2. Routing Headers for Mobile IPv6 and Other Purposes 2.1.2. Routing Headers for Mobile IPv6 and Other Purposes
In addition to the basic Routing Header (Type 0), which is intended In addition to the basic Routing Header (Type 0), which is intended
to influence the trajectory of a packet through a network by to influence the trajectory of a packet through a network by
specifying a sequence of router 'waypoints', Routing Header (Type 2) specifying a sequence of router 'waypoints', Routing Header (Type 2)
has been defined as part of the Mobile IPv6 specifications in has been defined as part of the Mobile IPv6 specifications in
[RFC3775]. The Type 2 Routing Header is intended for use by hosts to [RFC3775]. The Type 2 Routing Header is intended for use by hosts to
handle 'interface local' forwarding needed when packets are sent to handle 'interface local' forwarding needed when packets are sent to
the care-of address of a mobile node which is away from its home the care-of address of a mobile node that is away from its home
address. address.
It is important that nodes treat the different types of routing It is important that nodes treat the different types of routing
header appropriately. It should be possible to apply separate header appropriately. It should be possible to apply separate
filtering rules to the different types of Routing Header. By design, filtering rules to the different types of Routing Header. By design,
hosts must process Type 2 Routing Headers to support Mobile IPv6 but hosts must process Type 2 Routing Headers to support Mobile IPv6 but
routers should not: to avoid the issues in Section 2.1.1 it may be routers should not: to avoid the issues in Section 2.1.1 it may be
desirable to forbid or limit the processing of Type 0 Routing Headers desirable to forbid or limit the processing of Type 0 Routing Headers
in hosts and some routers. in hosts and some routers.
Routing Headers are an extremely powerful and general capability. Routing Headers are an extremely powerful and general capability.
Alternative future uses of Routing Headers need to be carefully Alternative future uses of Routing Headers need to be carefully
assessed to ensure that they do not open new avenues of attack that assessed to ensure that they do not open new avenues of attack that
can be exploited. can be exploited.
2.1.3. Site-scope Multicast Addresses 2.1.3. Site-scope Multicast Addresses
IPv6 supports multicast addresses with site scope which can IPv6 supports multicast addresses with site scope that can
potentially allow an attacker to identify certain important resources potentially allow an attacker to identify certain important resources
on the site if misused. on the site if misused.
Particular examples are the 'all routers' (FF05::2) and 'all Dynamic Particular examples are the 'all routers' (FF05::2) and 'all Dynamic
Host Configuration Protocol (DHCP) servers' (FF05::1:3) addresses Host Configuration Protocol (DHCP) servers' (FF05::1:3) addresses
defined in [RFC2375]: an attacker that is able to infiltrate a defined in [RFC2375]: an attacker that is able to infiltrate a
message destined for these addresses on to the site will potentially message destined for these addresses on to the site will potentially
receive in return information identifying key resources on the site. receive in return information identifying key resources on the site.
This information can then be the target of directed attacks ranging This information can then be the target of directed attacks ranging
from simple flooding to more specific mechanisms designed to subvert from simple flooding to more specific mechanisms designed to subvert
skipping to change at page 6, line 20 skipping to change at page 6, line 37
The risk can be minimized by ensuring that all firewalls and site The risk can be minimized by ensuring that all firewalls and site
boundary routers are configured to drop packets with site scope boundary routers are configured to drop packets with site scope
destination addresses. Also nodes should not join multicast groups destination addresses. Also nodes should not join multicast groups
for which there is no legitimate use on the site and site routers for which there is no legitimate use on the site and site routers
should be configured to drop packets directed to these unused should be configured to drop packets directed to these unused
addresses. addresses.
2.1.4. ICMPv6 and Multicast 2.1.4. ICMPv6 and Multicast
It is possible to launch a denial-of-service (DoS) attack using IPv6 It is possible to launch a denial-of-service (DoS) attack using IPv6
which could be amplified by the multicast infrastructure. that could be amplified by the multicast infrastructure.
Unlike ICMP for IPv4, ICMPv6 [RFC2463] allows error notification Unlike ICMP for IPv4, ICMPv6 [RFC2463] allows error notification
responses to be sent when certain unprocessable packets are sent to responses to be sent when certain unprocessable packets are sent to
multicast addresses. multicast addresses.
The cases in which responses are sent are: The cases in which responses are sent are:
o The received packet is longer than the next link MTU: 'Packet Too o The received packet is longer than the next link MTU: 'Packet Too
Big' responses are needed to support Path MTU Discovery for Big' responses are needed to support Path MTU Discovery for
multicast traffic. multicast traffic.
o The received packet contains an unrecognized option in a hop-by- o The received packet contains an unrecognized option in a hop-by-
hop or destination options extension header with the first two hop or destination options extension header with the first two
bits of the option type set to binary '10': 'Parameter Problem' bits of the option type set to binary '10': 'Parameter Problem'
responses are intended to inform the source that some or all of responses are intended to inform the source that some or all of
the recipients cannot handle the option in question. the recipients cannot handle the option in question.
If an attacker can craft a suitable packet sent to a multicast If an attacker can craft a suitable packet sent to a multicast
destination, it may be possible to elicit multiple responses directed destination, it may be possible to elicit multiple responses directed
at the victim (the spoofed source of the multicast packet). On the at the victim (the spoofed source of the multicast packet). On the
other hand, the use of 'reverse path forwarding' checks to eliminate other hand, the use of 'reverse path forwarding' checks to eliminate
loops in multicast forwarding automatically limits the range of loops in multicast forwarding automatically limits the range of
addresses which can be spoofed. addresses that can be spoofed.
In practice an attack using oversize packets is unlikely to cause In practice an attack using oversize packets is unlikely to cause
much amplification unless the attacker is able to carefully tune the much amplification unless the attacker is able to carefully tune the
packet size to exploit a network with smaller MTU in the edge than packet size to exploit a network with smaller MTU in the edge than
the core. Similarly a packet with an unrecognized hop-by-hop option the core. Similarly a packet with an unrecognized hop-by-hop option
would be dropped by the first router. However a packet with an would be dropped by the first router. However a packet with an
unrecognized destination option could generate multiple responses. unrecognized destination option could generate multiple responses.
In addition to amplification, this kind of attack would potentially In addition to amplification, this kind of attack would potentially
consume large amounts of forwarding state resources in routers on consume large amounts of forwarding state resources in routers on
multicast-enabled networks. These attacks are discussed in more multicast-enabled networks. These attacks are discussed in more
detail in [I-D.savola-v6ops-firewalling]. detail in [I-D.savola-v6ops-firewalling].
2.1.5. Anycast Traffic Identification and Security 2.1.5. Bogus Errored Packets in ICMPv6 Error Messages
Apart from the spurious load on the network, routers and hosts, bogus
ICMPv6 error messages (types 0 to 127) containing a spoofed errored
packet can impact higher layer protocols when the alleged errored
packet is referred to the higher layer at the destination of the
ICMPv6 packet [RFC2463]. The potentially damaging effects on TCP
connections and some ways to mitigate the threats are documented in
[I-D.gont-tcpm-icmp-attacks].
Specific countermeasures for particular higher layer protocols are
beyond the scope of this document but firewalls may be able to help
counter the threat by inspecting the alleged errored packet embedded
in the ICMPv6 error message. The firewall and the receiving host
should test that the embedded packet contains addresses that would
have been legitimate (i.e., would have passed ingress/egress
filtering) for a packet sent from the receiving host. The
specification of ICMPv6 and the requirement that networks should have
a minimum MTU of 1280 octets (as compared with ICMP and IPv4), means
that the ICMPv6 should normally carry all the header fields of the
errored packet. Firewalls and destination hosts should therefore be
suspicious of ICMPv6 error messages with very truncated errored
packets (e.g., those that only carry the address fields of the IPv6
base header.)
2.1.6. Anycast Traffic Identification and Security
IPv6 introduces the notion of anycast addresses and services. IPv6 introduces the notion of anycast addresses and services.
Originally the IPv6 standards disallowed using an anycast address as Originally the IPv6 standards disallowed using an anycast address as
the source address of a packet. Responses from an anycast server the source address of a packet. Responses from an anycast server
would therefore supply a unicast address for the responding server. would therefore supply a unicast address for the responding server.
To avoid exposing knowledge about the internal structure of the To avoid exposing knowledge about the internal structure of the
network, it is recommended that anycast servers now take advantage of network, it is recommended that anycast servers now take advantage of
the ability to return responses with the anycast address as the the ability to return responses with the anycast address as the
source address if possible. source address if possible.
If the server needs to use a unicast address for any reason, it may If the server needs to use a unicast address for any reason, it may
be desirable to consider using specialized addresses for anycast be desirable to consider using specialized addresses for anycast
servers which are not used for any other part of the network to servers, which are not used for any other part of the network, to
restrict the information exposed. Alternatively operators may wish restrict the information exposed. Alternatively operators may wish
to restrict the use of anycast services from outside the domain, thus to restrict the use of anycast services from outside the domain, thus
requiring firewalls to filter anycast requests. For this purpose, requiring firewalls to filter anycast requests. For this purpose,
firewalls need to know which addresses are being used for anycast firewalls need to know which addresses are being used for anycast
services: these addresses are arbitrary and not distinguishable from services: these addresses are arbitrary and not distinguishable from
any other IPv6 unicast address by structure or pattern. any other IPv6 unicast address by structure or pattern.
One particular class of anycast addresses that should be given One particular class of anycast addresses that should be given
special attention is the set of Subnet-Router anycast addresses special attention is the set of Subnet-Router anycast addresses
defined in The IPv6 Addressing Architecture [RFC3513]. All routers defined in The IPv6 Addressing Architecture [RFC4291]. All routers
are required to support these addresses for all subnets for which are required to support these addresses for all subnets for which
they have interfaces. For most subnets using global unicast they have interfaces. For most subnets using global unicast
addresses, filtering anycast requests to these addresses can be addresses, filtering anycast requests to these addresses can be
achieved by dropping packets with the lower 64 bits (the Interface achieved by dropping packets with the lower 64 bits (the Interface
Identifier) set to all zeroes. Identifier) set to all zeroes.
2.1.6. Address Privacy Extensions Interact with DDoS Defenses 2.1.7. Address Privacy Extensions Interact with DDoS Defenses
The purpose of the privacy extensions for stateless address auto- The purpose of the privacy extensions for stateless address auto-
configuration [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] is to change configuration [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] is to change
the interface identifier (and hence the global scope addresses the interface identifier (and hence the global scope addresses
generated from it) from time to time. By varying the addresses used, generated from it) from time to time. By varying the addresses used,
eavesdroppers and other information collectors find it more difficult eavesdroppers and other information collectors find it more difficult
to identify which transactions actually relate to a specific node. to identify which transactions actually relate to a specific node.
A security issue may result from this if the frequency of node A security issue may result from this if the frequency of node
address change is sufficiently great to achieve the intended aim of address change is sufficiently great to achieve the intended aim of
the privacy extensions: with a relatively high rate of change, the the privacy extensions: with a relatively high rate of change, the
observed behavior of the node could look very like that of a observed behavior of the node could look very like that of a
compromised node which was the source of a distributed denial of compromised node that was the source of a distributed denial of
service (DDoS). It would thus be difficult for any future defenses service (DDoS). It would thus be difficult for any future defenses
against DDoS attacks to distinguish between a high rate of change of against DDoS attacks to distinguish between a high rate of change of
addresses resulting from genuine use of the privacy extensions and a addresses resulting from genuine use of the privacy extensions and a
compromised node being used as the source of a DDoS with 'in-prefix' compromised node being used as the source of a DDoS with 'in-prefix'
spoofed source addresses as described in [I-D.dupont-ipv6- spoofed source addresses as described in [I-D.dupont-ipv6-
rfc3041harmful]. rfc3041harmful].
Even if a node is well behaved, the change in the address could make Even if a node is well behaved, the change in the address could make
it harder for a security administrator to define a policy rule (e.g. it harder for a security administrator to define a policy rule (e.g.
access control list) that takes into account a specific node. access control list) that takes into account a specific node.
2.1.7. Dynamic DNS: Stateless Address Auto-Configuration, Privacy 2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, Privacy
Extensions and SEND Extensions and SEND
The introduction of Stateless Address Auto-Configuration (SLAAC) The introduction of Stateless Address Auto-Configuration (SLAAC)
[RFC2462] with IPv6 provides an additional challenge to the security [RFC2462] with IPv6 provides an additional challenge to the security
of Dynamic DNS (DDNS). With manual addressing or the use of DHCP, of Dynamic DNS (DDNS). With manual addressing or the use of DHCP,
the number of security associations that need to be maintained to the number of security associations that need to be maintained to
secure access to the DNS server is limited, assuming any necessary secure access to the DNS server is limited, assuming any necessary
updates are carried out by the DHCP server. This is true equally for updates are carried out by the DHCP server. This is true equally for
IPv4 and IPv6. IPv4 and IPv6.
skipping to change at page 8, line 38 skipping to change at page 9, line 31
between each node and the DDNS server. This is discussed further in between each node and the DDNS server. This is discussed further in
[I-D.ietf-dnsop-ipv6-dns-issues]. [I-D.ietf-dnsop-ipv6-dns-issues].
Using the Privacy Extensions to SLAAC [RFC3041][I-D.ietf-ipv6- Using the Privacy Extensions to SLAAC [RFC3041][I-D.ietf-ipv6-
privacy-addrs-v2] may significantly increase the rate of updates of privacy-addrs-v2] may significantly increase the rate of updates of
DDNS. Even if a node using the Privacy Extensions does not publish DDNS. Even if a node using the Privacy Extensions does not publish
its address for 'forward' lookup (as that would effectively its address for 'forward' lookup (as that would effectively
compromise the privacy which it is seeking), it may still need to compromise the privacy which it is seeking), it may still need to
update the reverse DNS records so that reverse routability checks can update the reverse DNS records so that reverse routability checks can
be carried out. If the rate of change needed to achieve real privacy be carried out. If the rate of change needed to achieve real privacy
has to be increased as is mentioned in Section 2.1.6 the update rate has to be increased as is mentioned in Section 2.1.7 the update rate
for DDNS may be excessive. for DDNS may be excessive.
Similarly, the cryptographically generated addresses used by SEND Similarly, the cryptographically generated addresses used by SEND
[RFC3971] are expected to be periodically regenerated in line with [RFC3971] are expected to be periodically regenerated in line with
recommendations for maximum key lifetimes. This regeneration could recommendations for maximum key lifetimes. This regeneration could
also impose a significant extra load on DDNS. also impose a significant extra load on DDNS.
2.1.8. Extension Headers 2.1.9. Extension Headers
A number of issues relating to the specification of IPv6 Extension A number of issues relating to the specification of IPv6 Extension
headers have been identified. Several of these are discussed in headers have been identified. Several of these are discussed in
[I-D.savola-v6ops-firewalling]. [I-D.savola-v6ops-firewalling].
2.1.8.1. Processing Extension Headers in Middleboxes 2.1.9.1. Processing Extension Headers in Middleboxes
In IPv4 deep packet inspection techniques are used to implement In IPv4 deep packet inspection techniques are used to implement
policing and filtering both as part of routers and in middleboxes policing and filtering both as part of routers and in middleboxes
such as firewalls. Fully extending these techniques to IPv6 would such as firewalls. Fully extending these techniques to IPv6 would
require inspection of all the extension headers in a packet. This is require inspection of all the extension headers in a packet. This is
essential to ensure that policy constraints on the use of certain essential to ensure that policy constraints on the use of certain
headers and options are enforced and to remove, at the earliest headers and options are enforced and to remove, at the earliest
opportunity, packets containing potentially damaging unknown options. opportunity, packets containing potentially damaging unknown options.
This requirement appears to conflict with Section 4 of the IPv6 This requirement appears to conflict with Section 4 of the IPv6
specification in [RFC2460] which requires that destination options specification in [RFC2460] which requires that destination options
are not processed at all until the packet reaches the appropriate are not processed at all until the packet reaches the appropriate
destination (either the final destination or a routing header destination (either the final destination or a routing header
waypoint). waypoint).
Also [RFC2460] forbids processing the headers other than in the order Also [RFC2460] forbids processing the headers other than in the order
in which they appear in the packet. in which they appear in the packet.
A further ambiguity relates to whether an intermediate node should A further ambiguity relates to whether an intermediate node should
discard a packet which contains a header or destination option which discard a packet that contains a header or destination option which
it does not recognize. If the rules above are followed slavishly, it it does not recognize. If the rules above are followed slavishly, it
is not (or may not be) legitimate for the intermediate node to is not (or may not be) legitimate for the intermediate node to
discard the packet because it should not be processing those headers discard the packet because it should not be processing those headers
or options. or options.
[RFC2460] therefore does not appear to take account of the behavior [RFC2460] therefore does not appear to take account of the behavior
of middleboxes and other non-final destinations which may be of middleboxes and other non-final destinations that may be
inspecting the packet, and thereby potentially limits the security inspecting the packet, and thereby potentially limits the security
protection of these boxes. protection of these boxes.
2.1.8.2. Processing Extension Header Chains 2.1.9.2. Processing Extension Header Chains
There is a further problem for middleboxes that want to examine the There is a further problem for middleboxes that want to examine the
transport headers which are located at the end of the IPv6 header transport headers, which are located at the end of the IPv6 header
chain. In order to locate the transport header or other protocol chain. In order to locate the transport header or other protocol
data unit, the node has to parse the header chain. data unit, the node has to parse the header chain.
The IPv6 specification [RFC2460] does not mandate the use of the The IPv6 specification [RFC2460] does not mandate the use of the
Type-Length-Value format with a fixed layout for the start of each Type-Length-Value format with a fixed layout for the start of each
header although it is used for the majority of headers currently header although it is used for the majority of headers currently
defined. (Only the Type field is guaranteed in size and offset). defined. (Only the Type field is guaranteed in size and offset).
A middlebox cannot therefore guarantee to be able to process header A middlebox cannot therefore guarantee to be able to process header
chains which may contain headers defined after the box was chains that may contain headers defined after the box was
manufactured. As noted in Section 2.1.8.1, middleboxes ought not to manufactured. As noted in Section 2.1.9.1, middleboxes ought not to
have to know about all header types in use but still need to be able have to know about all header types in use but still need to be able
to skip over such headers to find the transport PDU start. This to skip over such headers to find the transport PDU start. This
either limits the security which can be applied in firewalls or makes either limits the security that can be applied in firewalls or makes
it difficult to deploy new extension header types. it difficult to deploy new extension header types.
At the time of writing, only the Fragment Header does not fully At the time of writing, only the Fragment Header does not fully
conform to the TLV format used for other extension headers. In conform to the TLV format used for other extension headers. In
practice, many firewalls reconstruct fragmented packets before practice, many firewalls reconstruct fragmented packets before
performing deep packet inspection, so this divergence is less performing deep packet inspection, so this divergence is less
problematic than it might have been, and is at least partially problematic than it might have been, and is at least partially
justified because the full header chain is not present in all justified because the full header chain is not present in all
fragments. fragments.
Destination Options may also contain unknown options. However, the Destination Options may also contain unknown options. However, the
options are encoded in TLV format so that intermediate nodes can skip options are encoded in TLV format so that intermediate nodes can skip
over them during processing, unlike the enclosing extension headers. over them during processing, unlike the enclosing extension headers.
2.1.8.3. Unknown Headers/Destination Options and Security Policy 2.1.9.3. Unknown Headers/Destination Options and Security Policy
A strict security policy might dictate that packets containing either A strict security policy might dictate that packets containing either
unknown headers or destination options are discarded by firewalls or unknown headers or destination options are discarded by firewalls or
other filters. This requires the firewall to process the whole other filters. This requires the firewall to process the whole
extension header chain which may be currently in conflict with the extension header chain, which may be currently in conflict with the
IPv6 specification as discussed in Section 2.1.8.1. IPv6 specification as discussed in Section 2.1.9.1.
Even if the firewall does inspect the whole header chain, it may not Even if the firewall does inspect the whole header chain, it may not
be sensible to discard packets with items unrecognized by the be sensible to discard packets with items unrecognized by the
firewall: the intermediate node has no knowledge of which options and firewall: the intermediate node has no knowledge of which options and
headers are implemented in the destination node. Hence it is highly headers are implemented in the destination node. Hence it is highly
desirable to make the discard policy configurable. This will avoid desirable to make the discard policy configurable. This will avoid
firewalls dropping packets with legitimate items that they do not firewalls dropping packets with legitimate items that they do not
recognize because their hardware or software is not aware of a new recognize because their hardware or software is not aware of a new
definition. definition.
2.1.8.4. Excessive Hop-by-Hop Options 2.1.9.4. Excessive Hop-by-Hop Options
IPv6 does not limit the number of hop by hop options which can be IPv6 does not limit the number of hop by hop options that can be
present in a hop-by-hop option header. The lack of a limit can be present in a hop-by-hop option header. The lack of a limit can be
used to mount denial of service attacks affecting all nodes on a path used to mount denial of service attacks affecting all nodes on a path
as described in [I-D.krishnan-ipv6-hopbyhop]. as described in [I-D.krishnan-ipv6-hopbyhop].
2.1.8.5. Overuse of Router Alert Option 2.1.9.5. Misuse of Pad1 and PadN Options
IPv6 allows multiple padding options of arbitrary sizes to be placed
in both Hop-by-Hop and Destination option headers. There is no
legitimate reason for having a sequence of padding option fields -
the required padding can be done with one field and there is
currently no legitimate reason for padding beyond the next four or,
at worst, eight octet boundary. PadN options are required to contain
zero octets as 'payload': there is, however, no incentive for
receivers to check this. It may therefore be possible to use padding
options as a covert channel. Firewalls and receiving hosts should
consider dropping packets that have sequences of Pad0 or PadN options
or use PadN of more than length 3 or 7, and should actively check
that PadN does not have other than zero octets in its 'payload'.
2.1.9.6. Overuse of Router Alert Option
The IPv6 router alert option specifies a hop-by-hop option that, if The IPv6 router alert option specifies a hop-by-hop option that, if
present, signals the router to take a closer look at the packet. present, signals the router to take a closer look at the packet.
This can be used for denial of service attacks. By sending a large This can be used for denial of service attacks. By sending a large
number of packets containing a router alert option an attacker can number of packets containing a router alert option an attacker can
deplete the processor cycles on the routers available to legitimate deplete the processor cycles on the routers available to legitimate
traffic. traffic.
2.1.9. Fragmentation: Reassembly and Deep Packet Inspection 2.1.10. Fragmentation: Reassembly and Deep Packet Inspection
The current specifications of IPv6 in [RFC2460] do not mandate any The current specifications of IPv6 in [RFC2460] do not mandate any
minimum packet size for the fragments of a packet before the last minimum packet size for the fragments of a packet before the last
one, except for the need to carry the unfragmentable part in all one, except for the need to carry the unfragmentable part in all
fragments. fragments.
The unfragmentable part does not include the transport port numbers The unfragmentable part does not include the transport port numbers
so that it is possible that the first fragment does not contain so that it is possible that the first fragment does not contain
sufficient information to carry out deep packet inspection involving sufficient information to carry out deep packet inspection involving
the port numbers. the port numbers.
Also the reassembly rules for fragmented packets in [RFC2460] do not Also the reassembly rules for fragmented packets in [RFC2460] do not
mandate behavior which would minimize the effects of overlapping mandate behavior that would minimize the effects of overlapping
fragments. fragments.
Depending on the implementation of packet reassembly and the Depending on the implementation of packet reassembly and the
treatment of packet fragments in firewalls and other nodes which use treatment of packet fragments in firewalls and other nodes that use
deep packet inspection for traffic filtering, this potentially leaves deep packet inspection for traffic filtering, this potentially leaves
IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128] IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128]
for IPv4. for IPv4.
There is no reason to allow overlapping packet fragments and overlaps There is no reason to allow overlapping packet fragments and overlaps
could be prohibited in a future revision of the protocol could be prohibited in a future revision of the protocol
specification. Some implementations already drop all packets with specification. Some implementations already drop all packets with
overlapped fragments. overlapped fragments.
Specifying a minimum size for packet fragments does not help in the Specifying a minimum size for packet fragments does not help in the
same way as it does for IPv4 because IPv6 extension headers can be same way as it does for IPv4 because IPv6 extension headers can be
made to appear very long: an attacker could insert one or more made to appear very long: an attacker could insert one or more
undefined destination options with long lengths and the 'ignore if undefined destination options with long lengths and the 'ignore if
unknown' bit set. Given the guaranteed minimum MTU of IPv6 it seems unknown' bit set. Given the guaranteed minimum MTU of IPv6 it seems
reasonable that hosts should be able to ensure that the transport reasonable that hosts should be able to ensure that the transport
port numbers are in the first fragment in almost all cases and that port numbers are in the first fragment in almost all cases and that
deep packet inspection should be very suspicious of first fragments deep packet inspection should be very suspicious of first fragments
that do not contain them. that do not contain them.
2.1.10. Fragmentation Related DoS Attacks 2.1.11. Fragmentation Related DoS Attacks
Packet reassembly in IPv6 hosts also opens up the possibility of Packet reassembly in IPv6 hosts also opens up the possibility of
various fragment-related security attacks. Some of these are various fragment-related security attacks. Some of these are
analogous to attacks identified for IPv4. Of particular concern is a analogous to attacks identified for IPv4. Of particular concern is a
DoS attack based on sending large numbers of small fragments without DoS attack based on sending large numbers of small fragments without
a terminating last fragment which would potentially overload the a terminating last fragment that would potentially overload the
reconstruction buffers and consume large amounts of CPU resources. reconstruction buffers and consume large amounts of CPU resources.
Mandating the size of packet fragments could reduce the impact of Mandating the size of packet fragments could reduce the impact of
this kind of attack by limiting the rate at which fragments could this kind of attack by limiting the rate at which fragments could
arrive and limiting the number of fragments which need to be arrive and limiting the number of fragments that need to be
processed. processed.
2.1.11. Link-Local Addresses and Securing Neighbor Discovery 2.1.12. Link-Local Addresses and Securing Neighbor Discovery
All IPv6 nodes are required to configure a link-local address on each All IPv6 nodes are required to configure a link-local address on each
interface. This address is used to communicate with other nodes interface. This address is used to communicate with other nodes
directly connected to the link accessed via the interface, especially directly connected to the link accessed via the interface, especially
during the neighbor discovery and auto-configuration processes. during the neighbor discovery and auto-configuration processes.
Link-local addresses are fundamental to the operation of the Neighbor Link-local addresses are fundamental to the operation of the Neighbor
Discovery Protocol (NDP) [RFC2461] and SLAAC [RFC2462]. NDP also Discovery Protocol (NDP) [RFC2461] and SLAAC [RFC2462]. NDP also
provides the functionality of associating link layer and IP addresses provides the functionality of associating link layer and IP addresses
provided by the Address Resolution Protocol (ARP) in IPv4 networks. provided by the Address Resolution Protocol (ARP) in IPv4 networks.
The standard version of NDP is subject to a number of security The standard version of NDP is subject to a number of security
threats related to ARP spoofing attacks on IPv4. These threats have threats related to ARP spoofing attacks on IPv4. These threats have
been documented in [RFC3756] and mechanisms to combat them specified been documented in [RFC3756] and mechanisms to combat them specified
in SEcure Neighbor Discovery (SEND) [RFC3971]. SEND is an optional in SEcure Neighbor Discovery (SEND) [RFC3971]. SEND is an optional
mechanism which is particularly applicable to wireless and other mechanism that is particularly applicable to wireless and other
environments where it is difficult to physically secure the link. environments where it is difficult to physically secure the link.
Because the link-local address can, by default, be acquired without Because the link-local address can, by default, be acquired without
external intervention or control, it allows an attacker to commence external intervention or control, it allows an attacker to commence
communication on the link without needing to acquire information communication on the link without needing to acquire information
about the address prefixes in use or communicate with any authorities about the address prefixes in use or communicate with any authorities
on the link. This feature gives a malicious node the opportunity to on the link. This feature gives a malicious node the opportunity to
mount an attack on any other node which is attached to this link; mount an attack on any other node that is attached to this link; this
this vulnerability exists in addition to possible direct attacks on vulnerability exists in addition to possible direct attacks on NDP.
NDP. Link-local addresses may also facilitate the unauthorized use Link-local addresses may also facilitate the unauthorized use of the
of the link bandwidth ('bandwidth theft') to communicate with another link bandwidth ('bandwidth theft') to communicate with another
unauthorized node on the same link. unauthorized node on the same link.
Link-local addresses allocated from the prefix 169.254.0.0/16 are Link-local addresses allocated from the prefix 169.254.0.0/16 are
available in IPv4 as well and procedures for using them are described available in IPv4 as well and procedures for using them are described
in [I-D.ietf-zeroconf-ipv4-linklocal] but the security issues were in [RFC3927] but the security issues were not as pronounced as for
not as pronounced as for IPv6 for the following reasons: IPv6 for the following reasons:
o link-local addresses are not mandatory in IPv4 and are primarily o link-local addresses are not mandatory in IPv4 and are primarily
intended for isolated or ad hoc networks that cannot acquire a intended for isolated or ad hoc networks that cannot acquire a
routable IPv4 address by other means, routable IPv4 address by other means,
o IPv4 link-local addresses are not universally supported across o IPv4 link-local addresses are not universally supported across
operating systems, and operating systems, and
o the IPv4 link-local address should be removed when a non-link- o the IPv4 link-local address should be removed when a non-link-
local address is configured on the interface and will generally local address is configured on the interface and will generally
not be allocated unless other means of acquiring an address are not be allocated unless other means of acquiring an address are
not available. not available.
These vulnerabilities can be mitigated in several ways. A general These vulnerabilities can be mitigated in several ways. A general
solution will require solution will require
o authenticating the link layer connectivity, for example by using o authenticating the link layer connectivity, for example by using
IEEE 802.1x functionality, port-based MAC address security IEEE 802.1x functionality, port-based MAC address security
(locking), or physical security, and (locking), or physical security, and
o using SEcure Neighbor Discovery (SEND) to create a o using SEcure Neighbor Discovery (SEND) to create a
cryptographically generated link-local address as described in cryptographically generated link-local address as described in
[RFC3971] which is tied to the authenticated link layer address. [RFC3971] that is tied to the authenticated link layer address.
This solution would be particularly appropriate in wireless LAN This solution would be particularly appropriate in wireless LAN
deployments where it is difficult to physically secure the deployments where it is difficult to physically secure the
infrastructure infrastructure
In wired environments, where the physical infrastructure is In wired environments, where the physical infrastructure is
reasonably secure, it may be sufficient to ignore communication reasonably secure, it may be sufficient to ignore communication
requests originating from a link-local address for other than local requests originating from a link-local address for other than local
network management purposes. This requires that nodes should only network management purposes. This requires that nodes should only
accept packets with link-local addresses for a limited set of accept packets with link-local addresses for a limited set of
protocols including NDP, MLD and other functions of ICMPv6. protocols including NDP, MLD and other functions of ICMPv6.
2.1.12. Securing Router Advertisements 2.1.13. Securing Router Advertisements
As part of the Neighbor Discovery process, routers on a link As part of the Neighbor Discovery process, routers on a link
advertise their capabilities in Router Advertisement messages. The advertise their capabilities in Router Advertisement messages. The
version of NDP defined in [RFC2461] does not protect the integrity of version of NDP defined in [RFC2461] does not protect the integrity of
these messages or validate the assertions made in the messages with these messages or validate the assertions made in the messages with
the result that any node which connects to the link can maliciously the result that any node that connects to the link can maliciously
claim to offer routing services which it will not fulfill, and claim to offer routing services that it will not fulfil, and
advertise inappropriate prefixes and parameters. These threats have advertise inappropriate prefixes and parameters. These threats have
been documented in [RFC3756]. been documented in [RFC3756].
A malicious node may also be able to carry out a DoS attack by A malicious node may also be able to carry out a DoS attack by
deprecating an established valid prefix (by advertising it with a deprecating an established valid prefix (by advertising it with a
zero lifetime). Similar DoS attacks are possible if the optional zero lifetime). Similar DoS attacks are possible if the optional
Router Selection mechanism is implemented as described in the Router Selection mechanism is implemented as described in the
security considerations of [I-D.ietf-ipv6-router-selection]. security considerations of [RFC4191].
SEND [RFC3971] can be used to provide verification that routers are SEND [RFC3971] can be used to provide verification that routers are
authorized to provide the services they advertise through a authorized to provide the services they advertise through a
certificate-based mechanism. This capability of SEND is also certificate-based mechanism. This capability of SEND is also
particularly appropriate for wireless environments where clients are particularly appropriate for wireless environments where clients are
reliant on the assertions of the routers rather than a physically reliant on the assertions of the routers rather than a physically
secured connection. secured connection.
2.1.13. Host to Router Load Sharing 2.1.14. Host to Router Load Sharing
If a host deploys the optional Host to Router Load Sharing mechanism If a host deploys the optional Host to Router Load Sharing mechanism
[I-D.ietf-ipv6-host-load-sharing] a malicious application could try [RFC4311] a malicious application could carry out a DoS attack on one
to subvert the load sharing algorithm to direct a large volume of or more of the load sharing routers if the application is able to use
traffic to a subset of the routers. knowledge of the load sharing algorithm to synthesize traffic that
subverts the load sharing algorithm and directs a large volume of
However, as described in [I-D.ietf-ipv6-host-load-sharing], this is bogus traffic towards a subset of the routers. The likelihood of
not considered a significant threat as such an attack can be reduced if the implementation uses a
1. load-sharing routers should be provisioned to handle the load in sufficiently sophisticated load sharing algorithm as described in the
any case (e.g., if one of them goes down), security considerations of [RFC4311].
2. a privileged user can launch such an attack using raw sockets in
any case, and
3. a user or application could just attack the routers directly or
in other, simpler ways.
2.1.14. Mobile IPv6 2.1.15. Mobile IPv6
Mobile IPv6 offers significantly enhanced security compared with Mobile IPv6 offers significantly enhanced security compared with
Mobile IPv4 especially when using optimized routing and care-of Mobile IPv4 especially when using optimized routing and care-of
addresses. Return routability checks are used to provide relatively addresses. Return routability checks are used to provide relatively
robust assurance that the different addresses which a mobile node robust assurance that the different addresses that a mobile node uses
uses as it moves through the network do indeed all refer to the same as it moves through the network do indeed all refer to the same node.
node. The threats and solutions are described in [RFC3775] and a The threats and solutions are described in [RFC3775] and a more
more extensive discussion of the security aspects of the design can extensive discussion of the security aspects of the design can be
be found in [I-D.ietf-mip6-ro-sec]. found in [RFC4225].
2.1.14.1. Obsolete Home Address Option in Mobile IPv6 2.1.15.1. Obsolete Home Address Option in Mobile IPv6
The Home Address option specified in early drafts of Mobile IPv6 The Home Address option specified in early drafts of Mobile IPv6
would have allowed a trivial source spoofing attack: hosts were would have allowed a trivial source spoofing attack: hosts were
required to substitute the source address of incoming packets with required to substitute the source address of incoming packets with
the address in the option, thereby potentially evading checks on the the address in the option, thereby potentially evading checks on the
packet source address. This is discussed at greater length in packet source address. This is discussed at greater length in
[I-D.savola-ipv6-rh-ha-security]. The version of Mobile IPv6 as [I-D.savola-ipv6-rh-ha-security]. The version of Mobile IPv6 as
standardized in [RFC3775] has removed this issue by ensuring that the standardized in [RFC3775] has removed this issue by ensuring that the
Home Address destination option is only processed if there is a Home Address destination option is only processed if there is a
corresponding binding cache entry and securing Binding Update corresponding binding cache entry and securing Binding Update
messages. messages.
A number of pre-standard implementations of Mobile IPv6 were A number of pre-standard implementations of Mobile IPv6 were
available which implemented this obsolete and insecure option: care available that implemented this obsolete and insecure option: care
should be taken to avoid running such obsolete systems. should be taken to avoid running such obsolete systems.
2.2. IPv4-mapped IPv6 Addresses 2.2. IPv4-mapped IPv6 Addresses
Overloaded functionality is always a double-edged sword: it may yield Overloaded functionality is always a double-edged sword: it may yield
some deployment benefits, but often also incurs the price which comes some deployment benefits, but often also incurs the price that comes
with ambiguity. with ambiguity.
One example of such is IPv4-mapped IPv6 addresses: a representation One example of such is IPv4-mapped IPv6 addresses: a representation
of an IPv4 address as an IPv6 address inside an operating system. of an IPv4 address as an IPv6 address inside an operating system.
Since the original specification, the use of IPv4-mapped addresses Since the original specification, the use of IPv4-mapped addresses
has been extended to a transition mechanism, Stateless IP/ICMP has been extended to a transition mechanism, Stateless IP/ICMP
Translation algorithm (SIIT) [RFC2765], where they are potentially Translation algorithm (SIIT) [RFC2765], where they are potentially
used in the addresses of packets on the wire. used in the addresses of packets on the wire.
Therefore, it becomes difficult to unambiguously discern whether an Therefore, it becomes difficult to unambiguously discern whether an
IPv4 mapped address is really an IPv4 address represented in the IPv6 IPv4 mapped address is really an IPv4 address represented in the IPv6
address format *or* an IPv6 address received from the wire (which may address format *or* an IPv6 address received from the wire (which may
be subject to address forgery, etc.). be subject to address forgery, etc.).
In addition, special cases like these, while giving deployment In addition, special cases like these, while giving deployment
benefits in some areas, require a considerable amount of code benefits in some areas, require a considerable amount of code
complexity (e.g. in the implementations of bind() system calls and complexity (e.g. in the implementations of bind() system calls and
reverse DNS lookups) which is probably undesirable. Some of these reverse DNS lookups) that is probably undesirable. Some of these
issues are discussed in [I-D.cmetz-v6ops-v4mapped-api-harmful] and issues are discussed in [I-D.cmetz-v6ops-v4mapped-api-harmful] and
[I-D.itojun-v6ops-v4mapped-harmful]. [I-D.itojun-v6ops-v4mapped-harmful].
In practice, although the packet translation mechanisms of SIIT are In practice, although the packet translation mechanisms of SIIT are
specified for use in the Network Address Translator - Protocol specified for use in the Network Address Translator - Protocol
Translator (NAT-PT) [RFC2765], NAT-PT uses a mechanism different from Translator (NAT-PT) [RFC2765], NAT-PT uses a mechanism different from
IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses
in IPv6 addresses. Also SIIT is not recommended for use as a in IPv6 addresses. Also SIIT is not recommended for use as a
standalone transition mechanism. Given the issues that have been standalone transition mechanism. Given the issues that have been
identified, it seems appropriate that mapped addresses should not be identified, it seems appropriate that mapped addresses should not be
skipping to change at page 16, line 19 skipping to change at page 17, line 27
of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end
transparency are described in IPv6 Network Architecture Protection transparency are described in IPv6 Network Architecture Protection
[I-D.ietf-v6ops-nap]. [I-D.ietf-v6ops-nap].
2.3.2. Enterprise Network Security Model for IPv6 2.3.2. Enterprise Network Security Model for IPv6
The favored model for enterprise network security in IPv4 stresses The favored model for enterprise network security in IPv4 stresses
the use of a security perimeter policed by autonomous firewalls and the use of a security perimeter policed by autonomous firewalls and
incorporating the NATs. Both perimeter firewalls and NATs introduce incorporating the NATs. Both perimeter firewalls and NATs introduce
asymmetry and reduce the transparency of communications through these asymmetry and reduce the transparency of communications through these
perimeters. The symmetric bidirectionality and transparency which perimeters. The symmetric bidirectionality and transparency that are
are extolled as virtues of IPv6 may seem to be at odds with this extolled as virtues of IPv6 may seem to be at odds with this model.
model. Consequently network managers may even see them as Consequently network managers may even see them as undesirable
undesirable attributes, in conflict with their need to control attributes, in conflict with their need to control threats to and
threats to and attacks on the networks they administer. attacks on the networks they administer.
It is worth noting that IPv6 does not *require* end-to-end It is worth noting that IPv6 does not *require* end-to-end
connectivity. It merely provides end-to-end addressability; the connectivity. It merely provides end-to-end addressability; the
connectivity can still be controlled using firewalls (or other connectivity can still be controlled using firewalls (or other
mechanisms), and it is indeed wise to do so. mechanisms), and it is indeed wise to do so.
A number of matters indicate that IPv6 networks should migrate A number of matters indicate that IPv6 networks should migrate
towards an improved security model, which will increase the overall towards an improved security model, which will increase the overall
security of the network but facilitate end-to-end communication: security of the network while at the same time facilitating end-to-
end communication:
o Increased usage of end-to-end security especially at the network o Increased usage of end-to-end security especially at the network
layer. IPv6 mandates the provision of IPsec capability in all layer. IPv6 mandates the provision of IPsec capability in all
nodes and increasing usage of end-to-end security is a challenge nodes and increasing usage of end-to-end security is a challenge
to current autonomous firewalls that are unable to perform deep to current autonomous firewalls that are unable to perform deep
packet inspection on encrypted packets. It is also incompatible packet inspection on encrypted packets. It is also incompatible
with NATs because they modify the packets, even when packets are with NATs because they modify the packets, even when packets are
only authenticated rather than encrypted. only authenticated rather than encrypted.
o Acknowledgement that over-reliance on the perimeter model is o Acknowledgement that over-reliance on the perimeter model is
potentially dangerous. An attacker who can penetrate today's potentially dangerous. An attacker who can penetrate today's
perimeters will have free rein within the perimeter, in many perimeters will have free rein within the perimeter, in many
cases. Also a successful attack will generally allow the attacker cases. Also a successful attack will generally allow the attacker
to capture information or resources and make use of them. to capture information or resources and make use of them.
o Development of mechanisms such as 'Trusted Computing' which will o Development of mechanisms such as 'Trusted Computing' that will
increase the level of trust which network managers are able to increase the level of trust that network managers are able to
place on hosts. place on hosts.
o Development of centralized security policy repositories and secure o Development of centralized security policy repositories and secure
distribution mechanisms which, in conjunction with trusted hosts, distribution mechanisms that, in conjunction with trusted hosts,
will allow network managers to place more reliance on security will allow network managers to place more reliance on security
mechanisms at the end points. The mechanisms are likely to mechanisms at the end points. The mechanisms are likely to
include end-node firewalling and intrusion detection systems as include end-node firewalling and intrusion detection systems as
well as secure protocols that allow end points to influence the well as secure protocols that allow end points to influence the
behavior of perimeter security devices. behavior of perimeter security devices.
o Review of the role of perimeter devices with increased emphasis on o Review of the role of perimeter devices with increased emphasis on
intrusion detection, network resource protection and coordination intrusion detection, network resource protection and coordination
to thwart distributed denial of service attacks. to thwart distributed denial of service attacks.
Several of the technologies required to support an enhanced security Several of the technologies required to support an enhanced security
model are still under development, including secure protocols to model are still under development, including secure protocols to
allow end points to control firewalls: the complete security model allow end points to control firewalls: the complete security model
utilizing these technologies is now emerging but still requires some utilizing these technologies is now emerging but still requires some
development. development.
In the meantime, initial deployments will need to make use of similar In the meantime, initial deployments will need to make use of similar
firewalling and intrusion detection techniques to IPv4 which may firewalling and intrusion detection techniques to IPv4 that may limit
limit end-to-end transparency temporarily, but should be prepared to end-to-end transparency temporarily, but should be prepared to use
use the new security model as it develops and avoid the use of NATs the new security model as it develops and avoid the use of NATs by
by the use of the architectural techniques described in [I-D.ietf- the use of the architectural techniques described in [I-D.ietf-v6ops-
v6ops-nap]. In particular, using NAT-PT [RFC2766] as a general nap]. In particular, using NAT-PT [RFC2766] as a general purpose
purpose transition mechanism should be avoided as it is likely to transition mechanism should be avoided as it is likely to limit the
limit the exploitation of end-to-end security and other IPv6 exploitation of end-to-end security and other IPv6 capabilities in
capabilities in future as explained in [I-D.ietf-v6ops-natpt-to- future as explained in [I-D.ietf-v6ops-natpt-to-exprmntl].
exprmntl].
2.4. IPv6 in IPv6 Tunnels
IPv6 in IPv6 tunnels can be used to circumvent security checks, so it
is essential to filter packets both at tunnel ingress and egress
points (the encapsulator and decapsulator) to ensure that both the
inner and outer addresses are accpetable, and the tunnel is not being
used to carry inappropriate traffic. The security discussions in
[RFC3964], which is primarily about the 6to4 transition tunneling
mecahnism (see Section 3.1) contains useful discussion of possible
attacks and ways to counteract these threats.
3. Issues Due to Transition Mechanisms 3. Issues Due to Transition Mechanisms
3.1. IPv6 Transition/Co-existence Mechanism-specific Issues 3.1. IPv6 Transition/Co-existence Mechanism-specific Issues
The more complicated the IPv6 transition/co-existence becomes, the The more complicated the IPv6 transition/co-existence becomes, the
greater the danger that security issues will be introduced either greater the danger that security issues will be introduced either
o in the mechanisms themselves, o in the mechanisms themselves,
o in the interaction between mechanisms, or o in the interaction between mechanisms, or
o by introducing unsecured paths through multiple mechanisms. o by introducing unsecured paths through multiple mechanisms.
skipping to change at page 18, line 18 skipping to change at page 19, line 38
to a physical segment and sending them there. to a physical segment and sending them there.
o automatic tunneling mechanisms are typically particularly o automatic tunneling mechanisms are typically particularly
dangerous as there is no pre-configured association between end dangerous as there is no pre-configured association between end
points. Accordingly, at the receiving end of the tunnel packets points. Accordingly, at the receiving end of the tunnel packets
have to be accepted and decapsulated from any source. have to be accepted and decapsulated from any source.
Consequently, special care should be taken when specifying Consequently, special care should be taken when specifying
automatic tunneling techniques. automatic tunneling techniques.
3.2. Automatic Tunneling and Relays 3.2. Automatic Tunneling and Relays
Two mechanisms have been (or are being) specified which use automatic Two mechanisms have been specified that use automatic tunneling and
tunneling and are intended for use outside a single domain. These are intended for use outside a single domain. These mechanisms
mechanisms encapsulate the IPv6 packet directly in an IPv4 packet in encapsulate the IPv6 packet directly in an IPv4 packet in the case of
the case of 6to4 [RFC3056] or in an IPv4 UDP packet in the case of 6to4 [RFC3056] or in an IPv4 UDP packet in the case of Teredo
Teredo [I-D.huitema-v6ops-teredo]. In each case packets can be sent [RFC4380]. In each case packets can be sent and received by any
and received by any similarly equipped nodes in the IPv4 Internet. similarly equipped nodes in the IPv4 Internet.
As mentioned in Section 3.1, a major vulnerability in such approaches As mentioned in Section 3.1, a major vulnerability in such approaches
is that receiving nodes must allow decapsulation of traffic sourced is that receiving nodes must allow decapsulation of traffic sourced
from anywhere in the Internet. This kind of decapsulation function from anywhere in the Internet. This kind of decapsulation function
must be extremely well secured because of the wide range of potential must be extremely well secured because of the wide range of potential
sources. sources.
An even more difficult problem is how these mechanisms are able to An even more difficult problem is how these mechanisms are able to
establish communication with native IPv6 nodes or between the establish communication with native IPv6 nodes or between the
automatic tunneling mechanisms: such connectivity requires the use of automatic tunneling mechanisms: such connectivity requires the use of
some kind of "relay". These relays could be deployed in various some kind of "relay". These relays could be deployed in various
locations such as: locations such as:
o all native IPv6 nodes, o all native IPv6 nodes,
o native IPv6 sites, o native IPv6 sites,
o in IPv6-enabled ISPs, or o in IPv6-enabled ISPs, or
o just somewhere in the Internet. o just somewhere in the Internet.
Given that a relay needs to trust all the sources (e.g., in the 6to4 Given that a relay needs to trust all the sources (e.g., in the 6to4
case, all 6to4 routers) which are sending it traffic, there are case, all 6to4 routers) that are sending it traffic, there are issues
issues in achieving this trust and at the same time scaling the relay in achieving this trust and at the same time scaling the relay system
system to avoid overloading a small number of relays. to avoid overloading a small number of relays.
As authentication of such a relay service is very difficult to As authentication of such a relay service is very difficult to
achieve, and particularly so in some of the possible deployment achieve, and particularly so in some of the possible deployment
models, relays provide a potential vehicle for address spoofing, models, relays provide a potential vehicle for address spoofing,
(reflected) Denial-of-Service attacks, and other threats. (reflected) Denial-of-Service attacks, and other threats.
Threats related to 6to4 and measures to combat them are discussed in Threats related to 6to4 and measures to combat them are discussed in
[RFC3964]. [I-D.huitema-v6ops-teredo] incorporates extensive [RFC3964]. [RFC4380] incorporates extensive discussion of the
discussion of the threats to Teredo and measures to combat them. threats to Teredo and measures to combat them.
3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 Network 3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 Network
Security Assumptions Security Assumptions
NATs and firewalls have been deployed extensively in the IPv4 NATs and firewalls have been deployed extensively in the IPv4
Internet, as discussed in Section 2.3. Operators who deploy them Internet, as discussed in Section 2.3. Operators who deploy them
typically have some security/operational requirements in mind (e.g. a typically have some security/operational requirements in mind (e.g. a
desire to block inbound connection attempts), which may or may not be desire to block inbound connection attempts), which may or may not be
misguided. misguided.
The addition of tunneling can change the security model which such The addition of tunneling can change the security model that such
deployments are seeking to enforce. IPv6-over-IPv4 tunneling using deployments are seeking to enforce. IPv6-over-IPv4 tunneling using
protocol 41 is typically either explicitly allowed, or disallowed protocol 41 is typically either explicitly allowed, or disallowed
implicitly. Tunneling IPv6 over IPv4 encapsulated in UDP constitutes implicitly. Tunneling IPv6 over IPv4 encapsulated in UDP constitutes
a more difficult problem as UDP must usually be allowed to pass a more difficult problem as UDP must usually be allowed to pass
through NATs and firewalls. Consequently, using UDP implies the through NATs and firewalls. Consequently, using UDP implies the
ability to punch holes in NAT's and firewalls although, depending on ability to punch holes in NAT's and firewalls although, depending on
the implementation, this ability may be limited or only achieved in a the implementation, this ability may be limited or only achieved in a
stateful manner. In practice, the mechanisms have been explicitly stateful manner. In practice, the mechanisms have been explicitly
designed to traverse both NATs and firewalls in a similar fashion. designed to traverse both NATs and firewalls in a similar fashion.
skipping to change at page 19, line 45 skipping to change at page 21, line 16
cases where the administrator or user makes an explicit decision to cases where the administrator or user makes an explicit decision to
create the hole, this is less of a problem, although (for example) create the hole, this is less of a problem, although (for example)
some enterprises might want to block IPv6 tunneling explicitly if some enterprises might want to block IPv6 tunneling explicitly if
employees were able to create such holes without reference to employees were able to create such holes without reference to
administrators. On the other hand, if a hole is punched administrators. On the other hand, if a hole is punched
transparently, it is likely that a proportion of users will not transparently, it is likely that a proportion of users will not
understand the consequences: this will very probably result in a understand the consequences: this will very probably result in a
serious threat sooner or later. serious threat sooner or later.
When deploying tunneling solutions, especially tunneling solutions When deploying tunneling solutions, especially tunneling solutions
which are automatic and/or can be enabled easily by users who do not that are automatic and/or can be enabled easily by users who do not
understand the consequences, care should be taken not to compromise understand the consequences, care should be taken not to compromise
the security assumptions held by the users. the security assumptions held by the users.
For example, NAT traversal should not be performed by default unless For example, NAT traversal should not be performed by default unless
there is a firewall producing a similar by-default security policy to there is a firewall producing a similar by-default security policy to
that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is
less of a problem, as it is easier to block if necessary; however, if less of a problem, as it is easier to block if necessary; however, if
the host is protected in IPv4, the IPv6 side should be protected as the host is protected in IPv4, the IPv6 side should be protected as
well. well.
As has been shown in Appendix A, it is relatively easy to determine As has been shown in Appendix A, it is relatively easy to determine
the IPv6 address corresponding to an IPv4 address in tunneling the IPv6 address corresponding to an IPv4 address in tunneling
deployments. It is therefore vital NOT to rely on "security by deployments. It is therefore vital NOT to rely on "security by
obscurity" i.e., assuming that nobody is able to guess or determine obscurity" i.e., assuming that nobody is able to guess or determine
the IPv6 address of the host especially when using automatic the IPv6 address of the host especially when using automatic
tunneling transition mechanisms. tunneling transition mechanisms.
The network architecture must provide separate IPv4 and IPv6 The network architecture must provide separate IPv4 and IPv6
firewalls with tunneled IPv6 traffic arriving encapsulated in IPv4 firewalls with tunnelled IPv6 traffic arriving encapsulated in IPv4
packets routed through the IPv4 firewall before being decapsulated, packets routed through the IPv4 firewall before being decapsulated,
and then through the IPv6 firewall as shown in Figure 1. and then through the IPv6 firewall as shown in Figure 1.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Site | Native | IPv6 |v6 in v4| IPv4 | Native | Public Site | Native | IPv6 |v6 in v4| IPv4 | Native | Public
Network <--->| IPv6 |<---->| Tunnel |<---->| IPv4 |<---> Internet Network <--->| IPv6 |<---->| Tunnel |<---->| IPv4 |<---> Internet
|Firewall| |Endpoint| |Firewall| |Firewall| |Endpoint| |Firewall|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 1: Tunneled Traffic and Firewalls Figure 1: Tunnelled Traffic and Firewalls
4. Issues Due to IPv6 Deployment 4. Issues Due to IPv6 Deployment
4.1. Avoiding the Trap of Insecure IPv6 Service Piloting 4.1. Avoiding the Trap of Insecure IPv6 Service Piloting
Because IPv6 is a new service for many networks, network managers Because IPv6 is a new service for many networks, network managers
will often opt to make a pilot deployment in a part of the network to will often opt to make a pilot deployment in a part of the network to
gain experience and understand the problems as well as the benefits gain experience and understand the problems as well as the benefits
that may result from a full production quality IPv6 service. that may result from a full production quality IPv6 service.
Unless IPv6 service piloting is done in a manner which is as secure Unless IPv6 service piloting is done in a manner that is as secure as
as possible there is a risk that security in the pilot which does not possible there is a risk that security in the pilot that does not
match up to what is achievable with current IPv4 production service match up to what is achievable with current IPv4 production service
can adversely impact the overall assessment of the IPv6 pilot can adversely impact the overall assessment of the IPv6 pilot
deployment. This may result in a decision to delay or even avoid deployment. This may result in a decision to delay or even avoid
deploying an IPv6 production service. For example, hosts and routers deploying an IPv6 production service. For example, hosts and routers
might not be protected by IPv6 firewalls, even if the corresponding might not be protected by IPv6 firewalls, even if the corresponding
IPv4 service is fully protected by firewalls as described in IPv4 service is fully protected by firewalls as described in
[I-D.ietf-v6ops-v6onbydefault]. This is particularly critical where [I-D.ietf-v6ops-v6onbydefault]. This is particularly critical where
IPv6 capabilities are turned on by default in new equipment or new IPv6 capabilities are turned on by default in new equipment or new
releases of operating systems: network managers may not be fully releases of operating systems: network managers may not be fully
aware of the security exposure that this creates. aware of the security exposure that this creates.
In some cases a perceived lack of availability of IPv6 firewalls and In some cases a perceived lack of availability of IPv6 firewalls and
other security capabilities, such as intrusion detection systems may other security capabilities, such as intrusion detection systems may
have lead network managers to resist any kind of IPv6 service have lead network managers to resist any kind of IPv6 service
deployment. These problems may be partly due to the relatively slow deployment. These problems may be partly due to the relatively slow
development and deployment of IPv6-capable security equipment, but development and deployment of IPv6-capable security equipment, but
the major problems appear to have been a lack of information, and the major problems appear to have been a lack of information, and
more importantly a lack of documented operational experience on which more importantly a lack of documented operational experience on which
managers can draw. In actual fact, as of the time of writing (2005) managers can draw. In actual fact, as of the time of writing (2006)
there are a significant number of alternative IPv6 packet filters and there are a significant number of alternative IPv6 packet filters and
firewalls already in existence, which could be used for provide firewalls already in existence, which could be used for provide
sufficient access controls. sufficient access controls.
However, there are a small number of areas that where the available However, there are a small number of areas that where the available
equipment and capabilities may still be a barrier to secure equipment and capabilities may still be a barrier to secure
deployment: deployment:
o 'Personal firewalls' intended for use on hosts are not yet widely o 'Personal firewalls' intended for use on hosts are not yet widely
available. available.
o Enterprise firewalls are at an early stage of development and may o Enterprise firewalls are at an early stage of development and may
skipping to change at page 21, line 34 skipping to change at page 23, line 4
become IPv6-capable -- even though this is not really required and become IPv6-capable -- even though this is not really required and
the equipment may not have the requisite hardware capabilities to the equipment may not have the requisite hardware capabilities to
support fast packet filtering for IPv6. Suggestions for the support fast packet filtering for IPv6. Suggestions for the
appropriate deployment of firewalls are given in Section 3.3 -- as appropriate deployment of firewalls are given in Section 3.3 -- as
will be seen from this section it is usually desirable that the will be seen from this section it is usually desirable that the
firewalls are in separate boxes and there is no necessity for them firewalls are in separate boxes and there is no necessity for them
to be same model of equipment. to be same model of equipment.
o A lesser factor may be that some design decisions in the IPv6 o A lesser factor may be that some design decisions in the IPv6
protocol make it more difficult for firewalls to be implemented protocol make it more difficult for firewalls to be implemented
and work in all cases, and to be fully future proof (e.g. when new and work in all cases, and to be fully future proof (e.g. when new
extension headers are used) as discussed in Section 2.1.8: it is extension headers are used) as discussed in Section 2.1.9: it is
significantly more difficult for intermediate nodes to process the significantly more difficult for intermediate nodes to process the
IPv6 header chains than IPv4 packets. IPv6 header chains than IPv4 packets.
o Adequate Intrusion Detection Systems (IDS) are more difficult to o Adequate Intrusion Detection Systems (IDS) are more difficult to
construct for IPv6. IDSs are now beginning to become available construct for IPv6. IDSs are now beginning to become available
but the pattern-based mechanisms used for IPv4 may not be the most but the pattern-based mechanisms used for IPv4 may not be the most
appropriate for long-term development of these systems as end-to- appropriate for long-term development of these systems as end-to-
end encryption becomes more prevalent. Future systems may be more end encryption becomes more prevalent. Future systems may be more
reliant on traffic flow pattern recognition. reliant on traffic flow pattern recognition.
o Implementations of high availability capabilities supporting IPv6 o Implementations of high availability capabilities supporting IPv6
are also in short supply. In particular, development of the IPv6 are also in short supply. In particular, development of the IPv6
skipping to change at page 22, line 49 skipping to change at page 24, line 19
configurations (e.g. Access Control List), since numerical IPv6 configurations (e.g. Access Control List), since numerical IPv6
addresses are more prone to human error than IPv4 due to their length addresses are more prone to human error than IPv4 due to their length
and unmemorability. and unmemorability.
It is also essential to ensure that the management interfaces of It is also essential to ensure that the management interfaces of
routers are well secured as the router will usually contain a routers are well secured as the router will usually contain a
significant cache of neighbor addresses in its neighbor cache. significant cache of neighbor addresses in its neighbor cache.
4.4. Consequences of Multiple Addresses in IPv6 4.4. Consequences of Multiple Addresses in IPv6
One positive consequence of IPv6 is that nodes which do not require One positive consequence of IPv6 is that nodes that do not require
global access can communicate locally just by the use of a link-local global access can communicate locally just by the use of a link-local
address (if very local access is sufficient) or across the site by address (if very local access is sufficient) or across the site by
using a Unique Local Address (ULA). In either case it is easy to using a Unique Local Address (ULA). In either case it is easy to
ensure that access outside the assigned domain of activity can be ensure that access outside the assigned domain of activity can be
controlled by simple filters (which may be the default for link- controlled by simple filters (which may be the default for link-
locals). However, the security hazards of using link-local addresses locals). However, the security hazards of using link-local addresses
for non-management purposes as documented in Section 2.1.11 should be for non-management purposes as documented in Section 2.1.12 should be
borne in mind. borne in mind.
On the other hand, the possibility that a node or interface can have On the other hand, the possibility that a node or interface can have
multiple global scope addresses makes access control filtering both multiple global scope addresses makes access control filtering both
on ingress and egress more complex and requires higher maintenance on ingress and egress more complex and requires higher maintenance
levels. Vendors and network administrators need to be aware that levels. Vendors and network administrators need to be aware that
multiple addresses are the norm rather than the exception in IPv6: multiple addresses are the norm rather than the exception in IPv6:
when building and selecting tools for security and management a when building and selecting tools for security and management a
highly desirable feature is the ability to be able to 'tokenize' highly desirable feature is the ability to be able to 'tokenize'
access control lists and configurations in general to cater for access control lists and configurations in general to cater for
skipping to change at page 24, line 36 skipping to change at page 26, line 6
ICMPv6 errors using a stateful packet inspection mechanism to ensure ICMPv6 errors using a stateful packet inspection mechanism to ensure
that the packet carried as a payload is associated with legitimate that the packet carried as a payload is associated with legitimate
traffic to or from the protected network. traffic to or from the protected network.
4.6. IPsec Transport Mode 4.6. IPsec Transport Mode
IPsec provides security to end-to-end communications at the network IPsec provides security to end-to-end communications at the network
layer (layer 3). The security features available include access layer (layer 3). The security features available include access
control, connectionless integrity, data origin authentication, control, connectionless integrity, data origin authentication,
protection against replay attacks, confidentiality, and limited protection against replay attacks, confidentiality, and limited
traffic flow confidentiality (see [RFC2401] section 2.1). IPv6 traffic flow confidentiality (see [RFC4301] section 2.1). IPv6
mandates the implementation of IPsec in all conforming nodes, making mandates the implementation of IPsec in all conforming nodes, making
the usage of IPsec to secure end-to-end communication possible in a the usage of IPsec to secure end-to-end communication possible in a
way which is generally not available to IPv4. way that is generally not available to IPv4.
To secure IPv6 end-to-end communications, IPsec transport mode would To secure IPv6 end-to-end communications, IPsec transport mode would
generally be the solution of choice. However, use of these IPsec generally be the solution of choice. However, use of these IPsec
security features can result in novel problems for network security features can result in novel problems for network
administrators and decrease the effectiveness of perimeter firewalls administrators and decrease the effectiveness of perimeter firewalls
because of the increased prevalence of encrypted packets on which the because of the increased prevalence of encrypted packets on which the
firewalls cannot perform deep packet inspection and filtering. firewalls cannot perform deep packet inspection and filtering.
One example of such problems is the lack of security solutions in the One example of such problems is the lack of security solutions in the
middlebox, including effective content-filtering, ability to provide middlebox, including effective content-filtering, ability to provide
DoS prevention based on the expected TCP protocol behavior, and DoS prevention based on the expected TCP protocol behavior, and
intrusion detection. Future solutions to this problem are discussed intrusion detection. Future solutions to this problem are discussed
in Section 2.3.2. Another example is an IPsec-based DoS (e.g., in Section 2.3.2. Another example is an IPsec-based DoS (e.g.,
sending malformed ESP/AH packets) which can be especially detrimental sending malformed ESP/AH packets) that can be especially detrimental
to software-based IPsec implementations. to software-based IPsec implementations.
4.7. Reduced Functionality Devices 4.7. Reduced Functionality Devices
With the deployment of IPv6 we can expect the attachment of a very With the deployment of IPv6 we can expect the attachment of a very
large number of new IPv6-enabled devices with scarce resources and large number of new IPv6-enabled devices with scarce resources and
low computing capacity. The resource limitations are generally low computing capacity. The resource limitations are generally
because of a market requirement for cost reduction. Although the because of a market requirement for cost reduction. Although the
IPv6 Node Requirements [I-D.ietf-ipv6-node-requirements] specifies IPv6 Node Requirements [I-D.ietf-ipv6-node-requirements] specifies
some mandatory security capabilities for every conformant node, these some mandatory security capabilities for every conformant node, these
do not include functions required for a node to be able to protect do not include functions required for a node to be able to protect
itself. Accordingly, some such devices may not be able even to itself. Accordingly, some such devices may not be able even to
perform the minimum set of functions required to protect themselves perform the minimum set of functions required to protect themselves
(e.g. 'personal' firewall, automatic firmware update, enough CPU (e.g. 'personal' firewall, automatic firmware update, enough CPU
power to endure DoS attacks). This means a different security scheme power to endure DoS attacks). This means a different security scheme
may be necessary for such reduced functionality devices. may be necessary for such reduced functionality devices.
4.8. Operational Factors when Enabling IPv6 in the Network 4.8. Operational Factors when Enabling IPv6 in the Network
There are a number of reasons which make it essential to take There are a number of reasons that make it essential to take
particular care when enabling IPv6 in the network equipment: particular care when enabling IPv6 in the network equipment:
Initially, IPv6-enabled router software may be less mature than Initially, IPv6-enabled router software may be less mature than
current IPv4-only implementations and there is less experience with current IPv4-only implementations and there is less experience with
configuring IPv6 routing, which can result in disruptions to the IPv6 configuring IPv6 routing, which can result in disruptions to the IPv6
routing environment and (IPv6) network outages. routing environment and (IPv6) network outages.
IPv6 processing may not happen at (near) line speed (or at a IPv6 processing may not happen at (near) line speed (or at a
comparable performance level to IPv4 in the same equipment). A high comparable performance level to IPv4 in the same equipment). A high
level of IPv6 traffic (even legitimate, e.g. Network News Transport level of IPv6 traffic (even legitimate, e.g. Network News Transport
skipping to change at page 26, line 23 skipping to change at page 27, line 41
its tradeoffs [RFC4029]. If multiple routing protocols are used, one its tradeoffs [RFC4029]. If multiple routing protocols are used, one
should note that this causes double the amount of processing when should note that this causes double the amount of processing when
links flap or recalculation is otherwise needed -- which might more links flap or recalculation is otherwise needed -- which might more
easily overload the router's CPU, causing slightly slower convergence easily overload the router's CPU, causing slightly slower convergence
time. time.
4.9. Ingress Filtering Issues Due to Privacy Addresses 4.9. Ingress Filtering Issues Due to Privacy Addresses
[RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] describes a method for [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] describes a method for
creating temporary addresses on IPv6 nodes to address privacy issues creating temporary addresses on IPv6 nodes to address privacy issues
created by the use of a constant identifier. In a network, which created by the use of a constant identifier. In a large network
implements such a mechanism, with a large number of nodes, new implementing such a mechanism new temporary addresses may be created
temporary addresses may be created at a fairly high rate. This might at a fairly high rate. This might make it hard for ingress filtering
make it hard for ingress filtering mechanisms to distinguish between mechanisms to distinguish between legitimately changing temporary
legitimately changing temporary addresses and spoofed source addresses and spoofed source addresses, which are "in-prefix" (i.e.,
addresses, which are "in-prefix" (They use a topologically correct they use a topologically correct prefix and non-existent interface
prefix and non-existent interface ID). This can be addressed by ID). This can be addressed by using finer grained access control
using finer grained access control mechanisms on the network egress mechanisms on the network egress point.
point.
4.10. Security Issues Due to ND Proxies 4.10. Security Issues Due to ND Proxies
In order to span a single subnet over multiple physical links, a new In order to span a single subnet over multiple physical links, a new
capability is being introduced in IPv6 to proxy Neighbor Discovery capability is being introduced in IPv6 to proxy Neighbor Discovery
messages. This node will be called an NDProxy (see [I-D.ietf-ipv6- messages. This node will be called an NDProxy (see [I-D.ietf-ipv6-
ndproxy]. NDProxies are susceptible to the same security issues as ndproxy]. NDProxies are susceptible to the same security issues as
the ones faced by hosts using unsecured Neighbor Discovery or ARP. the ones faced by hosts using unsecured Neighbor Discovery or ARP.
These proxies may process unsecured messages, and update the neighbor These proxies may process unsecured messages, and update the neighbor
cache as a result of such processing, thus allowing a malicious node cache as a result of such processing, thus allowing a malicious node
skipping to change at page 27, line 15 skipping to change at page 28, line 34
6. Security Considerations 6. Security Considerations
This memo attempts to give an overview of security considerations of This memo attempts to give an overview of security considerations of
the different aspects of IPv6, particularly as they relate to the the different aspects of IPv6, particularly as they relate to the
transition to a network in which IPv4- and IPv6-based communications transition to a network in which IPv4- and IPv6-based communications
need to coexist. need to coexist.
7. Acknowledgements 7. Acknowledgements
Alain Durand, Alain Baudot, Luc Beloeil, Tim Chown, Andras Kis-Szabo, Alain Durand, Alain Baudot, Luc Beloeil, Tim Chown, Andras Kis-Szabo,
Alvaro Vives, Janos Mohacsi and Mark Smith provided feedback to Vishwas Manral, Janos Mohacsi, Alvaro Vives and Mark Smith provided
improve this memo. Satoshi Kondo, Shinsuke Suzuki and Alvaro Vives feedback to improve this memo. Satoshi Kondo, Shinsuke Suzuki and
provided additional inputs in cooperation with the Deployment Working Alvaro Vives provided additional inputs in cooperation with the
Group of the Japanese IPv6 Promotion Council and the Euro6IX IST co- Deployment Working Group of the Japanese IPv6 Promotion Council and
funded project, together with inputs from Jordi Palet, Brian the Euro6IX IST co-funded project, together with inputs from Jordi
Carpenter, and Peter Bieringer. Michael Wittsend and Michael Cole Palet, Brian Carpenter, and Peter Bieringer. Michael Wittsend and
discussed issues relating to probing/mapping and privacy. Michael Cole discussed issues relating to probing/mapping and
privacy.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.huitema-v6ops-teredo]
Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo-05 (work in progress),
April 2005.
[I-D.ietf-ipv6-privacy-addrs-v2] [I-D.ietf-ipv6-privacy-addrs-v2]
Narten, T., "Privacy Extensions for Stateless Address Narten, T., "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", Autoconfiguration in IPv6",
draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress), draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress),
May 2005. December 2005.
[I-D.ietf-v6ops-natpt-to-exprmntl] [I-D.ietf-v6ops-natpt-to-exprmntl]
Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work Experimental", draft-ietf-v6ops-natpt-to-exprmntl-03 (work
in progress), July 2005. in progress), October 2005.
[I-D.ietf-vrrp-ipv6-spec] [I-D.ietf-vrrp-ipv6-spec]
Hinden, R., "Virtual Router Redundancy Protocol for IPv6", Hinden, R., "Virtual Router Redundancy Protocol for IPv6",
draft-ietf-vrrp-ipv6-spec-07 (work in progress), draft-ietf-vrrp-ipv6-spec-07 (work in progress),
October 2004. October 2004.
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998. Assignments", RFC 2375, July 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
skipping to change at page 28, line 30 skipping to change at page 29, line 46
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999. October 1999.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for [RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004. 6to4", RFC 3964, December 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
8.2. Informative References 8.2. Informative References
[FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc. [FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc.
Second Internet Measurement Workshop , November 2002, Second Internet Measurement Workshop , November 2002,
<http://www.research.att.com/~smb/papers/fnat.pdf>. <http://www.research.att.com/~smb/papers/fnat.pdf>.
[I-D.chown-v6ops-port-scanning-implications] [I-D.chown-v6ops-port-scanning-implications]
Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", Chown, T., "IPv6 Implications for TCP/UDP Port Scanning",
draft-chown-v6ops-port-scanning-implications-01 (work in draft-chown-v6ops-port-scanning-implications-02 (work in
progress), July 2004. progress), October 2005.
[I-D.cmetz-v6ops-v4mapped-api-harmful] [I-D.cmetz-v6ops-v4mapped-api-harmful]
Metz, C. and J. Hagino, "IPv4-Mapped Address API Metz, C. and J. Hagino, "IPv4-Mapped Address API
Considered Harmful", Considered Harmful",
draft-cmetz-v6ops-v4mapped-api-harmful-01 (work in draft-cmetz-v6ops-v4mapped-api-harmful-01 (work in
progress), October 2003. progress), October 2003.
[I-D.davies-v6ops-icmpv6-filtering-bcp] [I-D.davies-v6ops-icmpv6-filtering-bcp]
Davies, E. and J. Mohacsi, "Best Current Practice for Davies, E. and J. Mohacsi, "Best Current Practice for
Filtering ICMPv6 Messages in Firewalls", Filtering ICMPv6 Messages in Firewalls",
draft-davies-v6ops-icmpv6-filtering-bcp-00 (work in draft-davies-v6ops-icmpv6-filtering-bcp-00 (work in
progress), July 2005. progress), July 2005.
[I-D.dupont-ipv6-rfc3041harmful] [I-D.dupont-ipv6-rfc3041harmful]
Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", Dupont, F. and P. Savola, "RFC 3041 Considered Harmful",
draft-dupont-ipv6-rfc3041harmful-05 (work in progress), draft-dupont-ipv6-rfc3041harmful-05 (work in progress),
June 2004. June 2004.
[I-D.gont-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP",
draft-gont-tcpm-icmp-attacks-05 (work in progress),
October 2005.
[I-D.ietf-dnsop-ipv6-dns-issues] [I-D.ietf-dnsop-ipv6-dns-issues]
Durand, A., "Operational Considerations and Issues with Durand, A., "Operational Considerations and Issues with
IPv6 DNS", draft-ietf-dnsop-ipv6-dns-issues-11 (work in IPv6 DNS", draft-ietf-dnsop-ipv6-dns-issues-12 (work in
progress), July 2005. progress), October 2005.
[I-D.ietf-ipv6-host-load-sharing]
Hinden, R. and D. Thaler, "IPv6 Host to Router Load
Sharing", draft-ietf-ipv6-host-load-sharing-04 (work in
progress), June 2005.
[I-D.ietf-ipv6-ndproxy] [I-D.ietf-ipv6-ndproxy]
Thaler, D., "Neighbor Discovery Proxies (ND Proxy)", Thaler, D., "Neighbor Discovery Proxies (ND Proxy)",
draft-ietf-ipv6-ndproxy-03 (work in progress), July 2005. draft-ietf-ipv6-ndproxy-04 (work in progress),
October 2005.
[I-D.ietf-ipv6-node-requirements] [I-D.ietf-ipv6-node-requirements]
Loughney, J., "IPv6 Node Requirements", Loughney, J., "IPv6 Node Requirements",
draft-ietf-ipv6-node-requirements-11 (work in progress), draft-ietf-ipv6-node-requirements-11 (work in progress),
August 2004. August 2004.
[I-D.ietf-ipv6-router-selection]
Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", draft-ietf-ipv6-router-selection-07
(work in progress), January 2005.
[I-D.ietf-mip6-ro-sec]
Nikander, P., "Mobile IP version 6 Route Optimization
Security Design Background", draft-ietf-mip6-ro-sec-03
(work in progress), May 2005.
[I-D.ietf-v6ops-nap] [I-D.ietf-v6ops-nap]
Velde, G., "IPv6 Network Architecture Protection", Velde, G., "IPv6 Network Architecture Protection",
draft-ietf-v6ops-nap-01 (work in progress), June 2005. draft-ietf-v6ops-nap-02 (work in progress), October 2005.
[I-D.ietf-v6ops-v6onbydefault] [I-D.ietf-v6ops-v6onbydefault]
Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
(work in progress), July 2004. (work in progress), July 2004.
[I-D.ietf-zeroconf-ipv4-linklocal]
Aboba, B., "Dynamic Configuration of Link-Local IPv4
Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in
progress), July 2004.
[I-D.itojun-v6ops-v4mapped-harmful] [I-D.itojun-v6ops-v4mapped-harmful]
Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire
Considered Harmful", Considered Harmful",
draft-itojun-v6ops-v4mapped-harmful-02 (work in progress), draft-itojun-v6ops-v4mapped-harmful-02 (work in progress),
October 2003. October 2003.
[I-D.krishnan-ipv6-hopbyhop] [I-D.krishnan-ipv6-hopbyhop]
Krishnan, S., "Arrangement of Hop-by-Hop options", Krishnan, S., "Arrangement of Hop-by-Hop options",
draft-krishnan-ipv6-hopbyhop-00 (work in progress), draft-krishnan-ipv6-hopbyhop-00 (work in progress),
June 2004. June 2004.
skipping to change at page 31, line 14 skipping to change at page 32, line 20
[JpIPv6DC] [JpIPv6DC]
Deployment WG, "IPv6 Deployment Guideline (2005 Edition)", Deployment WG, "IPv6 Deployment Guideline (2005 Edition)",
IPv6 Promotion Council (Japan) Deployment Working Group, IPv6 Promotion Council (Japan) Deployment Working Group,
2005, <http://www.v6pc.jp/>. 2005, <http://www.v6pc.jp/>.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering", RFC 1858,
October 1995. October 1995.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000. (SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766, Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000. February 2000.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny [RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001. Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004. May 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into Savola, "Scenarios and Analysis for Introducing IPv6 into
ISP Networks", RFC 4029, March 2005. ISP Networks", RFC 4029, March 2005.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition", Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005. RFC 4038, March 2005.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
DNS Queries for IPv6 Addresses", RFC 4074, May 2005. DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
Sharing", RFC 4311, November 2005.
[SIXNET] 6Net, "Large Scale International IPv6 Pilot Network", EU [SIXNET] 6Net, "Large Scale International IPv6 Pilot Network", EU
Information Society Technologies Project , 2005, Information Society Technologies Project , 2005,
<http://www.6net.org/>. <http://www.6net.org/>.
Appendix A. IPv6 Probing/Mapping Considerations Appendix A. IPv6 Probing/Mapping Considerations
One school of thought wants the IPv6 numbering topology (either at One school of thought wants the IPv6 numbering topology (either at
network or node level) [I-D.schild-v6ops-guide-v4mapping] to match network or node level) [I-D.schild-v6ops-guide-v4mapping] to match
IPv4 as exactly as possible, whereas others see IPv6 as giving more IPv4 as exactly as possible, whereas others see IPv6 as giving more
flexibility to the address plans, not wanting to constrain the design flexibility to the address plans, not wanting to constrain the design
skipping to change at page 36, line 41 skipping to change at page 38, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 98 change blocks. 
226 lines changed or deleted 292 lines changed or added

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