draft-ietf-opsec-ipv6-implications-on-ipv4-nets-06.txt   draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07.txt 
opsec wg F. Gont opsec wg F. Gont
Internet-Draft SI6 Networks/UTN-FRH Internet-Draft SI6 Networks/UTN-FRH
Intended status: Informational W. Liu Intended status: Informational W. Liu
Expires: May 30, 2014 Huawei Technologies Expires: June 9, 2014 Huawei Technologies
November 26, 2013 December 6, 2013
Security Implications of IPv6 on IPv4 Networks Security Implications of IPv6 on IPv4 Networks
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-06 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07
Abstract Abstract
This document discusses the security implications of native IPv6 This document discusses the security implications of native IPv6
support and IPv6 transition/co-existence technologies on "IPv4-only" support and IPv6 transition/co-existence technologies on "IPv4-only"
networks, and describes possible mitigations for the aforementioned networks, and describes possible mitigations for the aforementioned
issues. issues.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 30, 2014. This Internet-Draft will expire on June 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
3. Security Implications of Tunneling Mechanisms . . . . . . . . 5 3. Security Implications of Tunneling Mechanisms . . . . . . . . 5
3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . 6 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . 6
3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . 7 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . 7
3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . 7 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . 7
3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . 9 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . 9
3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . 9 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . 9
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 11 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 11
3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 11 3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 11
4. Additional Considerations when Filtering IPv6 Traffic . . . . 11 4. Additional Considerations when Filtering IPv6 Traffic . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Summary of filtering rules . . . . . . . . . . . . . 17 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Most general-purpose operating systems implement and enable native Most general-purpose operating systems implement and enable native
IPv6 [RFC2460] support and a number of transition/co-existence IPv6 [RFC2460] support and a number of transition/co-existence
technologies by default. Support of IPv6 by all nodes is intended to technologies by default. Support of IPv6 by all nodes is intended to
become best current practice [RFC6540]. Some enterprise networks become best current practice [RFC6540]. Some enterprise networks
might, however, choose to delay active use of IPv6. might, however, choose to delay active use of IPv6.
This document describes operational practices for enterprise networks This document describes operational practices for enterprise networks
skipping to change at page 12, line 25 skipping to change at page 12, line 25
traversing their devices should consider configuring their local traversing their devices should consider configuring their local
recursive DNS servers to respond to queries for AAAA DNS records with recursive DNS servers to respond to queries for AAAA DNS records with
a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such
queries, and should even consider filtering AAAA records at the queries, and should even consider filtering AAAA records at the
network ingress point to prevent the internal hosts from attempting network ingress point to prevent the internal hosts from attempting
their own DNS resolution. This will ensure that hosts which are on their own DNS resolution. This will ensure that hosts which are on
an IPv4-only network will only receive DNS A records, and they will an IPv4-only network will only receive DNS A records, and they will
be unlikely to attempt to use (likely broken) IPv6 connectivity to be unlikely to attempt to use (likely broken) IPv6 connectivity to
reach their desired destinations. reach their desired destinations.
We note that in scenarios where DNSsec [RFC4033] is deployed,
stripping AAAA records from DNS responses would lead to DNS responses
elicited by queries with the DO and CD bits set [RFC4035] to be
considered invalid, and hence discarded. This situation is similar
to that of DNS64 [RFC6147] in the presence of DNSsec and should be
considered a drawback associated with this approach.
Additionally, it should be noted that when filtering IPv6 traffic, it Additionally, it should be noted that when filtering IPv6 traffic, it
is good practice to signal the packet drop to the source node, such is good practice to signal the packet drop to the source node, such
that it is able to react to the packet drop in a more appropriate and that it is able to react to the packet drop in a more appropriate and
timely way. timely way.
For example, a firewall could signal the packet drop by means of For example, a firewall could signal the packet drop by means of
an ICMPv6 error message (or TCP [RFC0793] RST segment if an ICMPv6 error message (or TCP [RFC0793] RST segment if
appropriate), such that the source node can e.g. quickly react as appropriate), such that the source node can e.g. quickly react as
described in [RFC5461]. described in [RFC5461].
skipping to change at page 13, line 47 skipping to change at page 14, line 11
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, 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.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001. RFC 3068, June 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February Network Address Translations (NATs)", RFC 4380, February
2006. 2006.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, January Multicast Name Resolution (LLMNR)", RFC 4795, January
2007. 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
skipping to change at page 14, line 23 skipping to change at page 14, line 41
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010. Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", RFC Infrastructures (6rd) -- Protocol Specification", RFC
5969, August 2010. 5969, August 2010.
[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol (TSP)", RFC 5572, February 2010. Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.
8.2. Informative References 8.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, August 1999. 2663, August 1999.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
 End of changes. 8 change blocks. 
7 lines changed or deleted 27 lines changed or added

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