What a terrible logo design, and semingly no real buy-in from any major organization. I'm not surprised this doesn't have any traction.
I think an IPv6-compliance logo scheme would be a good idea, but it should be driven by major commercial vendors like Apple, Microsoft, Google etc on the software side, and supported by industry forums like the WiFi Alliance and the GSM Association on the hardware side. I would love to be able to ditch IPv4 entirely for running large production networks.
I think Apple have already started to enforce IPv6 support on iOS apps. It would also be interesting to audit open source projects for IPv6 support; just the presence of the appropriate API calls would probably be sufficient for a first hack to tell the difference between IPv6-compliant and non-IPv6 compliant applications. This would allow influential distros like Debian to start the process of deprecating old software which is incapable of working properly with modern networks.
The about page says the logos have been available since 2003/2005. It looks exactly like a logo from 2003.. so I don't think it's terrible at the time it was designed... it's just dated.
If you look at the approved products page and sort by date, you'll see Samsung, IBM, Cisco, Intel, ZTE, Nokia and lots of other tech companies--software and hardware. So clearly they were involved early on.
> I think an IPv6-compliance logo scheme would be a good idea, but it should be driven by major commercial vendors like […]
Have you bothered to investigate what this program does actually does? Approval entails interoperability testing: the below Cisco against Arista and Juniper routers, and RHEL and Windows hosts.
The govt takes a stance that most vendors can't be trusted on their word so everything to be purchased must undergo a certification process to ensure that it meets the baseline requirements.
I'm really uncertain if this is not just some joke page. But I went to the ipv6 Forums page [1] und they have even more horrible logos/certificates and their websites looks like it might be made bevore ipv1 was a thing...
Is it worth doing a brand refresh for a 15 year logo where the mission (hardware support for IPv6) is pretty much "mission accomplished"? It's been a little of the software side, and a lot of the operator side that is left for the gap.
An absolutely comically bad logo design. I mean, that is worse than atrocious. If you're going to attempt to design something, at least possess the intellect to know that you must be good at what you're spearheading.
Just looking at the horrible logo mashed into the header that is 100% illegible because its like 50px wide is all you need to know.
Isn't this ancient? I saw a logo like this many, many years ago, and the ipv6 support was still really really shitty (eg. firewall for ipv4 being full-featured while one checkmark existed for ipv6 - pass through everythong or nothing).
EU has some financing rules, where in many cases, you cannot buy any equipment with public money if it doesn't support IPv6, and RIPE-554 (now 722 - https://www.ripe.net/publications/docs/ripe-772 ) was written just to avoid the "ipv6 ready" devices... so many tenders had a ripe 554/722 requirement written in back then (now it doesn't really matter, since most of equipment adequately supports ipv6, at least the stuff from "big vendors".
edit: yeah, right from the ripe772 : "While the Logo certification was devised around 20 years ago..."
That logo is not only ugly, but functionally deficient when it comes to hardware.
This design can only be applied to equipments as a sticker as it is impossible to directly imprint into the mold.
Not only this increases the cost (negligible, I know), but for devices that are meant to be used for years, it will just degrade and won't be as visible.
Since we're already talking about IPv6, I'll take the opportunity to bring up a topic I've been thinking about recently. If they were already redesigning the IP protocol, why didn't the creators of IPv6 ensure good support for multiple/changing IP addresses? For example, couldn't they have extended port numbers to 128 or 256 bits and recommended that IP flows be identified just by the pair (source port, destination port) instead of the current (source IP, source port, destination IP, destination port)? That would make it possible, for instance, to start a HTTP upload via an LTE modem but finish it on WiFi without interrupting the connection.
> For example, couldn't they have extended port numbers to 128 or 256 bits and recommended that IP flows be identified just by the pair (source port, destination port) instead of the current (source IP, source port, destination IP, destination port)?
Port numbers aren't part of the IP layer. Regardless, IPv6 contains a 20 bit flow label (https://datatracker.ietf.org/doc/html/rfc6437) that can be used to indicate a specific (sub)connection. I don't think it's ever used, though.
> That would make it possible, for instance, to start a HTTP upload via an LTE modem but finish it on WiFi without interrupting the connection.
That's already technically possible, but not in the IP layer. Multi-path TCP solves this problem exactly how you would think, by agreeing on an identifier between two hosts and performing a handshake over an alternate route using that key. iOS uses it by default for various services. This can even be used to bundle the connection (upload over LTE and WiFi at the same time for maximum network speed) or theoretically to do weird stuff like upload over ethernet and download over WiFi.
Sadly, many Android devices still run old Linux kernels so MPTCP is disabled on there by default, though more recent devices should support it just fine. Many networked clients also don't use it, though I'm not sure why; it's just an option flag in TCP, if the network is fucked up by corporate middleboxes, the connection will just behave like a normal connection.
If you're ever writing a TCP server or client, consider enabling MPTCP by default!
Depends on your programming language and platform.
If you're using the C API on a Linux kernel, use IPPROTO_MPTCP instead of IPPROTO_TCP. With Go, call SetMultipathTCP(true) on listeners and other connections. On iOS, set MultipathServiceType to NSUrlSessionMultipathServiceType.Handover for your NSUrlSessionConfigurations.
Depending on your platform, you may need to do a quick "is MPTCP supported" check with fallbacks, i.e. when you need to support older Android, Windows, or BSDs, or an old (<5.6) Linux kernel.
How do you route all these IP addresses to the correct destination ? Actually all the IPv6 prefixes are know to all big routers (ASes, but that's getting technical). It's called the default free zone and it is growing by the day.
The more non-aggregatable IPs, the more space on the route table of routers is occupied. And this space is really expensive
I think the reason this never gains any user mindshare while other technologies like 802.11<x> or 5G do is because ipv6 doesn’t actually change anything about the user experience. So why would they bother putting it on the marketing material?
I think that’s the chief reason it’s failed to catch on at any meaningful rate. It may be good overall or have long-term effects, but if any one typical use asked you, “what will be different for me if I buy this?” there’s no answer.
In data centers we are used to that IPv6 is cheaper, IPv4 addresses cost real money. If IPv6 only were cheaper for consumers it would make a difference for them.
But maybe that's really only relevant for routable static addresses and consumers typically don't need any. I understood e.g. T-Mobile US consumer subscriptions are IPv6 only already now. (Not living there, so from hearsay) It's just transparent to the customer via NAT64 where needed? And obviously all somewhat recent phones just work, so no logo required.
> T-Mobile US consumer subscriptions are IPv6 only already now.
I'm a T-Mobile US customer. This is correct - the only real address your phone gets is IPv6. I believe V4-only sites are reachable using 464XLAT (RFC6877, RFC7335) or equivalent.
> I think the reason this never gains any user mindshare [...] is ipv6 doesn’t actually change anything about the user experience
Lots of purely technical things which have no impact on user experience take over old technologies.
The issue with IPv6 is that it has no visible impact on users -_and_ it's a major paradigm shift in terms of complexity and addressing scheme compared to v4.
Every year I secretly hope some major consortium with traction release "IPv4 2.0" with 8 bytes and get done with it.
> Every year I secretly hope some major consortium with traction release "IPv4 2.0" with 8 bytes and get done with it.
How exactly would this work?
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
Those are the exact same challenges as with the IPv6 roll-out.
And of course "IPv4 1.0" continues to work, so what motivation is there for going to your "2.0"—just like what motivation is/was there for going to IPv6 when IPv4 is/was 'working'?
See "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):
I never said moving from 4 to 8 bytes would require less changes that IPv6.
The problem of adoption with IPv6 is not technical. It's that IPv6 changes radically how we thing about IP networks.
IPv6 explodes all existing concepts of DHCP, DNS, NAT, etc. You have an entire generation of network, system and software engineers that have no clue at how IPv6 work, no existing infrastructure to learn it, and somehow expect that it's going to stick.
I say, let's solve the 90% that is really problematic with IPv4, being the number of adresses, and the rest is moved to some other standard.
> It's that IPv6 changes radically how we thing about IP networks.
I never understood this line of thinking.
You put your Layer 4 bits into a Layer 3 packet with a larger address space, then stuff that into a Layer 2 frame, and send it off onto the wire/air waves.
You can have DHCP(v6) if you wish. DNS is only different with a new record type (AAAA). NAT-y stuff can still be done, but stateful firewalls are not different.
The fact that you can—if you wish—have less infrastructure (no DHCP server, no NAT (but still SPI)) should make it easier to deal with, not harder.
> The fact that you can—if you wish—have less infrastructure should make it easier to deal with, not harder.
Look, I don't know what to tell you, honestly.
I tend to think I'm fairly more litterate in networking than most software engineers. I am no network engineer, but I have spent most of the last decade writing networking software, including layer 2 VPNs.
I am also genuinely interested in understanding new tech.
Yet, IPv6 _terrifies_ me.
Every 2 years or so I'm in the mood of learning it. And every time, after reading docs on the subject, I'm like "Nope, I'll wait til I retire to get my IPv6 PhD".
Maybe that's just a matter of finding a proper, accessible documentation. I always end up thinking "okay so that's a total big bang I have to rethink entirely everything I know about L3".
On a Linux router, you would set this up by doing:
ip addr add 2001:db8:ffff:200::2/64 dev wan0
ip route add default via 2001:db8:ffff:200::1
ip addr add 2001:db8:42:1::1/64 dev lan0 [like "192.168.1.1/24"]
Then install radvd, put the following into /etc/radvd.conf and start the radvd daemon:
This is enough to give you a functioning network. Your machines will pick up the announcement, assign themselves addresses and default routes, and can talk to each other and the Internet. And as you can see, this L3 setup isn't any different to v4 -- you've got a WAN IP, a LAN IP and a route. Devices get IPs from 2001:db8:42:1::/64 like they get IPs from 192.168.1.0/24. The client autoconfig is different but it's a lot simpler than DHCP.
What am I glossing over? Most ISPs aren't static, which means you need to automate the above setup, and even for a static ISP you'd need to persist the `ip` commands (e.g. via /etc/network/interfaces or whatever your distro uses to do network config). If your ISP needs ppp or VLANs or whatever then you gotta deal with those too, but that's not v6-specific.
You're also going to want a firewall, but that will look very similar to your v4 one: deny new connections from the WAN, allow new connections from the LAN, allow packets from existing connections in both directions. I can give you ip6tables or ferm for that if you want.
Lastly, I'll point this out explicitly, but you don't need NAT which is why there's no mention of it above. It's just not necessary. The ISP has an inbound route set for 2001:db8:42::/48 to your router, and a /48 is more than enough address space.
Other than that, those three commands + radvd config really are enough for a fully-functioning network. It doesn't seem terrifying to me, nor does it seem inaccessible to someone that already knows how v4 networks work.
This actually did more to explain the implementation basics that most intros I’ve read.
I’m not the parent but I just end up not wanting to have to debug network traffic across two protocols where I don’t know how to deterministically work out which is in use.
Then I need to work out new firewall rules and replacements for things like Pi-hole, home DNS, etc. Realistically that’s just me reading docs for 10 minutes, and double-checking everything has the “work with ipv6 box” toggled.
But personally my hesitation is getting stuck in this in between and maintaining two network setups.
Not terrifying, just a lot of work I don’t need to do.
This program has existed since past decade and not many router manufacturers cared about it. Customers wouldn’t pay extra for this logo and there is not value for this cert.
Several countries are mandating IPv6 support for government projects, validated IPv6 capabilities are useful if you're shopping for a compliant device.
I think an IPv6-compliance logo scheme would be a good idea, but it should be driven by major commercial vendors like Apple, Microsoft, Google etc on the software side, and supported by industry forums like the WiFi Alliance and the GSM Association on the hardware side. I would love to be able to ditch IPv4 entirely for running large production networks.
I think Apple have already started to enforce IPv6 support on iOS apps. It would also be interesting to audit open source projects for IPv6 support; just the presence of the appropriate API calls would probably be sufficient for a first hack to tell the difference between IPv6-compliant and non-IPv6 compliant applications. This would allow influential distros like Debian to start the process of deprecating old software which is incapable of working properly with modern networks.