From dez at otenet.gr Sun May 3 19:56:19 2015 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Sun, 03 May 2015 20:56:19 +0300 Subject: [ipv6-wg] Chair replacement procedure for ipv6-wg In-Reply-To: <5541E395.5070003@heanet.ie> References: <5540DC92.30909@heanet.ie> <5541DA22.7090104@iszt.hu> <5541E395.5070003@heanet.ie> Message-ID: <55466143.3070108@otenet.gr> On 04/30/2015 11:11 AM, Dave Wilson wrote: > > For clarity, here's the text again with the introduction so edited. > > Best regards, > Dave seems fine to me :) From training at ripe.net Mon May 11 09:59:26 2015 From: training at ripe.net (Training Services) Date: Mon, 11 May 2015 09:59:26 +0200 Subject: [ipv6-wg] [training] RIPE NCC Training Courses July-September 2015 Message-ID: <5550615E.4010705@ripe.net> Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Frankfurt, London, Skopje, Stockholm, Minsk, Sarajevo, Vladivostok, Tel Aviv, Tallinn, Zurich, Paris, Amsterdam. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - Database Training Course - Basic IPv6 Training Course - 2 day Advanced Training Course - Routing Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager From furry13 at gmail.com Mon May 11 13:46:21 2015 From: furry13 at gmail.com (Jen Linkova) Date: Mon, 11 May 2015 13:46:21 +0200 Subject: [ipv6-wg] IPv6-only network at RIPE70 Message-ID: I'm glad to announce that there is a IPv6-only (with NAT64) network at RIPE70. Please note that this experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team and is offered on a best-effort basis. How to connect: - Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort Please note that NAT64&DNS64 is used to provide connectivity to IPv4-only resources, so use DNS servers information provided by the network. If you see any connectivity issues: - connect to the 'normal' dual-stack one; - if connecting to dual-stack network solves the issue, please email me (furry13 at gmail.com) with details, I'd love to know about any problems. General feedback (do you guys see any value in such an experiment, what was your experience etc) is appreciated. -- SY, Jen Linkova aka Furry From furry13 at gmail.com Mon May 11 14:41:42 2015 From: furry13 at gmail.com (Jen Linkova) Date: Mon, 11 May 2015 14:41:42 +0200 Subject: [ipv6-wg] IPv6-only network at RIPE70 In-Reply-To: References: Message-ID: Sorry, a very important part was missed in my email: Big thanks to Cisco Systems (Eric Vynce, Steve Simlo and Andrew Yourtchenko in particular) for providing with NAT64 solution and to RIPE NCC for building this network and proving that IPv6 does work! IPv6-only network @RIPE would have never happened without their help! My apologies for not mentioning this in my email in the first place. On Mon, May 11, 2015 at 1:46 PM, Jen Linkova wrote: > I'm glad to announce that there is a IPv6-only (with NAT64) network at RIPE70. > > Please note that this experimental network is not supported by the > RIPE NCC or RIPE 67 Technical Team and is offered on a best-effort > basis. > > How to connect: > > - Make sure IPv6 is enabled on your device > - Connect to SSID: IPV6ONLYEXP > - Enter the password: iknowbesteffort > > Please note that NAT64&DNS64 is used to provide connectivity to > IPv4-only resources, so use DNS servers information provided by the > network. > > If you see any connectivity issues: > - connect to the 'normal' dual-stack one; > - if connecting to dual-stack network solves the issue, please email > me (furry13 at gmail.com) with details, I'd love to know about any > problems. > > General feedback (do you guys see any value in such an experiment, > what was your experience etc) is appreciated. > > -- > SY, Jen Linkova aka Furry -- SY, Jen Linkova aka Furry From jerome at fleury.net Tue May 12 14:50:28 2015 From: jerome at fleury.net (=?UTF-8?B?SsOpcsO0bWUgRmxldXJ5?=) Date: Tue, 12 May 2015 05:50:28 -0700 Subject: [ipv6-wg] IPv6-only network at RIPE70 In-Reply-To: References: Message-ID: I suspect Dropbox to hardcode their IP in their application. It's not working at all on ipv6-only. On the contrary, I'm pleasantly surprised to see that Cisco DTLS VPN works over NAT64. Thanks for giving us a sandbox, that is really interesting. On Mon, May 11, 2015 at 5:41 AM, Jen Linkova wrote: > Sorry, a very important part was missed in my email: > > Big thanks to Cisco Systems (Eric Vynce, Steve Simlo and Andrew > Yourtchenko in particular) for providing with NAT64 solution and to > RIPE NCC for building this network and proving that IPv6 does work! > IPv6-only network @RIPE would have never happened without their help! > > My apologies for not mentioning this in my email in the first place. > > On Mon, May 11, 2015 at 1:46 PM, Jen Linkova wrote: >> I'm glad to announce that there is a IPv6-only (with NAT64) network at RIPE70. >> >> Please note that this experimental network is not supported by the >> RIPE NCC or RIPE 67 Technical Team and is offered on a best-effort >> basis. >> >> How to connect: >> >> - Make sure IPv6 is enabled on your device >> - Connect to SSID: IPV6ONLYEXP >> - Enter the password: iknowbesteffort >> >> Please note that NAT64&DNS64 is used to provide connectivity to >> IPv4-only resources, so use DNS servers information provided by the >> network. >> >> If you see any connectivity issues: >> - connect to the 'normal' dual-stack one; >> - if connecting to dual-stack network solves the issue, please email >> me (furry13 at gmail.com) with details, I'd love to know about any >> problems. >> >> General feedback (do you guys see any value in such an experiment, >> what was your experience etc) is appreciated. >> >> -- >> SY, Jen Linkova aka Furry > > > > -- > SY, Jen Linkova aka Furry > From furry13 at gmail.com Tue May 12 15:00:54 2015 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 12 May 2015 15:00:54 +0200 Subject: [ipv6-wg] IPv6-only network at RIPE70 In-Reply-To: References: Message-ID: On Tue, May 12, 2015 at 2:50 PM, J?r?me Fleury wrote: > I suspect Dropbox to hardcode their IP in their application. It's not > working at all on ipv6-only. Yeah, looks like that: furry at Wintermute:~>sudo tcpdump -i en0 -s 1500 -n 'net 64:ff9b::6ca0:0/120 or net 108.160.172.0/24' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type EN10MB (Ethernet), capture size 1500 bytes 14:59:48.934365 ARP, Request who-has 108.160.172.193 tell 169.254.64.90, length 28 14:59:49.323255 ARP, Request who-has 108.160.172.204 tell 169.254.64.90, length 28 14:59:50.019231 ARP, Request who-has 108.160.172.193 tell 169.254.64.90, length 28 14:59:50.420251 ARP, Request who-has 108.160.172.204 tell 169.254.64.90, length 28 I'll follow up on this... > On the contrary, I'm pleasantly surprised to see that Cisco DTLS VPN > works over NAT64. > > Thanks for giving us a sandbox, that is really interesting. Great to know, thanks for the feedback! > > > On Mon, May 11, 2015 at 5:41 AM, Jen Linkova wrote: >> Sorry, a very important part was missed in my email: >> >> Big thanks to Cisco Systems (Eric Vynce, Steve Simlo and Andrew >> Yourtchenko in particular) for providing with NAT64 solution and to >> RIPE NCC for building this network and proving that IPv6 does work! >> IPv6-only network @RIPE would have never happened without their help! >> >> My apologies for not mentioning this in my email in the first place. >> >> On Mon, May 11, 2015 at 1:46 PM, Jen Linkova wrote: >>> I'm glad to announce that there is a IPv6-only (with NAT64) network at RIPE70. >>> >>> Please note that this experimental network is not supported by the >>> RIPE NCC or RIPE 67 Technical Team and is offered on a best-effort >>> basis. >>> >>> How to connect: >>> >>> - Make sure IPv6 is enabled on your device >>> - Connect to SSID: IPV6ONLYEXP >>> - Enter the password: iknowbesteffort >>> >>> Please note that NAT64&DNS64 is used to provide connectivity to >>> IPv4-only resources, so use DNS servers information provided by the >>> network. >>> >>> If you see any connectivity issues: >>> - connect to the 'normal' dual-stack one; >>> - if connecting to dual-stack network solves the issue, please email >>> me (furry13 at gmail.com) with details, I'd love to know about any >>> problems. >>> >>> General feedback (do you guys see any value in such an experiment, >>> what was your experience etc) is appreciated. >>> >>> -- >>> SY, Jen Linkova aka Furry >> >> >> >> -- >> SY, Jen Linkova aka Furry >> -- SY, Jen Linkova aka Furry From furry13 at gmail.com Tue May 12 15:03:31 2015 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 12 May 2015 15:03:31 +0200 Subject: [ipv6-wg] IPv6-only network at RIPE70 In-Reply-To: References: Message-ID: On Tue, May 12, 2015 at 3:00 PM, Jen Linkova wrote: > On Tue, May 12, 2015 at 2:50 PM, J?r?me Fleury wrote: >> I suspect Dropbox to hardcode their IP in their application. It's not >> working at all on ipv6-only. > > Yeah, looks like that: > > furry at Wintermute:~>sudo tcpdump -i en0 -s 1500 -n 'net > 64:ff9b::6ca0:0/120 or net 108.160.172.0/24' > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on en0, link-type EN10MB (Ethernet), capture size 1500 bytes > 14:59:48.934365 ARP, Request who-has 108.160.172.193 tell > 169.254.64.90, length 28 > 14:59:49.323255 ARP, Request who-has 108.160.172.204 tell > 169.254.64.90, length 28 > 14:59:50.019231 ARP, Request who-has 108.160.172.193 tell > 169.254.64.90, length 28 > 14:59:50.420251 ARP, Request who-has 108.160.172.204 tell > 169.254.64.90, length 28 Seems to be a know issue: https://www.dropboxforum.com/hc/communities/public/questions/203283805-IPv6-Support- "After checking in with our engineering team, unfortunately we can't commit to a timeline for IPv6 access right now. " However I do see some difference between 'not support v6' and 'hardcode v4 addresses' ;-\ -- SY, Jen Linkova aka Furry From furry13 at gmail.com Tue May 12 15:14:06 2015 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 12 May 2015 15:14:06 +0200 Subject: [ipv6-wg] IPv6-only network at RIPE70 In-Reply-To: References: Message-ID: On Tue, May 12, 2015 at 2:50 PM, J?r?me Fleury wrote: > I suspect Dropbox to hardcode their IP in their application. It's not > working at all on ipv6-only. Heh, they are not hardcoding anything, they are just not consistent: 1) asking for AAAA for client.v.dropbox.com 15:10:32.233655 IP6 2001:67c:64:49:4c02:64ed:71e7:a16.62668 > nat64-ubuntu.ripemtg.ripe.net.domain: 54028+ AAAA? client.v.dropbox.com. (38) 15:10:32.234425 IP6 2001:67c:64:49:4c02:64ed:71e7:a16.58556 > nat64-ubuntu.ripemtg.ripe.net.domain: 28552+ AAAA? d.dropbox.com. (31) 15:10:32.270841 IP6 nat64-ubuntu.ripemtg.ripe.net.domain > 2001:67c:64:49:4c02:64ed:71e7:a16.58556: 28552 3/4/0 CNAME d.v.dropbox.com., AAAA 64:ff9b::6ca0:ace1, AAAA 64:ff9b::6ca0:acc1 (241) 15:10:32.279229 IP6 nat64-ubuntu.ripemtg.ripe.net.domain > 2001:67c:64:49:4c02:64ed:71e7:a16.62668: 54028 2/4/0 AAAA 64:ff9b::6ca0:accc, AAAA 64:ff9b::6ca0:acec (230) 2) but then asking for A only: 15:10:32.643915 IP6 2001:67c:64:49:4c02:64ed:71e7:a16.51052 > nat64-ubuntu.ripemtg.ripe.net.domain: 42675+ A? d.v.dropbox.com. (33) 15:10:32.647198 IP6 nat64-ubuntu.ripemtg.ripe.net.domain > 2001:67c:64:49:4c02:64ed:71e7:a16.51052: 42675 2/4/0 A 108.160.172.193, A 108.160.172.225 (201) 15:10:32.650615 ARP, Request who-has d.v.dropbox.com tell 169.254.64.90, length 28 -- SY, Jen Linkova aka Furry From lists at quux.de Wed May 13 17:36:42 2015 From: lists at quux.de (Jens Link) Date: Wed, 13 May 2015 17:36:42 +0200 Subject: [ipv6-wg] IPv6-only network at RIPE70 In-Reply-To: (Jen Linkova's message of "Mon, 11 May 2015 13:46:21 +0200") References: Message-ID: <87iobw4hh1.fsf@pc8.berlin.quux.de> Jen Linkova writes: > If you see any connectivity issues: > - connect to the 'normal' dual-stack one; > - if connecting to dual-stack network solves the issue, please email > me (furry13 at gmail.com) with details, I'd love to know about any > problems. And some more content for http://wiki.test-ipv6.com would be good. "This site contains information on what has been tested in IPv6 environments. Most notably, things that work or fail in the IPv6 single-stack environment, or in environments such as NAT64/DNS64 or XLAT464." Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at jabber.quux.de | --------------- | ---------------------------------------------------------------------------- From jan at go6.si Thu May 14 17:41:01 2015 From: jan at go6.si (Jan Zorz) Date: Thu, 14 May 2015 17:41:01 +0200 Subject: [ipv6-wg] Link to publicly available DNS64/NAT64 implementations Message-ID: <5554C20D.1060006@go6.si> Dear IPv6 WG, As promised during the IPv6 WG meeting at RIPE70, I'm sending the link with information how to test remotely different implementations of NAT64 that we are running in Go6lab: http://go6lab.si/current-ipv6-tests/nat64dns64-public-test/ Ecdysis is the weakest one and somehow a bit buggy, so please use the PAN and C1000 ones, that are dedicated boxes for this test and *will* handle the traffic and translation process ;) Cheers, Jan Zorz From erey at ernw.de Thu May 14 18:05:15 2015 From: erey at ernw.de (Enno Rey) Date: Thu, 14 May 2015 18:05:15 +0200 Subject: [ipv6-wg] NAT64 Config on Cisco in Conference WLAN In-Reply-To: <5554C20D.1060006@go6.si> References: <5554C20D.1060006@go6.si> Message-ID: <20150514160515.GA45460@ernw.de> Hi, as someone from the audience asked during the session - we had a (probably very similar, Andrew Yourtchenko inspired) v6-only SSID recently at the IPv6 Security Summit. Details incl. the relevant config snippets can be found at: https://www.troopers.de/media/filer_public/66/b2/66b2da26-c2d1-4478-8890-2cd8484a2c58/tr15_ipv6_security_summit_ipv6_guest_wlan_v10.pdf thanks Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From marc.blanchet at viagenie.ca Thu May 14 18:03:07 2015 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Thu, 14 May 2015 12:03:07 -0400 Subject: [ipv6-wg] Link to publicly available DNS64/NAT64 implementations In-Reply-To: <5554C20D.1060006@go6.si> References: <5554C20D.1060006@go6.si> Message-ID: On 14 May 2015, at 11:41, Jan Zorz wrote: > Dear IPv6 WG, > > As promised during the IPv6 WG meeting at RIPE70, I'm sending the link > with information how to test remotely different implementations of > NAT64 that we are running in Go6lab: > > http://go6lab.si/current-ipv6-tests/nat64dns64-public-test/ > > Ecdysis is the weakest one and somehow a bit buggy, why is it? FYI, Ecdysis has been integrated into OpenBSD pf and is now part of the OpenBSD bistro. That version is more stable. So I would suggest to use an openbsd platform to do testing and get best results (compared to the linux one). Marc. > so please use the PAN and C1000 ones, that are dedicated boxes for > this test and *will* handle the traffic and translation process ;) > > Cheers, Jan Zorz From woeber at cc.univie.ac.at Thu May 14 22:35:30 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Thu, 14 May 2015 22:35:30 +0200 Subject: [ipv6-wg] Fwd: Re: IPv6-only network at RIPE70 In-Reply-To: <55546FCF.3060809@cc.univie.ac.at> References: <55546FCF.3060809@cc.univie.ac.at> Message-ID: <55550712.3060506@cc.univie.ac.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forgot to also include the wg mail list. sorry. Here you go, Wilfried. - -------- Forwarded Message -------- Subject: Re: [ipv6-wg] IPv6-only network at RIPE70 Date: Thu, 14 May 2015 11:50:07 +0200 From: Wilfried Woeber To: Jen Linkova Hi Jen, v6-folks, > General feedback (do you guys see any value in such an experiment, > what was your experience etc) is appreciated. I was on this network while doing stuff after yesterday's key signing party, and it simply works, to fetch keys from servers and to upload. Just a minor thing and not too important for the "masses", but still thumbs-up :-) Wilfried -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVVQcKAAoJEPMGt0I/M2zSbX4P+waEJREbW9GoozrhpZov584V lKG5PKQGDRmLLvroF95Xr/KCKSMVwkOeE1Sizelh6uJXYkbnNpCCMifSg495SQY1 Oug/v0f6trhv03FpmQIKtpy2Jj9A3Vz6SislNbGFuvCB0T6LwV8vH1SKmGUdBeKX UoA8VfymQ6PGTOe2JsbIc6r3mdIhw9vjUeXYvoshEcItYmDYjrkXEELEO+YLpv88 8InaUVtlS1x5GR5M7DTaFhCjBaUPlEt9HXBk0BBg/6E+xXwaOU8JbtKq4yiifRH8 EjIEjsl77NGuhtlVPuUDmdq+pZ+Lgx9Sf1s0w7qOhQPxQI18EvnbqR0gVMZT0XGg PZjMt3W4AhktjXcwnS0bctCC+fdWYDK4YoxxhT9m9use94mj76Qk7BNMqyGKNJgF R9MFwps5pvVzykpoL0kHiIrfeN09EWMzjNTu+N5xUzu5KF4N3W431aYqsg4bFB64 mEbfzXbI7UBx7PYfCoGIvWwX+9Z4SM7MoO+FtZv/Bo/nXBP1X9nml2H3w0xYf7+R 2rOTciNesi9u1Mp0HCh6q0IUrijviw0QgdR7+fHYw7MDSbHmYaCO2ZGGDI8AVKjR aTf6Y6JZTr/WcH+nC18/Ix8gX88p8HfJT2bAsHVvmsAc5kzXxjlbklDFxMjYjV6i TaC7zIrY992Wt5ZXXFJc =FBOo -----END PGP SIGNATURE----- From jerome at fleury.net Fri May 15 00:21:08 2015 From: jerome at fleury.net (=?UTF-8?B?SsOpcsO0bWUgRmxldXJ5?=) Date: Fri, 15 May 2015 00:21:08 +0200 Subject: [ipv6-wg] IPv6 only as default for next meeting Message-ID: During WG this afternoon, the idea was submitted that the IPv6 only experimentation be made the default SSID for the next meeting. While this has been working tremendously well for routine internet usage, I've been unable to use this network mainly because of incompatibility with my VPN network. We have a dual-stack VPN. some of the resources are v4 only though. The DNS64 converts my v4 VPN resources into v6 resources that are then routed to the non-VPN interface. While there could be workarounds (DNS64 on the VPN side, full v6 routing on the VPN, or all VPN resources available on v6) I don't think the technology is mature enough to make it the default for advanced usage. My 0.02$ From tore at fud.no Fri May 15 00:06:38 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 15 May 2015 00:06:38 +0200 Subject: [ipv6-wg] Link to publicly available DNS64/NAT64 implementations In-Reply-To: References: <5554C20D.1060006@go6.si> Message-ID: <20150515000638.16190042@envy.fud.no> * Marc Blanchet > On 14 May 2015, at 11:41, Jan Zorz wrote: > > > Dear IPv6 WG, > > > > As promised during the IPv6 WG meeting at RIPE70, I'm sending the > > link with information how to test remotely different > > implementations of NAT64 that we are running in Go6lab: > > > > http://go6lab.si/current-ipv6-tests/nat64dns64-public-test/ > > > > Ecdysis is the weakest one and somehow a bit buggy, > > why is it? > > FYI, Ecdysis has been integrated into OpenBSD pf and is now part of > the OpenBSD bistro. That version is more stable. So I would suggest > to use an openbsd platform to do testing and get best results > (compared to the linux one). Or, if there is a desire to run the implementation Linux in the first place, I'd suggest Jool (http://jool.mx), which is actively maintained. BTW all the NAT64 prefixes given on the page are incorrect, at least if the ping6 test targets given are correct the NAT64 prefixes are all /96es, not /64s. Tore From marc.blanchet at viagenie.ca Fri May 15 00:43:04 2015 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Thu, 14 May 2015 18:43:04 -0400 Subject: [ipv6-wg] IPv6 only as default for next meeting In-Reply-To: References: Message-ID: On 14 May 2015, at 18:21, J?r?me Fleury wrote: > During WG this afternoon, the idea was submitted that the IPv6 only > experimentation be made the default SSID for the next meeting. > > While this has been working tremendously well for routine internet > usage, I've been unable to use this network mainly because of > incompatibility with my VPN network. > > We have a dual-stack VPN. some of the resources are v4 only though. > The DNS64 converts my v4 VPN resources into v6 resources that are then > routed to the non-VPN interface. While there could be workarounds > (DNS64 on the VPN side, full v6 routing on the VPN, or all VPN > resources available on v6) I don't think the technology is mature > enough I think the technology (v6only-nat64-dns64) is mature enough. The problem is that various applications and services are not compatible with it (usually IPv4 addresses negotiated in the payload) I know it is a variation, but what I?m trying to say is that if we can push more and more to have applications/services ipv6-ready, then that issue will just disappear. Marc. > to make it the default for advanced usage. > > My 0.02$ From bs at stepladder-it.com Fri May 15 11:25:27 2015 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Fri, 15 May 2015 09:25:27 +0000 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar (was: Re: IPv6 only as default for next meeting) In-Reply-To: (Marc Blanchet's message of "Thu, 14 May 2015 18:43:04 -0400") References: Message-ID: <87a8x6ry48.fsf_-_@stepladder-it.com> Hi folks, this is admittedly a pet peeve of mine, so apologies right in advance to anybody getting offended by this, but I'd like to rephrase "Marc Blanchet" writes: > I think the technology (v6only-nat64-dns64) is mature enough. The > problem is that various applications and services are not compatible > with it (usually IPv4 addresses negotiated in the payload) as this: I think the technology (v6only-nat64-dns64) is inherently broken by design. By design it doesn't support a range of important and widely used existing applications and services that it should be compatible with to be considered "working". With NAT, NAT64 or whatever other application unaware translation hack being around, a lot of extra complexity is pushed towards the application layer. NAT* doesn't solve any problems, it just puts the burden on others who is unlikely in a situation to defend themselves (the app. developers) ; the overall effect is counterproductive. Aside from that, once we talk not full-blown computers but embedded devices, adding support for NAT penetration (STUN or whatever) is a major problem. The original Arduino uses a microcontroller with 32KB of flash (for program code) and 2KB of RAM, and that's already a fairly big one. Adding STUN support there is a serious problem. Again, this isn't meant as a flame or anything, but to show that these technologies have serious implications for others. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ From erey at ernw.de Fri May 15 12:54:06 2015 From: erey at ernw.de (Enno Rey) Date: Fri, 15 May 2015 12:54:06 +0200 Subject: [ipv6-wg] Extension Headers / Impact on Security Devices Message-ID: <20150515105406.GA3028@ernw.de> Hi, hope everybody had a great #RIPE70 meeting. We did! Many thanks to the organizers and chairs! With regard to the strong position on ext hdrs that I expressed in the session yesterday pls allow to add some material/sources: - this is a paper laying out how we could circumvent some major (both commercial and FOSS) IDPS solutions in their at the time of testing latest versions, by various combinations of extension headers and fragmentation: https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf. - here's some thoughts and preliminary results of tests performed to circumvent stateless ACLs: http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/. http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/. We have a (somewhat) ongoing research project looking more closely on the interaction of ACLs and extension headers. For the moment I can only state that it's not just Cisco who are "affected". More results will be available in some months. If the chairs consider this appropriate we will happily give a presentation on this stuff in Bucharest or at another occasion. We could even bring some devices to Bucharest to do some practical testing and demos "in some side room" during #RIPE71, for those interested. We can even do the latter without any official part in a session, if there's interest. As for the topic itself I'd like to summarize our position as follows: - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic. - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case. - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered this thesis. one can probably find much more issues provided time & resources). Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case. - the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown). - now that "this vicious circle" has gained sufficient ground it will be even less incentivized to develop a compelling use case. which is why we do not expect to see one in the future. === Everybody have a great weekend and for those still in AMS: have a safe trip home! Best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From dave.wilson at heanet.ie Fri May 15 13:22:55 2015 From: dave.wilson at heanet.ie (Dave Wilson) Date: Fri, 15 May 2015 13:22:55 +0200 Subject: [ipv6-wg] Chair replacement procedure for ipv6-wg In-Reply-To: <5541E395.5070003@heanet.ie> References: <5540DC92.30909@heanet.ie> <5541DA22.7090104@iszt.hu> <5541E395.5070003@heanet.ie> Message-ID: <5555D70F.5060304@heanet.ie> Hi all, Since there was positive feedback and no objections on the list, and no objections in the meeting, I'm happy to say that we've adopted this procedure. Best regards, Dave > ===(cut here)=== > Note on Language: Throughout this document the word Chair shall be used > for both Chairs and Co-Chairs. > > ** Introduction: > > This document outlines procedures dealing with the tenure of IPv6 RIPE > Working Group Chairs. > > ** WG Chair Term: > > The term of a WG Chair is three years. A current chair may stand for > re-selection at the end of their term. A WG Chair may resign > voluntarily at any time. > > ** Selection of a WG Chair: > > WG Chair vacancies, along with a call for candidates, must be announced > on the WG mailing list at least one month in advance of the date upon > which the selection will be held. The announcement should set a closing > date for candidates. A WG may request that a WG Chair vacancy be opened > so long as the addition of a new Chair would not cause the number of > Chairs of that WG to exceed three. > > WG Chairs are elected at WG sessions at RIPE meetings. Anyone physically > present at the WG session is eligible to participate in the selection > process. The candidate does not need to be physically present at the WG > session. > > If possible the Chair should be elected by acclamation by the WG or by > consensus after discussion. If the result is unclear, then a secret > ballot should be held. In the case of a ballot, votes will be counted by > RIPE NCC Staff and/or Chairs of other WGs. The result will be determined > by simple majority. > > ** Removal of a WG Chair: > > A WG Chair may be unable to fulfil their duties as described in this > document or otherwise fail to serve the WG and the community. With the > endorsement of a significant share of the WG, a vote of no confidence > may be initiated. > > Before a vote of no confidence is taken, due effort should be made to > address the issue(s) leading to the vote. The right of reply must be > given to all parties involved in the procedure. If this effort fails to > resolve the issue, the vote may proceed. > > The vote must be requested on the WG mailing list at least one week in > advance of the WG Session at a RIPE meeting and should take place during > the WG session. Anyone physically present at the WG session may take > part in the vote. The vote should be conducted by secret ballot and > votes counted by RIPE NCC Staff and/or WG Chairs of other WGs. The > result will be determined by simple majority. If the vote of no > confidence in a WG Chair is passed, the seat is vacated and the WG Chair > is not eligible for stand for re-selection. > > ** No Chair: > > If a working group is left with no Chair, e.g. due to the resignation or > removal of the sole WG Chair, then the WG may elect an interim WG Chair > according to the selection procedures specified above, but with > candidates nominated at the WG session. An interim WG Chair must resign > at the next WG session, but may stand for re-selection. > > ** Staggered Introduction: > > For the purposes of staggering the introduction of this policy, in the > case where all co-Chairs of a WG have served for more than the standard > WG Chair term limit, an optional waiver is given to these WGs to allow > them to schedule the automatic resignations of their Chairs over the two > RIPE meetings immediately following the adoption of this policy. If the > WG decides to avail of this waiver, it is the responsibility of the WG > to decide in what order its co-Chairs should stand down. > ===(cut here)=== > > > -- Dave Wilson, Project Manager web: www.heanet.ie HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 Registered in Ireland, no 275301 fax: +353-1-660-3666 From silvia.hagen at sunny.ch Fri May 15 13:38:21 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Fri, 15 May 2015 11:38:21 +0000 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar (was: Re: IPv6 only as default for next meeting) In-Reply-To: <87a8x6ry48.fsf_-_@stepladder-it.com> References: <87a8x6ry48.fsf_-_@stepladder-it.com> Message-ID: Hi Benedikt But in combination with 464XLAT it seems to do the job well enough to support millions of IPv6-only users for T-Mobile. And thereby allows them to deploy v6-only at the edge, where address consumption is highest. So maybe it would be good to differentiate a bit more and not throw out the baby with the bathwater. Silvia -----Urspr?ngliche Nachricht----- Von: ipv6-wg [mailto:ipv6-wg-bounces at ripe.net] Im Auftrag von Benedikt Stockebrand Gesendet: Freitag, 15. Mai 2015 11:25 An: ipv6-wg at ripe.net IPv6 Betreff: [ipv6-wg] Implications of NAT/NAT64 and similar (was: Re: IPv6 only as default for next meeting) Hi folks, this is admittedly a pet peeve of mine, so apologies right in advance to anybody getting offended by this, but I'd like to rephrase "Marc Blanchet" writes: > I think the technology (v6only-nat64-dns64) is mature enough. The > problem is that various applications and services are not compatible > with it (usually IPv4 addresses negotiated in the payload) as this: I think the technology (v6only-nat64-dns64) is inherently broken by design. By design it doesn't support a range of important and widely used existing applications and services that it should be compatible with to be considered "working". With NAT, NAT64 or whatever other application unaware translation hack being around, a lot of extra complexity is pushed towards the application layer. NAT* doesn't solve any problems, it just puts the burden on others who is unlikely in a situation to defend themselves (the app. developers) ; the overall effect is counterproductive. Aside from that, once we talk not full-blown computers but embedded devices, adding support for NAT penetration (STUN or whatever) is a major problem. The original Arduino uses a microcontroller with 32KB of flash (for program code) and 2KB of RAM, and that's already a fairly big one. Adding STUN support there is a serious problem. Again, this isn't meant as a flame or anything, but to show that these technologies have serious implications for others. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ From akaratepe at turksat.com.tr Fri May 15 13:49:56 2015 From: akaratepe at turksat.com.tr (Adem Karatepe) Date: Fri, 15 May 2015 11:49:56 +0000 Subject: [ipv6-wg] How to Unsubscribe!? Message-ID: <9DD8016F9C901D45890E9649A95451F089565248@EXCMBX02.turksat.local> Hi folks, I used to work in IPV6 work group before in my company and my colleague add me to this list but I'm not working on this group anymore and my colleague resigned from company so we don't have login details and we can not unsubscribe from the mail list. Is there any other way to unsubscribe? Adem Karatepe BT Proje Asistan? Project Support Staff Yaz?l?m Geli?tirme Direkt?rl??? Software Development www.turksat.com.tr akaratepe at turksat.com.tr Gazi ?niversitesi G?lba?? Yerle?kesi Teknoparkplaza kat 2 06830 G?lba??/ANKARA T : +90 312 497 47 00 F : +90 "Bu mesaj ve ekleri mesajda g?nderildi?i belirtilen ki?i ya da ki?ilere ?zel olup gizli bilgiler i?eriyor olabilir. Mesaj?n muhatab? ilgilisi ya da g?nderileni de?ilseniz l?tfen mesaj? herhangi bir ?ekilde kullanmay?n?z ?o?altmay?n?z ve ba?kalar?na if?a etmeyiniz. E?er mesaj yanl??l?kla size ula?m??sa an?lan mesaj ve ekinde yer alan bilgileri gizli tutunuz ve mesaj? g?nderen ki?iyi bilgilendirerek s?z konusu mesaj ile eklerini derhal imha ediniz. Bu mesaj ve ekindeki belgelerin bilinen vir?slere kar?? kontrol? yap?lm??t?r. Ancak e-posta sistemlerinin ta??d??? risklerden dolay? ?irketimiz bu mesaj?n ve i?erdi?i bilgilerin size de?i?ikli?e u?rayarak veya ge? ula?mas?ndan b?t?nl???n?n ve gizlili?inin korunamamas?ndan vir?s i?ermesinden ve herhangi bir sebeple bilgisayar?n?za ve sisteminize verebilece?i zararlardan sorumlu tutulamaz.?<<<<< ?This message together with its attachments is intended solely for the address(es) and may contain confidential or privileged information. If you are not the intended recipient please do not use copy or disclose the message for any purpose. Should you receive this message by mistake please keep all information contained in the message or its attachments strictly confidential and advise the sender and delete it immediately without retaining a copy. This message and its attachments have been swept by anti-virus systems for the presence of known viruses. However due to the risks of e-mail systems our company cannot accept liability for any changes or delay in receiving loss of integrity and confidentiality containing viruses and any damages caused in any way to your computer and system recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited. ? From ripe-wgs at radu-adrian.feurdean.net Fri May 15 14:36:23 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 15 May 2015 14:36:23 +0200 Subject: [ipv6-wg] IPv6 only as default for next meeting In-Reply-To: References: Message-ID: <1431693383.3190459.269583297.1AA78EA5@webmail.messagingengine.com> On Fri, May 15, 2015, at 00:21, J?r?me Fleury wrote: > During WG this afternoon, the idea was submitted that the IPv6 only > experimentation be made the default SSID for the next meeting. > > While this has been working tremendously well for routine internet > usage, I've been unable to use this network mainly because of > incompatibility with my VPN network. Hi Jerome, The VPN clients (almost all of them) are actually changing your host from a IPv6-only one to a dual-stacked one. The "split DNS" feature is supposed to solve (or at least alleviate) the problem if available and enabled. A somehow similar situation (IPv6 only device turned dual-stack) arises when you use your mobile phone on the v6-only network, with mobile data still turned on.The problem in that set-up is that you are not able to see misbehaving applications, since they may be using the 3G/4G interface to communicate using IPv4. I've seen this happening with Lollipop (Kitekat was not working at all on v6-only network). Does somebody have any idea about the exact situation in Apple/iOS-land ? From dwing at cisco.com Fri May 15 21:26:22 2015 From: dwing at cisco.com (=?utf-8?Q?=F0=9F=94=93Dan_Wing?=) Date: Fri, 15 May 2015 12:26:22 -0700 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar (was: Re: IPv6 only as default for next meeting) In-Reply-To: <87a8x6ry48.fsf_-_@stepladder-it.com> References: <87a8x6ry48.fsf_-_@stepladder-it.com> Message-ID: <746CB974-9A51-47B1-B009-51CB6239AD7D@cisco.com> On 15-May-2015 02:25 am, Benedikt Stockebrand wrote: > > Hi folks, > > this is admittedly a pet peeve of mine, so apologies right in advance > to anybody getting offended by this, but I'd like to rephrase > > "Marc Blanchet" writes: > >> I think the technology (v6only-nat64-dns64) is mature enough. The >> problem is that various applications and services are not compatible >> with it (usually IPv4 addresses negotiated in the payload) > > as this: > > I think the technology (v6only-nat64-dns64) is inherently broken by > design. By design it doesn't support a range of important and > widely used existing applications and services that it should be > compatible with to be considered "working". > > With NAT, NAT64 or whatever other application unaware translation hack > being around, a lot of extra complexity is pushed towards the > application layer. NAT* doesn't solve any problems, it just puts the > burden on others who is unlikely in a situation to defend themselves > (the app. developers) ; the overall effect is counterproductive. > > Aside from that, once we talk not full-blown computers but embedded > devices, adding support for NAT penetration (STUN or whatever) is a > major problem. The original Arduino uses a microcontroller with 32KB > of flash (for program code) and 2KB of RAM, and that's already a fairly > big one. Adding STUN support there is a serious problem. > > > Again, this isn't meant as a flame or anything, but to show that > these technologies have serious implications for others. To avoid some of that, they can go IPv6-only, including their servers and all peers they communicate with, then there doesn't need to be NAT64 for their traffic. But even IPv6-only they will need firewall traversal support, as firewalls by default will block unsolicited incoming traffic (RFC6092). -d From bs at stepladder-it.com Sun May 17 18:39:10 2015 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sun, 17 May 2015 16:39:10 +0000 Subject: [ipv6-wg] Extension Headers / Impact on Security Devices In-Reply-To: <20150515105406.GA3028@ernw.de> (Enno Rey's message of "Fri, 15 May 2015 12:54:06 +0200") References: <20150515105406.GA3028@ernw.de> Message-ID: <87siav2m6p.fsf@stepladder-it.com> Hi Enno and list, Enno Rey writes: > hope everybody had a great #RIPE70 meeting. We did! > Many thanks to the organizers and chairs! and thanks to the actual speakers as well the speakers we had to turn down due to time constraints, too:-) > If the chairs consider this appropriate we will happily give a > presentation on this stuff in Bucharest or at another occasion. Sounds good to me! > - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > their number, order[...] Actually, as far as I'm concerned that's the real core of the problem. Or more specifically, the first two lines of RFC 2460, section 4.1: When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: followed on the next page by Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). Note in particular that these are not even RFC 2119 "SHOULD" or "RECOMMENDED" and such. The impact here is actually at least twofold: - It is impossible to implement this as a simple pipeline architecture in hardware; at least for cases deviating from the "recommendations" above this effectively becomes either excessively complex to implement in hardware or an invitation to DoS when implemented in software on an otherwise hardware router. - As I understand it, at least some of the issues you have found are effectively based on violating the second paragraph quoted, making it impossible to come up with a lower bound on how long the header chain can actually get and therefore leading to the fragmentation related attacks and similar you have discovered. The original idea was that the extension headers are processed strictly in the order they occur, so one question to ask is if there is any valid reason to violate these "recommendations" for other than malicious purposes. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ From bs at stepladder-it.com Sun May 17 18:49:29 2015 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sun, 17 May 2015 16:49:29 +0000 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar In-Reply-To: (Silvia Hagen's message of "Fri, 15 May 2015 11:38:21 +0000") References: <87a8x6ry48.fsf_-_@stepladder-it.com> Message-ID: <87mw132lpi.fsf@stepladder-it.com> Hi Silvia and list, Silvia Hagen writes: > Hi Benedikt > > But in combination with 464XLAT it seems to do the job well enough to > support millions of IPv6-only users for T-Mobile. And thereby allows > them to deploy v6-only at the edge, where address consumption is > highest. > > So maybe it would be good to differentiate a bit more and not throw > out the baby with the bathwater. fair enough, but even then 464XLAT is a transition technology which following your reasoning causes a long term problem that software developers can't rely on end-to-end connectivity even with IPv6. In other words, while it helps in the short term, we'll pay dearly for it in the long run. Yes, of course you are right that this is a complex issue, but there's a widespread tendency to carry the old limitations of today's IPv4 to IPv6 even if there's no real need to do so. And Marc calling NAT64 a working solution despite the fact that it breaks IPv6 the same way NAT broke IPv4 really asks to be balanced by a similarly oversimplified statement going the other way:-) So the real question is: How do we deal with exactly that risk, i.e. that some transition technologies burden the IPv6 world with otherwise unnecessary legacy issues? Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ From bs at stepladder-it.com Sun May 17 18:52:36 2015 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sun, 17 May 2015 16:52:36 +0000 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar In-Reply-To: <746CB974-9A51-47B1-B009-51CB6239AD7D@cisco.com> (=?utf-8?Q?=22=F0=9F=94=93=2E?= Dan Wing"'s message of "Fri, 15 May 2015 12:26:22 -0700") References: <87a8x6ry48.fsf_-_@stepladder-it.com> <746CB974-9A51-47B1-B009-51CB6239AD7D@cisco.com> Message-ID: <87egmf2lkb.fsf@stepladder-it.com> Hi Dan and list, ?Dan Wing writes: > On 15-May-2015 02:25 am, Benedikt Stockebrand wrote: >> [Implications of NAT64] > > To avoid some of that, they can go IPv6-only, including their servers > and all peers they communicate with, then there doesn't need to be > NAT64 for their traffic. But even IPv6-only they will need firewall > traversal support, as firewalls by default will block unsolicited > incoming traffic (RFC6092). I'm not sure if I get you correctly, but: Do you mean IPv6 only, or dual-stacked servers (so whatever a client connects with works without translation)? Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ From gert at space.net Sun May 17 19:27:36 2015 From: gert at space.net (Gert Doering) Date: Sun, 17 May 2015 19:27:36 +0200 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar In-Reply-To: <87mw132lpi.fsf@stepladder-it.com> References: <87a8x6ry48.fsf_-_@stepladder-it.com> <87mw132lpi.fsf@stepladder-it.com> Message-ID: <20150517172736.GK54385@Space.Net> Hi, On Sun, May 17, 2015 at 04:49:29PM +0000, Benedikt Stockebrand wrote: > Yes, of course you are right that this is a complex issue, but there's a > widespread tendency to carry the old limitations of today's IPv4 to IPv6 > even if there's no real need to do so. And Marc calling NAT64 a working > solution despite the fact that it breaks IPv6 the same way NAT broke > IPv4 really asks to be balanced by a similarly oversimplified statement > going the other way:-) Actually, the whole point is that NAT64 does not touch IPv6, so it is not "breaking IPv6" - it ensures that IPv4 legacy is still reachable, even if you're inside an IPv6-only network. Which sounds quite positive to me, given the alternative is "run dual-stack everywhere, forever, because someone out there might still be IPv4-only"... Carriers can't "just turn off IPv4" if users still connect to IPv4-only sites... so what is worse, NAT44/CGN and dual-stack all the way to the client, or nice and shiny IPv6-only at the edges, and NAT64 for talking to the old Internet? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From silvia.hagen at sunny.ch Sun May 17 19:41:30 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Sun, 17 May 2015 17:41:30 +0000 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar In-Reply-To: <87mw132lpi.fsf@stepladder-it.com> References: <87a8x6ry48.fsf_-_@stepladder-it.com> <87mw132lpi.fsf@stepladder-it.com> Message-ID: Transition mechanisms have the attribute of being transitional by definition. So they bridge gaps. That is exactly what NAT was originally designed for - bridge a gap until real solution is at hand. We have waited far too long with deploying IPv6, and now we have to live with the fact that IPv4 ran out. We are all paying the price and many have been predicting just that - but there weren't many that listened So let's hope we learned from the NAT issue We live in a free world and the Internet is VERY diverse. What is good for the ones is bad for others. If T-Mobile feels XLAT and NAT64 solves an issue, they and their customers must live with it. They can have an IPv6-only backbone and they can assign IPv6-only at the edge. Not bad. Maybe that helps the market to migrate the IPv4-legacy apps and design apps optimized for IPv6? :-) I do not believe in IETF or whoever else dictating the market how to do it. I think we should offer different transitional solutions solving different issues and let the actors in the market decide, what combination works best for them. My two cents Silvia -----Urspr?ngliche Nachricht----- Von: ipv6-wg [mailto:ipv6-wg-bounces at ripe.net] Im Auftrag von Benedikt Stockebrand Gesendet: Sonntag, 17. Mai 2015 18:49 An: ipv6-wg at ripe.net IPv6 Betreff: Re: [ipv6-wg] Implications of NAT/NAT64 and similar Hi Silvia and list, Silvia Hagen writes: > Hi Benedikt > > But in combination with 464XLAT it seems to do the job well enough to > support millions of IPv6-only users for T-Mobile. And thereby allows > them to deploy v6-only at the edge, where address consumption is > highest. > > So maybe it would be good to differentiate a bit more and not throw > out the baby with the bathwater. fair enough, but even then 464XLAT is a transition technology which following your reasoning causes a long term problem that software developers can't rely on end-to-end connectivity even with IPv6. In other words, while it helps in the short term, we'll pay dearly for it in the long run. Yes, of course you are right that this is a complex issue, but there's a widespread tendency to carry the old limitations of today's IPv4 to IPv6 even if there's no real need to do so. And Marc calling NAT64 a working solution despite the fact that it breaks IPv6 the same way NAT broke IPv4 really asks to be balanced by a similarly oversimplified statement going the other way:-) So the real question is: How do we deal with exactly that risk, i.e. that some transition technologies burden the IPv6 world with otherwise unnecessary legacy issues? Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ From silvia.hagen at sunny.ch Sun May 17 19:42:02 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Sun, 17 May 2015 17:42:02 +0000 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar In-Reply-To: <20150517172736.GK54385@Space.Net> References: <87a8x6ry48.fsf_-_@stepladder-it.com> <87mw132lpi.fsf@stepladder-it.com> <20150517172736.GK54385@Space.Net> Message-ID: YES :-) -----Urspr?ngliche Nachricht----- Von: ipv6-wg [mailto:ipv6-wg-bounces at ripe.net] Im Auftrag von Gert Doering Gesendet: Sonntag, 17. Mai 2015 19:28 An: Benedikt Stockebrand Cc: ipv6-wg at ripe.net IPv6 Betreff: Re: [ipv6-wg] Implications of NAT/NAT64 and similar Hi, On Sun, May 17, 2015 at 04:49:29PM +0000, Benedikt Stockebrand wrote: > Yes, of course you are right that this is a complex issue, but there's > a widespread tendency to carry the old limitations of today's IPv4 to > IPv6 even if there's no real need to do so. And Marc calling NAT64 a > working solution despite the fact that it breaks IPv6 the same way NAT > broke > IPv4 really asks to be balanced by a similarly oversimplified > statement going the other way:-) Actually, the whole point is that NAT64 does not touch IPv6, so it is not "breaking IPv6" - it ensures that IPv4 legacy is still reachable, even if you're inside an IPv6-only network. Which sounds quite positive to me, given the alternative is "run dual-stack everywhere, forever, because someone out there might still be IPv4-only"... Carriers can't "just turn off IPv4" if users still connect to IPv4-only sites... so what is worse, NAT44/CGN and dual-stack all the way to the client, or nice and shiny IPv6-only at the edges, and NAT64 for talking to the old Internet? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From marc.blanchet at viagenie.ca Sun May 17 19:46:26 2015 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Mon, 18 May 2015 01:46:26 +0800 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar In-Reply-To: <20150517172736.GK54385@Space.Net> References: <87a8x6ry48.fsf_-_@stepladder-it.com> <87mw132lpi.fsf@stepladder-it.com> <20150517172736.GK54385@Space.Net> Message-ID: <6C12B8F8-38A7-48A1-999A-5FD7892E1FA0@viagenie.ca> On 18 May 2015, at 1:27, Gert Doering wrote: > Hi, > > On Sun, May 17, 2015 at 04:49:29PM +0000, Benedikt Stockebrand wrote: >> Yes, of course you are right that this is a complex issue, but >> there's a >> widespread tendency to carry the old limitations of today's IPv4 to >> IPv6 >> even if there's no real need to do so. And Marc calling NAT64 a >> working >> solution despite the fact that it breaks IPv6 the same way NAT broke >> IPv4 really asks to be balanced by a similarly oversimplified >> statement >> going the other way:-) > > Actually, the whole point is that NAT64 does not touch IPv6, so it is > not "breaking IPv6" - it ensures that IPv4 legacy is still reachable, > even if you're inside an IPv6-only network. > > Which sounds quite positive to me, given the alternative is "run > dual-stack > everywhere, forever, because someone out there might still be > IPv4-only"... Right. NAT64-DNS64, while not perfect, is to me the only viable solution to move from where we are now to IPv6 in a cost effective manner. Running dual-stack is not cost-effective, while ipv6-only could be. When we first talked about NAT64 a while ago, I hated it. But I became fast convinced that it is a very important tool to move to IPv6. Marc. > > Carriers can't "just turn off IPv4" if users still connect to > IPv4-only > sites... so what is worse, NAT44/CGN and dual-stack all the way to > the > client, or nice and shiny IPv6-only at the edges, and NAT64 for > talking > to the old Internet? > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From silvia.hagen at sunny.ch Sun May 17 20:43:11 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Sun, 17 May 2015 18:43:11 +0000 Subject: [ipv6-wg] Extension Headers / Impact on Security Devices In-Reply-To: <87siav2m6p.fsf@stepladder-it.com> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> Message-ID: Hi I keep stumbling about that "recommendational wording" in RFC 2460 everytime I teach it. Couldn't we update RFC2460 and make this list a strict order? I would want my firewall to notify me if the EHs in a packet do not follow the list. And limiting the number of possible EHs per packet might be a good idea. Silvia -----Urspr?ngliche Nachricht----- Von: ipv6-wg [mailto:ipv6-wg-bounces at ripe.net] Im Auftrag von Benedikt Stockebrand Gesendet: Sonntag, 17. Mai 2015 18:39 An: ipv6-wg at ripe.net Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices Hi Enno and list, Enno Rey writes: > hope everybody had a great #RIPE70 meeting. We did! > Many thanks to the organizers and chairs! and thanks to the actual speakers as well the speakers we had to turn down due to time constraints, too:-) > If the chairs consider this appropriate we will happily give a > presentation on this stuff in Bucharest or at another occasion. Sounds good to me! > - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > their number, order[...] Actually, as far as I'm concerned that's the real core of the problem. Or more specifically, the first two lines of RFC 2460, section 4.1: When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: followed on the next page by Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). Note in particular that these are not even RFC 2119 "SHOULD" or "RECOMMENDED" and such. The impact here is actually at least twofold: - It is impossible to implement this as a simple pipeline architecture in hardware; at least for cases deviating from the "recommendations" above this effectively becomes either excessively complex to implement in hardware or an invitation to DoS when implemented in software on an otherwise hardware router. - As I understand it, at least some of the issues you have found are effectively based on violating the second paragraph quoted, making it impossible to come up with a lower bound on how long the header chain can actually get and therefore leading to the fragmentation related attacks and similar you have discovered. The original idea was that the extension headers are processed strictly in the order they occur, so one question to ask is if there is any valid reason to violate these "recommendations" for other than malicious purposes. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ From erey at ernw.de Sun May 17 21:18:41 2015 From: erey at ernw.de (Enno Rey) Date: Sun, 17 May 2015 21:18:41 +0200 Subject: [ipv6-wg] Extension Headers / Impact on Security Devices In-Reply-To: References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> Message-ID: <20150517191841.GA26929@ernw.de> Hi Silvia, On Sun, May 17, 2015 at 06:43:11PM +0000, Silvia Hagen wrote: > Hi > > I keep stumbling about that "recommendational wording" in RFC 2460 everytime I teach it. > > Couldn't we update RFC2460 and make this list a strict order? good luck bringing this suggestion to IETF 6man... ;-) > > I would want my firewall to notify me if the EHs in a packet do not follow the list. actually when we tested a number of commercial firewalls in late 2013 (results here: https://www.ernw.de/download/TR14_IPv6SecSummit_AAtlasis-RISC-project_results.pdf) it turned out that pretty much all of them follow a (from our perspective "reasonable approach", that is dropping "unusal combinations or number of ext_hdrs" by default. (which, of course, violates RFC 2460. but apparently all major vendors follow a line of reasoning similar to ours). so, in short, firewalls "are not affected". > And limiting the number of possible EHs per packet might be a good idea. yes, that _would actually be_ a good idea. I'm cross-posting this to v6ops as there's a related discussion going on right now. pls forgive this potential Usenet etiquette violation. best Enno > > Silvia > > -----Urspr?ngliche Nachricht----- > Von: ipv6-wg [mailto:ipv6-wg-bounces at ripe.net] Im Auftrag von Benedikt Stockebrand > Gesendet: Sonntag, 17. Mai 2015 18:39 > An: ipv6-wg at ripe.net > Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices > > Hi Enno and list, > > Enno Rey writes: > > > hope everybody had a great #RIPE70 meeting. We did! > > Many thanks to the organizers and chairs! > > and thanks to the actual speakers as well the speakers we had to turn down due to time constraints, too:-) > > > If the chairs consider this appropriate we will happily give a > > presentation on this stuff in Bucharest or at another occasion. > > Sounds good to me! > > > - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > > their number, order[...] > > Actually, as far as I'm concerned that's the real core of the problem. > Or more specifically, the first two lines of RFC 2460, section 4.1: > > When more than one extension header is used in the same packet, it is > recommended that those headers appear in the following order: > > followed on the next page by > > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). > > Note in particular that these are not even RFC 2119 "SHOULD" or "RECOMMENDED" and such. > > The impact here is actually at least twofold: > > - It is impossible to implement this as a simple pipeline architecture > in hardware; at least for cases deviating from the "recommendations" > above this effectively becomes either excessively complex to implement > in hardware or an invitation to DoS when implemented in software on an > otherwise hardware router. > > - As I understand it, at least some of the issues you have found are > effectively based on violating the second paragraph quoted, making it > impossible to come up with a lower bound on how long the header chain > can actually get and therefore leading to the fragmentation related > attacks and similar you have discovered. > > The original idea was that the extension headers are processed strictly in the order they occur, so one question to ask is if there is any valid reason to violate these "recommendations" for other than malicious purposes. > > > Cheers, > > Benedikt > > -- > Benedikt Stockebrand, Stepladder IT Training+Consulting > Dipl.-Inform. http://www.stepladder-it.com/ > > Business Grade IPv6 --- Consulting, Training, Projects > > BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From volker at pall.as Sun May 17 21:28:25 2015 From: volker at pall.as (Volker D. Pallas) Date: Sun, 17 May 2015 21:28:25 +0200 Subject: [ipv6-wg] IPv6 only as default for next meeting In-Reply-To: References: Message-ID: On Fri, May 15, 2015 at 12:21 AM, J?r?me Fleury wrote: > During WG this afternoon, the idea was submitted that the IPv6 only > experimentation be made the default SSID for the next meeting. > > While this has been working tremendously well for routine internet > usage, I've been unable to use this network mainly because of > incompatibility with my VPN network. > > We have a dual-stack VPN. some of the resources are v4 only though. > The DNS64 converts my v4 VPN resources into v6 resources that are then > routed to the non-VPN interface. While there could be workarounds > (DNS64 on the VPN side, full v6 routing on the VPN, or all VPN > resources available on v6) I don't think the technology is mature > enough to make it the default for advanced usage. > > My 0.02$ > > We could set up some kind of (friendly) rate limiting for the v4 network to make all regular users _want_ to be on the v6 network, which would not be limited. I can confirm all the major stuff was working, but I am sure not everybody tried. For those who still need v4, the fallback network with v4 would work, and it would maybe make them submit a ticket with their software vendor for incompatible applications (not necessarily including your problem, which seems to be more of a design thing) - Volker D. Pallas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun May 17 22:38:55 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 17 May 2015 22:38:55 +0200 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar In-Reply-To: <6C12B8F8-38A7-48A1-999A-5FD7892E1FA0@viagenie.ca> References: <87a8x6ry48.fsf_-_@stepladder-it.com> <87mw132lpi.fsf@stepladder-it.com> <20150517172736.GK54385@Space.Net> <6C12B8F8-38A7-48A1-999A-5FD7892E1FA0@viagenie.ca> Message-ID: <5558FC5F.5070303@seacom.mu> On 17/May/15 19:46, Marc Blanchet wrote: > > > Right. NAT64-DNS64, while not perfect, is to me the only viable > solution to move from where we are now to IPv6 in a cost effective > manner. Running dual-stack is not cost-effective, while ipv6-only > could be. > > When we first talked about NAT64 a while ago, I hated it. But I became > fast convinced that it is a very important tool to move to IPv6. IMHO, NAT64/DNS64 is the only real solution out there - one that does not require an entire re-design of the network once the last IPv4 bit has been carried. Mark. From evyncke at cisco.com Mon May 18 08:07:45 2015 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Mon, 18 May 2015 06:07:45 +0000 Subject: [ipv6-wg] Extension Headers / Impact on Security Devices In-Reply-To: References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> Message-ID: Let me chime in ;-) On this topic, I am suffering of schizophrenia with a double personality... - security person: I hate when there are too many options and sub-options and my usual recommendation is to use white list approach at the destination (being plain layer-4 ACL or more content filtering) and at the source (let's try to cut down covert channels): block unused ports, block unused protocols (remember IP protocol 41), block unused extension headers and drop everything which is not a normal IP packet (from address spoofing to invalid EH chain). If your firewall cannot implement this policy, then it is time to change or to use a combination of FW & IPS or whatever. - network person: as I will live with IPv6 for the rest of my life, then I want a way to extend it and I need any packet to travel to my source to my destination. Any IPv6 packet should be able to traverse the Internet/private network as long as its layer-3 header is valid (filtering/dropping can be done exceptionally for good operational reason). Did we remember the IPv4 teardrop attack? It is blocked by default by most routers for years ;-) Bugs will plague us for ever... And make our life more complex than the above description of course ;-) -?ric On 17/05/15 20:43, "Silvia Hagen" wrote: >Hi > >I keep stumbling about that "recommendational wording" in RFC 2460 >everytime I teach it. > >Couldn't we update RFC2460 and make this list a strict order? > >I would want my firewall to notify me if the EHs in a packet do not >follow the list. >And limiting the number of possible EHs per packet might be a good idea. > >Silvia > >-----Urspr?ngliche Nachricht----- >Von: ipv6-wg [mailto:ipv6-wg-bounces at ripe.net] Im Auftrag von Benedikt >Stockebrand >Gesendet: Sonntag, 17. Mai 2015 18:39 >An: ipv6-wg at ripe.net >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices > >Hi Enno and list, > >Enno Rey writes: > >> hope everybody had a great #RIPE70 meeting. We did! >> Many thanks to the organizers and chairs! > >and thanks to the actual speakers as well the speakers we had to turn >down due to time constraints, too:-) > >> If the chairs consider this appropriate we will happily give a >> presentation on this stuff in Bucharest or at another occasion. > >Sounds good to me! > >> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to >> their number, order[...] > >Actually, as far as I'm concerned that's the real core of the problem. >Or more specifically, the first two lines of RFC 2460, section 4.1: > > When more than one extension header is used in the same packet, it is > recommended that those headers appear in the following order: > >followed on the next page by > > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). > >Note in particular that these are not even RFC 2119 "SHOULD" or >"RECOMMENDED" and such. > >The impact here is actually at least twofold: > >- It is impossible to implement this as a simple pipeline architecture > in hardware; at least for cases deviating from the "recommendations" > above this effectively becomes either excessively complex to implement > in hardware or an invitation to DoS when implemented in software on an > otherwise hardware router. > >- As I understand it, at least some of the issues you have found are > effectively based on violating the second paragraph quoted, making it > impossible to come up with a lower bound on how long the header chain > can actually get and therefore leading to the fragmentation related > attacks and similar you have discovered. > >The original idea was that the extension headers are processed strictly >in the order they occur, so one question to ask is if there is any valid >reason to violate these "recommendations" for other than malicious >purposes. > > >Cheers, > > Benedikt > >-- >Benedikt Stockebrand, Stepladder IT Training+Consulting >Dipl.-Inform. http://www.stepladder-it.com/ > > Business Grade IPv6 --- Consulting, Training, Projects > >BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ > > From Ondrej.Caletka at cesnet.cz Mon May 18 13:58:05 2015 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=) Date: Mon, 18 May 2015 13:58:05 +0200 Subject: [ipv6-wg] IPv6 only as default for next meeting In-Reply-To: References: Message-ID: <5559D3CD.1040004@cesnet.cz> Hello list, Dne 17.5.2015 v 21:28 Volker D. Pallas napsal(a): > > We could set up some kind of (friendly) rate limiting for the v4 network > to make all regular users _want_ to be on the v6 network, which would > not be limited. I can confirm all the major stuff was working, but I am > sure not everybody tried. My observation is that most people haven't tried the v6only network just because they had troubles learning its password. That especially affects the newcommers. I don't think it is reasonable to rate limit the legacy network, proper naming should be sufficient. I would adopt naming convention in the same way the NCC promotes 5 GHz Wi-Fi technology instead of 2,4 GHz: Network type || 5 GHz essid | 2,4 GHz essid ---------------++----------------+-------------------- IPv6 + NAT64 || ripemtg | ripemtg-2.4 IPv6 + IPv4 || ripemtg-legacy | ripemtg-legacy-2.4 This way everybody would probably try the v6only network first and only those that would fail would switchover to legacy network. It would be then really useful to see the nuber of clients for which the v6only network is sufficient. -- Ond?ej Caletka CESNET -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3265 bytes Desc: Elektronicky podpis S/MIME URL: From shane at time-travellers.org Mon May 18 14:39:41 2015 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 18 May 2015 12:39:41 +0000 Subject: [ipv6-wg] IPv6 only as default for next meeting In-Reply-To: <5559D3CD.1040004@cesnet.cz> References: <5559D3CD.1040004@cesnet.cz> Message-ID: <20150518123941.1dc0c91d@casual> Ond?ej, On Mon, 18 May 2015 13:58:05 +0200 Ond?ej Caletka wrote: > Dne 17.5.2015 v 21:28 Volker D. Pallas napsal(a): > My observation is that most people haven't tried the v6only network just > because they had troubles learning its password. That especially affects > the newcommers. I think this is probably true. > I don't think it is reasonable to rate limit the legacy network, proper > naming should be sufficient. I would adopt naming convention in the same > way the NCC promotes 5 GHz Wi-Fi technology instead of 2,4 GHz: > > Network type || 5 GHz essid | 2,4 GHz essid > ---------------++----------------+-------------------- > IPv6 + NAT64 || ripemtg | ripemtg-2.4 > IPv6 + IPv4 || ripemtg-legacy | ripemtg-legacy-2.4 > > This way everybody would probably try the v6only network first and only > those that would fail would switchover to legacy network. It would be > then really useful to see the nuber of clients for which the v6only > network is sufficient. If we wanted to be very cautious, we could try just changing the password for RIPE 71 to be the same, and then in RIPE 72 changing the default to be what you've put in the chart here. I'm happy with your proposal for RIPE 71, of course, since I don't have horrible VPN software from the 20th century. ;) Cheers, -- Shane From gert at space.net Mon May 18 16:17:28 2015 From: gert at space.net (Gert Doering) Date: Mon, 18 May 2015 16:17:28 +0200 Subject: [ipv6-wg] IPv6 only as default for next meeting In-Reply-To: <20150518123941.1dc0c91d@casual> References: <5559D3CD.1040004@cesnet.cz> <20150518123941.1dc0c91d@casual> Message-ID: <20150518141728.GQ54385@Space.Net> Hi, On Mon, May 18, 2015 at 12:39:41PM +0000, Shane Kerr wrote: > I'm happy with your proposal for RIPE 71, of course, since I don't have > horrible VPN software from the 20th century. ;) Thing is, this wasn't actually the VPN software's doing, but DNS(64) - so if you try to access an IPv4-host *inside* the VPN, but try to resolve it using the public recursive DNS that you've been given, your client will receive an IPv6 address instead... With "full redirect VPN" this works (redirect DNS inside the VPN) but with "split tunnel" VPN, you're basically stuck between a rock and a hard place here - either you use the inside DNS, then your access to outside IPv4-only places fails (no DNS64), or you use the outside DNS, then see above... Gert Doering -- part time VPN software maintainer -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From dwing at cisco.com Mon May 18 18:57:08 2015 From: dwing at cisco.com (=?utf-8?Q?=F0=9F=94=93Dan_Wing?=) Date: Mon, 18 May 2015 09:57:08 -0700 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar In-Reply-To: <87egmf2lkb.fsf@stepladder-it.com> References: <87a8x6ry48.fsf_-_@stepladder-it.com> <746CB974-9A51-47B1-B009-51CB6239AD7D@cisco.com> <87egmf2lkb.fsf@stepladder-it.com> Message-ID: <7B931A10-B39F-4DCF-888D-69D2258E9504@cisco.com> On 17-May-2015 09:52 am, Benedikt Stockebrand wrote: > > Hi Dan and list, > > ?Dan Wing writes: > >> On 15-May-2015 02:25 am, Benedikt Stockebrand wrote: >>> [Implications of NAT64] >> >> To avoid some of that, they can go IPv6-only, including their servers >> and all peers they communicate with, then there doesn't need to be >> NAT64 for their traffic. But even IPv6-only they will need firewall >> traversal support, as firewalls by default will block unsolicited >> incoming traffic (RFC6092). > > I'm not sure if I get you correctly, but: Do you mean IPv6 only, or > dual-stacked servers (so whatever a client connects with works without > translation)? Go IPv6-only. If servers run IPv4 there will be a NAT on path, necessitating the NAT traversal support in the client. But IPv6-only reduces the market to only those homes/businesses with IPv6. Short version of what I'm saying: there is no way to avoid NAT translation support in the client. -d From bs at stepladder-it.com Sun May 24 12:25:36 2015 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sun, 24 May 2015 10:25:36 +0000 Subject: [ipv6-wg] Extension Headers / Impact on Security Devices In-Reply-To: (Silvia Hagen's message of "Sun, 17 May 2015 18:43:11 +0000") References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> Message-ID: <871ti6uva7.fsf@stepladder-it.com> Hi Silvia and list, Weekend:-) Anyway: Silvia Hagen writes: > I keep stumbling about that "recommendational wording" in RFC 2460 everytime I teach it. So do I. The problem underneath however is anything but trivial. > Couldn't we update RFC2460 and make this list a strict order? As I understand it the way extension headers work was effectively a response to the severe limitations of header options in IPv4 (like 60 octets max, not even enough to do a proper record route option). The reason for the rather relaxed wording here is in all likelyhood that people at that time didn't want to impose any rules cast in stone which would later on turn out to be another similar limitation; for example, if a subsequently defined extension header was specified, it would be rather difficult to retrofit. However, with the experience we have with extension headers so far I guess you're right, it is likely time to investigate the possibility to make the ordering and such mandatory. That will allow for much better hardware implementations, if nothing else. > I would want my firewall to notify me if the EHs in a packet do not follow the list. > And limiting the number of possible EHs per packet might be a good idea. Right, but there are a number of differences between a firewall and a high end router, so this should really be investigated from a wide range of perspectives, from microcontroller based embedded devices to high end routers, and from consumer-managed home environments to high security environments. This is quite likely a pretty big job. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ From bs at stepladder-it.com Sun May 24 13:29:09 2015 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sun, 24 May 2015 11:29:09 +0000 Subject: [ipv6-wg] Implications of NAT/NAT64 and similar In-Reply-To: (Silvia Hagen's message of "Sun, 17 May 2015 17:41:30 +0000") References: <87a8x6ry48.fsf_-_@stepladder-it.com> <87mw132lpi.fsf@stepladder-it.com> Message-ID: <87lhgemcxm.fsf@stepladder-it.com> Hi Silvia and list, Silvia Hagen writes: > Transition mechanisms have the attribute of being transitional by > definition. So they bridge gaps. That is exactly what NAT was > originally designed for - bridge a gap until real solution is at hand. > [...] yes, but they also have another effect: They make people believe that the problem is solved, often leading to a situation where these stopgap measures don't work any longer and the pressure to fix the problem is *really* bad. Or, in a different context: As long as the painkillers work, why should I go to the dentist? Only when the workaround is more painful than the problem it solves, then people start to move. We see that with DS-Lite, which is why I called it so useful at the RIPE meeting in Amsterdam: To the ISPs and the content providers, and increasingly to the enterprises too, it is simply less painful to go server side dual-stack than deal with the collateral damage caused by IPv4-only on their side and DS-Lite on their users. > So let's hope we learned from the NAT issue Seriously, I doubt that; this behaviour is too deeply entrenched in peoples minds. And while we're both making a living out of IPv6, it's still a niche market for people like us; if people had learned, then we'd be drowning in project offers. > We live in a free world and the Internet is VERY diverse. > What is good for the ones is bad for others. Fully agree on that. And it's rather difficult to come up with ideas or approaches that won't cause significant problems for others. But that's exactly why I point out the problems NAT causes to other people. > I do not believe in IETF or whoever else dictating the market how to > do it. Hmm, I guess there are a number of people at the IETF who'd be quite seriously offended by that statement, but anyway: One of the most fundamental goals of the Internet and the technologies used there is interoperability. I still remember how Compuserve and AOL and MSN and various others tried to establish their proprietary internetworking products, and people eventually opted for the Internet largely because of its interoperability. The role of the IETF is to ensure that specifications (not standards by the way, but that's yet another issue:-) support this interoperation. > I think we should offer different transitional solutions solving > different issues and let the actors in the market decide, what > combination works best for them. Yes, but: If the "market decides" then there's a good chance that people will sacrifice that interoperability for their own advantage. There are some people who benefit from full-blown NAT66, but others will then have to pay the price (STUN, reduced reliability, increased operational expenses, extra hardware, ...). One of the problems with transitional solutions, aside from delaying the inevitable until it really hurts, and always lasting forever, is that each increases complexity. And considering how difficult it is to recall those solutions when once made available. Which leads back to the extension header issue... Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/