Re: Realistic number of hosts for a /64 subnet?
On Tue, 14 May 2019, WILSON Sam wrote: Except those nasty security people are now allowing systems to randomise their MAC addresses. I'm sure some people's Life Goal is to make life as difficult as possible for us network operators. That's why one should always create solutions that do not depend on any kind of uniqueness. 15 years ago I checked the mac addresses of our customers (ADSL customer base). I noticed that 5% of the customers were using the same mac address. Tracked that down to D-Link shipping lots of routers via electronics stores, all with the same mac address. Then I was happy I had designed the solution with single broadcast domain (vlan) per customer so this still worked. Other ISPs weren't so lucky, and this caused significant customer service costs. If you want a robust access network, make sure it works even if the customers have customer-controlled identifiers that overlap, such as DUID, MAC addresses etc. Track people on physical ports (so you know where that port/cable goes) or on username/password (802.1x). Make sure the customers/users can't affect each other (protect the Internet from them). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Realistic number of hosts for a /64 subnet?
On Thu, 9 May 2019, Doug Barton wrote: 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. It's a good topic to bring up. There has been some work on this in the IETF, for instance https://tools.ietf.org/html/rfc8273 This means there is single broadcast domain and single /64 per customer, which if properly implemented helps with a lot of the problem space people like to solve in this area. It however includes moving away from quite a lot of what you call "IPv4 thinking". I however do not operate wifi networks so I have no idea how widely this is implemented in gear available today. If someone else knows, I would appreciate if they would share. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 on VoLTE
On Wed, 7 Nov 2018, Anurag Bhatia wrote: I recently got VoLTE from my provider (AS9498). I noticed that after VoLTE is enabled, device is creating two IPsec tunnels and also has IPv6 address on those IPsec tunnels. Was wondering if someone can point me to any paper/documentation on how VoLTE works and how this IPv6 over ipsec works in the background? https://en.wikipedia.org/wiki/Voice_over_LTE , there should be links to the 3GPP specifications. I have not heard of VoLTE using IPSEC, that's not how it was supposed to work at least when I looked into this 5 years ago. Instead it should have additional bearer on mobile interface to handle this traffic. How are you identifying this as IPSEC tunnels? What kind of device is it you're looking at? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 plan for multisite corporate
On Mon, 21 May 2018, Luigi Rosa wrote: Hi, one of my customer is a US corporate with offices literally on 5 continents and one datacentre. Offices are connected each other and to the datacentrevia MPLS, each office accesses the Internet via local ISP. Since they asked me to start planning for IPv6, my idea was originally to buy a netblock from ARIN (maybe a /40) and use it for the offices (each office has many different IPv4 networks). My concern is: if I buy a netblock from ARIN and use it in every office, how can I handle the access to local ISP? I thing I should NAT the netblock of each office to handle the routing, or is there some other way to do so? https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-06 might be relevant to your requirements. If you feel you must perform NAT, make sure you do 1:1 NAT and not 1:N NAT (ie, create a solution where each internal IPv6 address gets a unique external address so you avoid all the port translations). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Win10 update CLAT
On Thu, 27 Jul 2017, Ross Chandler wrote: I've had no luck getting it to work either on an IPv6-only LAN with DNS64 and NAT64. Ross After reading the text again, I speculated that it was Win10 mobile only. I therefore dug up a win10 mobile phone I have, and updated it, and tried to connect to NAT64+DNS64 wifi I have. After updating it to 1703 I still can't see any CLAT being detected in any way (for instance test-ipv6.com). So the only thing I can think of is that the CLAT is mobile-only on win10 mobile only. So I put in a SIM card in it and tried to create a new APN, and it indeed does have a new APN type called "IPv4v6XLAT" (in addition to "IPv4", "IPv6" and "IPv4v6"). Unfortunately my mobile provider is dual stack and doesn't offer NAT64+DNS64 (at least not on its default APN) so I can't test it. So my take on this is that it's a Win10 only feature, and it's mobile only. Pity. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Win10 update CLAT
Hi, I did all the updates in Win10 because of the claim that CLAT would be included in the latest updates. I can't make it work. DNS64+NAT64 works correctly, but I can't ping IPv4 literals (expected behaviour of a host on IPv6-only+DNS64+NAT64 without CLAT). https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/ "Improved 464XLAT support 464XLAT was originally designed for cellular only scenarios since mobile operators are some of the first ISPs with IPv6 only networks. However, some apps are not IP-agnostic and still require IPv4 support. Since a major use case for mobile is tethering, 464XLAT should provide IPv4 connectivity to tethered clients as well as to apps running on the mobile device itself. Creators Update adds support for 464XLAT on desktops and tablets too. We also enabled support for TCP Large Send Offload (LSO) over 464XLAT improving throughput and reducing CPU usage." Is there anything specific I need to do to enable this? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: question regarding over the counter devices
On Tue, 7 Mar 2017, Brian E Carpenter wrote: I notice this because I log IPv6 connectivity. My wife has no idea this is going on. (Why my ISP offers inconsistent IPv6 service is another question, which their help desk cannot answer.) Yeah, I have the same experience. Historically I've had my IPv6 down for days before I actually needed it to ssh home to one of my devices. HE solvs most user issues. Only thing that makes it break is if there is PMTUD blackhole. So better to stop IPv6 (or IPv4) working completely, than to introduce PMTUD blackhole. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: question regarding over the counter devices
On Mon, 6 Mar 2017, Gert Doering wrote: 3G mandated IPv6, no carrier actually deployed it *before* they had a huge legacy of IPv4-only handsets in the field... could have been done from day one. On the other hand no handset manufacturer apart from Nokia ever made any 3G handsets that supported IPv6. Also, since you needed two concurrent bearers and the 3GPP network vendors charged per bearer, it also make IPv6 deployment extremely expensive. Yes, plenty of blame to go around. It's not only a carrier problem. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: question regarding over the counter devices
On Mon, 6 Mar 2017, Gert Doering wrote: If a CPE has no v6 support, having it available on the DSLAM (in passive mode = do not start IPv6CP until the client initiates it) will not do harm. The issue here isn't devices that do not support IPv6, it's the ones that do support IPv6 when it "suddenly" is turned on. The mobile carriers nicely demonstrated how *not* to do it - by ignoring the mandate for IPv6 in 3G, and rolling out huge masses of v4-only handsets, they suddenly had a huge installed basis of, well, v4-only legacy devices to deal with... Most carriers do not control handsets anymore. Those days are long gone. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: question regarding over the counter devices
On Wed, 1 Mar 2017, Nick Buraglio wrote: Is this actually a realistic fear? Let me put it this way, I have personally found an anon-ftp server with company confidential documents on it, that was reachable from the outside without the owners knowledge, because there was a port-forward in the residential gateway that the owner wasn't actively aware of, and the NAS had anon-ftp turned on without the owners active knowledge. So google had indexed all files on this NAS. I contacted the person (did some digging using pictures etc on this NAS) via their employer, and talked to the person who had no idea. Now, with unfiltered IPv6 it would be harder to actually find this NAS, but once found, there is no need for port forward for it to be reachable from the Internet. So yes, I can understand the fear and I agree that it's realistic. That's why most ISPs have chosen to have stateful filtering toward the customers by default. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: question regarding over the counter devices
On Wed, 1 Mar 2017, Bjørn Mork wrote: As an ISP: If you don't manage the CPE, should you even care? That is good question. In Sweden ISPs have gotten in trouble historically for not filtering stuff and customers files were exposed. For instance when ETTH had people plug their computers directly into the ETTH RJ45 jack (12-15 years ago), had no-password SMB shares on their computers, and there was no broadcast filtering on the LAN. Then they could "see" other users SMB shares and access them, and this made the papers as "unsecure". This was blamed on ISPs, not users. So when IPv6 now comes along, ISPs are scared that users might have no-firewall IPv6 devices, so when IPv6 is enabled all of a sudden lots of unsecured devices are then reachable from the Internet, devices that were configured in that way because before NAT "protected" them. yes, yes, being nice is good. But this is an impossible task. There is no way you can make assumptions about the security of any unmanaged CPE, with or without IPv6. I tend to agree, but I can also understand why an ISP might hesitate in this case. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: question regarding over the counter devices
On Wed, 1 Mar 2017, JORDI PALET MARTINEZ wrote: IPv6 firewall non-on by default. I’ve not seen that myself in any product up to now. How many products have you looked at? We're still talking about home routers now, right? I just checked Netgear R6100. Factory default has "IPv6 disabled", when I change it to "Auto Detect" the setting "IPv6 filtering" is "secured" by default. So this seems to be same thing that you've been seeing. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: question regarding over the counter devices
On Wed, 1 Mar 2017, JORDI PALET MARTINEZ wrote: What I’ve seen, yes is on by default, but I also heard the same complain, but actually never seen a device not-on by default … so I’m not really convinced is very real. "not-on", do you mean "IPv6" or "IPv6 firewalling"? -- Mikael Abrahamssonemail: swm...@swm.pp.se
question regarding over the counter devices
Hi, I just had a discussion with people from an ISP in the process of implementing IPv6. They were afraid of turning on IPv6 for customers who had purchased their own routers themselves, because these routers might not have IPv6 firewalling on by default, thus exposing customers who used to be "protected" by IPv4 NAT, to now be exposed with unfirewalled IPv6. So my question: Devices that people buy in electronics stores etc, do they even come with IPv6 turned on by default? If they do, is firewalling turned on by default? My Apple Airport Express at least came with firewalling turned on, I don't remember what the default setting was for IPv6 support. But if one turned on IPv6 support, then one had to unclick the firewall clickbox to be able to get incoming connections. I'm going to check the devices I have in my boxes here at home, but in the mean time would appreciate if others could share their experiences. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: contact with One & One ?
On Fri, 14 Oct 2016, Paul Stewart wrote: honestly we’ve never fixed it. it works for lots of customer/visitors but breaks for others (and they fail back to IPv4) - we thought it was Errr, how does this fallback work? I am not aware of any such mechanism. Happy Eyeballs is done when the SYN+ACK gets back. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: DHCPv6 client in Windows 10 broken after anniversary update
So I did some more investigation. I had missed that I needed to use /renew6 and /release6 before. Now I have 10 minute lease time. 5 minutes into the lease time, I can /renew6 the lease successfully and get 10 more minutes leasetime. around 2-3 minutes before the lease-time expires I see that Win10 has marked the IA_NA as (deprecated), I try to do "/renew6" I get the following error: "An error has occured while renewing interface Ethernet: The semaphore timeout period has expired". This renew fails. If I now ctrl-c this /renew6 and run /renew6 again, the renew succeeds and the address is back again as (preferred) and the lease time is 10 minutes. I also have a Ubuntu 16.04 box that won't keep its lease either... so I don't know what's going on. Will look further. Harald, what DHCPv6 server are you using? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Re: Re: CPE Residential IPv6 Security Poll
On Mon, 26 Sep 2016, Ted Mittelstaedt wrote: Well there is an answer to that. Instead of paying your development team to do a from-scratch build, you can just have them port over dd-wrt or openwrt. Both of these router firmwares are most likely tremendously advanced over anything your CPE development team can come up with. I've been working with this for the past 3 years or so. We have a CPE using OpenWrt we use as development platform. So while OpenWrt is great for supporting development of new protocols, it's nowhere near as stable/bug free as one of the more restrictive vendor CPEs. When you have millions of devices in the field, shipping OpenWrt with all the bells and whistles available would be just a nightmare. If one were to restrict it a lot and just use the features "needed", then it might be managable. I know some vendors who do this and ship HGWs based on OpenWrt. It's however quite heavily modified OpenWrt from what I can tell, and they don't rev their versions as fast as the OPenWrt project does. I am sorry about this but there you have it. The largest ISPs out there are solving the support issue by basically offering no useable support, the customer calls in, complains something doesn't work and is told to go away and find someone else to help them. These ISPs know that no matter how angry the customer gets with a non-answer, that ultimately the customer knows if they quit service and go to another large competitor that the other large competitor is going to treat them exactly the same way - so they don't benefit by quitting service. 90% (or more) of people want their ISP to just "FIX IT! FIX IT! FIX IT!". So we're going to see more and more ISP provided equipment in peoples homes and ISPs getting more and more involved in running the home networks. This is not something the ISPs are generally great at, the product cycles are generally long, it's quite a lot of "let's come up with something that works, is fairly bug free, then run the production line for 3 years, oh, and we need to support it for another 3-5 years". This is not a great combination with some customers wishes to always have the latest and greatest. Very few people give any kind of love to their "home router". They go and buy a USD40 device (or complain to the ISP that it's too expensive when the ISP wants to charge that kind of money for it) and then they connect their 1000 USD iPhone to it and expect everything to work great. But I also (I think we're in agreement here) think I am seeing people more interested in their home networks now compared to 5-10 years ago. More people now know that you shouldn't put your wifi router in the basement behind a lot of boxes if you want good wifi coverage. But there is more to be done here, and we need more tools to help the customers figure out what's wrong. Doing truck rolls to fix peoples home networks is going to be too expensive, so we need home network devices (and SoHo devices) to talk to each other so they can figure out what's going on and give advice to the customer. Right now I see forum posts all the time with people frantically kicking all the things to try to figure out what's going on. There is no indication to them if the connectivity is bad because the problem is in their home network, on the access line, ISP core network, or further out from the Internet. People just don't have the tools to help them understand what's going on. The only thing they can say is "my Internet is slow", which of course says nothing what the problem really is. Current devices can't even tell them if DNS lookups are slow, if TCP establishment is slow, if TCP transfer rate is low because of packet loss, because of high delay, because of something else. This information just isn't available to the end user, and it's sad state of affairs. The IETF, vendors and ISPs are all quite siloed so I don't know where we would start to actually improve this. I tried talking to the TCP people at the IETF and had no takers. I tried talking to the IPPM people, but they just want to measure with test traffic. I don't know who to talk to next. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: A=1 L=0 PIO
On Tue, 16 Aug 2016, Bjørn Mork wrote: if (L) then add route if (A) then do autoconf Win10 and MacOS seems to do the same as you described here. Ok, goodness, that's what I wanted to hear. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: A=1 L=0 PIO
On Tue, 16 Aug 2016, Enno Rey wrote: from my memory: yes to all of those, for common desktop OS (Win, Linux, Max OS-X). When we did the lab testing for this one (https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf) we played a bit with the L-flag as well, so the L=0 + A=1 scenario occurred. I don't remember any case where the things you mention did not happen. We still have that lab infrastructure so we can repeat (some of) the tests with L=1 (and without DHCPv6). Let me know if you (or the group) is interested; we can assign a student to the task. (I'm on family holiday myself until end of Aug). I just tried A=1 L=0 with the following operating systems, all fully updated with whatever latest versions is shipping to normal people. Windows 10 MacOS 10.11.6 iOS 9.3.4 Android 5.1.1 Linux 14.04 LTS They all did what I consider "the right thing". They autoconfigured addresses and used them, and they did DAD on the link. -- Mikael Abrahamssonemail: swm...@swm.pp.se
A=1 L=0 PIO
Hi, I'm trying to figure out what a "normal" currently deployed in the field IPv6 host would do if it receives an RA with PIO /64 where L=0 and A=1. I've skimmed RFC4861 and RFC4862 without finding an answer. Thoughts on this? I can of course try it out myself, but I have a limited number of operating systems available. Anyone here have any data or other insights? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Netflix hates IPv6
On Wed, 15 Jun 2016, Michael Oghia wrote: That is a good and constructive suggestion. Forgive me if I'm a broken record, though, when I ask if Netflix is involved at any level or even aware of this discussion? If not, it seems advantageous to me to invite them to be included. Every point that has been made on this list so far, has already been made in the huge thread on nanog-l. I would take for granted that Netflix is aware of that one. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: DHCPv6 relay with PD
On Wed, 8 Jun 2016, Ole Troan wrote: I've talked to several people who claim there are lots of equipment out there which will happily do DHCPv6 relaying of PD messages, but then not install a route for the corresponding delegation. That's perfectly fine behaviour by the way. DHCPv6 PD snooping is just one way of doing route injection, among many. Ok, I invoke https://en.wikipedia.org/wiki/Principle_of_least_astonishment Does the DHCPv6-PD server backend have access to all information needed to trigger a provisioning system to install/remove a static route on the relay? What other methods are there apart from provisioning a static route on the relay? BGP? -- Mikael Abrahamssonemail: swm...@swm.pp.se
DHCPv6 relay with PD
Hi, I've talked to several people who claim there are lots of equipment out there which will happily do DHCPv6 relaying of PD messages, but then not install a route for the corresponding delegation. One example seems to be HP 5400zl. My own experience is only when I did this with a DOCSIS CMTS, which did install a static route properly. The two other examples I have are with DHCPv6(-PD) server running on the L3 device itself (no relaying), a Huawei 5300 L3-switch and a Cisco 7206 router. Both of them properly installed that corresponding static route as soon as the DHCPv6-PD process had completed the delegation. I'm looking for experience with other equipment, please share! -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: v6 naming and shaming - *.europa.eu
On Wed, 18 May 2016, Phil Mayers wrote: Ok so basically, if more/most access networks were IPv6-enabled (because big or vital providers are IPv6 only) then all service networks would have to get it working? Yes, if it's broken from one network but works from the rest, then the problem to fix is for that broken network. If it's broken for everybody, then it's the one who has the broken end that needs to fix. This is the same thing with IPv6, DNSSEC and all such new technologies. If there is only one ISP that does DNSSEC validation and it's broken because the zone is signed wrong, then that ISP gets blamed. In Sweden, where 85% of customers sit behind a DNSSEC validating resolver, nobody gets away with screwing up their zone signing because now it's their problem. It's all about critical mass. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: push apps failing in Android until you disable IPv6
On Mon, 9 May 2016, JORDI PALET MARTINEZ wrote: Just got a “screen” capture from one of those situations (rdisc6). Hopefully is useful ! They made it from a virtual machine in the same network as the Androids have the problema, having the VMware interfaces in bridge mode. So that looks like something is sending an RA, announcing itself as a router but there are no addresses to be used on the link (there is no on-link prefix thus implicitly A=0, and M=0). 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 packets to the world outside the link. According to standards, this shouldn't be a problem. IPv6 would not be used to communicate with the outside world. Looking at https://tools.ietf.org/html/rfc6724 2.1 and the table there. Why is there nothing there matching fe80::/10 ? I guess it just implicitly takes for granted that anything in fe80::/10 can't be used without also specifying the interface? If someone did something "smart" and thought they'd help the user by not requiring them to specify interface, then this might cause problems unless the application immediately gets an error back? And if it gets an error back, how do we know it tries the next option, for instance IPv4? Could this be the problem here, the applications only try one address family and if that doesn't work, it won't establish the notification channel? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: push apps failing in Android until you disable IPv6
On Tue, 10 May 2016, Erik Kline wrote: It's really not clear to me what that version of rdisc6 would print if it encounters options about which it did not know anything. A pcap of just an RA would be best. The adb commands I pasted should also suffice to show what the device thinks it has for DNS, routes, everything. The version of rdisc6 included in Ubuntu 14.04 displays recursive DNS server. This is also seen in "tcpdump -vvv -n -i eth0 icmp6" and I see it as: rdnss option (25), length 24 (3): -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: ip switching from ipv4 to ipv6
On Fri, 29 Apr 2016, re wrote: but is there any explanation to the repeated changing of the ip address from ipv4 to ipv6? https://en.wikipedia.org/wiki/Happy_Eyeballs If network conditions change then IPv4 or IPv6 might be preferred over time. It'll usually give a little bit of head-start for IPv6 (depending on implementation), but if v6 is significantly worse parts of the time, then you'll see the client bouncing between versions. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: ip switching from ipv4 to ipv6
On Fri, 29 Apr 2016, re wrote: is it us or the deutsche telekom who is causing the problem? This isn't a problem, this is expected behavior. Don't trust the IP address to be stable, at least not between IPv4/IPv6. -- Mikael Abrahamssonemail: swm...@swm.pp.se
MTU/MSS testing IPv6
Hi, I've run into a scenario where a website doesn't seem to be listening to PTB. I can reach them just fine from an MTU1500 clean IPv6 connection, but if I reach from a MTU1500<->MTU1480<->MTU1500 connection, it doesn't work. I don't get the big packets after SYN handshake. I've been considering asking iis.se (the .SE ccTLD registry) who are already running multiple testing tools for web sites and domain name owners) to include these kinds of testing, and perhaps develop more of them. So I'd like to gather some information and feedback here. 1. Are there are already FOSS tools out there that could be used for this, or would be good to enhance to include capability for this kind of testing. I don't want to waste work, and if I can enhance FOSS tools already existing and also solve my problem, that's a double win. 2. Test cases? From my testing, I've seen two different behavior just in the last two days: Site A as described in top paragraph, probably doesn't listen to PTB. Can be either because they drop PTBs, or traffic traverses a load balancer/IPv4v6proxy that doesn't correctly handle PTB. Site B which sends all data packets as fragments. This is most likely because they have some kind of AFTR where the IPv4 side has MTU1500 and the IPv6 side has MTU1320 or something like that. Neither of this is of course optimal, and I'd like to be able to test for these and tell the site owner that their solution either is broken or suboptimal (the fragment case isn't strictly broken, it's just not a good way to do things). Opinions? Thoughts? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Slow WiFi with Android Marshmallow & IPv6?
On Tue, 26 Apr 2016, Jeroen Massar wrote: specifically a 'router' but a CPE (that for IPv4 NATs and for IPv6 sorta Let me just say that when I used "CPE" in a document, I was reminded by BBF (BroadBand Forum) people that they use "CPE" as "any device in the home". Their terminology for the first router in the home is "RG" as in "Residential Gateway". -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Ubuntu 16.04
On Fri, 22 Apr 2016, Jeroen Massar wrote: Isn't it awesome that Ubuntu wants dynamic addresses on servers? :) Well, this wasn't a server, this is installed as a desktop. They have been told about that problem by many people already, unfortunately, they claim to know better... Who are "they"? But, check your 'sysctl -a | net.ipv6.conf' you might find some knobs there. Next to that, check systemd settings as that thing wants to take over the kernel and thus ignores those settings and comes up with it's own... It's strangem it looks like they still have the kernel to process RAs? Doesn't it seem like the kernel now has support for the kind of stable non-EUI64 based addresses from https://tools.ietf.org/html/rfc7217 ? http://unix.stackexchange.com/questions/251401/cannot-read-key-net-ipv6-conf-all-stable-secret-in-sysctl seems to indicate that the error message below is because the secret isn't set? So potentially if I set the secret I'll get the same address every time? Let's try... $ sudo sysctl -a | grep net.ipv6.conf | grep -i eth0 sysctl: reading key "net.ipv6.conf.all.stable_secret" sysctl: reading key "net.ipv6.conf.default.stable_secret" sysctl: reading key "net.ipv6.conf.eth0.stable_secret" net.ipv6.conf.eth0.accept_dad = 1 net.ipv6.conf.eth0.accept_ra = 1 net.ipv6.conf.eth0.accept_ra_defrtr = 0 net.ipv6.conf.eth0.accept_ra_from_local = 0 net.ipv6.conf.eth0.accept_ra_min_hop_limit = 1 net.ipv6.conf.eth0.accept_ra_mtu = 1 net.ipv6.conf.eth0.accept_ra_pinfo = 0 net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 0 net.ipv6.conf.eth0.accept_ra_rtr_pref = 0 net.ipv6.conf.eth0.accept_redirects = 1 net.ipv6.conf.eth0.accept_source_route = 0 net.ipv6.conf.eth0.autoconf = 1 net.ipv6.conf.eth0.dad_transmits = 1 net.ipv6.conf.eth0.disable_ipv6 = 0 net.ipv6.conf.eth0.force_mld_version = 0 net.ipv6.conf.eth0.force_tllao = 0 net.ipv6.conf.eth0.forwarding = 0 net.ipv6.conf.eth0.hop_limit = 64 net.ipv6.conf.eth0.ignore_routes_with_linkdown = 0 net.ipv6.conf.eth0.max_addresses = 16 net.ipv6.conf.eth0.max_desync_factor = 600 net.ipv6.conf.eth0.mc_forwarding = 0 net.ipv6.conf.eth0.mldv1_unsolicited_report_interval = 1 sysctl: reading key "net.ipv6.conf.lo.stable_secret" sysctl: reading key "net.ipv6.conf.wlan0.stable_secret" net.ipv6.conf.eth0.mldv2_unsolicited_report_interval = 1000 net.ipv6.conf.eth0.mtu = 1500 net.ipv6.conf.eth0.ndisc_notify = 0 net.ipv6.conf.eth0.proxy_ndp = 0 net.ipv6.conf.eth0.regen_max_retry = 3 net.ipv6.conf.eth0.router_probe_interval = 60 net.ipv6.conf.eth0.router_solicitation_delay = 1 net.ipv6.conf.eth0.router_solicitation_interval = 4 net.ipv6.conf.eth0.router_solicitations = 3 net.ipv6.conf.eth0.suppress_frag_ndisc = 1 net.ipv6.conf.eth0.temp_prefered_lft = 86400 net.ipv6.conf.eth0.temp_valid_lft = 604800 net.ipv6.conf.eth0.use_oif_addrs_only = 0 net.ipv6.conf.eth0.use_tempaddr = 2 -- Mikael Abrahamssonemail: swm...@swm.pp.se
Ubuntu 16.04
Hi, 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. In the GUI, it came default with "privacy extensions disabled". I used to administrate this device using its EUI64 based SLAAC address, which was stable across reboots. Now with 16.04, I get two addresses, none of them stable across reboots. Anyone know what the thought is behind this? I want to continue using SLAAC and I'm fine with privacy extension addresses over time, but I want a single stable address across reboots. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Windows 10 + VLC + IPv6 SSM
On Sun, 21 Feb 2016, Harald F. Karlsen wrote: They broke IPv6 multicast streaming in VLC version 2.0.6. It works in version 2.0.5 although it required that you opened for ICMPv6 type 143 outgoing in the windows firewall (at least in Windows 7) in order to get SSM to work. ASM worked fine iirc. I opened a ticket with the Videolan team 15 months ago, but the ticket hasn't received much attention: https://trac.videolan.org/vlc/ticket/13071 Thanks a lot for this info. I have now verified that VLC 2.0.5 indeed works on Windows 10 (at least if I join the stream from a Linux box on the same subnet as the windows machine), and VLC 2.0.6 gives an immediate error when trying to open the same URL/stream. I will send in this comment in the ticket. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Cost of IPv6 for IT operations team
On Fri, 3 Apr 2015, Ted Mittelstaedt wrote: normal hardware refresh cycles is something the Fortune 1000 have. It's a nice concept but not one universally adopted by everyone else in the real world. Another one of these is hardware service contracts That's not universally adopted, either. Obviously, otherwise Win XP market share wouldn't be where it is considering MS has stopped supporting it. The state of the SCADA and other industry applications is the result of a near total disregard for security when it comes to application programming. This will hopefully improve, but it'll take time, the same way IPv6 adoption will take time. However, it's still the truth that if you're buying equipment today that you intend to have around for 5-10 years and you don't check them for IPv6 functionality, you're being short-sighted. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Re: Why do we still need IPv4 when we are migrating to IPv6...
On Fri, 13 Feb 2015, Richard Hartmann wrote: On Fri, Feb 13, 2015 at 12:26 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: so I guess clients need to try a few times and not listen to the (initial) ICMP messages until the hole is open. That sounds slightly broken as well. I agree. Do you have a better suggestion? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Re: Why do we still need IPv4 when we are migrating to IPv6...
On Fri, 13 Feb 2015, Thomas Schäfer wrote: and the practice in Germany to blocking all IPv6-inbound traffic the result is the problem for some gamers. So I guess applications should use the same technique as one does to traverse NAT44:s, ie both ends of the connection send packets to each other to open their respective firewall. I do agree that the firewall in question needs to not send rejects for this traffic for this to work. I am happy this use-case was brought up, because I hadn't heard and thought about this before. Personally I don't want to silently drop packets, so I guess clients need to try a few times and not listen to the (initial) ICMP messages until the hole is open. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Why do we still need IPv4 when we are migrating to IPv6...
On Fri, 13 Feb 2015, Phil Mayers wrote: None of this should be a problem for non-NATed IPv6. The absence of NAT will mean an ICMP error doesn't block a NAT translation - there's no such thing to block - so a CPE can send errors or not. Ah, thanks for pointing that out. So currently there are multiple providers disallowing incoming connections to IPv6 addresses for customers. But if I understand correctly, including what you described before, this would work: U1=User1, U2=User2... HGW1=HomeGateWay, belonging to U1. Assume IPv6 and no NAT. U1 and U2 are going to play a game together. They're speaking to the game server. U1 says please talk to me on U1IP UDP port U1PORT). U2 says please talk to me on U2IP UDP port U2PORT. Game server informs respective user about the other users' IP/PORT combination. Now, U1 sends a UDP packet from U1IP,U1PORT to U2IP,U2PORT. HGW1 creates flow state for U1IP,U1PORT-U2IP,U2PORT. Packet reaches HGW2, which has no flow state, and is dropped. ICMP error message might be created. In case of ICMP error message, U1 should ignore this. U2 sends a packet from U2IP,U2PORT to U1IP,U1PORT. HGW2 creates flow state. Packet hits HGW1 which already has a flow state, and packet successfully reaches U1. U1 now can start sending packets to U2 as well and they've worked around both of them having HGWs with stateful firewalls disallowing new connections to them. Right? The crucial step here seems to be the fact that initial packets might be dropped and error messages be generated, but these should be ignored by the application. Is this commonplace? Is it a problem at all? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Why do we still need IPv4 when we are migrating to IPv6...
On Thu, 12 Feb 2015, erik.tarald...@telenor.com wrote: 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. xbox is no good example for *wanting* IPv6. Could you elaborate on the IPv6 issues for xbox? I was under the impresion that xbox works well with IPv6. This thread probably: http://lists.cluenet.de/pipermail/ipv6-ops/2014-March/009929.html -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: google path mtu?
On Sat, 24 Jan 2015, Andras Toth wrote: Airport Express is setting the IPv6 Tunnel MTU to 1280 in all cases and it's not configurable, as far as I'm aware. That is what I have discovered. So the HE.net tunnel termination point will send PTB=1480 when sent 1500 byte packets, and my airport extreme will send PTB=1280. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: google path mtu?
On Mon, 26 Jan 2015, Ignatios Souvatzis wrote: This is why setting the MTU (maximum _transmission_ unit) at your end doesn't necessarily help. You'll have to lower your OS's notion of maximum TCP segment size negotiated for TCP reception. That depends if the QUIC implementation in Chrome will understand path MTU and send smaller UDP packets than 1350 if needed. In my case it didn't. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: google path mtu?
I had another problem with Youtube just now, with Chrome+OSX. I saw my machine sending fragmented UDP-packets to google on 443, which it was not getting any responses to. On a hunch, I disabled QUIC in Chrome which made things start working again. 03:20:45.891286 IP6 2001:470:X 2a02:808:1:100::c: frag (0|1232) 59430 443: UDP, length 1350 03:20:45.891286 IP6 2001:470:X 2a02:808:1:100::c: frag (1232|126) -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: google path mtu?
On Fri, 23 Jan 2015, Lorenzo Colitti wrote: Thanks for reporting this. What was the effect? Connections just getting stuck? Was there fallback to IPv4? I would get all the CSS, comments etc, the player would start to try to load the video stream, but there would be no video loaded at all (ie the progress bar never moved). Personally I don't understand why everyone behind a manually-configured tunnel doesn't set the MTU in the RA to the MTU of the tunnel... but that's not an excuse for things not working. I did that before, but I can't do it in my Airport Express. I have been considering changing my IPv6 tunneling to another device. However, I have no clue why my OSX box thought it couldn't send 1350 byte sized UDP packets to the Internet. Could Google have sent me PTB=1280 from this host, so my OSX box thinks it can't send them unfragmented? Anyone know how I can check in OSX for what destinations it has received PTB packets and what the PMTU it think it has for these destionations? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: google path mtu?
On Fri, 23 Jan 2015, Mikael Abrahamsson wrote: Anyone know how I can check in OSX for what destinations it has received PTB packets and what the PMTU it think it has for these destionations? Found it: $ netstat -f inet6 -narlW Internet6: Destination Gateway Flags Refs UseMtuNetif Expire default fe80::9272:40ff:fe07:cc74%en0 UGc 140 1500 en0 ... $ netstat -f inet6 -narlW | grep -v 1500 | grep en0 2620:109:c007:102::5be1:f881fe80::9272:40ff:fe07:cc74%en0 UGHWIi 2 237 1280 en0 2a00:1450:4005:801::1017fe80::9272:40ff:fe07:cc74%en0 UGHWIi 1 454 1280 en0 2a00:1450:400f:804::2000fe80::9272:40ff:fe07:cc74%en0 UGHWIi 2 73 1280 en0 2a00:1450:400f:804::200efe80::9272:40ff:fe07:cc74%en0 UGHWIi 2 1476 1280 en0 2a00:1450:400f:805::2003fe80::9272:40ff:fe07:cc74%en0 UGHWIi 1 20 1280 en0 2a00:1450:4010:c07::bd fe80::9272:40ff:fe07:cc74%en0 UGHWIi 1 820 1280 en0 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 handling this situation by doing fall-back to something else. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: google path mtu?
On Fri, 23 Jan 2015, Tore Anderson wrote: I highly doubt that Google would be sending you PTBs. 10 SEK says it's your tunnel ingress router (i.e., your Airport Express)... I just took for granted that this would be the case because I've been told that google would be capping their communication at 1280. That's what I get for taking things for granted. But this could be found out, run tcpdump -nvi eth0 'icmp6 and ip6[40] == 2' in a terminal while reproducing the problem and see what's the source address of the PTBs? 08:10:06.394230 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1240) 2001:470:X:X::1 2001:470:28:35e:650d:12ec:4019:6a38: [icmp6 sum ok] ICMP6, packet too big, mtu 1280 You're correct. Wonder why I never noticed this before. So I guess this explains why I sometimes saw SYN packets coming from my machine with MSS 1440 and sometimes with 1220, the 1440 was for destinations by which there was no PTB seen (yet), and 1220 for the ones where PTB had been seen. Ok, thanks for helping clearing that up! -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: google path mtu?
On Mon, 19 Jan 2015, Mikael Abrahamsson wrote: But regardless, I had trouble this morning with Youtube that might be related to the same issue. I turned off my IPv6 HE.net tunnel yesterday because family was complaining about Youtube not working. I haven't enabled it again. Other people who had problems, are things working again now? It struck me that this should be possible to test on an host. Basically if the host can just respond to a packet with PTB, then checking if the size of the packets received changes or not would be interesting. Is anyone aware of someone implementing this already? Basic functionality: Would sniff traffic, send PTB packets for select sessions (configurable), and then I cold check using tcpdump or similar tool, if the packet sizes go down after the PTB has been sent. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: google path mtu?
On Mon, 19 Jan 2015, Ignatios Souvatzis wrote: I had some problems at home, which is not tunneled, but a less-than-1500-octet-mtu PPPoE DSL line, so - thinking it's tunnels only ignores an increasing number of native private users. Well, PPPoE is a tunnel, but I guess that's splitting hairs. But regardless, I had trouble this morning with Youtube that might be related to the same issue. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 6to4 in Internet aaaa records
On Mon, 13 Oct 2014, Nick Edwards wrote: boxes, the box is dual stack, we just need 6yp4 to send ipv6 onto its ipv4 address - oh and before some bright spark says it, because we From reading the above, 6to4 isn't what you think it is. 6to4 is a way to tunnel IPv6 on top of IPv4, it's not a translation mechanism. It seems you want a load balancer that can take an IPv6 incoming TCP connection and talk to your IPv4 only news server... or you want to just add a TCP bouncer that'll listen to an IPv6 socket and connect this together with a new IPv4 socket call to ::1. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)
On Mon, 22 Sep 2014, Stig Venaas wrote: Aren't the existing documents sufficient? See RFC 4541 RFC 4605 and also this is related draft-ietf-pim-explicit-tracking-10 RFC 4541 is only informational, not standards track. RFC4605 is standards track. The PIM draft is also standards track, but as far as I can see, there is no standards-track document for MLD/IGMP snooping. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)
On Wed, 17 Sep 2014, Enno Rey wrote: it should be noted that RFC 4541 is an Informational one and I don't think any normative value for a kind-of vendor-proprietary thing called MLD snooping might be attached to it ;-) I would like to see IGMP and MLD snooping properly standardized. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)
On Tue, 16 Sep 2014, Tom Hill wrote: I'd be quite surprised if you find a switch that doesn't treat ff02::1 in the same way as IPv4 broadcast, by default. Saying that, I'd much prefer that IPv6 WoL had a known IPv6 multicast address, as opposed to using ff02::1. This is actually quite interesting. I read RFC 4291: All Nodes Addresses:FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1 The above multicast addresses identify the group of all IPv6 nodes, within scope 1 (interface-local) or 2 (link-local). So, one interpretation would be that if the device hasn't subscribed to the all IPv6 nodes multicast group, it's not an IPv6 node, and shouldn't receive the traffic. Also, regarding the above, in order to keep being subscribed to a WoL multicast address group, wouldn't the NIC have to keep emitting REGISTER messages periodically? Is this something NICs do today, emitting packets while the CPU is in fairly deep sleep? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Residential subscribers: numbered or unnumbered?
On Tue, 25 Mar 2014, Philip Matthews wrote: What were your reasons for selecting this option? I see a few up-sides. You get clean /56 handoff to customer, and you don't need to have any of the customer GUA addresses on the ISP router, meaning control plane protection is easier. You also lessen amount of table entries you need for uRPF. Downside: People actually need CPE, they can't connect a computer directly (at least not without turning on Internet Connection Sharing or alike). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Bonjour / Apple / Service discovery
Hello. I have an apple 802.11ac latest gen timecapsule+airport express. It's currently sitting with its WAN port connected to a GUA IPv4 and IPv6 subnet. On that GUA subnet is an AppleTV3. The Apple Airport has an IPv6 subnet delegated to it using DHCPv6-PD, and does IPv4 NAT. On the wifi behind these NAT+PD are Apple iPads, all running latest software available from Apple. I want to be able to do AirPlay frmo the iPads to the Apple TV, but service discovery fails in this case and the units behind the NAT doesn't detect the AppleTV service announcements. So, this is a typical scenario that Homenet tries to solve with its hybrid DNS-SD proxy etc http://www.dns-sd.org/ http://www.ietf.org/proceedings/87/slides/slides-87-homenet-2.pdf http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-02 However, above probably isn't in any shipping code currently. I have seen examples out there where they put a linux box with avahi deamon connected to both subnets and use as a dnssd proxy. I don't want to do that. There doesn't seem to be any service discovery related configuration on the AirPort using the AirPort utility. Is there anything else I can do? I control the dns resolver that all devices use. I don't want to manually create entries, I would like this to be dynamic. If I at the same time could get devices to register their GUA IPv6 address at the same time (like dyndns) that would be an added bonus. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
On Fri, 17 Jan 2014, Mikael Abrahamsson wrote: On Fri, 17 Jan 2014, Templin, Fred L wrote: Sorry, I was looking at the wrong section. I see now that Section 8 is talking about a method for a CE to send an ordinary data packet that loops back via the BR. That method is fine, but it is no more immune to someone abusing the mechanism than would be sending a ping (or some other NUD message). By using a ping, the BR can impose rate-limiting on its ping responses whereas with a looped-back data packet the BR really can't do rate limiting. You don't ping the BR, you ping yourself via the BR. The BR only forwards the packet. My bad, I didn't read your text properly. Why would the BR want to rate-limit data plane traffic? -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
On Fri, 17 Jan 2014, Templin, Fred L wrote: Sorry, I was looking at the wrong section. I see now that Section 8 is talking about a method for a CE to send an ordinary data packet that loops back via the BR. That method is fine, but it is no more immune to someone abusing the mechanism than would be sending a ping (or some other NUD message). By using a ping, the BR can impose rate-limiting on its ping responses whereas with a looped-back data packet the BR really can't do rate limiting. You don't ping the BR, you ping yourself via the BR. The BR only forwards the packet. Also, Section 8 of RFC5969 only talks about the CE testing the forward path to the BR. Unless the BR also tests the reverse path to the CE it has no way of knowing whether the CE can accept large packets. You misread the text. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
On Fri, 17 Jan 2014, Templin, Fred L wrote: But, if the BR doesn't examine the packet it could get caught up in a flood-ping initiated by a malicious CE. The BR should have enough dataplane forwarding capacity to handle this. I am considering a specific ping rather than an ordinary data packet as a way for the BR to know whether the CE is testing the MTU vs whether it is just looping back packets. If the BR knows the CE is testing the MTU, it can send ping replies subject to rate limiting so a malicious CE can't swamp the BR with excessive pings. Why does it need to know? The CE is pinging itself CE-BR-CE, and if the CE doesn't receive the packet back then the MTU is obviously limited. So the CE sends out a packet towards the BR, with the IPv6 address being the CE itself. So the packet arrives at the BR, gets decapsulated, does IPv6 dst address lookup, gets encapsulated, and then sent onto the CE. Pure data plane. I don't get why the BR should need to get involved in anything more complicated than that? -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
On Thu, 9 Jan 2014, Templin, Fred L wrote: I don't doubt that your experience is valid for the environment you are working in. What I am saying is that there may be many environments where setting IPv4 link MTUs to 1520+ is a viable alternative and then the hosts can see a full 1500+ MTU w/o ICMPs. SEAL detects when such favorable conditions exist and uses limited fragmentation/reassembly only when they don't. Or, if fragmentation/reassembly is deemed unacceptable for the environment, then clamp the MSS. 6RD relays can be made cheap because they are stateless. 6RD implementation in hosts can be bade cheap, because it's easy. SEAL isn't stateless (obviously, since it can do re-assembly), thus increasing cost and complexity both in host and relay. So while it might have a technical fit, it isn't really an operational or monetary fit right this minute. 6RD is widely implemented today, by the time any other mechanism is implemented, the use-case for IPv6 tunneled in IPv4 might be much less interesting, hopefully more are moving towards IPv4 over native IPv6 for new implementations. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MTU handling in 6RD deployments
On Tue, 7 Jan 2014, Mark Townsley wrote: Note I've heard some ISPs consider running Jumbo Frames under the covers so that IPv4 could carry 1520 and 1500 would be possible for IPv6, but have not yet seen that confirmed to me in practice. Unless this is done in a very controlled environment I'd say this is bordering on the impossible. There are so many failure points for a jumbo solution it's scary. Most of them is also silent failure of PMTUD, basically blackholing of traffic. Yes, it can be done of course, but I'd say operationally it's easier to just drop the MTU to 1480 and known working, than the jumbo alternative. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: RA DHCP problem...
On Mon, 30 Dec 2013, Roger Jørgensen wrote: What is wrong with having something else than our _current_ RAs to provide defaultgateway on a network if the operator wish so? Let that be DHCPv6 or dibbler? Because the current method is known to work and you haven't given convincing arguments why it doesn't or why doing what you want is superior enough to warrant having two (or more) ways to do this? When I first looked into IPv6 I was of your opinion, why not do it the same way it's done in IPv4. Then I got over it. Operationally, I don't see having default gateway in DHCPv6 as something that makes much sense, apart from the fact that it means people have to learn less to start using IPv6, which I don't consider a valid use-case. For me, RA/RS/ND is all one single thing, you can't make IPv6 function without ND, so there is little reason to try to avoid the RA/RS machinery. A more valid use-case would be if you were propagating for new functionality and said that this would be easier to implement in DHCPv6 than in ND, and then you would get default-gw for free. That is the path I would choose. Unfortunately, the use-case that comes to mind (having routers that shouldn't have ::/0 pointed to them) is already implemented in by means of RIO in RAs. There is just very little deployed support for it as far as I know. -- Mikael Abrahamssonemail: swm...@swm.pp.se
i...@prizmaphoto.com
Every time I post to the list I get an email back from i...@prizmaphoto.com. Could someone please check if that address is subscribed to this list, and in that case, remove it? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: RA DHCP problem...
On Sat, 28 Dec 2013, Roger Jørgensen wrote: supply default gateway independing of RAs or no RAs. That is a client should be able to get only in a IPv6 only network _if_ there is no RAs, only DHCP there. Why? What problem are you solving by changing the current behavior? DHCP must support defaultroute and must be decoupled from RAs, no M-bit or whatever. M-bit is a hint, nothing in the standard says a host isn't allowed to use DHCP on a network. (tons of options on how DHCP and RAs can live together, all with their own pitfalls. From the simple one that dhcpclient can disable the kernel from accepting RAs with it's own pitfalls, to let the kernel sorting them out, and over to preferring either one - RAs or DHCPs defaultroute) Personally I think it's a huge mistake for an implementor to have the kernel process RAs, all this control plane should be done in userspace, not in the kernel. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: RA DHCP problem...
On Sat, 28 Dec 2013, Roger Jørgensen wrote: did you see the start of my mail? Yes. It should be possible to have a network running DHCP without any RA, if someone wants to do that. Why? Because I want to isn't a good technical answer. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 broken on Fedora 20?
On Fri, 20 Dec 2013, Lorenzo Colitti wrote: Sigh. Why do we keep reinventing the wheel? What was wrong with the in-kernel RA implementation? If you want to support other ND/RA functionality than the kernel supports, this is a good idea. Personally I think having ND processing built into the kernel is a mistake. -- Mikael Abrahamssonemail: swm...@swm.pp.se
question regarding Sweden IPv6 rollout
http://www.vyncke.org/ipv6status/project.php?metric=pcountry=se The above indicates that Sweden went from 0.2% to 0.6% in two weeks. I don't know what this operator that did this is, and I'm extremely curious. How can I find out? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: question regarding Sweden IPv6 rollout
On Wed, 18 Dec 2013, Lorenzo Colitti wrote: On Wed, Dec 18, 2013 at 9:59 PM, Mikael Abrahamsson swm...@swm.pp.sewrote: http://www.vyncke.org/ipv6status/project.php?metric=pcountry=se The above indicates that Sweden went from 0.2% to 0.6% in two weeks. I don't know what this operator that did this is, and I'm extremely curious. From what I can see, it's not an ISP. Now I am even more intrigued! -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: ipv6 source address selection
On Sun, 20 Oct 2013, Ole Troan wrote: wouldn't this be RFC6724: Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) CommonPrefixLen(SA, D), then prefer SB. The host has a bunch of /64s. I am pinging stuff outside of these /64:s. I am however pinging stuff in adjacent /64:s within the same /56 (or /48), but the host tables I can find has no information about /56 or /48s. $ ip addrlabel list prefix ::1/128 label 0 prefix ::/96 label 3 prefix :::0.0.0.0/96 label 4 prefix 2001::/32 label 6 prefix 2001:10::/28 label 7 prefix 2002::/16 label 2 prefix fc00::/7 label 5 prefix ::/0 label 1 I don't understand why the host would choose source address in 2001:db8:1:1000:/64 when pinging 2001:db8:1:1001:1/128 because of this, but use 2001:db8:1:8000::/64 when pinging the rest of the Internet (well, actually my hosts are in 2a00::/16 really, but never mind, should be the same). What am I missing? -- Mikael Abrahamssonemail: swm...@swm.pp.se
ipv6 source address selection
I'm trying to influence my source address selection. First I thought I'd figure out how it works by default. I have a /48. Let's call it 2001:db8:1::/48 I created three /64s on the same LAN with A-bit set so clients would do SLAAC within these: 2001:db8:1::/64 2001:db8:1:1000:/64 2001:db8:1:2000:/64 Then I set up loopback addresses on my router: 2001:db8:1:0001:1/128 2001:db8:1:1001:1/128 2001:db8:1:2001:1/128 Then I tried pinging each loopback address from a host which has 2 addresses out of each /64. It now picked a source address within the same /56. I consistently both on a Ubuntu 13.04 and OSX 10.8.5 machine get the same behaviour. So above means that pinging 2001:db8:1:1fff::1 it would use the :1000: address, and pinging :2fff::1 would use the :2000::/64 address. If I ping outside my /48 it will consistently use the last created address (I tried adding a 4th lan, 8000, and it then uses that one), which I perfectly understand. When I ping :5000: and so on, it will sometimes use the :: address and not the :8000: that is used for the rest of global traffic. I have nothing /56 or /48 magic in routing table or ip addrlabel list, but it still seems to be something special when it comes to the same /48 as the machine has addresses in. Any help understanding what is going on is appreciated. -- Mikael Abrahamssonemail: swm...@swm.pp.se
interesting about OSX, NAT64 prefix discovery
Macbook running 10.8.5 with latest updates. I am at the RIPE67 meeting, on their IPv6 only wifi. This has NAT64+DNS64 support. I had an entry in my /etc/hosts with an IPv4 address only, and was SSHing to it. By some internal magic, OSX had discovered the NAT64 prefix and was using it by itself to connect to this ipv4 only host. This caused great confiusion before I could figure out what was going on (didn't remember I had this hostname there), because when I was ssh:ing, it would first try the IPv4 address (using IPv4 LL, ie arp:ing directly on the link), and then it would try the IPv4 address mapped to the NAT64 prefix, which I couldn't understand where it came from. Well, I don't *know* this is what was happening, but I see no other mechanism that would explain the behaviour I was seeing. Anyone else seen this or know more? -- Mikael Abrahamssonemail: swm...@swm.pp.se
IPv6 only + NAT64 experience on iOS 7.0.2
Basic stuff works (web surfing for instance, I get 7/10 for IPv4 and 10/10 for IPv6 on testipv4.com, but so far installing apps via App store just fails silently. So I guess iOS 7 still doesn't have 464XLAT unfortunately. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: interesting about OSX, NAT64 prefix discovery
On Mon, 14 Oct 2013, Simon Perreault wrote: Did they implement the NAT64 prefix discovery heuristic? That would be great! Well, I dont know, but this is what happens: THis is without entry in /etc/hosts: dhcp-28-70:~ mikaelabrahamsson$ ping6 swm.pp.se PING6(56=40+8+8 bytes) 2001:67c:64:47:b501:73ad:3c6:867c -- 2a00:801::f 16 bytes from 2a00:801::f, icmp_seq=0 hlim=49 time=78.654 ms 16 bytes from 2a00:801::f, icmp_seq=1 hlim=49 time=81.850 ms ^C --- swm.pp.se ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 78.654/80.252/81.850/1.598 ms dhcp-28-70:~ mikaelabrahamsson$ host swm.pp.se swm.pp.se has address 212.247.200.143 swm.pp.se has IPv6 address 2a00:801::f Then I put 212.247.200.143uplift.swm.pp.se uplift swm.pp.se webmail.swm.pp.se in /etc/hosts and I get: hcp-28-70:~ mikaelabrahamsson$ ssh swm...@swm.pp.se -v OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013 debug1: Reading configuration data /etc/ssh_config debug1: /etc/ssh_config line 20: Applying options for * debug1: /etc/ssh_config line 53: Applying options for * debug1: Connecting to swm.pp.se [212.247.200.143] port 22. debug1: connect to address 212.247.200.143 port 22: No route to host debug1: Connecting to swm.pp.se [2001:db8:624::d4f7:c88f] port 22. debug1: Connection established. debug1: identity file /Users/mikaelabrahamsson/.ssh/id_rsa type 1 It's a bit strange, Chrome won't connect either, telnet doesn't work, but Safari does work, Firefox connects but it takes a very long time (minutes). So perhaps ssh and Safari/Firefox uses a different API call than the others? -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Microsoft: Give Xbox One users IPv6 connectivity
On Thu, 10 Oct 2013, Christopher Palmer wrote: The thing about protocols like UPnP - the vendors who would ignore an IETF recommendation are likely to be the same vendors to skip out on making an adequate UPnP stack. Most people today do NOT have home routers that support UPnP. Do you have numbers on this? My belief has been that most people today who care about anything more than web surfing would have a decently new gateway (less than 3-5 years old) and that this would support UPnP. I don't have any numbers so I would like to know more :) -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: PTR records for IPv6
On Mon, 2 Sep 2013, Mohacsi Janos wrote: Yes, but we must not forget temporary addresses. If the MTA has temporary addresses, then it will prefer them for its smtp sessions. So, one should either disable temporaries on all MTAs or use DNS dynamic updates. I think that it would be much wiser to deprecate PTR checks for IPv6. Why would you use temporary address on a defined SMTP server? Mostly because it's on by default. Even if you configure a static address and default gw, as soon as the system sees RAs it might start to use SLAAC based privacy addresses for outgoing connections. I've already seen this happen once, which caused problems sending mail to google. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Linux IPv6 routing strange behaviour
On Thu, 15 Aug 2013, Jeroen Massar wrote: Yes, that is 5 /40s worth of address space and everything is piped into the sixxs interface to a single neighbor that lives on the tapped interface. We thus indeed hit the Linux routing logic a bit, but as the table is small and it is a single neighbor nothing much dynamic happens there. ip -6 monitor route is thus nice an silent. So you're actually not seeing any flow based routing here? cat /proc/net/ipv6_route contains just those routes you see in ip -6 r show? Because in my linux kernel 3.2 based machines I have a lot more entries in cat /proc/net/ipv6_route than I have routes. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Linux IPv6 routing strange behaviour
On Wed, 14 Aug 2013, Max Tulyev wrote: What is the soultion? There are *MILLIONS* of flows in the backbone... The solution is not to use a flow routing platform in the core. This lesson was learnt at the end of the 90ties. So until the linux ipv6 forwarding code is fixed to do stateless forwarding, it's just not suited for your application. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Sunsetting Teredo Experiment [IETF slides]
On Sun, 4 Aug 2013, Sander Steffann wrote: Well, I am on that list, so the barrier is not *that* high ;-) Sander I sent in a subscription request after I saw this discussion and after a few hours, I am also subscribed. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: teredo.ipv6.microsoft.com off?
On Tue, 16 Jul 2013, Christopher Palmer wrote: If there is feedback on the ongoing experiment or our consideration of sunsetting Teredo, do let me know. So far people have been quite enthusiastic. I am too. I would really like to see 6to4 and teredo be default off everywhere, and people who want it can manually turn it on. If teredo went away completely, that would also be a good thing. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: same link-local address on multiple interface and OSPFv3
On Fri, 28 Jun 2013, Matjaž Straus Istenič wrote: Workaround is rather simple: use different link-local addresses on IPv6-enabled interfaces and you are safe. But, nevertheless, I think using same link-local pairs on links should not get you into any trouble, right? Correct, the same way that configuring fe80::1 on one interface and fe80::2 on a second interface, and on this second interface the other end should be able to have fe80::1 as its address, and everything should work fine. Everything else is buggy, as you already have concluded. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: New IPv6 king of the hill: Switzerland?
On Wed, 22 May 2013, Eric Vyncke (evyncke) wrote: So, back to normal and Switzerland now 'ruling' the IPv6 world with 9.47% vs. Romania which is now number 2 with 8.63% (and I do not talk here about the eurovision song contest of course ;-)) http://www.vyncke.org/ipv6status/compare.php?metric=pcountries=ch,us,de,fr,ro,se still showing CH in the lead. Do we have any insights from within Swisscom? Have they seen any problems reported to their customer service? Sharing of experience would be really helpful in trying to convince other organisations that enabling dual stack for end users is safe and is not going to cause a storm of complaints to customer service. -- Mikael Abrahamssonemail: swm...@swm.pp.se
enterprise IPv6 only client computers and IPv4 connectivity
Hi, If an enterprise today would decide that they're going to run IPv6 only on their LAN, they would have recent Win7|Win8|OSX|Ubuntu clients on their client computers, what mechanism would they use to access IPv4 Internet? My thinking immediately went to DS-lite, NAT64/DNS64 and MAP-E, but I NAT64/DNS64 isn't good enough without 464XLAT, and DS-lite and MAP-E requires additional software on most of these operating systems, right? Are these kinds of client software even available? What other mechanism could be used to achieve IPv4 Internet reachability over IPv6 only access for end-systems? HTTP proxy or SOCKS-proxy also sounds too cumbersome. -- Mikael Abrahamssonemail: swm...@swm.pp.se
