Spreadsheet with various IPv6 tools
I have been cleaning up and reworking some old stuff of mine regarding how to determine required address space based on sizes of sites, sizes of different VLANs, etc. I have versions of these for IPv4, IPv6 using actual network sizes, and IPv4 using a /48 prefix or smaller for every site. I also included some other IPv6 related examples that I've shared various places in the past to help folks making the transition from IPv4 understand things like nibble boundaries, sparse allocation, etc. If you are interested I would love to get your thoughts and opinions on any or all of these. My plan is to share them more widely at some point in the near future, but I've been staring at them for so long now that it's time for new eyes. :) The formatting is still a bit rough, I need to polish/test in MS Excel once I'm comfortable with the content. It should work in LibreOffice now, as that's what I've been using. Thanks, Doug https://dougbarton.us/IPv4%20and%20IPv6%20Network%20Structure%20Planning-20190519.xls
Realistic number of hosts for a /64 subnet?
It's been a while since I was configuring subnets, and last time I did the guidance was always no more than 1,000 hosts per subnet/vlan. A lot of that was IPv4 thinking regarding broadcast domains, but generally speaking we kept to it for dual stacked networks, equating an IPv4 /22 with an IPv6 /64. (This was commonly in office environments where we used a subnet per floor to accommodate all of the desktops, printers, phones, tablets, etc.) Is this still how people roll nowadays? Have switches and/or other network gear advanced to the point where subnets larger than 1k hosts are workable? In IPv4 or IPv6? I've done quite a bit of web searching, and can't find anything newer than 2014 that has any kind of intelligent discussion of this topic. Doug
Re: Fwd: SixXS shutting down 2017-06-06
I'll add a voice to the chorus. :) Happy user off and on over many years, and deeply appreciative of all that you both have done to support the community. Best regards, Doug
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
On 6/12/15 1:11 AM, Lorenzo Colitti wrote: Ole said: do we agree that a host that wakes up and has expired its last default router should restart router discovery? In my mind this makes a lot of sense. That's not necessary. For things to work well a host needs to be able to maintain connectivity even when asleep. So it needs to be able to receive unicast packets, Agreed and it needs to process RAs The problem is that due to the design of the protocol processing RAs (Note, you did not specify unicast or multicast) is a known battery drainer. So it's awesome to say that wireless devices operating on a battery should simply stick to the protocol that was designed 15+ years ago when it was almost universally true that every networked device was connected to power and a LAN cable. But the world has moved on. (e.g., so it can know that it has lost connectivity when it receives an RA with a default lifetime of 0). The device should know if it loses connectivity if it actually, you know, loses connectivity. If the router hasn't expired yet it should be able to use it. The scenario you describe should be incredibly rare. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! signature.asc Description: OpenPGP digital signature
Re: Some very nice broken IPv6 networks at Google and Akamai (Was: Some very nice IPv6 growth as measured by Google)
On 11/9/14 12:27 PM, Tore Anderson wrote: So far you've been claiming that the problem lies with Google or Akamai. If true - and I don't dispute that it is - then testing from the RING should work just as well as from any home network. No, that's not true at all. Eyeball networks have very different characteristics than colos. Sure there will be some overlap, but your statement above is demonstrably false. It's also true that both Google and Akamai have admitted problems with IPv6, and Google claims to have fixed them. So at this point it's not at all clear what you're arguing about, other than an Asperger'y need to prove that something you said was correct at some point in some context. So can you please just let it go, and let's return this list back to its normally high S::N? Doug
Re: Google IPv6 measurements in Europe appear heading down...
So far all the conversation I've seen about this has been on the eyeball side. Has anyone looked into whether or not the content networks have made changes (removing/adding s for example) that would be responsible for the temporary skew? Doug On 11/5/14 7:23 PM, Kate Lance wrote: Hi Éric, I'm puzzled, not about the recent decline (and now near-recovery) but at the odd 'kick' in the stats on Aug 17, mainly for Europe. Compare Belgium and most of the high-IPv6 EU countries (for clarity I left a couple out like FR and CH, but they have small kicks as well): https://www.vyncke.org/ipv6status/compare.php?metric=pcountries=be,de,lu,ro,cz,no - with high-IPv6 non-EU (BE left in for comparison): https://www.vyncke.org/ipv6status/compare.php?metric=pcountries=be,us,jp,pe,my The US and Peru show small increments too, but certainly not like the EU countries. Looking closely, it appears something increased the measurements in Europe a little on 13 Aug, then a lot on 17 Aug. Erik Taraldsen from Telenor Norway said they'd been rolling out v6 since summer - but that sounds more gradual than a sudden increment in mid-August. Any ideas ...? Regards, Kate On Thu, Oct 23, 2014 at 06:03:42PM +, Eric Vyncke (evyncke) wrote: With the link, it is probably better… still need some caffein [1]https://www.vyncke.org/ipv6status/compare.php?metric=pcountries=be, de,us,lu From: Eric Vyncke [2]evyn...@cisco.com Date: jeudi 23 octobre 2014 09:38 To: [3]ipv6-ops@lists.cluenet.de [4]ipv6-ops@lists.cluenet.de Subject: Google IPv6 measurements in Europe appear heading down... For a couple of weeks, it seems that Google IPv6 measurements are heading down mainly for Europe. For example, here is a link to a presentation of the Google measurements for several European countries and USA. There is a clear drop in the last days/weeks for European countries but not for USA. This includes a big drop for my country (BE) :-O and I have checked with all Belgian ISP and they have no explanation as for them 'business as usual'. Apnic also does not show such a big drop. So, I am guessing either a 'bug' in Google measurements infrastructure in Europe or could it be that the IPv6 latency to Google has increased a lot so that Happy Eyeball prefers IPv4? Recent measurement of dual-stack latency to www.google.com from several Belgian ISP gave 10% slower over IPv6. Any clue will be welcome -éric References 1. https://www.vyncke.org/ipv6status/compare.php?metric=pcountries=be,de,us,lu 2. mailto:evyn...@cisco.com 3. mailto:ipv6-ops@lists.cluenet.de 4. mailto:ipv6-ops@lists.cluenet.de
Re: IPv6 address on Safari 8
On 10/27/14 11:25 AM, Michael Chang wrote: On OS X 10.9.5 and Safari 7.1 (9537.85.10.17.1) I see: [2a02:ed8:::8] yields first part of its address is not valid. [2a02:0ed8:::8] (change the second part) yields a webpage. [2a02:ed8::0::8] yields first part of its address is not valid. [2a02:0ed8::0::8] (change the second part) yields a webpage. Confirmed on Yosemite/Safari 8. However the 2607:: address I tried already has 4 characters in each of the first 3 sections (ala, 2607:abcd:abcd::8) so this trick doesn't work. I also tried 2607:abcd:abcd:0:0:0:0:8 and various other zero-padded combinations that didn't work either. Doug
Re: IPv6 address on Safari 8
On 10/27/14 1:43 AM, Antonio Prado wrote: Hi, some customers report they can't open certain IPv6 addresses using Safari Version 8.0 (10600.1.25) on OSX Yosemite Version 10.10 (14A389). If an address starts with 2A02 Safari complains 'can’t open “[2a02:ed8:::8]” because the first part of its address is not valid'. Yes, I get that with http:// as well. With https:// it endlessly cycles back to the Safari can't verify the identity of the website dialog, so there seem to be either multiple bugs, or the same bug affecting different code paths. FWIW, I get the same with a 2607:: address, so it would seem that anything that isn't 2001 is triggering the bug. Everything works for example with http://[2001:200:dff:fff1:216:3eff:feb1:44d7] Confirmed as well. I see downthread that someone already filed a bug for this. If there is a URL where I can add a me too I'm happy to do that if it's useful. hth, Doug
Re: IPv6 address on Safari 8
On 10/27/14 12:15 PM, Marco Davids wrote: Hi, I ran across something similar (while I was still running 10.9) when I tried to configure an IPv6- printer: https://twitter.com/marcodavids/status/514381881719394304 Yeah, posting this on twitter is useless. :) Meanwhile, it looks like the bug pre-existed Yosemite which is interesting. Also interesting, I just tested a ULA address and it worked. Doug
Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818
FWIW, I agree with Matthew 100%, especially about the fact that the SMTP world is changing. It's also worth noting that it's been in constant (although not always rapid) flux since I first got involved in Internet stuff 20+ years ago. Back then it was common for any connected system to be able to send mail, nowadays that's unthinkable of course. Also FWIW, since I know Nick a bit based on his postings on other lists it's probably worth pointing out that in all likelihood his concern here is based on not slowing down IPv6 adoption. That's a worthy goal, which I'm fully in support of. However the change has been blowing in the wind towards SPF/DKIM/DMARC now for years, and as Matthew pointed out there are only going to be more folks requiring it, not less. Fortunately SPF is dead simple, and DKIM isn't that much harder. In fact for one domain it's also dead simple (ProTip: Use OpenDKIM). I couldn't find a good, concise, up to date guide on using OpenDKIM for multiple domains, so it took me 2 tries to get it right, but I'm happy to write up my results if there's a need. DMARC is also pretty painless, although right now I'm set up for report only, at least until the mailing list software folks get that problem fixed. I do find it interesting to see how often mail is being Joe-jobbed from some of my mostly-unused domains though. So yes, rDNS/SPF/DKIM at minimum to get in the game, regardless of your IP protocol. DMARC is highly recommended. I realize that change is always painful, more so to folks who've been in the game just long enough to be really comfortable with their IPv4 address-based reputation stuff. But the times, they are a-changin'. Doug On 8/23/14 8:52 AM, Matthew Huff wrote: Nick, I would expect the response will be silence. Since the current RBL methods are not currently operational with IPv6 due to design issues and that IPv4 reputation is a large part of anti-spam, there is a fundamental difference currently between the two protocols. As IPv6 smtp ramps up, I would expect more to move to Googles direction than vice versa. The idea that you will be able to send email from an IPv6 address without rDNS, SPF and DKIM and have it end up in anything other than the spam folder is a pipe dream. Hell, I helped a friend that was running a hosted domain with only IPv4 and he had difficulty getting email delivered to corporate emails systems without SPF/DKIM. The SMTP world is changing, I doubt it is going to go back. -Original Message- From: ipv6-ops-bounces+mhuff=ox@lists.cluenet.de [mailto:ipv6-ops-bounces+mhuff=ox@lists.cluenet.de] On Behalf Of Nick Hilliard Sent: Saturday, August 23, 2014 11:37 AM To: Lorenzo Colitti Cc: IPv6 Ops list; Marco d'Itri; Jared Mauch Subject: Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818 On 22 Aug 2014, at 20:26, Lorenzo Colitti lore...@google.com wrote: What specifically would you like me to pass on? Dear gmail team, can you please publicly present data on IPv4 spam vs IPv6 spam in order to justify your documented policy? ? How about: Dear gmail team, v6 mta operators have noticed that there is a substantial difference between how spam detection is handled for ipv4 and ipv6 connections and this appears to be causing problems with high rates of false positives on v6 sessions. These problems appear to be specific to gmail and are not seen with connections to other major mail operators. Where SPF/dkim are not feasible/possible, this causes people to either implement gmail specific hacks or else disable ipv6. Both these workarounds act against the interests of both Google and the internet at large. Can you please reach out to the ipv6 operator community about this? ? Nick
Re: problem with www.xbox.com / akamai
On 06/14/2014 12:12 PM, niels=clue...@bakker.net wrote: The problem isn't the amount of CNAMEs, the problem is Microsoft's broken nameserver implementation. Quite correct, your message arrived shortly after I sent mine, and your analysis was more thorough. Doug
Re: Poll on SMTP over IPv6 Usage
On 02/18/2014 07:55 PM, SM wrote: Hi Doug, At 17:52 18-02-2014, Doug Barton wrote: My point is that all the hooha about We can't do mail over IPv6 because we can't do IP address reputation seems to be nonsense. There are plenty of ways to do spam filtering that don't involve keeping a log of every single IP address that sends spam. People are used to blocking spam by IPv4 address. That makes it difficult to explain that it is no longer the better way for IPv4 connections, and nowadays for IPv6 connections. Sorry I wasn't clear, but my post was already long enough. I understand that blocking spam by IPv4 address hasn't been an effective solution by itself for many years now, and I understand that the vendors are crying foul because IPv6 makes their snake oil sales harder. My purpose was to offer some actual concrete numbers from a mail server that's hit relatively hard with spam, to demonstrate that the entire argument of We can't filter spam on IPv6 is specious. :) Doug
Re: Reaching google.com using Chrome
On 01/13/2014 09:28 PM, Friedemann Stoyan wrote: Isn't ShowIP that spying app which reports all IP-Addresses to api.ip2info.org? Dunno about the specific location, but ShowIP does phone home. Personally I'm a big fan of SixOrNot: https://addons.mozilla.org/en-US/firefox/addon/sixornot/
Re: 'Upgrading' NAT64 to 464XLAT?
On 11/25/2013 10:48 PM, Lorenzo Colitti wrote: On Tue, Nov 26, 2013 at 3:36 AM, Doug Barton do...@dougbarton.us mailto:do...@dougbarton.us wrote: DNS64 was a non-starter because there are always going to be IPv4 sites that hard-code IP addresses, and a non-trivial number of them are going to be critical sites for any given set of users. The authors chose to plunge ahead anyway, leaving us with yet another transition technology cure that is worse than the disease. Wait, what? The problem you describe is the one that 464xlat solves. Didn't you just make my case? DNS64 didn't solve the problem, at best you can say it laid the groundwork for the (arguably) more thorough and (unarguably) dramatically more complex solution of 464xlat. And what was the delay between them? I realize we're never going to come up with a canonical answer for the relative value of transition tech helping the transition vs. delaying it. And I can even see merit in what 464xlat provides. But IPv6 has always been particularly pathological about let's shun the easy solutions in favor of creating increasingly complex ivory palaces, and that bothers me. Particularly when innocent folks like the OP put effort into deploying things like DNS64 because they bought the IETF snake oil that it will actually solve something for them. Doug
Re: 'Upgrading' NAT64 to 464XLAT?
On 11/26/2013 12:22 AM, Lorenzo Colitti wrote: On Tue, Nov 26, 2013 at 5:19 PM, Doug Barton do...@dougbarton.us mailto:do...@dougbarton.us wrote: Wait, what? The problem you describe is the one that 464xlat solves. Didn't you just make my case? DNS64 didn't solve the problem, at best you can say it laid the groundwork for the (arguably) more thorough and (unarguably) dramatically more complex solution of 464xlat. And what was the delay between them? Are you suggesting that we should have designed 464xlat on day one instead of DNS64? That's a bit like saying that we should have designed fiber optics without having copper. If DNS64 had not been designed and implemented we wouldn't have 464xlat today. No, I'm saying that we never should have gone down the road at all. But I'm really not interested in another pointless theological debate with you ... What I'm trying to point out here is that we've got NAT64/DNS64 sitting out there for well-meaning folks to stumble into with no idea that it's neither a thorough nor a robust solution. If 464xlat is the right answer to that particular problem then its proponents need to get to work on the HOWTOs. Doug
Re: 'Upgrading' NAT64 to 464XLAT?
On 11/25/2013 05:20 AM, Dick Visser wrote: We've been running a NAT64/DNS64 set-up for a while now on some parts of our office network. This seems to work well, but it doens't work for everything (e.g. Skype etc). When it was first being considered there was a non-zero number of us who made an initial effort to explain to the authors that DNS64 was a non-starter because there are always going to be IPv4 sites that hard-code IP addresses, and a non-trivial number of them are going to be critical sites for any given set of users. The authors chose to plunge ahead anyway, leaving us with yet another transition technology cure that is worse than the disease. Dual stack on the inside network is the only (effective) way to address this issue, even if it requires IPv4 NAT at the border. Doug
Re: Over-utilisation of v6 neighbour slots
On 10/28/2013 10:49 PM, Lorenzo Colitti wrote: On Tue, Oct 29, 2013 at 6:53 AM, Phil Mayers p.may...@imperial.ac.uk mailto:p.may...@imperial.ac.uk wrote: I wanted to follow up on this. Some folks from Cisco kindly contacted me off-list, and correctly guessed that a large number of the IPv6 neighbour entries were in state STALE, and pointed me to the relatively new: ipv6 nd cache expire seconds ...interface-level command. This wasn't in the IOS train we were running until relatively recently, so I hadn't seen it before. I wonder what the designers were thinking when they did the original implementation. Without this option, a box with enough client churn could run out of neighbour cache entries even if all the clients are perfectly behaved. Perhaps they didn't think of it because it doesn't happen in IPv4 due to a) much fewer addresses on a given box due to scarcity and b) ARP has timeouts. Probably not scarcity in 1918 world, but I think you hit the nail on the head with arp has timeouts. :) Doug
Re: Over-utilisation of v6 neighbour slots
Has anyone communicated directly with the Apple folks on this issue? Doug On 10/21/2013 01:37 PM, Phil Mayers wrote: On 21/10/2013 21:19, Cutler James R wrote: 4. Does Apple's approach to IPv6 privacy addresses properly support the intent of privacy addresses? My tentative answer is, Yes, and we need to learn to cope. The general approach perhaps, but the rollover timing is way, way too aggressive IMO. It should be on a timer, not driven by PHY wake events. Even 300 seconds would be an improvement over the behaviour we're seeing. As to we need to learn to cope - lots of networks have huge amounts of capital investment which can't just be ripped out and replaced overnight because Apple have decided to be aggressive with address rollovers. If the main outcome is for FIB-pressured sites to disable IPv6 on OUIs registered to Apple, it's a retrograde step ;o) Maybe we need a neigbour un-advert ICMPv6 message that the old addresses could be torn down with.
Re: same link-local address on multiple interface and OSPFv3
On 06/29/2013 03:18 AM, Benedikt Stockebrand wrote: IPv4 doesn't have link-local addresses or anything similar (unless you want to consider 192.169/16 similar in this context). https://tools.ietf.org/html/rfc3927
Re: Looking for support.netapp.com contact
Lars, support.netapp.com looks good from here (Los Angeles) over IPv6. The page loads some elements from now.netapp.com, which seems to still be IPv4-only, but I'm not going to quibble. :) Doug On 06/02/2013 11:53 PM, Eggert, Lars wrote: Hi Bernhard, your email was forwarded to me last week. I poked some people internally, and I just heard that IT has completed development and testing of the fix to this issue, and it is scheduled to deploy Monday, June 3. Please let me know if this problem is reappearing, or if there are other IPv6 issues. Thanks, Lars From: Bernhard Schmidt be...@birkenwald.de Subject: Re: Looking for support.netapp.com contact Date: 14 May 2013 22:46:31 BST To: ipv6-ops@lists.cluenet.de Am 03.04.2013 20:03, schrieb Bernhard Schmidt: today I had the first we enabled IPv6 and $something is really broken incident for months, if not years. https://support.netapp.com connects, sends a certificate and then just hangs. Of course this does not trigger any failover, so the site was completely broken from the user perspective. Not too happy to introduce them to network.dns.ipv4OnlyDomains in Firefox :-( 6 weeks later it is still broken. If SOMEONE is considering buying from them I would appreciate some bashing of the sales clerk, maybe that would wake them up. Bernhard
