Re: Windows 7 / IPv6 on PPP Adapter

* Liviu Pislaru since there's no opinion about this issue here's my viewpoint: i think this isn't an RFC 5072 compliant implementation and Microsoft should fix that on Windows 7. Hi Liviu, I'm not intimately familiar with PPP on Win7, but what you describe sounds broken to me. I'd suggest

Re: PTR records for IPv6

* Holger Zuleger I think the subnet address with all 64 bits set to zero is reserved by [1] as the subnet router anycast address. Only if there's a subnet to begin with, so e.g. 2001:db8::/128 isn't a subnet-router anycast address. Also see RFC6164. Tore

Re: Microsoft: Give Xbox One users IPv6 connectivity

* Mark Townsley On Oct 10, 2013, at 4:56 PM, Geoff Huston wrote: I have not gathered data on Teredo-to-Teredo reliability. The connection failure numbers quoted above make use of a Teredo Relay. But this teredo-to-teredo connection failure rate in the Internet appears to be a critical

Re: 'Upgrading' NAT64 to 464XLAT?

* Dick Visser I just am reading up on the RFC and it looks like it doesn't have to be on the end host necessarily: http://tools.ietf.org/html/rfc6877#section-6.5 This is implemented in Android - its wireless hotspot feature works just fine using IPv6-only + 464XLAT as the upstream mobile

Re: 'Upgrading' NAT64 to 464XLAT?

* Bjørn Mork Tore Anderson t...@fud.no writes: This is implemented in Android - its wireless hotspot feature works just fine using IPv6-only + 464XLAT as the upstream mobile connectivity. The hotspot zone remains IPv4-only though, Really? I have only tested on Android 4.2 (without

IPv6 support in the PlayStation 4?

Hi list, Did any of you get to test whether or not the PS4 supports IPv6, and if so to what extent? Tore

Re: in6_pfx_newpersistaddr: %s is already configured

* Jared Mauch Anyone seen these logs on their machines? I get a fairly consistent set of syslogs on my machines (MacOS 10.9) each time I get a RA from my cable modem. 14:18:13.209477 20:e5:2a:b8:10:cf 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 174: (hlim 255, next-header

Re: MTU handling in 6RD deployments

* Gert Doering Have a higher IPv4 MTU between the 6rd tunnel endpoints sounds like a nice solution an ISP could deploy. True, well, in theory anyway. The reason I didn't include this in my list was that considering the whole point of 6RD is to be able to bypass limitations of old rusty gear

Re: MTU handling in 6RD deployments

* Templin, Fred L 6RD could use SEAL the same as any tunneling technology. SEAL makes sure that packets up to 1500 get through no matter what, and lets bigger packets through (as long as they fit the first-hop MTU) with the expectation that hosts sending the bigger packets know what they are

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

* Hannes Frederic Sowa Let me cook up a patch this week and depending on the size we maybe can get this into stable. Wow, that¹ was fast, thanks! \o/ [1] http://thread.gmane.org/gmane.linux.network/301135 How do you rate the chances of it going into stable? Or will it be targeted at 3.14, do

Re: I can fetch the header of websites via IPv6 but not the webpage, why?

* Ez mail Since I have no fr**king clue what could the problem be, I'm trying on this list :) I concur 100% with Erik's assessment that this in all likelihood is a PMTUD problem, specifically in the web_server-your_desktop direction. I'd just like to add that the fact that you see it

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

* Hannes Frederic Sowa In its current form, not so good. If you can tell me specific software that *breaks*, I can ask. At first I thought I might be able to just switch an 'if' but the patch got a bit more complex. What breaks is OpenVPN servers listening on an UDP IPv6 socket with

464XLAT CLAT for Linux

Hi list, In the hope that someone will find this interesting, and would like to test it out: I've just published an implementation of a 464XLAT CLAT for Linux at https://github.com/toreanderson/clatd/. It integrates with systemd/upstart/NetworkManager to automatically enable/disable the CLAT when

Re: Clueless national monopoly providers

* Frank Bulk Note that www.att.net has been down for 156 days, www.charter.com for 266 days, www.globalcrossing.com for 829 days These tree WFM from Oslo. They look fine from the NLNOG RING as well. Tore

Re: Google IPv6 measurements in Europe appear heading down...

* erik.tarald...@telenor.com Telenor Norway has had an pretty steep growth in IPv6 enabled subscribers since the summer. We are the larges ISP in Norway, so rollouts we do usually are somewhat reflected in the graphs. On the fixed access (DSL and fiber) we had approx. 60.000 lines 1. oct.

Re: Some very nice IPv6 growth as measured by Google

* Jeroen Massar On 2014-11-08 11:34, Tore Anderson wrote: * Jeroen Massar On 2014-11-08 10:27, Yannis Nikolopoulos wrote: [..] the short story here is that we're (finally) enabling IPv6 on our (already capable) CPEs :) And then getting broken connectivity to Google: https

Re: Some very nice IPv6 growth as measured by Google

* Jeroen Massar The only link: they are all using IPv6. You are trying to make this OTE link. I have never stated anything like that. Though, you likely take that from the fact that the reply followed in that thread. Yannis: «We're enabling IPv6 on our CPEs» Jeroen: «And then getting

Re: Some very nice broken IPv6 networks at Google and Akamai (Was: Some very nice IPv6 growth as measured by Google)

* Jeroen Massar On 2014-11-08 18:38, Tore Anderson wrote: Yannis: «We're enabling IPv6 on our CPEs» Jeroen: «And then getting broken connectivity to Google» I'm not a native speaker of English, but I struggle to understand it any other way than you're saying there's something broken

Re: Some very nice broken IPv6 networks at Google and Akamai (Was: Some very nice IPv6 growth as measured by Google)

* Nick Hilliard On 09/11/2014 11:00, Tore Anderson wrote: Only if Google and Akamai are universally broken, which does not seem to have been the case. I tested Google from the RING at 23:20 UTC yesterday: did you do a control run on a known working site? No. I feel that 250+ successes

Re: Some very nice broken IPv6 networks at Google and Akamai (Was: Some very nice IPv6 growth as measured by Google)

* Jeroen Massar Testing from colod boxes on well behaved networks (otherwise they would not know or be part of the RING), while the problem lies with actual home users is quite a difference. So far you've been claiming that the problem lies with Google or Akamai. If true - and I don't dispute

Re: google path mtu?

* Mikael Abrahamsson swm...@swm.pp.se So I guess the problem this time was some Google servers sending me PTB=1280 and then Chrome not taking this into account when sending UDP packets when using QUIC, resulting in fragmented IPv6 packets (which works very badly in real life), and then not

Re: Why do we still need IPv4 when we are migrating to IPv6...

* Anfinsen, Ragnar I am working with my management team to implement IPv6, but I got an interesting question from one of the managers; Why do we need more IPv4 if we are moving towards IPv6? IPv6 doesn't relieve you of IPv4 growth pains until you can start shutting down IPv4 in parts of your

Re: Why do we still need IPv4 when we are migrating to IPv6...

* Ole Troan When will IPv6 provide me as an end-user with more value than what my current NATed IPv4 connection does? If you, like me, like to play games online, and at some point find yourself googling for the cause of connectivity problems (it is just *so* *extremely* infuriating to have the

Re: Why do we still need IPv4 when we are migrating to IPv6...

* Thomas Schäfer This might be so in Norway. In German customer portals the gamers mostly demand ipv4 (public ipv4 address to their home) instead of DS-Lite. They have already native IPv6 but avm was forced to allow teredo over DS and DS-lite - because xbox has problems with native IPv6.

Re: Looking for information on IGP choice in dual-stack networks

* Philip Matthews philip_matth...@magma.ca We are looking particularly at combinations of the following IGPs: IS-IS, OSPFv2, OSPFv3, EIGRP. We're using OSPFv2 and OSPFv3 as ships in the night for IPv4 and IPv6, respectively. That said, somewhere far down in the darkest depths of my TODO list I

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

* Lorenzo Colitti are *all* IPv6 packets blocked, or just multicast packets? I know that a number of devices will drop multicast IPv6 packets. This eventually blackholes connections because the device stops receiving RAs and thus loses its default route, but that can be worked around by

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

* Lorenzo Colitti lore...@google.com On Wed, Jun 10, 2015 at 9:45 PM, Tore Anderson t...@fud.no wrote: are *all* IPv6 packets blocked, or just multicast packets? I know that a number of devices will drop multicast IPv6 packets. This eventually blackholes connections because the device

Re: Curious situation - not urgent, but I'd like to know more

* Kurt Buff > Can you expand a bit on the above? I'm quite ignorant of what you're > speaking, and would love to know more. > > Why shouldn't ATT allow her 6to4 packet back, and what is the tcpdump > session to which you refer? And, I've only recently become aware that > CGN has its own address

Re: Curious situation - not urgent, but I'd like to know more

Hi Kurt, First of all, +1 to Brian's suggestion to disable 6to4. I'd also disable Teredo. > On my test machine (Also Win8.1), sitting outside of my corporate > firewall on a public IP address, I see the following: > > Tunnel adapter 6TO4 Adapter: > >Connection-specific DNS Suffix . : >

Re: Ubuntu 16.04

* Mikael Abrahamsson > I have a pretty standard Ubuntu 14.04 machine I just upgraded to 16.04, > which means I get a "4.4.0-21-generic" kernel. > > I guess I'm using straight up network manager, because my > /etc/network/interfaces doesn't mention anything about eth0 or wlan0, only > lo. > >

Re: Ubuntu 16.04

Hi again, > Ubuntu (at least previous versions) hard-codes privacy extensions to be > on and preferred, overriding any user configuration to the contrary in > NM or /etc/network/interfaces. For the record, this has actually been fixed in 16.04, probably as a side-effect of changing to systemd.

Re: push apps failing in Android until you disable IPv6

* Erik Kline > If this router were to send out an RA advertising itself as a default > router in this configuration that would probably cause the symptoms > you're seeing. That's why I asked for a sample of any RAs seen on > such a network. (Such a configuration would of

Re: push apps failing in Android until you disable IPv6

* Lorenzo Colitti > On Fri, May 13, 2016 at 3:27 PM, Mikael Abrahamsson > wrote: > > > My guess is that any device which sees this, will install default IPv6 > > route but will only have link local addresses on the interface, thus there > > is no source address to use to send

Re: Linux and ULA support and default route

* Holger Zuleger > Hmm, what's so bad with still using the global prefix until the global > connectivity comes back and the CPE gets a new one? > Than it's early enough to set the preferred time of the former prefix to > 0 and let them time out. > In this way all local

Re: Link-local and ACLs

* Brian E Carpenter > So, I'm not aware of any realistic case where this happens, or any > reason for it. As Gert already pointed out: Neighbour Discovery. A few examples from an IX near me: 23:06:11.020045 In IP6 fe80::8678:acff:fe66:80db > 2001:7f8:12:1::3:9029: ICMP6, neighbor

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

* JORDI PALET MARTINEZ > It is true however, that this list must follow GDPR, and this means having an > explicit unsubscription link in the footer Which GDPR article requires that, exactly? Tore

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

* JORDI PALET MARTINEZ > I don't know it by memory Huh. In that case, what do you base your claims about what the GDPR requires on, exactly? > 1) Before 25 May 2018, every EU citizen or resident must get a confirmation > from any database holder with his personal data, to re-confirm the >