A new draft has been posted, at http://tools.ietf.org/html/draft-generic-v6ops-tunmtu. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@... https://www.ietf.org/mailman/listinfo/v6ops
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) Author(s) : Fernando Gont Filename : draft-ietf-v6ops-ra-guard-implementation-04.txt Pages : 19 Date : 2012-05-22 The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation-04.txt The IETF datatracker page for this Internet-Draft is:(Continue reading)
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the IPv6 Operations Working Group of the IETF.
Title : A Discard Prefix for IPv6
Author(s) : Nick Hilliard
David Freedman
Filename : draft-ietf-v6ops-ipv6-discard-prefix-04.txt
Pages : 6
Date : 2012-05-22
Remote triggered black hole filtering describes a method of
mitigating the effects of denial-of-service attacks by selectively
discarding traffic based on source or destination address. Remote
triggered black hole routing describes a method of selectively re-
routing traffic into a sinkhole router (for further analysis) based
on destination address. This document updates RFC5156 by explaining
why a unique IPv6 prefix should be formally assigned by IANA for the
purpose of facilitating IPv6 remote triggered black hole filtering
and routing.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-04.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-04.txt
(Continue reading)In response to comments recieved during the 6204bis draft wglc and subsequent discsussion among the authors, draft 09 was produced. http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 diffs between the two are here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6204bis-09.txt please review by tue 5/22, this is the version that I plan on generating the document shepherds review from. It strikes me as unlikley that the current discussion on mtu/mss adjustment is going to produce a sustainable consensus and we should therefore consider where or whether or where to expose that problem in a document. Minor niggles can be corrected in auth-48, larger problems should not. thanks joel _______________________________________________ v6ops mailing list v6ops@... https://www.ietf.org/mailman/listinfo/v6ops
Folks, We have published a new IETF I-D entitled: "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers". It is analogous to the RA-Guard (RFC 6105) mechanism currently employed for mitigating RA-based attacks. The I-D is available at: <http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt> I'm not sure in which wg I'd be pursuing this effort (v6ops, opsec, or dhcwg). If there's interest in this wg, it could be done here (the obvious argument for pursuing this in v6ops is that this is heavily based on draft-ietf-v6ops-ra-guard-implementation, and hence the wg is already familiar with the idea). In any case, discussion of this document within v6ops would be welcome. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-opsec-dhcpv6-shield-00.txt Date: Thu, 17 May 2012 22:26:10 -0700 From: internet-drafts@... To: fgont@... A new version of I-D, draft-gont-opsec-dhcpv6-shield-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository.(Continue reading)
A new draft has been posted, at http://tools.ietf.org/html/draft-bar-v6ops-ismtu. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@... https://www.ietf.org/mailman/listinfo/v6ops
A new draft has been posted, at http://tools.ietf.org/html/draft-foo-v6ops-6rdmtu. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@... https://www.ietf.org/mailman/listinfo/v6ops
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the IPv6 Operations Working Group of the IETF.
Title : Basic Requirements for IPv6 Customer Edge Routers
Author(s) : Hemant Singh
Wes Beebee
Chris Donley
Barbara Stark
Filename : draft-ietf-v6ops-6204bis-09.txt
Pages : 22
Date : 2012-05-16
This document specifies requirements for an IPv6 Customer Edge (CE)
router. Specifically, the current version of this document focuses
on the basic provisioning of an IPv6 CE router and the provisioning
of IPv6 hosts attached to it. The document also covers IP transition
technologies. Two transition technologies in RFC 5969's 6rd and RFC
6333's DS-Lite are covered in the document. The document obsoletes
RFC 6204, if approved.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-09.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-09.txt
(Continue reading)
_______________________________________________ v6ops mailing list v6ops@... https://www.ietf.org/mailman/listinfo/v6ops
Hi, I sometimes hear folks say that CGN adds latency or otherwise makes the network slower, and this fact will mean that IPv6 will take more traffic than the slower CGN IPv4 path. I do not believe CGN adds any meaningful latency when the CGN path and IPv6 are ostensibly the same for the internal network (something an access network provider controls). Sometimes, on the external network (the internet), the IPv6 peering is less robust and results in longer paths and therefore higher latency and lower performance for IPv6. Here is some data i casually collect from my phone doing speedtest at ipv6-test.com. Yes, i know these test are flawed in many ways, but this is just a casual observation. The test was done using the IPv6-only connection across an HSPA+ mobile network. The IPv6 path is native end to end. The "IPv4 path" is IPv6 from the Samsung handset to a NAT64 (CGN) and then IPv4 to the test server. This is just a casual test using production and easily available elements. IPv4 / IPv6 speeds Mbit/s 10.2 /9.07 http://img2.ipv6-test.com/speedtest/result/2012/05/14/0b6984f7f589c0fdd10bce5bdaf7b80f.png 11.8/10.8 http://img2.ipv6-test.com/speedtest/result/2012/05/14/898322b8348a47dfe31d944bf3d8b154.png 11.8/12.0 http://img2.ipv6-test.com/speedtest/result/2012/05/14/ae2cb534d9d5e74020191d072f127456.png As you can see, no noticeable difference in this casual observation. I am sure someone with time and precision gear can show that CGN addes ~1ms of latency, but that is hardly impactful on today's internet Does anyone have data showing CGN harms network performance from a speed perspective? Perhaps in such a way that it may impact a happy eyeballs implementations that may do a "straight race" such as Apple's? CB _______________________________________________ v6ops mailing list v6ops@... https://www.ietf.org/mailman/listinfo/v6ops
[The CPE router MUST support a TCP MSS Adjust feature on packets traversing the CPE router. By default, the TCP MSS Adjust feature is turned off. ]
Some thoughts below on why the above text.
The TCP MSS Adjust is not needed for TCP packets sourced or destined to the CPE because the number of such packets at the CPE will be very small. Additionally, we (Wes and I) deliberately left out qualifying the feature for IPv4 or IPv6 because the feature should be supported for both since the CPE also supports 6rd. We have left out specifying any default value for the MSS because there are several values since the MSS is a function of the protocols being used. Note IPv4 CPE routers already support a TCP MSS Adjust knob. Further, the DS-Lite AFTR and the 6rd BR in the SP domain sit between the home TCP client and a TCP server on the Internet. Thus the AFTR and the BR can perform TCP MSS Adjust. It’s only for 6rd where the CPE’s talk without going through the BR, the CPE has to invoke the TCP MSS Adjust.
The problems that the above text alleviates are:
(a) Any of native IPv6 and tunneled technologies such as DS-Lite and 6rd can cause ICMPv6 errors for packet too big to the source. Even when the CPE issues the ICMPv6 error to the host connected to the CPE, the Internet access of the host is delayed which is not good. Additionally, what if the CPE passes the host packet to the Internet and one router on the Internet issues the ICMPv6 error with packet too big but a node in the path back blocks the ICMPv6 error. Now the Internet connectivity is really delayed for the host. This summarizes that we do have problems to fix.
(b) DS-Lite is an additional problem. Since DS-Lite mandates that the CPE and the AFTR perform fragmentation and reassembly, we have a nasty problem. Reassembly of tunneled encapsulated packets is very complex because the receiver of the fragmented packet has to reassemble before decapsulation. Thus the received needs more memory and a general purpose cpu. If I want to choke a DS-Lite deployment at the AFTR and the CPE, I will generate packets close to 1500 bytes and force tunnel fragmentation. Thus the DS-Lite problem is an attack vector that Daniel Rosen pointed out too.
Further, PMTUD is not practical to deploy so the TCP MSS Adjust is still a usable choice.
Thanks,
Hemant
_______________________________________________ v6ops mailing list v6ops@... https://www.ietf.org/mailman/listinfo/v6ops
RSS Feed398 | |
|---|---|
249 | |
368 | |
264 | |
137 | |
266 | |
569 | |
386 | |
96 | |
375 | |
500 | |
207 | |
444 | |
547 | |
312 | |
604 | |
279 | |
580 | |
327 | |
421 | |
208 | |
175 | |
80 | |
34 | |
9 | |
223 | |
278 | |
63 | |
135 | |
24 | |
44 | |
47 | |
41 | |
91 | |
163 | |
28 | |
55 | |
57 | |
216 | |
27 | |
27 | |
36 | |
114 | |
68 | |
58 | |
134 | |
489 | |
91 | |
61 | |
284 | |
130 | |
141 | |
186 | |
127 | |
128 | |
138 | |
79 | |
70 | |
237 | |
32 | |
76 | |
145 | |
163 | |
29 | |
27 | |
33 | |
43 | |
37 | |
20 | |
30 | |
123 | |
78 | |
83 | |
53 | |
80 | |
34 | |
48 | |
25 | |
51 | |
65 | |
42 | |
159 | |
48 | |
29 | |
45 | |
100 | |
74 | |
30 | |
68 | |
44 | |
308 | |
131 | |
108 | |
236 | |
172 | |
177 | |
187 | |
179 | |
283 | |
135 | |
40 | |
32 | |
409 | |
194 | |
167 | |
124 | |
237 | |
53 | |
91 | |
24 | |
199 | |
154 | |
128 | |
139 | |
288 | |
123 | |
480 | |
4 |
