From fgont at si6networks.com Tue Sep 1 05:35:24 2015 From: fgont at si6networks.com (Fernando Gont) Date: Tue, 1 Sep 2015 00:35:24 -0300 Subject: [ipv6-wg] Why operators filter IPv6 packets with extension headers? Message-ID: <55E51CFC.2020601@si6networks.com> Folks, The topic of operators dropping IPv6 packets containing extension headers has been raised quite a few times on a number of mailing-lists and forums. A month ago or so we published a document trying to summarize the reasons for which operators filter IPv6 packets containing extension headers. The document is available at: We're currently working on a revision of this document, and would like to hear feedback from the ops community regarding our document. e.g., * Did we get anything wrong? * Is there anything missing? Or, if you like the document and agree with its content, that's also interesting feedback to have. P.S.: If possible, please CC and when sending feedback. Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From evyncke at cisco.com Tue Sep 1 10:42:14 2015 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Tue, 1 Sep 2015 08:42:14 +0000 Subject: [ipv6-wg] [v6ops] Why operators filter IPv6 packets with extension headers? In-Reply-To: <55E4FCB6.8040407@gont.com.ar> References: <55E4FCB6.8040407@gont.com.ar> Message-ID: Fernando et al., A couple of quick comments: - this reminds me of taylor-v6ops-fragdrop (which you cite at the end), did you approach any of this old I-D authors? - not sure whether the security implications should be re-stated again in this document, let's rather split the security & operational issues into two documents - in the introduction, 'widespread implementation limitations' is probably too strong (and I agree that my employer products could do better) - in the introduction, "intentionally dropped" ? I am afraid that some drop are not intentional - I would shorten a lot the section 3 (security implications) and simply put a lot of references to existing good documents of yours and others - I like section 4 (operational implications) but it does not match the title, it is more about why transit operators have to look at layer-4 - section 4 approaches the goal described in the abstract but actually only provide clues why operators intentionally (or non intentionally) drops packets with EH. For example, being unable to do ECMP is of course an operational impact but why would it be the cause of EH drop? - section 4.1 (iACL), beyond the permit/deny, some operators also rate limit some traffic such pings - section 4.1, perhaps worth mentioning that infrastructure ACL are more in the white list approach, i.e., what is not BGP/ICMP (in your example) to some prefixes is dropped, so, if someone uses EH to obscure the traffic, this EH traffic matching the destination prefix is dropped anyway by the ACL (so iACL works) but traffic destined to other destination is not impacted. Or did I got something wrong? - section 4.2 (route processor protection) is a little unclear - the processing of HbH would kill the Internet of course (at least with most routers), should HbH be separately called? - section 4.3 (DDoS mitigation), I am unsure about FlowSPec but can it also specify 'any traffic with EH' ? This would do the trick probably for dropping or diverting the DoS packets? - missing issue is lack of granular EH control by some routers, for example if an operator wants to block its subscribers RH-0 but can only drop RH (because RH type cannot be specified), then all RH are dropped including MIPv6 - section 5 (potential attack vector) appears to be focus on fragment drop by the public Internet. While it can probably work, the issues are twofold: 1) bad host implementations not doing enough tests before accepting a ICMP packet-too-big 2) public Internet dropping valid fragments in transit In both cases, we (the industry, vendors + operators) need to fix those two issues. May I STRONGLY suggest to remove all security issues (other docs are describing this) and focus only on the operational issues (esp in V6OPS) ? And skip any discussion on the rationale why packets with EH are dropped? Hope this helps to refine a potentially useful I-D. -?ric On 1/09/15 03:17, "v6ops on behalf of Fernando Gont" wrote: >Folks, > >The topic of operators dropping IPv6 packets containing extension >headers has been raised quite a few times on this list and elsewhere. > >A month ago or so we published a document trying to summarize the >reasons for which operators filter IPv6 packets containing extension >headers. The document is available at: > > >We're currently working on a revision of this document, and would like >to hear feedback from the working group regarding our document. e.g., > >* Did we get anything wrong? >* Is there anything missing? > >Or, if you like the document and agree with its content, that's also >interesting feedback to have. > >Thanks! > >Best regards, >-- >Fernando Gont >e-mail: fernando at gont.com.ar || fgont at si6networks.com >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > >_______________________________________________ >v6ops mailing list >v6ops at ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From fgont at si6networks.com Tue Sep 1 12:06:57 2015 From: fgont at si6networks.com (Fernando Gont) Date: Tue, 1 Sep 2015 07:06:57 -0300 Subject: [ipv6-wg] [v6ops] Why operators filter IPv6 packets with extension headers? In-Reply-To: References: <55E4FCB6.8040407@gont.com.ar> Message-ID: <55E578C1.3040507@si6networks.com> Hi, Eric, Thanks so much for the timely feedback! Please find some comments inline (more in a subsequent email)... On 09/01/2015 05:42 AM, Eric Vyncke (evyncke) wrote: > > A couple of quick comments: > > - this reminds me of taylor-v6ops-fragdrop (which you cite at the end), > did you approach any of this old I-D authors? Warren (co-author of this I-D) was a co-author of both draft-taylor-v6ops-fragdrop and draft-wkumari-long-headers -- but I did not approach all co-authors of the aforementioned I-Ds. FWIW, version -00 of our I-D is based in part on what was in version -00 of draft-gont-v6ops-ipv6-ehs-in-real-world (before we decided to have that one just focus on the measurements), and then discussions of this topic on the v6ops mailing-list (mostly the input from Nick and Gert, which was then augmented/elaborated for this I-D). > - not sure whether the security implications should be re-stated again in > this document, let's rather split the security & operational issues into > two documents FWIW, the intent here with respect to the security implications was to provide a rather high-level discussion, and provide pointers for the interested reader. While in principle I don't object to splitting considerations in separate documents, I'm not sure it's possible to separate them, since the security aspect is probably one of the reasons for which some people filter them, though. > - in the introduction, 'widespread implementation limitations' is probably > too strong (and I agree that my employer products could do better) The intent here was to note that it's not a single product/vendor that has limitations in this respect, but rather rather a more widespread/general thing. Do you have any suggestions on how to tweak the text? > - in the introduction, "intentionally dropped" ? I am afraid that some > drop are not intentional Agreed. We noted that "...may be intentionally dropped on the public Internet in some network deployments". i.e., some operators do filter packets with EHs for a reason (rather than just e.g. wrong configuration defaults of buggy boxes). > - I would shorten a lot the section 3 (security implications) and simply > put a lot of references to existing good documents of yours and others This is indeed an open question. One one hand, the idea was to provide pointers (please let us know the ones we may have missed). On the other hand, we tried to provide some level discussion of each of the bullets such that folks could get some idea of "what this is all about" without digging into lots of documents. > - I like section 4 (operational implications) but it does not match the > title, it is more about why transit operators have to look at layer-4 My mental model of this section is "We filter packets with EHs because they prevent us from doing our job, because we need the layer-4 info... And this is why we need that info". > - section 4 approaches the goal described in the abstract but actually > only provide clues why operators intentionally (or non intentionally) > drops packets with EH. For example, being unable to do ECMP is of course > an operational impact but why would it be the cause of EH drop? You mean other than you don't have many header fields on which to hash? > - section 4.1 (iACL), beyond the permit/deny, some operators also rate > limit some traffic such pings Yep. Will fix. > - section 4.2 (route processor protection) is a little unclear > > - the processing of HbH would kill the Internet of course (at least with > most routers), should HbH be separately called? I think that'd be sensible. -- and seem to recall that there was some I-D (RFC?) focusing on HbH? (or was it on router alert option?) > - missing issue is lack of granular EH control by some routers, for > example if an operator wants to block its subscribers RH-0 but can only > drop RH (because RH type cannot be specified), then all RH are dropped > including MIPv6 Good point. Will add this. > - section 5 (potential attack vector) appears to be focus on fragment drop > by the public Internet. Yes. > While it can probably work, the issues are twofold: FWIW, kernel.org was vulnerable to this (before the Linux kernel was patched to prevent the generation of atomic fragments) > 1) bad host implementations not doing enough tests before accepting a ICMP > packet-too-big Agreed. However: i) RFC4443 does not require such checks (unfortunately) ii) Because of EHs, at least in theory you might not even have such info available (a packet with EHs might mean that what you get in the ICMPv6 payload does not even have the layer-4 header) > 2) public Internet dropping valid fragments in transit > In both cases, we (the industry, vendors + operators) need to fix those > two issues. "Agreed" -- although some have argued against that (fwiw, I'm just the messenger :-) ) > May I STRONGLY suggest to remove all security issues (other docs are > describing this) and focus only on the operational issues (esp in V6OPS) ? > And skip any discussion on the rationale why packets with EH are dropped? Let's hear from other folks what they think. I think that without at least some "roadmap"/brief discussion, folks might need to dig deep into many documents in order to grasp "what this is ll about". FWIW, 8just me thinking out loud), I guess that one of the possible outcomes could be to have (some reduced version of) Section 3 be a subsection of Section 4? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter at gmail.com Tue Sep 1 22:43:50 2015 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 2 Sep 2015 08:43:50 +1200 Subject: [ipv6-wg] [v6ops] Why operators filter IPv6 packets with extension headers? In-Reply-To: <55E578C1.3040507@si6networks.com> References: <55E4FCB6.8040407@gont.com.ar> <55E578C1.3040507@si6networks.com> Message-ID: <55E60E06.1050305@gmail.com> On 01/09/2015 22:06, Fernando Gont wrote: > Hi, Eric, > > Thanks so much for the timely feedback! Please find some comments inline > (more in a subsequent email)... > > > On 09/01/2015 05:42 AM, Eric Vyncke (evyncke) wrote: ... >> - the processing of HbH would kill the Internet of course (at least with >> most routers), should HbH be separately called? > > I think that'd be sensible. -- and seem to recall that there was some > I-D (RFC?) focusing on HbH? (or was it on router alert option?) You're probably thinking of draft-baker-6man-hbh-header-handling, but there's a slight conflict between that and RFC 7045, which made a normative change to HbH by downgrading them to SHOULD: The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour. Also of course the next version of 2460bis will revisit this topic. Brian From joelja at bogus.com Tue Sep 8 07:45:33 2015 From: joelja at bogus.com (joel jaeggli) Date: Mon, 7 Sep 2015 22:45:33 -0700 Subject: [ipv6-wg] [v6ops] Why operators filter IPv6 packets with extension headers? In-Reply-To: References: <55E4FCB6.8040407@gont.com.ar> Message-ID: <55EE75FD.5060704@bogus.com> On 9/1/15 1:42 AM, Eric Vyncke (evyncke) wrote: > Fernando et al., > > A couple of quick comments: > > - this reminds me of taylor-v6ops-fragdrop (which you cite at the end), > did you approach any of this old I-D authors? I think it's safe to say they we're all operating in the same milieu. > - not sure whether the security implications should be re-stated again in > this document, let's rather split the security & operational issues into > two documents > > - in the introduction, 'widespread implementation limitations' is probably > too strong (and I agree that my employer products could do better) > > - in the introduction, "intentionally dropped" ? I am afraid that some > drop are not intentional > > - I would shorten a lot the section 3 (security implications) and simply > put a lot of references to existing good documents of yours and others > > - I like section 4 (operational implications) but it does not match the > title, it is more about why transit operators have to look at layer-4 > > - section 4 approaches the goal described in the abstract but actually > only provide clues why operators intentionally (or non intentionally) > drops packets with EH. For example, being unable to do ECMP is of course > an operational impact but why would it be the cause of EH drop? > > - section 4.1 (iACL), beyond the permit/deny, some operators also rate > limit some traffic such pings > > - section 4.1, perhaps worth mentioning that infrastructure ACL are more > in the white list approach, i.e., what is not BGP/ICMP (in your example) > to some prefixes is dropped, so, if someone uses EH to obscure the > traffic, this EH traffic matching the destination prefix is dropped anyway > by the ACL (so iACL works) but traffic destined to other destination is > not impacted. Or did I got something wrong? > > - section 4.2 (route processor protection) is a little unclear > > - the processing of HbH would kill the Internet of course (at least with > most routers), should HbH be separately called? > > - section 4.3 (DDoS mitigation), I am unsure about FlowSPec but can it > also specify 'any traffic with EH' ? This would do the trick probably for > dropping or diverting the DoS packets? > > - missing issue is lack of granular EH control by some routers, for > example if an operator wants to block its subscribers RH-0 but can only > drop RH (because RH type cannot be specified), then all RH are dropped > including MIPv6 > > - section 5 (potential attack vector) appears to be focus on fragment drop > by the public Internet. While it can probably work, the issues are > twofold: > 1) bad host implementations not doing enough tests before accepting a ICMP > packet-too-big > 2) public Internet dropping valid fragments in transit > In both cases, we (the industry, vendors + operators) need to fix those > two issues. > > > May I STRONGLY suggest to remove all security issues (other docs are > describing this) and focus only on the operational issues (esp in V6OPS) ? > And skip any discussion on the rationale why packets with EH are dropped? > > > Hope this helps to refine a potentially useful I-D. > > > > -?ric > > > On 1/09/15 03:17, "v6ops on behalf of Fernando Gont" > wrote: > >> Folks, >> >> The topic of operators dropping IPv6 packets containing extension >> headers has been raised quite a few times on this list and elsewhere. >> >> A month ago or so we published a document trying to summarize the >> reasons for which operators filter IPv6 packets containing extension >> headers. The document is available at: >> >> >> We're currently working on a revision of this document, and would like >> to hear feedback from the working group regarding our document. e.g., >> >> * Did we get anything wrong? >> * Is there anything missing? >> >> Or, if you like the document and agree with its content, that's also >> interesting feedback to have. >> >> Thanks! >> >> Best regards, >> -- >> Fernando Gont >> e-mail: fernando at gont.com.ar || fgont at si6networks.com >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops at ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops at ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From training at ripe.net Tue Sep 8 13:26:07 2015 From: training at ripe.net (Training Services) Date: Tue, 08 Sep 2015 13:26:07 +0200 Subject: [ipv6-wg] [training] IP Address Space Course this November in Bucharest Message-ID: <55EEC5CF.6080807@ripe.net> Dear colleagues, We are happy to announce that a RIPE NCC training course will take place on the Sunday before the RIPE 71 Meeting in Bucharest this November. This course will focus on how to obtain and manage IP address space. The course is free of charge and is open to anyone interested. The course will cover the most frequently asked questions that the RIPE NCC receives about IP address space. ----------------- Course details ---------------- IPv6 Address Space Basics: How to Obtain and Manage Your IP Addresses Sunday, 15 November 2015, 10-16:00 JW Marriott Bucharest Grand Hotel ---------------- Course goals ---------------- By the end of this course, you will be able to: - Manage your IPv4 and IPv6 addresses according to current RIPE Policies - Understand how to obtain IPv4 addresses through transfers - Protect your address space from hijacking ---------------------------------------- Who will benefit from this course? ----------------------------------------- Anyone interested in the policies and procedures around address space in the RIPE NCC service region will find this course useful. No prior knowledge of the topic is necessary. ------------------------- Course outline: ------------------------- - Becoming a RIPE NCC member (why and how) - Obtaining IP addresses (IPv4 and IPv6) - IP address space transfers, mergers and acquisitions - IPv6 basics - Address space hijacking - Resource Certification (RPKI) ---------------------------- Additional information ---------------------------- - Free of charge - Coffee and lunch will be provided - Delivered by the RIPE NCC?s Training Services and Registration Services departments ----------------------------------------- Registration for RIPE NCC members ----------------------------------------- If you are a RIPE NCC member and interested in attending this course, please visit our website on the following page to register: ------------------------------------ Registration for non-members ------------------------------------- If you are not (yet) a member, please fill out the following information and send this to : - Email: - Course name: - Full name : - Vegetarian: yes/no Be quick - we only have 45 seats available on a first come, first served basis! If there is enough interest, we will continue to offer courses on different topics of interest alongside future RIPE Meetings. Kind regards, RIPE NCC Training Services From furry13 at gmail.com Tue Sep 15 10:43:19 2015 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 15 Sep 2015 10:43:19 +0200 Subject: [ipv6-wg] [ipv6-wg-chair] ipv6 deployment startup In-Reply-To: <7E424102-B3D6-4C29-A9E0-90AC8B4C8EB1@win-dsl.com> References: <7E424102-B3D6-4C29-A9E0-90AC8B4C8EB1@win-dsl.com> Message-ID: Hi Nadim, On Sat, Sep 12, 2015 at 9:59 PM, Nadim Houeiss wrote: > looking to start the deployment of ipv6 only network for a new part in my > network , i need to have info about wish solution will be the best to be > used for NAT64 techniques for new ipv6 only end users will be able to reach > ipv4 different services and web servers on the web. As far as I know most network vendors (Cisco, Juniper etc) support NAT64 on their equipment. However don't forget that you'd need DNS64 as well, so I'd suggest to check if the DNS solution you are using currently supports DNS64. >From my experience the main issue is not choosing a vendor for NAT64 but dealing with broken applications: - applications which assume than "no IPv4 address" means "no Internet connectivity" and not even trying to establish any connections if the device does not receive Ipv4 address; - applications which are using IPv4 literals; - applications which ask for "A" DNS RR only, so DNS64 does not help etc. > looking forward for your reply, BTW I'm removing ipv-wg-chairs@ (as it is just an alias which is used to reach RIPE IPv6 Working group chairs) and adding RIPE IPv6 mailing list. -- SY, Jen Linkova aka Furry From training at ripe.net Tue Sep 22 10:33:59 2015 From: training at ripe.net (Training Services) Date: Tue, 22 Sep 2015 10:33:59 +0200 Subject: [ipv6-wg] [training] RIPE NCC Webinars - new dates In-Reply-To: <56010F39.7000006@ripe.net> References: <56010F39.7000006@ripe.net> Message-ID: <56011277.2020203@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/support/training/learn-online/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email . We look forward to seeing you online. Kind regards, RIPE NCC Training Services From dez at otenet.gr Tue Sep 22 11:36:50 2015 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Tue, 22 Sep 2015 12:36:50 +0300 Subject: [ipv6-wg] [ipv6-wg-chair] ipv6 deployment startup In-Reply-To: References: <7E424102-B3D6-4C29-A9E0-90AC8B4C8EB1@win-dsl.com> Message-ID: <56012132.8050201@otenet.gr> Hello, MAP-(E/T) and lw4o6, both recently standardized, should also be considered. cheers, Yannis On 09/15/2015 11:43 AM, Jen Linkova wrote: > Hi Nadim, > > On Sat, Sep 12, 2015 at 9:59 PM, Nadim Houeiss wrote: >> looking to start the deployment of ipv6 only network for a new part in my >> network , i need to have info about wish solution will be the best to be >> used for NAT64 techniques for new ipv6 only end users will be able to reach >> ipv4 different services and web servers on the web. > > As far as I know most network vendors (Cisco, Juniper etc) support > NAT64 on their equipment. > However don't forget that you'd need DNS64 as well, so I'd suggest to > check if the DNS solution you are using currently supports DNS64. > > From my experience the main issue is not choosing a vendor for NAT64 > but dealing with broken applications: > - applications which assume than "no IPv4 address" means "no Internet > connectivity" and not even trying to establish any connections if the > device does not receive Ipv4 address; > - applications which are using IPv4 literals; > - applications which ask for "A" DNS RR only, so DNS64 does not help > etc. > >> looking forward for your reply, > > BTW I'm removing ipv-wg-chairs@ (as it is just an alias which is used > to reach RIPE IPv6 Working group chairs) and adding RIPE IPv6 mailing > list. > From mir at ripe.net Fri Sep 25 12:37:44 2015 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 25 Sep 2015 12:37:44 +0200 Subject: [ipv6-wg] New on RIPE Labs: IPv6 on the March Message-ID: <560523F8.2060509@ripe.net> Dear colleagues, In this new RIPE Labs article Tony Smith from APNIC is looking at the increase in IPv6 deployment now ARIN has depleted their free pool of IPv4 addresses: https://labs.ripe.net/Members/mirjam/ipv6-on-the-march Kind regards, Mirjam Kuehne RIPE NCC