Security Implications of IPv6 on IPv4 Networks
RFC 7123
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
07 | (System) | Notify list changed from opsec-chairs@ietf.org, draft-ietf-opsec-ipv6-implications-on-ipv4-nets@ietf.org to (None) |
2014-02-10 |
07 | (System) | RFC published |
2014-02-05 |
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-01-29 |
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-01-27 |
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-12-12 |
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-12-12 |
07 | (System) | IANA Action state changed to No IC from In Progress |
2013-12-12 |
07 | (System) | IANA Action state changed to No IC from In Progress |
2013-12-12 |
07 | (System) | IANA Action state changed to In Progress |
2013-12-12 |
07 | (System) | RFC Editor state changed to EDIT |
2013-12-12 |
07 | (System) | Announcement was received by RFC Editor |
2013-12-12 |
07 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'No Response' |
2013-12-11 |
07 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-12-11 |
07 | Amy Vezza | IESG has approved the document |
2013-12-11 |
07 | Amy Vezza | Closed "Approve" ballot |
2013-12-11 |
07 | Amy Vezza | Ballot approval text was generated |
2013-12-09 |
07 | Joel Jaeggli | 07 addresses Stephen Farrell's discuss with respect to warning of dnssec breakage. He cleared so this is ready to proceed. |
2013-12-09 |
07 | Joel Jaeggli | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-12-09 |
07 | Stephen Farrell | [Ballot comment] Thanks for addressing my discuss points. --- old comments below Used to be a discuss point: (1) Only just about a discuss: The … [Ballot comment] Thanks for addressing my discuss points. --- old comments below Used to be a discuss point: (1) Only just about a discuss: The title is overly broad - are you claiming to have identified *all* security implications? I doubt that. Truth in advertising would suggest pre-pending "Some" to the title or perhaps appending "considered in a bath." Same goes for the abstract. -- comments.... - end of section 2: is it really true that the exact same policies should be enforced for v6 and v4? I guess that depends on what you call policy - some might consider the use of NATs and private address space as a policy but that doesn't seem to be something worth recommending does it? I'm happy to let the INT or OPSEC folks say this however they like but as stated this seems overly broad. - 2.1 - is it really wise to recommend blocking v6 at layer 2? Would that not possibly get hard to turn off when you do want v6 packets? Seems fragile to me fwiw. I know you don't strongly recommend that but for things like this where you point at something it'd be better if you also called out any significant downsides. |
2013-12-09 |
07 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-12-06 |
07 | Fernando Gont | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-12-06 |
07 | Fernando Gont | New version available: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07.txt |
2013-12-04 |
06 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2013-12-03 |
06 | Sean Turner | Ballot comment text updated for Sean Turner |
2013-12-02 |
06 | Tina Tsou | Request for Telechat review by OPSDIR is assigned to Niclas Comstedt |
2013-12-02 |
06 | Tina Tsou | Request for Telechat review by OPSDIR is assigned to Niclas Comstedt |
2013-12-01 |
06 | Joel Jaeggli | [Ballot comment] With respect to stephen's discuss. There's no advice I'm aware of out there as to how else to ameliorate that situation. nor were … [Ballot comment] With respect to stephen's discuss. There's no advice I'm aware of out there as to how else to ameliorate that situation. nor were we able to solicit any. Certain transition states (or in this case non-transition) effectively require the selective omission or synthesis of resource records for the avoidance of unwanted traffic, skipping over bugs in your stack, or in the ipv6 --> ipv4 direction to attract traffic to translators. those reflect local preference necessity and are hopefully not internet scale. perhaps it is best to simply note that conquences for dnssec validation exist, that cannot be aleviated short of not doing it that way. |
2013-12-01 |
06 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2013-12-01 |
06 | Joel Jaeggli | Telechat date has been changed to 2013-12-05 from 2013-05-16 |
2013-12-01 |
06 | Joel Jaeggli | should address the discuss with respect to multicast dns |
2013-12-01 |
06 | Joel Jaeggli | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-12-01 |
06 | Joel Jaeggli | should address the discuss with respect to multicast dns |
2013-12-01 |
06 | Joel Jaeggli | State changed to IESG Evaluation from IESG Evaluation::AD Followup |
2013-11-27 |
06 | Stephen Farrell | [Ballot discuss] updated for -06 I don't see any change here and don't recall any specific suggested text from authors/chairs/shepherd on the topic. Apologies if … [Ballot discuss] updated for -06 I don't see any change here and don't recall any specific suggested text from authors/chairs/shepherd on the topic. Apologies if I've missed that, (in which case please point me at it) but it looks to me like the discuss point remains unresolved. (2) section 4, 3rd para seems to recommend something that'd make DNSSEC deployment harder. Even in an informational document that seems like a bad plan. Why is it ok to recommend that? Or am I wrong that this practice would make it harder to start deploying DNSSEC? |
2013-11-27 |
06 | Stephen Farrell | [Ballot comment] Used to be a discuss point: (1) Only just about a discuss: The title is overly broad - are you claiming to have … [Ballot comment] Used to be a discuss point: (1) Only just about a discuss: The title is overly broad - are you claiming to have identified *all* security implications? I doubt that. Truth in advertising would suggest pre-pending "Some" to the title or perhaps appending "considered in a bath." Same goes for the abstract. -- comments.... - end of section 2: is it really true that the exact same policies should be enforced for v6 and v4? I guess that depends on what you call policy - some might consider the use of NATs and private address space as a policy but that doesn't seem to be something worth recommending does it? I'm happy to let the INT or OPSEC folks say this however they like but as stated this seems overly broad. - 2.1 - is it really wise to recommend blocking v6 at layer 2? Would that not possibly get hard to turn off when you do want v6 packets? Seems fragile to me fwiw. I know you don't strongly recommend that but for things like this where you point at something it'd be better if you also called out any significant downsides. |
2013-11-27 |
06 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2013-11-26 |
06 | Ted Lemon | [Ballot comment] I am abstaining on this document—I think the advice here is as good as can be managed if you want to disable IPv6 … [Ballot comment] I am abstaining on this document—I think the advice here is as good as can be managed if you want to disable IPv6 on your network, which is a valid thing to want to do, but I am uncomfortable with the IETF giving advice on how to do it. All of my comments and DISCUSSes (shown below) have been addressed. Former comment: The buffer overflow referred to in [Core2007] is six years old at the time of review, applies to an operating system that no-one uses, and is therefore a poor basis for recommending link-local filtering. I think protecting against RA-based and DHCPv6-based attacks is important, but can't be cleanly achieved by filtering the IPv6 ethertype. I support Stephen Farrel's DISCUSS relating to DNSSEC, as well as Barry Lieba's comment. I think this document is trying to do something worthwhile, so please don't take these DISCUSS points as general disapproval. Former DISCUSS: 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation. Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph: However, neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DCHPv6- server messages. Remove this paragraph: If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses. As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour. A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome. If you go this route, you should include all but the first sentence of the first paragraph of this DISCUSS point so that network operators who may not be aware of this realize what's at stake. 2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic). Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient. I would suggest something like the following: Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6. This document describes operational practices for enterprise networks to prevent security exposure resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, Wifi hotspot providers or any other public internet service. In scenarios in which the IPv6-capable devices are deployed on enterprise networks that are intended to be IPv4-only, native IPv6 support and/or IPv6 transition/ co-existence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example, Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated. If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo. 3. This recommendation breaks DNS: For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for AAAA DNS records with a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such queries, and should even consider filtering AAAA records at the network ingress point to prevent the internal hosts from attempting 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 be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations. Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tells the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers. Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS. Proposed action: Delete this paragraph. Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS. If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right. |
2013-11-26 |
06 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2013-11-26 |
06 | Ted Lemon | [Ballot comment] I am abstaining on this document—I think the advice here is as good as can be managed if you want to disable IPv6 … [Ballot comment] I am abstaining on this document—I think the advice here is as good as can be managed if you want to disable IPv6 on your network, which is a valid thing to want to do, but I am uncomfortable with the IETF giving advice on how to do it. The buffer overflow referred to in [Core2007] is six years old at the time of review, applies to an operating system that no-one uses, and is therefore a poor basis for recommending link-local filtering. I think protecting against RA-based and DHCPv6-based attacks is important, but can't be cleanly achieved by filtering the IPv6 ethertype. I support Stephen Farrel's DISCUSS relating to DNSSEC, as well as Barry Lieba's comment. I think this document is trying to do something worthwhile, so please don't take these DISCUSS points as general disapproval. Former DISCUSS: 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation. Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph: However, neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DCHPv6- server messages. Remove this paragraph: If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses. As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour. A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome. If you go this route, you should include all but the first sentence of the first paragraph of this DISCUSS point so that network operators who may not be aware of this realize what's at stake. 2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic). Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient. I would suggest something like the following: Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6. This document describes operational practices for enterprise networks to prevent security exposure resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, Wifi hotspot providers or any other public internet service. In scenarios in which the IPv6-capable devices are deployed on enterprise networks that are intended to be IPv4-only, native IPv6 support and/or IPv6 transition/ co-existence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example, Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated. If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo. 3. This recommendation breaks DNS: For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for AAAA DNS records with a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such queries, and should even consider filtering AAAA records at the network ingress point to prevent the internal hosts from attempting 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 be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations. Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tells the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers. Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS. Proposed action: Delete this paragraph. Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS. If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right. |
2013-11-26 |
06 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to Abstain from Discuss |
2013-11-26 |
06 | Fernando Gont | New version available: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-06.txt |
2013-07-10 |
05 | Stephen Farrell | [Ballot discuss] updated for -05 (2) section 4, 3rd para seems to recommend something that'd make DNSSEC deployment harder. Even in an informational document that … [Ballot discuss] updated for -05 (2) section 4, 3rd para seems to recommend something that'd make DNSSEC deployment harder. Even in an informational document that seems like a bad plan. Why is it ok to recommend that? Or am I wrong that this practice would make it harder to start deploying DNSSEC? |
2013-07-10 |
05 | Stephen Farrell | [Ballot comment] Used to be a discuss point: (1) Only just about a discuss: The title is overly broad - are you claiming to have … [Ballot comment] Used to be a discuss point: (1) Only just about a discuss: The title is overly broad - are you claiming to have identified *all* security implications? I doubt that. Truth in advertising would suggest pre-pending "Some" to the title or perhaps appending "considered in a bath." Same goes for the abstract. -- comments.... - end of section 2: is it really true that the exact same policies should be enforced for v6 and v4? I guess that depends on what you call policy - some might consider the use of NATs and private address space as a policy but that doesn't seem to be something worth recommending does it? I'm happy to let the INT or OPSEC folks say this however they like but as stated this seems overly broad. - 2.1 - is it really wise to recommend blocking v6 at layer 2? Would that not possibly get hard to turn off when you do want v6 packets? Seems fragile to me fwiw. I know you don't strongly recommend that but for things like this where you point at something it'd be better if you also called out any significant downsides. |
2013-07-10 |
05 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2013-07-05 |
05 | Fernando Gont | New version available: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.txt |
2013-05-16 |
04 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'No Response' |
2013-05-16 |
04 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-05-16 |
04 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-05-16 |
04 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from No Record |
2013-05-16 |
04 | Jari Arkko | [Ballot comment] I agree with the issues Ted has raised. |
2013-05-16 |
04 | Jari Arkko | Ballot comment text updated for Jari Arkko |
2013-05-15 |
04 | Pete Resnick | [Ballot comment] This document is far enough outside of my expertise that I would normally ballot NO OBJECTION, especially because it's Informational. But between Brian's … [Ballot comment] This document is far enough outside of my expertise that I would normally ballot NO OBJECTION, especially because it's Informational. But between Brian's ABSTAIN, Stephen's DISCUSS, and the fact that I can't determine how this fits into OPSEC's charter, I will also ABSTAIN. Since this is Informational, this makes no practical difference; if Joel wants to go ahead with the document, my abstention won't affect approval. But I thought I ought to register my concern. |
2013-05-15 |
04 | Pete Resnick | [Ballot Position Update] New position, Abstain, has been recorded for Pete Resnick |
2013-05-15 |
04 | Ted Lemon | [Ballot comment] The buffer overflow referred to in [Core2007] is six years old at the time of review, applies to an operating system that no-one … [Ballot comment] The buffer overflow referred to in [Core2007] is six years old at the time of review, applies to an operating system that no-one uses, and is therefore a poor basis for recommending link-local filtering. I think protecting against RA-based and DHCPv6-based attacks is important, but can't be cleanly achieved by filtering the IPv6 ethertype. I support Stephen Farrel's DISCUSS relating to DNSSEC, as well as Barry Lieba's comment. I think this document is trying to do something worthwhile, so please don't take these DISCUSS points as general disapproval. |
2013-05-15 |
04 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2013-05-15 |
04 | Ted Lemon | [Ballot discuss] 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour … [Ballot discuss] 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation. Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph: However, neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DCHPv6- server messages. Remove this paragraph: If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses. As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour. A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome. If you go this route, you should include all but the first sentence of the first paragraph of this DISCUSS point so that network operators who may not be aware of this realize what's at stake. 2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic). Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient. I would suggest something like the following: Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6. This document describes operational practices for enterprise networks to prevent security exposure resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, Wifi hotspot providers or any other public internet service. In scenarios in which the IPv6-capable devices are deployed on enterprise networks that are intended to be IPv4-only, native IPv6 support and/or IPv6 transition/ co-existence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example, Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated. If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo. 3. This recommendation breaks DNS: For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for AAAA DNS records with a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such queries, and should even consider filtering AAAA records at the network ingress point to prevent the internal hosts from attempting 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 be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations. Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tells the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers. Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS. Proposed action: Delete this paragraph. Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS. If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right. |
2013-05-15 |
04 | Ted Lemon | Ballot discuss text updated for Ted Lemon |
2013-05-15 |
04 | Ted Lemon | [Ballot discuss] 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour … [Ballot discuss] 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation. Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph: However, neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DCHPv6- server messages. Remove this paragraph: If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses. As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour. A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome. If you go this route, you should include all but the first sentence of the first paragraph of this DISCUSS point so that network operators who may not be aware of this realize what's at stake. 2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic). Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient. I would suggest something like the following: Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6. This document describes operational practices for enterprise networks to prevent security exposure resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, Wifi hotspot providers or any other public internet service. In scenarios in which the IPv6-capable devices are deployed on enterprise networks that are intended to be IPv4-only, native IPv6 support and/or IPv6 transition/ co-existence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example, Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated. If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo. 3. This recommendation breaks DNS: For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for AAAA DNS records with a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such queries, and should even consider filtering AAAA records at the network ingress point to prevent the internal hosts from attempting 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 be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations. Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tels the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers. Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS. Proposed action: Delete this paragraph. Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS. If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right. |
2013-05-15 |
04 | Ted Lemon | Ballot discuss text updated for Ted Lemon |
2013-05-15 |
04 | Ted Lemon | [Ballot discuss] 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour … [Ballot discuss] 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation. Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph: However, neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DCHPv6- server messages. Remove this paragraph: If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses. As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour. A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome. 2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic). Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient. I would suggest something like the following: Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6. This document describes operational practices for enterprise networks to prevent security exposure resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, Wifi hotspot providers or any other public internet service. In scenarios in which the IPv6-capable devices are deployed on networks that are intended to be IPv4-only, native IPv6 support and/or IPv6 transition/ co-existence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example, Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated. If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo. 3. This recommendation breaks DNS: For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for AAAA DNS records with a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such queries, and should even consider filtering AAAA records at the network ingress point to prevent the internal hosts from attempting 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 be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations. Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tels the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers. Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS. Proposed action: Delete this paragraph. Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS. If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right. |
2013-05-15 |
04 | Ted Lemon | Ballot discuss text updated for Ted Lemon |
2013-05-15 |
04 | Ted Lemon | [Ballot discuss] 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour … [Ballot discuss] 1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation. Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph: However, neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DCHPv6- server messages. Remove this paragraph: If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses. As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour. A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome. 2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic). Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient. I would suggest something like the following: Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6. This document describes operational practices for enterprise networks to prevent security exposure resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, Wifi hotspots or any other public internet service. In scenarios in which the IPv6-capable devices are deployed on networks that are intended to be IPv4-only, native IPv6 support and/or IPv6 transition/ co-existence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example, Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated. If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo. 3. This recommendation breaks DNS: For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for AAAA DNS records with a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such queries, and should even consider filtering AAAA records at the network ingress point to prevent the internal hosts from attempting 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 be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations. Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tels the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers. Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS. Proposed action: Delete this paragraph. Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS. If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right. |
2013-05-15 |
04 | Ted Lemon | [Ballot comment] The buffer overflow referred to in [Core2007] is six years old at the time of review, and is a poor basis for making … [Ballot comment] The buffer overflow referred to in [Core2007] is six years old at the time of review, and is a poor basis for making such a drastic recommendation. I support Stephen Farrel's DISCUSS relating to DNSSEC, as well as Barry Lieba's comment. |
2013-05-15 |
04 | Ted Lemon | [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon |
2013-05-15 |
04 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-05-15 |
04 | Brian Haberman | [Ballot comment] I have issues with this document, but do not see any benefit in arguing for changes. This document: - Only discusses approaches that … [Ballot comment] I have issues with this document, but do not see any benefit in arguing for changes. This document: - Only discusses approaches that have been well-known for years and have been discussed on numerous IPv6-related mailing lists - Encourages filtering of nascent/experimental testing of IPv6 in legacy networks rather than encouraging controlled testing/deployment/monitoring of IPv6 traffic - Engendered only a smattering of positive support in the WG and a large amount of disinterest from the silent majority. |
2013-05-15 |
04 | Brian Haberman | [Ballot Position Update] New position, Abstain, has been recorded for Brian Haberman |
2013-05-15 |
04 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-05-15 |
04 | Benoît Claise | [Ballot comment] I found the draft interesting to read. However, I wish the draft would be clearer regarding: 1. the security mechanisms that should be … [Ballot comment] I found the draft interesting to read. However, I wish the draft would be clearer regarding: 1. the security mechanisms that should be in place while waiting for the network to be IPv6-enabled, and then disabled (example: "layer-2 device filtering") 2. versus the measures that must remain in place once the network is IPv6-enabled (RA-Guard [RFC6105]) Within 2., there are actually two cases 2.1 when the network is both IPv6 and IPv4 enabled 2.2 when the network is only IPv6. It's interesting to note that - this is just one example. For example, same question for the next section "tunneling mechanisms" (some tunneling mechanisms are not valid any longer in the 2.2 case ) - the two previous examples are from the same section "filtering native IPv6 traffic". Having different sections for the points 1 and 2 may help, or having an introduction with generic security mechanism (point 2), and then, the content of this draft (point 1) If there are more reviews in that direction, it might be worth seriously considering. |
2013-05-15 |
04 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-05-15 |
04 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-05-14 |
04 | Sean Turner | [Ballot comment] My shakey notes from the roads around the Cliffs of Moher read like this: ---- 0) Should we rename this "Filtering IPv6 from … [Ballot comment] My shakey notes from the roads around the Cliffs of Moher read like this: ---- 0) Should we rename this "Filtering IPv6 from IPv4 to avoid some IPv6 Security Issues". 1) I guess there's the recommendation that the same security policy be applied to both IPv4 and IPv6 traffic, but that's really what like 2 paragraphs in the whole draft? 2) Do we REALLY want to recommend filtering IPv6? ---- I think the first and second bits are kind of covered by Stephen's discuss, but maybe we should go a step further in truth in advertising and just title this draft what it's mostly about. Funny that the 3rd one Jari and Joel discussed while at the IESG retreat last week (not security related but more like unexpected traffic loads) so I know these surprises happen on mixed networks. But, 'd hate for this kind of recommendation to stick around for a while. That is when we don't need to be filtering for immature products we ought to get this document gone. |
2013-05-14 |
04 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-05-14 |
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-05-14 |
04 | Stephen Farrell | [Ballot discuss] (1) Only just about a discuss: The title is overly broad - are you claiming to have identified *all* security implications? I doubt … [Ballot discuss] (1) Only just about a discuss: The title is overly broad - are you claiming to have identified *all* security implications? I doubt that. Truth in advertising would suggest pre-pending "Some" to the title or perhaps appending "considered in a bath." Same goes for the abstract. (2) section 4, 3rd para seems to recommend something that'd make DNSSEC deployment harder. Even in an informational document that seems like a bad plan. Why is it ok to recommend that? Or am I wrong that this practice would make it harder to start deploying DNSSEC? |
2013-05-14 |
04 | Stephen Farrell | [Ballot comment] - end of section 2: is it really true that the exact same policies should be enforced for v6 and v4? I guess … [Ballot comment] - end of section 2: is it really true that the exact same policies should be enforced for v6 and v4? I guess that depends on what you call policy - some might consider the use of NATs and private address space as a policy but that doesn't seem to be something worth recommending does it? I'm happy to let the INT or OPSEC folks say this however they like but as stated this seems overly broad. - 2.1 - is it really wise to recommend blocking v6 at layer 2? Would that not possibly get hard to turn off when you do want v6 packets? Seems fragile to me fwiw. I know you don't strongly recommend that but for things like this where you point at something it'd be better if you also called out any significant downsides. |
2013-05-14 |
04 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-05-13 |
04 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-05-10 |
04 | Barry Leiba | [Ballot comment] From the shepherd writeup: The Document Shepherd has had a number of discussions with the authors on this topic, and has … [Ballot comment] From the shepherd writeup: The Document Shepherd has had a number of discussions with the authors on this topic, and has followed the progression of the draft through revisions and the WG. The Document Shepherd also sat in the bath with a highlighter and carefully reviewed the document. One can always rely on Warren for a good chuckle.... |
2013-05-10 |
04 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-05-07 |
04 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Joseph Salowey |
2013-05-07 |
04 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Joseph Salowey |
2013-05-07 |
04 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'Withdrawn' |
2013-05-07 |
04 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Simon Josefsson |
2013-05-07 |
04 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Simon Josefsson |
2013-05-03 |
04 | Roni Even | Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. |
2013-05-02 |
04 | Joel Jaeggli | draft-04 addresses last call comments. |
2013-05-02 |
04 | Joel Jaeggli | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2013-05-02 |
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-05-02 |
04 | Fernando Gont | New version available: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04.txt |
2013-04-18 |
03 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey. |
2013-04-16 |
03 | Joel Jaeggli | Ballot writeup was changed |
2013-04-16 |
03 | Joel Jaeggli | Placed on agenda for telechat - 2013-05-16 |
2013-04-16 |
03 | Joel Jaeggli | State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2013-04-12 |
03 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-04-04 |
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2013-04-04 |
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2013-04-04 |
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2013-04-04 |
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2013-03-29 |
03 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 under the Evaluation ticket [#668335] on 2013-03-26. The Evaluation notification was issued before the Last Call notification. We understand … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 under the Evaluation ticket [#668335] on 2013-03-26. The Evaluation notification was issued before the Last Call notification. We understand that, upon approval of this document, there are no IANA Actions that need completion. We have received an acknowledgment from Fernando Gont confirming the above. The comment is in the tracker. |
2013-03-29 |
03 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <opsec@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications … The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <opsec@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Security Implications of IPv6 on IPv4 Networks' <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-03-29 |
03 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-03-29 |
03 | Amy Vezza | Last call announcement was changed |
2013-03-28 |
03 | Joel Jaeggli | Last call was requested |
2013-03-28 |
03 | Joel Jaeggli | Last call announcement was generated |
2013-03-28 |
03 | Joel Jaeggli | State changed to Last Call Requested from AD Evaluation |
2013-03-28 |
03 | Joel Jaeggli | Removed from agenda for telechat |
2013-03-28 |
03 | Joel Jaeggli | altering my understanding of the procedure that should be applied. requesting ietf LC |
2013-03-28 |
03 | Joel Jaeggli | State changed to AD Evaluation from Publication Requested |
2013-03-28 |
03 | Joel Jaeggli | State changed to Publication Requested from IESG Evaluation |
2013-03-26 |
03 | Pearl Liang | S) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03, which is currently in IESG Evaluation and has the following comments: We understand that, upon approval of this … S) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03, which is currently in IESG Evaluation and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. If this assessment is not accurate, please respond as soon as possible. BTW, we did not locate a Last Call request for this document in our ticketing system. |
2013-03-21 |
03 | Joel Jaeggli | Placed on agenda for telechat - 2013-04-25 |
2013-03-21 |
03 | Joel Jaeggli | State changed to IESG Evaluation from Publication Requested |
2013-03-21 |
03 | Joel Jaeggli | Ballot has been issued |
2013-03-21 |
03 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2013-03-21 |
03 | Joel Jaeggli | Created "Approve" ballot |
2013-03-21 |
03 | Joel Jaeggli | Ballot writeup was changed |
2013-03-21 |
03 | Joel Jaeggli | Ballot writeup was generated |
2013-03-21 |
03 | Joel Jaeggli | Ballot approval text was generated |
2013-03-21 |
03 | Joel Jaeggli | Intended Status changed to Informational |
2013-03-21 |
03 | Joel Jaeggli | IESG process started in state Publication Requested |
2013-03-21 |
03 | (System) | Earlier history may be found in the Comment Log for draft-gont-opsec-ipv6-implications-on-ipv4-nets |
2013-03-20 |
03 | Warren Kumari | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2013-03-20 |
03 | Warren Kumari | Changed protocol writeup |
2013-03-20 |
03 | Warren Kumari | Changed shepherd to Warren Kumari |
2013-03-20 |
03 | Warren Kumari | Changed consensus to Yes from Unknown |
2013-02-22 |
03 | Fernando Gont | New version available: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt |
2013-02-12 |
02 | Warren Kumari | IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2013-01-10 |
02 | Warren Kumari | IETF state changed to In WG Last Call from In WG Last Call |
2013-01-10 |
02 | Warren Kumari | IETF state changed to In WG Last Call from WG Document |
2012-12-28 |
02 | Warren Kumari | This starts a working group last call for draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 Networks" The draft is available at http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 and https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/ … This starts a working group last call for draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 Networks" The draft is available at http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 and https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/ Please review this draft to see if you think it is ready for publication. Send comments to the list. The WGLC will end on 25th January 2013. |
2012-12-28 |
02 | Fernando Gont | New version available: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02.txt |
2012-12-12 |
01 | Fernando Gont | New version available: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01.txt |
2012-09-04 |
00 | Fernando Gont | New version available: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-00.txt |