Re: IOS 10 (?) and IPv6-only WLAN
On Thu, Oct 20, 2016 at 4:16 PM, Bernhard Schmidt <be...@birkenwald.de> wrote: > After several people mailed me that this setup should be working I > tested a bit further. It turned out that most of the time (not always) > the iPad was not answering Neighbor Solicitations sent from the router. > Since our WLAN solution (Alcatel =~ Aruba) does some fancy things with > Multicast in general and particularly IPv6 neighbor solicitations I > wasn't sure whether the Wireless setup was faulty. > > Someone sent me a very nice link on how to debug this (essentially run > tcpdump on the iPad, see > https://developer.apple.com/library/content/qa/qa1176/_index.html). > > Running this revealed that the iPad did indeed receive the Neighbor > Solicitation but completely ignored it. See > > https://syncandshare.lrz.de/dl/fiX5fNH2Ccmp5nJhEbqhMRDn/ios-ipv6.pcapng > https://syncandshare.lrz.de/dl/fi7EYUXNX8df9gtZfCbiSXEp/ios-ipv6.txt > > This seems to be caused by our special setup not setting the on-link > flag in the RA (since the wireless clients can't talk to each other > anyway they are supposed to send all traffic to the router). I assume > this triggers some sort of spoofing protection on the iPad, since the > source address of the NS is global and (according to the routing table) > not on-link. > > I'm not sure who is at fault here (the RFC editors, me, Cisco or Apple), > but changing to the more standard on-link=1 RA fixed the issue for us. Yes, it looks like combination of two factors: - your router is sending NSes from GUA, not link-local address (it is allowed behavior. My router, however, use link-local address as a source to send NSes to the solicited node mcast address); - iOS device iOS device gets NS from an address which is non on-link so it does not put that address into neighbor cache and does not respond to it. (As per https://tools.ietf.org/html/rfc5942#page-9 , ND messages from an address do not indicate that that address is on-link (as it used to be as per RFC4861). So an address (the router GUA in this case) is not on-link, it probably (?? can not find a quote to prove it) means it should not be placed in the neighbor cache. However it breaks a legitimate network setup... If such interpretation of rfc5942 is correct (isn't it too strict?) then the only solution I see is to make routers sending ND packets from LLA always.. One of the possible solution could be making routers > On 13.10.2016 10:45, Bernhard Schmidt wrote: >> Hi, >> >> for a couple of years now we have been running an IPv6-only eduroam on >> Campus for testing purposes. We use the following setup >> >> - VLAN terminated on Cisco N7k >> - wireless clients can't talk to each other >> - no IPv4 at all on the network (blocked by Wireless ACLs) >> - /64 SLAAC, on-link flag in RA not set >> - O-bit set in RA (stateless DHCPv6) >> - DHCPv6 relay to ISC DHCP, handing out a dedicated DNS64 resolver >> - DNS64 resolver on BIND 9.9, with our own network specific NAT64 prefix >> (not 64:ff9b::/96) >> - NAT64 gateway with Tayga on Linux >> >> The setup works quite well Linux, Windows (as well as NAT64/DNS64 >> without 464XLAT works). It doesn't work on Android due to lack of DHCPv6 >> of course. I think I had tested it with IOS 9.something and it worked >> there as well. >> >> Today we've received a report that IOS 10 devices cannot use it. I tried >> myself with an iPad running IOS 10.0.2 and I'm unable to use it either. >> >> - device does not show any errors about internet connectivity >> - device configures two IPv6 addresses and router from RA >> - device receives DNS64 nameserver from stateless DHCPv6 >> - device eventually configures an autoconf IPv4 address (169.254.x.x) >> without a gateway >> - I see A/ DNS queries to the DNS64 server >> - neither IPv4 nor IPv6 nor dualstacked websites work, the browser just >> times out. I cannot see any network activity of the device (but it's >> hard to tell, since I'm currently at home) >> >> I don't have an older iOS device to crosscheck. >> >> Does anyone have any ideas what could be wrong? >> >> Bernhard >> > -- SY, Jen Linkova aka Furry
Re: 6to4 in Internet aaaa records
On Fri, Oct 3, 2014 at 4:37 AM, Ca By cb.li...@gmail.com wrote: Back to my question, should there be an RFC generated that advises network admins to only put native natural addresses in DNS for anything that is supposed to be production grade and routed across the Internet? Meaning: 1. Only make records from 2000::/3 2. Do not make records with 6to4 addresses 3. Do no make records with NAT64 WKP 64:ff9b::/96 ( saw this last week ) do not make records with link-localwith ULAs...with 2001:db8::/32..with ::1...with ipv4-[mapped|compatibe] etc..;) As well as 'do not make A records pointing to RFC1918, example networks etc' I'd say 'do return to external clients containing anything except addresses from your public routable blocks' - but it seems to be too short for becoming an RFC ;) ps. handy list of broken things http://www.employees.org/~dwing/-stats/ Yeah, I have a long list of invalid s for Alexa1M... -- SY, Jen Linkova aka Furry
Re: So, time for some real action?
On Thu, Feb 6, 2014 at 5:04 PM, Dick Visser vis...@terena.org wrote: I know there are different opinions on this. But between black and white there are many shades of grey. That's why I was asking. I know that some stuff will break, I'm looking for ways to put this 'breakage' to positive use. To put this breakage to positive use we shall: - think about what is going to break - fix it - test it ...and then try to disable IPv4 to prove that things are not going to break anymore. Previous IPv6 events were to demonstrate that the sky is not going to fall. This is the way to go. In addition I believe that we should choose words carefully when suggesting things like you are talking about. Even in this thread there has been plenty of misunderstanding. On 6 February 2014 16:48, Nick Hilliard n...@foobar.org wrote: On 06/02/2014 14:51, Dick Visser wrote: http://www.internetsociety.org/deploy360/blog/2013/12/campaign-turn-off-ipv4-on-6-june-2014-for-one-day/ This is a terrible idea which will cause IPv6 to be associated with gratuitous breakage. Nick -- Dick Visser System Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands -- SY, Jen Linkova aka Furry
Re: So, time for some real action?
On Thu, Feb 6, 2014 at 11:05 PM, Andrew Yourtchenko ayour...@gmail.com wrote: Maybe transforming this into a taking a day off and using this time to educate the others and help them with their IPv6 deployment could be a better option ? Take a day off because you can't do work without IPv6 and then use this time to configure an IPv6-only SSID with NAT64 on a network where you *do* have control (may be still a different segment at work, or maybe your home network) or test a couple of apps and submit bug reports - how does this sound ? *This* sounds much better that the original idea of breaking things, I'd say. ...hmmm...should such a day off be classified as 'for religious reasons'? ;))) -- SY, Jen Linkova aka Furry
Re: T-Mobile goes IPv6-only on Android 4.4+ devices
On Tue, Nov 5, 2013 at 8:41 AM, Tore Anderson t...@fud.no wrote: Some cool news to start the day with: http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devices-126506 W00t!!! P.S. The link to the news does not work from IPv6-only network. -- SY, Jen Linkova aka Furry
Re: T-Mobile goes IPv6-only on Android 4.4+ devices
On Wed, Nov 6, 2013 at 12:01 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devices-126506 P.S. The link to the news does not work from IPv6-only network. Use SSID ietf-nat64. It is exactly what I did to read the news ;) - at least I did not have to switch to just 'ietf' SSID... Our own dog food. Eat it. :) I do as you can see from my complains ;-P -- SY, Jen Linkova aka Furry
Fwd: Free book draft: IPv6 for IPv4 Experts
Hi guys, [shameless plug mode on] I edited this book and I must say that at least some of my own views on the IPv6 architecture and the practical ideas I managed to come up with in this area are thanks to this book. I'm glad its author finally got around to making it public. Hopefully, you may find it interesting. -- Jen Linkova aka Furry -- Forwarded message -- From: Yar Tikhiy yar.tik...@gmail.com Date: Mon, Sep 23, 2013 at 9:50 PM Subject: Free book draft: IPv6 for IPv4 Experts To: freebsd-...@freebsd.org Hi all, Not a complete stranger to the project, I hope the following 'advertisement' will be appropriate here. When sometime around 2007 I finally had to make real sense of IPv6, I found a magic garden where brilliant ideas bloomed, and I felt it would be a shame to have all that beauty only to myself. I simply couldn't resist trying to structure those ideas up so that each of them shined in a crown of logical connections with others and with facts an average IPv4 wizard could be expected to know. Then it took some slow-paced rethinking, editing, and formatting to arrive a few years later at what can be considered a textbook intended for the battle-hardened veterans of the IPv4 era who are sufficiently curious and confident at the same time to stretch their current knowledge to the limit in order to discover the whys and wherefores of the IPv6 architecture instead of just dull facts about it such as the IPv6 address length. (As an exercise, try to tell in under 3 seconds what the famous length equals to _in bytes_.) Unsure if I want to get into the publishing hassle, I figured the best way to launch my work into the interhuman information space would be just to offer the final draft to the attention of the community. If you like it, the biggest favor you can do me will be to share it via your social network of choice. If you don't quite like it---well, then you probably don't have to share it. :-) The project page is: https://sites.google.com/site/yartikhiy/home/ipv6book An e-reader friendly PDF as well as a conventional A4 size PDF is available. Hoping you will enjoy the reading as much as I have enjoyed the writing. Cheers, Yar (formerly yar@)
