Compile IPv6 support into kernel image

[grigorig]

IPv6 is the next-generation internet protocol and it's becoming more important quickly. Due to that, it should always be available, and should be compiled into the kernel image instead of merely being provided as a loadable module.

[0b1-k]

I strongly disagree. I believe IPv6 is perfect as a loadable module.

[grigorig]

It's hard to follow without any arguments. How are you (e.g.) going to use an IPv6 NFS root? Do you see any problems with including IPv6 support by default?

In most cases it might also be sensible to instead load IPv6 by default on the relevant distributions, mostly Raspbian. That requires additional work, though. Given how ubiquitous IPv6 is going to be, including it into the kernel image makes perfect sense in my opinion.

[P33M]

The vast majority of Raspberry Pis attached to a local area network will be at the beck and call of a SOHO (small office/home office) router or crapware router that comes with your internet subscriber package.

We're about 10 years away from these sorts of devices properly implementing native IPv6 on their LAN interfaces. Once they do have some sane IPv6 support, how long is it going to be before the old, perfectly functional router is thrown out?

As an example, when loaded on 3.12 the ip6 module consumes:

ipv6                  308648  9 ip6_tunnel

300k of ram, thereabouts. The tunneling module adds about 20k.

This is more than all the other modules currently loaded on my Pi combined.

[grigorig]

We're about 10 years away from these sorts of devices properly implementing native IPv6 on their LAN interfaces.

This is simply ignoring reality. Many CPEs have had IPv6 support for a couple of years, and many ISPs are already handing out IPv6 prefixes to those. Some ISPs are actually doing CGN or DualStack Lite, due to lack of IPv4 address space. That is, they don't really give customers proper globally routable IPv4 addresses anymore, and require IPv6 for full end-to-end connectivity.

IPv6 will soon become much more important, simply because of necessity. All major address registries have exhausted their address pools.

Furthermore, link-local IPv6 alone can already be quite useful, as it gives the Pi a static local address, that will never change. I have used link-local IPv6 since the very beginning to communicate with Raspberry Pis in my personal networks.

This is more than all the other modules currently loaded on my Pi combined.

Yet it's a drop in a bucket compared to the total amount of memory available.

[P33M]

I've changed ISPs (in the UK, between two major wholesalers) twice in the last 3 years, each time I've gotten a crapware router. Neither has supported IPv6 on the LAN side in any capacity.

Also, the majority UK provider's offering does not support IPv6:

http://www.neilturner.me.uk/2013/07/18/bt-home-hub-4-review.html

IPv6 uses additional RAM and is not something the majority of users will ever need, therefore there's no point compiling the module into the default distribution.

Feel free to roll your own kernel should you require otherwise. There are plenty guides around on how to do that.

[grigorig]

Sorry, but your arguments don't make sense. The Raspberry Pi doesn't only target the UK, and your personal experience doesn't really matter a whole lot. The fact is that IPv6 has non-trivial rollouts in various countries with various carriers [1]. To give you some numbers, in the US and Germany about 8% of end users have IPv6 connectivity. And it shouldn't nearly take 10 years for that move forward. Of course, if people and projects keep on holding back adoption on purpose, it will take an infinite number of years.

[1] https://www.google.com/intl/en/ipv6/statistics.html

[JamesH65]

The Raspi is a memory limited system in some ways - using up 300k when the majority of users will not be using V6 seems daft. Keeping it as a loadable module means that only those people who have IPv6 need to use that 300k. And since by your own numbers, only 8% of people are using IPv6, that means 92% of people would be throwing away 300k of memory.

What's wrong with that?

If and when IPv6 becomes more commonplace - I'd say 50% penetration to be democratic - it can then be built in because more people would benefit than suffer.

And in the UK, I've yet to use any sort of IPv6...so P33M is not alone...

[grigorig]

Okay, if you really think the 300 KB are an issue, maybe the module can be loaded by default on Raspbian, at least? People that have memory-sensitive use cases could simply remove the module from /etc/modules, and save about 0.05% of memory.

I'm not really sure if there is a proper place to request this. According to [1] the lack of IPv6 actually causes problems with various packages, but one of the Raspbian devs said the Foundation are making their own images.

If and when IPv6 becomes more commonplace - I'd say 50% penetration to be democratic - it can then be built in because more people would benefit than suffer.

This is exactly the backwards attitude that caused slow IPv6 adoption. As much as I hate this saying, you are "part of the problem"...

[1] https://bugs.launchpad.net/raspbian/+bug/1216624

[ghollingworth]

If the call for this is greater then we may look at it but currently it just requires people modprobe the module...

Otherwise 300KBytes is a huge size for functionality that isn't going to be used for >90% of people.

Unless you can find a module to remove that uses more than this to compensate?

As for [1] above we shouldn't be adding it because other software packages have bugs, they should fix their bugs!

Gordon

[jeremyvisser]

I cannot even begin to fathom the ignorance in this bug report as demonstrated by the owner.

You are second-guessing a technical decision already decided on by the developers of every single other major OS out there, including all major Linux distros, Windows, and OS X who have all decided that IPv6 is necessary, and therefore enabled by default.

I understand that the Raspberry Pi has special requirements, but to second-guess IPv6 on this basis demonstrates arrogance that flies in the face of sanity.

IPv6 is a chicken-and-egg problem. By not enabling it, you are part of the problem. I demand that you enable IPv6 immediately.

[martyvis]

Clearly RPi has two main target markets - educational and embedded. In both cases, I can't imagine why IPv6 support would be optional. Schools and universities have some of the biggest takeup of IPv6 on the LAN, mainly in order to provide scalable multi-campus deployment that allows more direct interaction with the rest of the Internet, rather than via proxies, and NATs, and so on. In the embedded space, if you are looking at deploying thousands or more devices to participate in the Internet of Things, you would be crazy to not be owning your own address space no matter where you deploy, driving you towards IPv6. Crazy and muddle-headed to not have IPv6 in the standard build.

[grigorig]

@ghollingworth

As for [1] above we shouldn't be adding it because other software packages have bugs, they should fix their bugs!

Well, I don't believe Debian consider these issues bugs, because they ship with IPv6 enabled by default. As you should be today, RFC6540 [1] mandates that all new IP nodes must support IPv6.

And again, I still can't understand why these 300 KB of memory should matter. It's only 0.1% of 256 MB or 0.05% of 512 MB RAM. There is a lot more bloat going on in the userspace by default (lots of gettys, thd, etc.). The Raspberry Pi really isn't THAT resource constrained. And again, I think the module is mostly fine as long as it is automatically loaded. It's simply really suboptimal at the moment. Especially for headless Pis it's bad, they won't have connectivity over IPv6 by default, while IPv6 is incredibly useful for the "first contact" due to the always available link-local addresses.

@jeremyvisser I know that some people have a passion for IPv6 (me included), but I think you should be a bit more polite and level-headed here.

[1] https://www.rfc-editor.org/rfc/rfc6540.txt

[duncaninnes]

I use IPv6 at home. I'm not alone. There are more of us than you think or expect. To exclude this on the basis of 300kb I believe is short sighted. RPi should be seen as solving problems, not being part of the problem.

[harishpillay]

IPv6 support should be in as a default. No need to argue about this. Doing it correctly paves the way for very interesting use cases. Denying it as a default will deny innovation in networking possibilities.

[tomstorey]

As a loadable module, IPv6 is too easy to continue ignoring, and thats a bad thing right now. No one realises the utility of something if it is kept stashed away in a dark corner of the room. And before something becomes popular people need to know about it, how they can use it, and why they need to use it.

To suggest that IPv6 is "not something the majority of users will ever need" is incredibly naive. If you properly understood the problems that the more finite nature of IPv4 will cause you would probably change your mind. CGNAT is one example.

And the year is 2014, not 2004 which is when we should have been talking about being 10 years away from cheap crappy CPE having decent support for IPv6 - and that would have been acceptable. To wait until 2024 is so completely and utterly unacceptable at this point in time it would have to be seen as negligence by the related industries.

Also, Google sees "only" 3.3% of its traffic via IPv6, but thats no small amount on Google scale. If they'd waited until 50% of their users were on IPv6 before enabling it themselves they'd already be far too late for the party, and couldnt claim to have helped its adoption and development in any way. If you look at the rate at which they are picking up IPv6 traffic, its not hard to see that in a couple of years it will represent a figure that is not at all insignificant... https://www.google.com/intl/en/ipv6/statistics.html

And your ISP not offering IPv6, and/or not giving you an IPv6 capable router is no real excuse. There are IPv6 tunnel brokers that will give you more address space than you can poke a stick at, and all for free. All you need is an IPIP tunnel to them and a minor investment in a better router. Ive been doing this since 2006 (bar a small period when I still worked for an ISP that offered native IPv6 on their broadband services), its not the best but its a damn sight better than nothing at all.

[danrl]

How much RAM can we save by making legacy IP loadable? All the fuzz for 0.05% of RAM and ignoring IPv6. Ridiculous!

[JamesH65]

I have to say the rudeness and sense of entitlement shown in some of the more recent posts here beggars believe. Do people REALLY think that DEMANDING stuff makes it any more likely to come to pass? Exactly the opposite I would have thought.

As stated above, IPv6 has 8% penetration (best case). Why should 92% suffer for those 8%? Do people REALLY think that enabling IPv6 by default on the Raspi will make IPv6 takeup worldwide any faster?

As for schools being big on IPv6. HAHAHAHAHAHAHA. Schools in the UK are lucky if they have routers less than 5 years old.

And I am also not sure that anyone said that IPv6 was something 92% of people would NEVER need. Just that they don't need it RIGHT NOW. Which at 8% penetration is clearly correct for 92% of people. The other 8% are simply an insmod away. One line of typing vs 300kb loss of memory for the majority of Raspi users. As an aside, the carelessness with which people throw away memory in their systems is one of the reasons code nowadays runs like a dog on anything but big memory systems. 300Kb is 10 times the memory I had on my first computer...

Interesting Fact. The company I work for, a leading supplier of networking chips, runs in internal IPv4 network....

[mrjester888]

Just that they don't need it RIGHT NOW

Have you noticed that none of the RIRs have more than 1 /8 left?

[JamesH65]

Most Raspi's are behind a router and get internal addresses (192.168....), so isn't that irrelevant unless the Raspi is directly connected? Serious question.

[mrjester888]

The immediate concern for typical end nodes is, as the available v4 pool runs out it will be harder and harder for a new service/site/anything on the internet to get a v4 address. This means that if you want to access the latest google/facebook/whatsapp/github/whateverNewAndFantasticService, you will have to have a v6 address on the device.

Some great new cloud based streaming service gets created, without v6 being a standard configuration feature on device, these services risk not being able to survive as it requires additional effort on the end nodes part just to access it.

This may not seem like a big deal, but it is a death by a thousand cuts kinds of problem. There is a reason all of the modern OSes have it enabled by default. There is a reason internet backbone providers support it. There is a reason why companies like Google, Facebook and Microsoft are deploying it for their services. The writing is on the wall and they don't have their heads in the sand.

[JamesH65]

I'm confused. My Raspi at home has a IPv4 address as allocated by DHCP by my router. My router doesn't support IPv6 (either for internal network or out to the host provider). Does that mean Facebook, Google etc stop working?

I pretty sure it doesn't. So why do I (and the many many people in exactly the same situation) need to use IPv6?

[tomstorey]

@JamesH65 Im pretty sure youre just trolling, but on the off chance you really do just need this much help...

Lets go back to the 1880s. The modern automobile is born. And youre sitting there saying "Why do we need these, we already have horses. I can get from A to B and move stuff around town perfectly fine with my horse, what good does this automobile do for anyone?"

Right now, this is not about what you cant do without IPv6, its simply about moving towards the better solution. What you cant do without IPv6 is likely to become more topical over the coming years as IPv4 just becomes too difficult to obtain for the newer service and content providers.

Your router can be replaced with something that has the functionality to allow you to hook up to one of the many free IPv6 tunnel brokers. That will get you IPv6 connectivity to your LAN until your ISP gets its act in to gear, and typically comes with a /48 subnet which is more address space than any mortal individual can utilise. And thats if there isnt already a free/open source firmware alternative available for it with that functionality, which means you dont have to spend a cent. Zero excuses now.

[pmarks-net]

Defaults matter, and IPv4-only kernels create negative externalities.

The Linux socket APIs allow you to create a single AF_INET6 socket, bind to [::], and receive connections from both IPv4 and IPv6 clients. But if you run a kernel with "ipv6" patched out, then those operations fail.

Thus, this inconsistency forces developers to either implement both the AF_INET6 and legacy APIs, or be lazy and go with AF_INET only. RAM is dirt cheap these days, but human labor is as expensive as ever.

[grigorig]

I pretty sure it doesn't. So why do I (and the many many people in exactly the same situation) need to use IPv6?

It's not so much about the big dogs like Google or Facebook, which probably have some IPv4 address space reserves. Some sites are only available over IPv6 right now. And the number will increase in the future. In addition, many residential ISPs have switched to DualStack lite (full IPv6, CGN IPv4) due to lack of IPv4 space. IPv6 is not only important if you (or your ISP) is lacking IPv4 addresses, but also the other way around. If you want to be able to communicate with all of the Internet, you need IPv6.

[DAFlippers]

For what it's worth.

RAM usage for IPv6 module. 8< This is more than all the other modules currently loaded on my Pi combined. This means including IPv6 support is not a trivial decision

Comment on RAM usage. 8< RAM is dirt cheap these days

External RAM is cheap but if the RAM is on-chip it is an absolutely limited resource so usage has to be carefully considered.

300KB RAM for IPv6 support - I presume this could be reduced if time was spent on optimising RAM usage.

Taking the above into consideration and the fact that it is possible for IPv6 support to be added then at this time I would:

Provide IPv4 support as is Simplify and document the process for users to add IPv6 support if they wish Keep a watch on IPv6 usage/requests and reassess this decision on a regular basis.

Just my thoughts based on the situation right now.

David

[martyvis]

@JamesH65 obviously if you are only interested in one RPi on one home network, it is irrelevant to you. But say you want a swarm of RPis, maybe thousands, all mobile, all connecting intermittently. You want them to be autonomous and be able be talked to asynchronous. Sure you can poll a central server, and NAT, and stuff, but how do you talk back to a unique address? IPv4 doesn't provide a solution in the world we live in now - you can't guarantee globally unique IPv4 addresses - they're just not around. If you think beyond playing around at home or even a few in a school room, you won't see the problem.

[DAFlippers]

@martyvis
8< If you think beyond playing around at home or even a few in a school room, you won't see the problem.

Did you mean: "If you don't think beyond playing around at home or even a few in a school room, you won't see the problem."

David

[pmarks-net]

Have you compared the RAM usage of loading the module, versus compiling it in? I'm guessing it's similar, but it makes sense to check.

If IPv6 does in fact use enough RAM to make its deployment economically unfeasible, then we need to work with the kernel community to figure out where all that RAM is going, and fix the problem.

As a point of reference, 300kB is equivalent to 7500 IPv6 packet headers.

[Ferroin]

Just a thought, but I think I remember reading somewhere (In the context of building kernels for Ubuntu I believe) that when IPv6 gets loaded as a module instead of built in, the kernel has to do a check to see that the module is loaded for EVERY IPv6 packet it receives. or tries to transmit. Considering that one of the biggest benefits of IPv6 (other than the increased address space) is the improvement in efficiency that it offers over IPv4. Also, the overhead of compiling something into the kernel statically is less than loading it as a module since it dosen't have the extra dynamic linking overhead.

As for those complaining about 300k of RAM usage, you should : a) Use the zram module for swap b) Get some fast secondary swap (ie, a cheap USB device) c) Consider the fact that, while 300k may seem very significant, you could easily save more than that much space by not using anything written in Python or Perl, or by disabling any kind of desktop background.

[0b1-k]

"c) Consider the fact that, while 300k may seem very significant, you could easily save more than that much space by not using anything written in Python"

This discussion is getting crazier every day.

[DAFlippers]

I believe there are a lot of passionate people pushing the IPv6 cause. I also believe that well over 80% of RPi users don't even know what IPv6 is and many will be running the same image that they first used. Those users are also probably not very vocal here.

I can see it would be sensible to include IPv6 support in the build but if this is for <5% of users to use at this point in time and those users are tech savvy enough to incorporate the code into their own kernel build then wouldn't it be better for those users to act as a test bed for IPv6 and allow the support to concentrate on issues that affect the majority of users?

To suggest removing some of the tools that allow people to learn about computers and programming, which after all is the RPi's prime objective, is simply silly.

To summarise, plan to incorporate IPv6 in the future roadmap and utilise the IPv6 protagonists to use , manage and support an IPv6 variant to give the code a real world soak test. I am sure there will be enough volunteers to do this given the knowledgeable posts on this matter.

David

[Ferroin]

I think that point C in my previous post was misunderstood, I was not in any way intending to suggest that any distributions remove either Python or Perl (Python is too good of an educational aid, and trying to remove Perl from most distributions is like pulling teeth from an alligator). I was simply intending to offer a point of reference for those who think that 300k is a ridiculous amount of memory to consume. As for the bit about not using a desktop background, I actually have it disabled on the one RPi that I actually use a graphical environment on and it saves almost 5MiB of memory at runtime.

[ghollingworth]

@DAFlippers

I agree, I was thinking of asking Alex to add the IPV6 enabling to raspi-config, then it's a simple job to enable without having to permanently load the module.

On a separate note, seriously IPV6 300kb... Doesn't anyone else think this is a bit heavyweight... I once wrote an IPV4 layer for a transputer and it was a couple of kb! Is IPV6 that much more complex, or is it just huge buffering (that we don't need since our max throughput is only around 70Mbits)

[asb]

Yes, ipv6 enabling in raspi-config is sensible. The only reason it's not there now is I was worried it might trigger a flame-war such as this about why you need to opt-in to ipv6 in the first place!

[grigorig]

@ghollingworth

On a separate note, seriously IPV6 300kb... Doesn't anyone else think this is a bit heavyweight...

IPv6 isn't really any more complex than IPv4, in some ways it's actually simpler. You can easily make a minimal IPv6 implementation fit into a couple of kilobytes (IPv6 on 8-bit MCUs has been done, check out uIPv6), but Linux ships a very feature complete and performance optimized implementation.

And, as far as I can tell, the Linux IPv4 implementation isn't particularly slim either... nonetheless I still don't really see how all of this matters on a device that has hundreds of megabytes of memory and is using a standard desktop Linux stack. I don't think this is opening the floodgates (and people will come and ask for inclusion of features that are actually pointless). I kind of have the impression that is what you might be fearing?

@asb Adding a raspi-config option for enabling IPv6 would be a good step forward!

[jeremyvisser]

@asb

Yes, ipv6 enabling in raspi-config is sensible.

Only if enabled by default. Otherwise I would not accept this as a solution.

Still suboptimal, as giving people an easy way to disable IPv6 promotes superstition (for some reason people believe disabling IPv6 is a valid way to work around problems, which is remarkably ignorant).

[DAFlippers]

@jeremyvisser

Can I suggest you edit your last mail to read:

"Yes, ipv6 enabling in raspi-config is sensible.

That is a great idea and I will work with others to test IPv6 in real world situations so we iron out any issues prior to being included in the standard build. Personally I believe we should set a target to incorporate IPv6 in 2-3 months and I look forward to the team's agreement on setting this target."

This is far more likely to achieve your goal than your than 'poking a stick'.

David

[ghollingworth]

It's easier if I just delete his comments... People who can't discuss issues without being passive aggressive don't get to have an opinion

[vk5tu]

Hello folks,

Have a I missed an important point here?

IPv6 is available as a module. In Raspbian if you comment out or delete /etc/modprobe.d/ipv6.conf then IPv6 comes up at system start. ifupdown gives interfaces IPv6 addresses at the same time as all of the other protocols. All of the packages have been compiled with IPv6 present, so Apache, SSH and so on are ready to work with IPv6 as-is.

I quite successfully run a website, DNS master, SMTP mailer and IMAP spool running IPv4 and IPv6 from a SLAAC subnet on a stock kernel Raspberry Pi using Raspbian with no recompiled packages; namely http://www.gdt.id.au/. I also run a ADSL gateway on a Raspberry Pi with IPv6, again with stock Raspbian and kernel. This is documented at http://vk5tu.livejournal.com/37206.html.

The request was to compile IPv6 into the kernel. That is, that it be available during very early boot. It's difficult to think of scenarios where that is useful to an RPi user.

I don't really take NFS root seriously on the RPi. The RPi lacks PXE on boot, so a lot of the systems administration advantages of running NFS root are already missing. In any case, NFS root is more of an argument for port of a bootloader which will allow a initramfs and thus allow any module to be accessed during early boot; for example, what if you want to use a USB/WiFi dongle for that NFS root?

Although I agree that IPv6 should be on by default, that's not a kernel issue, that's an issue for Raspbian.

Claims of ignorance, arrogance, etc seem to me to be excessive in light of the limited additional IPv6 functionality being requested.

Best wishes to all, glen

Glen Turner http://www.gdt.id.au/~gdt/

[asb]

Thanks Glen for your most reasonable response. Just to clarify the "issue for Raspbian" part. Not loading the ipv6 module by default is a Foundation decision rather than one made by the upstream Raspbian developers, which is one reason why the debate is going on here.

[grigorig]

@DAFlippers there is no reason to believe that enabling IPv6 by default will cause any problems, though. It is not some immature or new tech, and enabled by default and all consumer OSs.

Still, adding a toggle to raspi-config is good, as it will raise some awareness about IPv6.

@vk5tu

The request was to compile IPv6 into the kernel. That is, that it be available during very early boot. It's difficult to think of scenarios where that is useful to an RPi user.

Well, that was just an example, but I think there are some NFS root users (I used it myself for SD card compatibility testing). The primary reason why I'd like to see IPv6 enabled is simply because there is no particular reason to not have it, in this day and age. Ignoring IPv6 will stiffle adoption, and it's already too slow.

Some service providers will only see the light when they ask their LIR/RIR for IPv4 address space and finally get a "no" back. End users are already suffering from address shortage on a large scale, though. There are Carrier-Grade NAT rollouts everywhere. Also in Britain.

[vk5tu]

I agree, I was thinking of asking Alex to add the IPV6 enabling to raspi-config

That would be good. Turning it on is easy (change /etc/modprobe.d/ipv6.conf and modprobe ipv6), turning it off needs a reboot because a stack of other modules will be holding IPv6 resources (change /etc/modprobe.conf/ipv6.conf, reboot). In any case the reboot stops people getting into strife trying to turn off IPv6 from a IPv6-using ssh session :-)

It would be worth mentioning in the help screen that the interface is activated for native IPv6 networking, obtaining addressing using stateless addressing. Further command-line work is needed to set up stateful addressing, an IP tunnel to a IPv6 provider or PPP to a IPv6-native ADSL ISP.

On a separate note, seriously IPV6 300kb... Doesn't anyone else think this is a bit heavyweight... I once wrote an IPV4 layer for a transputer and it was a couple of kb!

IPv6 is slightly more complex than IPv4. Consider that it includes the address allocation which IPv6 pushes to user-space. But IPv4 and IPv6 aren't too far apart in LOC.

What's changed since the Transputer is the nature of the network. I'm sure your implementation was perfect, but I'm also also sure that it didn't do data structures for a routing table of half a million routes, or to be able to sustain some tens of thousands of concurrent connections, or to provide exactly the same resource use whatever the route used, or to rate-limit ICMP responses. Unfortunately the nature of the modern Internet means that if you don't do these things then some mongrel will simply exploit whatever implementation shortcut you took. Look upon it as "a couple of kb" of code, 98kb of feature creep, and 200kb of hard-earned lessions about the ways software can be abused.

Cheers, glen

Glen Turner http://www.gdt.id.au/~gdt/

[vk5tu]

Just to clarify the "issue for Raspbian" part. Not loading the ipv6 module by default is a Foundation decision rather than one made by the upstream Raspbian developers, which is one reason why the debate is going on here.

Thanks Alex, so that's what I had missed. My apologies.

My $0.02 is to turn it on by default for two reasons, one practical, one philospohical.

Practical: The eth0 interface will come up with a link-local address upon boot. The MAC address is printed on the box, so a simple algorithm (hidden behind a web page if you want) can convert that MAC address and the user's own link-local address into the address which they can use to ssh to their new RPi. This makes getting started with a headless pi much simpler. Note carefully that IPv6 link local addresses exist even where there is no global IPv6 service (on the so-called "IPv4 only network" you have at home).

Philospohical: The RPi is about teaching programming. IPv6 is the future of networking. I know that penetration in the UK is low, but for Comcast IPv6 is 50% of their traffic. Services from Google, Facebook, etc offer both IPv6 and IPv6. Understanding IPv6 is pretty much required for network programming.

Having said that, I'd make it very easy to turn off (ie, raspi-config).

I would also make it very prominent in the release notes. Reminding people that in this release that if they have configured iptables to limit access then they must also configure ip6tables in a similar fashion. I'd even put a "deny all" ip6tables configuration into the release notes for people to cut-and-paste. Mention that they must configure the firewall even if they are on a IPv4 network (because they'll still get a IPv6 link-local address).

Aside: I'd also like to point out the usefulness of IPv6 for embedded systems. Those systems struggle with how to automatically and securely find and connect with neighbours, such as controllers and user interface units. IPv6 link local, zeroconf's mDNS SRV records, HTTPS with a certificate-controlled access, and REST gives a reliable, secure and easily programmed approach. Using standards building blocks allows simple extension of the system into the wide area or interfacing with customer's own systems.

As for a Certain Employer: do encourage them to get IPv6 on their network. We recently bought new switches and management via IPv6 was mandatory as we're not going to waste perfectly good IPv4 addresses on the interior of our network when we could be using them for customer access (or at other ISPs: assigning them to customers and getting revenue). At NANOG the vibe was very much that IPv4 enterprise addressing doesn't scale for large switch purchasers such as ISPs and cloud providers (as too many people want to use network 10 -- the customers, the network, the VMs in the servers -- and the result is unmanageable). This does have a pushback into hardware design (eg, a fixed TCAM split for each address family gets annoying enough that we ask vendors about their TCAM entry allocation technique).

I've now wandered well from the topic, thanks for your tolerance, glen

Glen Turner http://www.gdt.id.au/~gdt/

[DAFlippers]

@grigorig I realise it is not likely to cause issues but the possibility cannot be ruled out. Demanding something immediately raises barriers however offering help is more likely to achieve the ultimate goal.

David

[martyvis]

More grist for the mill. From http://www.theregister.co.uk/2014/04/24/ipv6_iot/ - "Yes, within the existing IPv4 infrastructure you can do things such as network address translation (NAT), but in terms of scalability and sustainability and actually being able to support the capability we're talking about – some 50 billion devices by the year 2020 – that's going to be really difficult to do on a IPv4 environment.

I think the adoption of IPv6 will be key. The ability for the UK in particular to start to more heavily deploy it at a consumer level is also important."

[grigorig]

It should also be noted that the size of private address ranges from RFC 1918 are too small for some companies already. In addition, because there are so few ranges, collisions are common. So it does indeed make sense to also use IPv6 for private networks and smaller local area home networks.

[grigorig]

Some time has passed and IPv6 support is even more important now. Many more ISPs provide native IPv6 (for instance, there's about 14% IPv6 rolled out in US and DE) and the IPv4 shortage is quite a problem. So, how about enabling it by default now?

@DAFlippers I'm not demanding IPv6 support, I'm asking for it and I try to prove with data why it's necessary and useful. Maybe some people are not that constructive, but it's easy to get emotional at some point if people so often just refuse to listen. Especially if you're passionate about this.

[pete-mb]

I have rolled out IPv6 on the internal office LAN inside Raspberry Pi. Their hosting LAN is already IPv6 only (no IPv4, no RFC1918) c.f. http://blog.mythic-beasts.com/2016/03/09/rebuilding-raspberry-pi/, and some (currently fun only e.g. http://stats.pi3.raspberrypi.org/) internal bits and pieces are only available on IPv6 networks. As of March 2016, 9% of traffic to their site is IPv6.

[ghost]

My personal opinion: I agree that IPv6 support is important, but the Pi is a small hackable computer and I believe that every kernel feature that isn't absolutely necessary should be a module that can be loaded/unloaded by the user. As it is IPv6 is enabled, just as a module, and I'm glad it is, as it's one of the first things I disable when I write a new Raspbian image. If/when my ISP implements IPv6 support I'll happily use it, but I'll still be glad it's a module.

[grigorig]

I believe that every kernel feature that isn't absolutely necessary should be a module that can be loaded/unloaded by the user.

By that standard, the standard kernel configuration already is quite bloated for most use cases. Just saying...