IT Pros Blast Google Over Android's Refusal To Play Nice With IPv6 287
alphadogg writes: The widespread popularity of Android devices and the general move to IPv6 has put some businesses in a tough position, thanks to Android's lack of support for a central component in the newer standard. DHCPv6 is an outgrowth of the DHCP protocol used in the older IPv4 standard – it's an acronym for 'dynamic host configuration protocol,' and is a key building block of network management. Nevertheless, Google's wildly popular Android devices – which accounted for 78% of all smartphones shipped worldwide in the first quarter of this year – don't support DHCPv6 for address assignment.
Google's IPv6 SMTP servers (Score:5, Interesting)
Google's IPv6 support for mail is what annoys me. I have a static non-tunneled IPv6 address for my server, have reverse DNS set up for it that resolves properly, have SPF and DKIM records set up properly, and they still refuse to accept mail from the server, even though they accept my IPv4 mail just fine. Lots of other folks have been having the same problem, and it really makes me wonder why Google's even bothering with IPv6 SMTP when they're refusing mail from so many legitimate (i.e. non-spam) hosts.
Re:Google's IPv6 SMTP servers (Score:4, Interesting)
I know our servers won't accept it either since they don't even listen on it, are you saying Google is unusual in not accepting IPv6 only email? 'cause I reckon that's "standard".
Yes, Google is unusual - they do listen on IPv6 SMTP, but they reject the incoming mail as possible spam way more often than when it is being sent to them over IPv4. I had the same problem, and I had to explicitly force IPv4 for outgoing SMTP to Google in my Postfix configuration.
It's not just DHCPv6... (Score:4, Informative)
Re: (Score:2)
That is a vendor-specific bug unfortunately.
Re: (Score:2)
Re: (Score:2)
The server holds the IP for the set time, no matter what (barring a manual flush), so for 24 hours, the IP will not be assigned to anyone other than t
Re: (Score:2)
Meta: dynamic what? (Score:5, Insightful)
> it's an acronym for 'dynamic host configuration protocol,' and is a key building block of network management.
The above explanation is a clear proof that Slashdot is not a "news for nerds" site anymore.
Re: (Score:2)
Do you know what eutectic solder is, and it's merits? What is a totem pole output's advantage over open collector? do you use an H-bridge or are your stepper motors center tapped? I know what DHCP stands for, but this isn't an IT drone site, it's a nerd site.
DHCPv6 is NOT a central component of ipv6 (Score:4, Insightful)
DHCPv6 is a bad bolt-on, IPV6 always had superior solutions designed since the 90s (when it had another name)
Re: (Score:3)
"DHCP" is _not_ an acronym (Score:2)
An acronym is a special case of an abbreviation, that is pronounced like a word. A classic example is ASCII. Most people don't say each letter, they say ASCII as a two-syllable word.
Supports Stateless Autoconfiguration (Score:2)
I would suspect that stateless Auto configuration works on the phones. As long as it was passed along by the routers it would work just fine.
However that being said ARIN is at 0.07% left of IPv4 space as of a few days ago and likely less after this week. Estimates in July the ARIN free pool will be empty and you'll be leasing IPv4 ip's for a lot more and not own your IP's for quite awhile so it is in everyone's interests to push adoption of IPv6. Google's decision to make sure the phones are compatible a
Re: (Score:3, Insightful)
Obviously at this point it isn't a bug, its a "feature." The only question is why did Google decide to push this negative feature?
I remember first hearing about IPv6 around 1997.
Here we are almost 20 years later still sucking on the IPv4 teat. I'd say Google might as well take their fucking time on this "feature".
It's not like anyone is in a damn hurry, regardless of what's running dry.
Re: (Score:2)
Re: (Score:3)
https://www.arin.net/resources... [arin.net] perhaps?
It did happen, even if you didn't notice much impact.
Re: (Score:2)
The fact that there wasn't any real impact highlights how all the hype about IPv4 doomsday were overblown.
Re: (Score:2)
Re: (Score:2)
Granted CGN hardware isn't cheap, and it takes effort to get it up and running, but upgrading hardware to accommodate growth wasn't going to be cheap or effortless anyhow.
Re: (Score:2)
Try to get an IPv4 allocation and THEN tell me how there was no impact. Back in the '90's, they were handing out public IPs like water. All you had to do is ask and say how many you want.
These days, good luck getting an allocation without submitting the opinion of 3 fortune tellers, a detailed justification and the results of your last 3 colonoscopies. And don't dare try to plan ahead so you can grow into the block you request.
Re: (Score:3)
For some odd reason I was thinking IPv6 didn't require DHCP. Maybe that's why Google isn't in a hurry to implement it at an extra. But don't let that stop you from having a cussing fit.
Re: (Score:3)
It doesn't; it's capable of picking out an address that doesn't conflict with anything else on the same segment. But then you don't know which address is Bob's phone and which is Fred's, so you can't tell who to fire for downloading cat videos.
Re: (Score:3)
Sure you do. You just need to know Bob and Fred's MAC address. Same as for DHCP.
Re: (Score:2)
Re: (Score:2)
Really? You have to tell your DHCP server the MAC of every device on your network?
Unless you're using static assignments ("reservations"), then you don't need to tell the server anything at all.
You have no idea how DHCP works? When you ask the DHCP server for an IP, you do not have an IP address. In order for you to get the reply back from the DHCP server, it needs your MAC address.
Re: (Score:2)
For some odd reason I was thinking IPv6 didn't require DHCP. Maybe that's why Google isn't in a hurry to implement it at an extra. But don't let that stop you from having a cussing fit.
IPv6 doesn't require DHCPv6 - if you are fine w/ either auto-configuration or transient assignment of addresses. It's only required if the network admin has an address layout plan and wishes to implement it - that's when DHCPv6 is needed.
Unlike DHCPv4, which has to be requested for IPv4 addresses, DHCPv6 proactively assigns IPv6 addresses to the various nodes, depending on the assignment rules. If one wishes, one could configure DHCPv6 to assign only Unique local and not Global Unicast addresses. I'm
Re: No support for dynamic address assignment?!? (Score:4, Informative)
Re: (Score:2)
Re:No support for dynamic address assignment?!? (Score:5, Insightful)
IPv6 supports stateless IPv6 address assignment using SLAAC (StateLess Address AutoConfiguration). There is no need for a DHCP server. There are a number of reasons why using DHCPv6 to allocate individual addresses is a bad idea. If you've ever operated a DHCP server, you know about DHCP's failure modes, so I don't have to tell you. However, people get comfortable operating DHCP servers, and there's job security in it, so there are a lot of IPv4 old-timers who simply can't imagine a world without DHCP.
Speaking as one of the authors of RFC 3315, I think that Google is, if not right, at least not wrong. I would not personally want to have to set up a DHCPv6 server just to allocate individual IPv6 addresses. Talk about driving a nail with a sledgehammer. DHCPv6 is a great solution for the problem of configuring CPE routers with IPv6 prefixes. Addresses? Not so much.
Re: No support for dynamic address assignment?!? (Score:3)
SLAAC is good for dynamic address configuration and DHCP is good for the other hundred-ish host configuration variables, right?
Re: (Score:2, Informative)
Remember we are talking about Android devices. Most of these are phones and tablets.
When was the last time you used DHCP to set the WINS server on an Android device.
Besides, most of that configuration 'fun' should be moved to DNS (which is configured by SLAAC).
IMHO IPv6 will push people to rely more on DNS as its hard to remember v6 addresses.
On that note, in the SLAAC Router Advertisement messages, there is a facility for 'other configurations'. This at a minimum will contian DNS configs and reads like i
Re: (Score:2)
The O flag (it's a single bit) simply tells the device it should search for OTHER informational elements from (wait for it...) A DHCPv6 SERVER. That is the "stateless" mode, which android ALSO doesn't support.
I suppose you are referring to the relatively recent (and not widely supported) RDNSS fields of the RA -- which do list DNS servers.
Re: (Score:2)
That's not the point. Android devices, like laptops, are clients that have to accept whatever addresses are given to them by the network they are in.
Let's say you've got IPv6 from your provider, and have configured your router to issue IPv6 addreses like 2001:db8:cafe:1:dead:beef:1:[0-ffff] to the devices on your network. You've decided that you want to use other addresses for other purposes later, but for now, you just want to assign this to all your toys. Your router proactively issues 5 addresses
Re: (Score:2)
That's not how IPv6 works. You are trying to run an IPv4 network using the IPv6 transport. IPv6 is not just IPv4 with 2^96 more addresses.
Re: (Score:2)
There are no other hundred-ish host configuration variables in DHCPv6. There are two that you are likely to care about, and they're both also available in the RA.
Re: (Score:2)
The only DHCP server I've "operated" is the one in my WiFi router... What failure modes are you talking about?
Re: (Score:2)
You aren't likely to notice them on a home network with network address translation. If you actually _use_ IPv6' capabilities, having to operate a DHCPv6 server is going to start to seem like a chore.
Re: (Score:3, Interesting)
Spoken like someone who's never managed a deployment that's bigger that can fit in one's basement - Something a lot of the v6 creators I think have in common.
DHCP v6 exists not to coddle or comfort admins used to a v4 world. DHCP v6 was added because v6 will /Never/ be adopted without it. Ever. Full stop.
DHCP facilitates two-way communication prior to address assignment and lends flexibility to deployments that are now considered indispensable. It lets clients tell the network about themselves so they can b
Re: (Score:2)
Actually I used to manage a very large IPv4 network. However, you are correct that I'd never managed an IPv6 network of any size when I was working on RFC 3315, and I don't think any of the other authors had either. And it shows--there are quite a few embarrassing holes in the spec. I'm not going to go down your "what keeps IPv6 from being adopted rathole," because from my perspective IPv6 _is_ being adopted, and I don't feel any need to see it adopted faster. I'm amazed at how much of the Internet I
Re: (Score:3)
Having waded through the mega-thread with Lorenzo (who I've met by the way and he is a top class guy), this appears to be the nub of the dispute. It's some kind of immovable object/irresistible force situation.
The Andro
A perspective of an ISP (Score:5, Interesting)
I work for a (smallish) ISP so let me tell you why you will simply not get any IPv6 service without DHCPv6 on our network.
It has nothing at all to do with being IPv4 old-timers. That is just you not understanding the complexity of the world out there. Our network was build from the start with the idea that IPv6 is the future.
We use DHCPv6 to provide every user with his own /48 prefix. Yes you said that DHCPv6 is a great solution for prefixes. But we also use it to deliver a /128 to go with that prefix. We need this to have a stable and predictable address that we can use as next hob for your shiny new prefix.
We had this very same debate on the NANOG mailing list. Some people there asked why does your routers not sniff the DHCPv6 packet and add the route dynamically? Two reasons. One, that is not in any standard, so our vendor did not implement it. Two, it does not work if you have router redundancy (how would the backup router know the route?).
There are more reasons an ISP would not want to use SLAAC. It exposes 2**64 addresses to the ISP network access routers. This can harm the network in many different ways and you simply do not want your ND caches to be full of that crap. You want to use as few slots in the shared ND cache per user. Therefore you are going to disable SLAAC on the customer edge and use some other mechanism. One guy suggested not using GUA on the customer links and only use link local addressing here. We choose to use /128 DHCPv6 assigned addresses. In either case, GUA-SLAAC is a fail in the provider network.
SLAAC is great inside the household of our customers. But we leave that decision to the customer and his choice of CPE-router.
The problem with Android is that it should really be able to act like a CPE for tethering purposes. Therefore is should be able to accept our CPE configuration. Android should also be able to ask for a prefix to be sub-delegated from the house CPE and it should accept that this might come with extra addresses that will be used for routing or for other purposes.
Re: (Score:2)
There is only one other explanation that I get - that Google expects Android to be used only in cellular mode, rather than WiFi, and therefore, since it support Mobile IPv6, its IPv6 support is complete. But I agree w/ you that that is unsatisfactory.
DHCPv6 ought to be the first thing supported by any IPv6 implementation. SLAAC and stateless configuration should be secondary.
Re: (Score:2)
Re: (Score:2)
... except in a managed network (where something needs to keep track of what is what, and when.) Or in an IPv6 ONLY network. As I've bitched for years, a machine needs more than just an address to operate. At minimum, it needs a list of recursive DNS servers -- something that has now been bolted onto the still-a-bad-idea RA, if supported by your hardware (which is unlikely.)
You miss the entire point: on a managed IPv6 ONLY network, android devices have ZERO connectivity. As much as *you* don't want to setup
Re:No support for dynamic address assignment?!? (Score:4, Informative)
IPv6 supports stateless IPv6 address assignment using SLAAC (StateLess Address AutoConfiguration). There is no need for a DHCP server. There are a number of reasons why using DHCPv6 to allocate individual addresses is a bad idea. If you've ever operated a DHCP server, you know about DHCP's failure modes, so I don't have to tell you. However, people get comfortable operating DHCP servers, and there's job security in it, so there are a lot of IPv4 old-timers who simply can't imagine a world without DHCP.
Speaking as one of the authors of RFC 3315, I think that Google is, if not right, at least not wrong. I would not personally want to have to set up a DHCPv6 server just to allocate individual IPv6 addresses. Talk about driving a nail with a sledgehammer. DHCPv6 is a great solution for the problem of configuring CPE routers with IPv6 prefixes. Addresses? Not so much.
There are quite a number of wrong assumptions in the above statements.
First of all, if a /64 network has not just terminals, tablets and phones in it but servers as well, it makes sense that it should have DHCP. The servers in the network - particularly HTTP/S servers need to have static addresses. Let's say a network has 5 servers of various types - say 2 web servers, 1 mail server, 1 FTP server and 1 NFS server, you don't want to assign them dynamic addresses. Nor do you want to give them an address based on EUI-64. It makes more sense to give them a few unique addresses, such as 2001:db8:beef:1:cafe:cad:[1-5]:[$Port#], and for the rest of the subnet, give something like 2001:db8:beef:1:feed::[1-ffff] for a random assignment of say 65536 addresses. And set up your firewalls accordingly.
The other point is that SLAAC, if you look closely, is only commonly used w/ Link Local addresses - the addresses that a computer automatically configures itself. Essentially, it's a Layer 3 mapping of a Layer 2 signature, and is useful for Layer 3 communications b/w 2 computers w/o a router. For phones & other devices, other SLAAC techniques may be used, except that system admins would have no control over addresses that are assigned. Such a hands-off approach may not work for everyone.
Re: (Score:3)
Firstly servers don't need DHCPv6 to assign them a address. They can just pick a address and register it in the DNS themselves. They really don't need a DHCP server to do it for them. HTTP/S doesn't care about the IP address that a machine has.
Secondly SLAAC is not only used with link locals.
Just because you want to do things one way doesn't make it a requirement.
Re: (Score:2)
Android, AFAIK, isn't used for servers. That said, using DHCP to configure server IP addresses isn't recommended. What you want is to provision the server IP address using whatever orchestration software you use, so that it has the right address on startup.
Re: (Score:3)
But DHCPv6 also supplies INFORMATION REQUEST which designed to operate without address assignment. It supplies things like DNS.
With Windows not supporting RDNSS in RA, it requires DHCPv6 DNS via the information request to work in a pure IPv6 world.
In the same vein, Android not supporting DHCPv6 requires RDNSS in the RA to work in a pure IPv6 world.
So as it stands right now, we have to run both if we want to support both OS and that sadly means redundant data going around the network.
I cannot speak for Micro
Re:No support for dynamic address assignment?!? (Score:5, Informative)
Where to start?
1) IPv4 vs IPv6 has nothing to do with ASN. If you do have an ASN you will be using the same ASN for both protocols. With 32 bit ASN now in wide use, there is nothing limiting you from applying for one. Get your own /48 prefix with it.
2) IPv6 has NAT.
3) Multihoming is perfectly possible using IPv6. There is no rule telling you not to do it exactly like you always did with IPv4.
4) There is no rule that say you can not split a /64. You can split it down to /128 if you want. The only thing that breaks is SLAAC but you can still use DHCPv6 or static/manual configuration.
5) All major ISPs are giving out /56 or more address space, so you have no need to split a /64.
6) All major operating systems use privacy extension enabled by default, so you MAC will not be exposed when you surf the net. Your device will be no more tracked than with IPv4-NAT since it changes address all the time.
All IPv6 gives you are options. There are now more ways to do the above things. But in no way did you lose the ability to keep doing things like yesterday.
Re: (Score:2)
2) IPv6 has NAT
I remember some time ago in /. somebody arguing with me that IPv6 does not and should not have NAT because NAT is evil and the sole purpose of IPv6 is to get rid of it.
4) There is no rule that say you can not split a /64. You can split it down to /128 if you want. The only thing that breaks is SLAAC but you can still use DHCPv6 or static/manual configuration.
DHCPv6 works, unless you have Android devices (the point of TFA).
Re: (Score:2)
Right. So what do you want to do with DHCPv6 that you can't do because Android doesn't support DHCPv6 IA_NA?
Re: (Score:2)
2 has changed. The IETF included one particular NAT mechanism called NAPT - Network Address Port Translation. This does a 1:1 mapping b/w GUA and ULA/LLAs. The advantage of this is that it provides the internal network abstraction that network admins desire, in the absence of multi-homing standards. However, one does not have to do the PAT equivalent in IPv4 and consume ports the way one did there. (So for things like mapping applications, the map can use as many ports as it likes w/o them being neede
Re: (Score:2)
Yeah, ND needs work, and is being worked on.
Re: (Score:3)
It does support dynamic address assignment through router announcements, just like the IETF intended. DHCPv6 is a bolt-on for people who don't really understand v6 at all. The claims about identifying the source of traffic are just silly. Autoconfigured addresses are persistent and do identify a specific device, at least to the degree that DHCP can.
That isn't to say that Google shouldn't add support for DHCPv6 since people seem to really wanty it, but it's not like they force you to enter a static IP or som
Re: (Score:2)
You have to use static IPs if you want to split the singe /64 you got from your ISP into subnets, since SLAAC stops working then. Well, either that or NAT.
Re: (Score:2)
Any situation likely to benefit from subnets in a v6 network will already call for static assignments.
Re: (Score:2)
How about "Internal WiFi" and "Guest WiFi (internet access only)"? Currently this is done with a separate vlan and subnet for the guest WiFi. It also benefits greatly from dynamic address assignment.
Re: (Score:2)
DHCPv6 was "bolted on" 12+ years ago. It is an IETF STANDARD part of IPv6. Implementation is not "optional". Google simply refused to add it because they're butt-hurt that it *could* make certain features non-operational -- or more accurately, they don't want to do any of the work to make them possible. I can make XP and 2000 work properly within a stateful DHCPv6 only network (using a 3rd party dhcp client, because their ipv6 stacks are far too old), and other android devs HAVE added DHCPv6 support to thei
Re: (Score:2)
Re: No support for dynamic address assignment?!? (Score:2)
Re:No support for dynamic address assignment?!? (Score:5, Funny)
That's excellent news for those 15 users.
Re: (Score:2)
That's excellent news for those 15 users.
Surely you exaggerate a bit.... I turned in my Widows phone nearly 7 years ago now.
Re: (Score:2)
Or stateless DHCPv6. Or in other words: they don't support DHCPv6 AT ALL.
Re: (Score:2)
Re: (Score:3)
What?
No, SLAAC isn't used with link-locals -- link-local addresses are assigned automatically by the host. It's used with whatever the network range on the segment is, which will usually be a global unicast range, or sometimes ULA. That's where it's supposed to be used, it's a normal way to do v6 and it works just fine.
Re:Not Needed (Score:4, Informative)
Re: (Score:3, Informative)
Kind of true. Router autodiscovery works, but has some problems. It doesn't provide DNS information to the clients, nor does it allow the clients to populate their hostnames in the local DNS the way a DHCP server does.
Actually, that's what the RDNSS and DNSSL options are for. (RFC 6106 [ietf.org])
Whether devices honor them is another issue.
Re:Not Needed (Score:4, Informative)
At this point unless you are running an ancient version of your favorite operating system, RDNSS works fine. DNSSL is a Very Bad Idea, so you don't want your host to support that, but it probably does.
Re: (Score:3)
Not true. ICMPv6 router advertise messages can include DNS server addresses, and this works well. Populating hostnames in the local DNS using DHCP really hasn't caught on, even in IPv4. It's a neat hack, but hardly anybody uses it. DHCPv6 also lacks an authentication mechanism, although that's about to change, but in fact ICMPv6 has RA guard and SeND (Secure Neighbor Discovery). So you are exactly backwards on the authentication question.
Re: (Score:2)
It's a neat hack, but hardly anybody uses it.
IPv4 IPs are much easier to remember than IPv6 IPs.
Re:Static (Score:4, Insightful)
Re: (Score:2)
Please stop with this 64+64 BULLSHIT. There is no "host part" and "network part" in IPv6. (there isn't, anymore, in IPv4 either.) IPv6 is 100% CLASSLESS. The only thing that (currently) demands the 64/64 split is SLAAC -- BTW, it started at 80/48 -- and a network is not REQUIRED to run SLAAC. (which is the heart of the entire roasting of Google here.)
You CANNOT make such an assumption about a non-local network. You MUST know the prefix-length to know what part is "network" and which is "host". You can look
Re: (Score:2)
Re: (Score:2)
Static IP addresses contain whatever the operator sets. Automatically assigned IPv6 addresses used to be MAC based on Ethernet/Wifi, but few do that these days.
Re: (Score:2)
Good thing that was already solved back in 2001. https://tools.ietf.org/html/rf... [ietf.org]
Re: (Score:2)
Re: (Score:2)
I think you mean a stateless dynamic address, not a static address. Static addresses are manually configured, which nobody wants. RFC 7217 solves this problem by specifying a way of doing stateless auto-configuration without using the MAC address.
Re: (Score:2)
Re: (Score:2)
static IP 6 address has the devices MAC address in it. Therefore tracking becomes an issue for some
Not on phones - since when do they have Ethernet cards? The phone static address would be a function of EMEI addresses or something like it.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
This makes no sense. Routers do not care how addresses are assigned, they use neighbour discovery to find the hosts.
Re: (Score:3)
Anyone who wants privacy?
Re: (Score:2)
Actually the point is to give everyone a public IP, not necessarily static.
Re: (Score:2)
Isn't half the point of IPv6 that we can just give EVERYTHING a static IP? Who needs dynamic assignment?
No, the point of IPv6 is that everything that needs a public IP can have it, w/o running short. The static vs dynamic argument comes up when one is discussing whether a stateful address is needed for something that has to be constant, such as a server IP address. As opposed to say your iPhone, which should change addresses every few seconds so that nobody can discover it and penetrate it, even if they manage to infiltrate the network
There have been possibilities analyzed like the million light bulbs w/
Re: (Score:2)
Re: (Score:2)
Right, because peer-to-peer gaming is for losers, and nobody needs more than a few TCP or UDP ports per host, so multi-layer NAT is great, and will continue to limp boldly into the future.
Re: (Score:2)
Gaming on Android? Oh my.
He did say it was for losers...
Re: (Score:2)
RFC7040?
RFC6333?
Lightweight 4over6?
Re: (Score:2)
Re: (Score:2)
My Android phone works just fine on IPv6 networks.
Re: (Score:2)
Re: (Score:2)
It's about Android devices not being able to
However, Mobile IPv6 would work fine on Android, since it uses a variation of SLAAC that would keep the interface ID constant while switching across various mobile networks. Mellon didn't mention whether his phone works fine on an IPv6 enabled WiFi network - that's where it could have
Re: (Score:2)
Re: (Score:3)
No it works just fine on mobile, but only using SLAAC and not DHCPv6. They are two different ways of getting address assignments. SLAAC is typically going to be an autogenerated IPv6 address, based on MAC address, where DHCPv6 is going to give an address from whatever rules are defined on the DHCPv6 server.
My Galaxy S6 has IPv6 addresses on both the mobile and wifi networks. The wifi side was configured using SLAAC as expected.
The lack of DHCPv6 is generally an issue for corporate networks with r
Re: (Score:2)
Android supports RDNSS for IPv6, but not DHCP for IPv6. Basically, there is no need for DHCP in IPv6. There is no need for an IPv6 address to be dynamic. Your carrier has multiple ways to supply one or more global IPv6 addresses to your mobile device, and to renumber the devices under its control at any time. Since your carrier is responsible for routing the IPv6 packets from your mobile device, it's up to your carrier to assign IPv6 addresses. For use on a local network, your device can also use IPv6
Re: (Score:3)
Re: (Score:2)
But one wouldn't always use an Android device w/ the carrier. In fact, I generally disable internet connectivity on the go, and only enable it when I'm near a recognized WiFi hotspot. For this sort of a situation, if DHCP is used in assigning addresses, the Android device wouldn't work.
Verizon is very much IPv6 - in fact, that's what I get w/ my phones. I have an iPhone 5s and a Moto-X. Both work w/ the Verizon IPv6 network.
Re: (Score:2)