Slashdot Mirror


IT Pros Blast Google Over Android's Refusal To Play Nice With IPv6

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.

287 comments

  1. No support for dynamic address assignment?!? by cold+fjord · · Score: 0

    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?

    --
    much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
    1. Re:No support for dynamic address assignment?!? by geekmux · · Score: 2, 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.

    2. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      This is doubly true because the private address space for IPV4 is untouchable outside the walls of a campus, so most organizations don't give a flying crap about running out of address space.

    3. Re:No support for dynamic address assignment?!? by ganjadude · · Score: 1

      when i got my CCNA in 2001, we were told IP6 was 2 years out from being the defacto standard... this was 2001... (and yes, we learned how to do it back in 01)

      --
      have you seen my sig? there are many others like it but none that are the same
    4. Re:No support for dynamic address assignment?!? by magarity · · 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.

    5. Re:No support for dynamic address assignment?!? by ArcadeMan · · Score: 4, Funny

      That's excellent news for those 15 users.

    6. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      We've also been told that we'd be all out of IPv4 addresses "within a couple of years" every year since then, and that hasn't happened, either.

    7. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      They support SLAAC, just not the stateful dhcp6.

    8. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Or any users.

    9. Re:No support for dynamic address assignment?!? by dodobh · · Score: 2

      https://www.arin.net/resources... perhaps?

      It did happen, even if you didn't notice much impact.

      --
      I can throw myself at the ground, and miss.
    10. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      At this site (university with 32 000 students) we hand out public IP addresses on the WiFi. Yes we care.

    11. Re:No support for dynamic address assignment?!? by suutar · · Score: 2

      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.

    12. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      It doesn't. Router adtvertisement plus MAC address derived IP addresses cover everything but handing subnets, which s why there's DHCPv6. Shame Comcast doesn't support that. I have a subnet that I can't route.

    13. Re:No support for dynamic address assignment?!? by Guspaz · · Score: 1

      The fact that there wasn't any real impact highlights how all the hype about IPv4 doomsday were overblown.

    14. Re:No support for dynamic address assignment?!? by mellon · · 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.

    15. Re:No support for dynamic address assignment?!? by ganjadude · · Score: 1

      real impact to whom? the end user maybe, not so much for everyone else involved in making it work

      --
      have you seen my sig? there are many others like it but none that are the same
    16. Re: No support for dynamic address assignment?!? by psmears · · Score: 3, Informative

      Router Advertisement can handle subnets, FWIW...

    17. Re: No support for dynamic address assignment?!? by bill_mcgonigle · · Score: 2

      SLAAC is good for dynamic address configuration and DHCP is good for the other hundred-ish host configuration variables, right?

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    18. Re:No support for dynamic address assignment?!? by mattack2 · · Score: 1

      The only DHCP server I've "operated" is the one in my WiFi router... What failure modes are you talking about?

    19. Re:No support for dynamic address assignment?!? by Guspaz · · Score: 1

      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.

    20. Re:No support for dynamic address assignment?!? by sjames · · Score: 2

      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 something.

    21. Re:No support for dynamic address assignment?!? by sjames · · Score: 1

      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.

    22. Re:No support for dynamic address assignment?!? by sjames · · Score: 2

      Sure you do. You just need to know Bob and Fred's MAC address. Same as for DHCP.

    23. Re: No support for dynamic address assignment?!? by Anonymous Coward · · 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 it should be able add custom configuration paramaters

    24. Re: No support for dynamic address assignment?!? by bobbied · · Score: 0

      What a waste of address space... That many PUBLIC IP's? What a mess that must be.

      Personally, I don't know why ANYBODY not running a server would even want an public IP and not behind a NAT. It's way too dangerous, even with a modern firewall and security settings. Yea, sure your torrent client might have issues, but what are you downloading with that anyway?

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    25. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      There are big customer networks now where users can only choose between IPv6 and carrier-grade NAT IPv4. No public IPv4 address for you!

    26. Re:No support for dynamic address assignment?!? by bobbied · · Score: 1

      Surely the MAC address is still unique... IPv6 doesn't mess with layer 2 on down.... If you really care who's phone is who's, you have to set up layer 2 to be secure anyway, so you are going to need to know, in advance, who's MAC is who's. You'd need that knowledge for a DHCP server too... Nothing really changes here...

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    27. Re:No support for dynamic address assignment?!? by bobbied · · Score: 1

      That's excellent news for those 15 users.

      Surely you exaggerate a bit.... I turned in my Widows phone nearly 7 years ago now.

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    28. Re:No support for dynamic address assignment?!? by Pentium100 · · Score: 1

      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.

    29. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 1

      It does need DHCPv6 for other configuration information, for example the address of a TFTP server for network booting (but DNS servers can be configured through router advertisements). Address autoconfiguration has privacy / information leakage implications if used with embedded MAC addresses and makes running servers difficult if used with random addresses. DHCPv6 may be preferred in order to dynamically add host names to DNS, etc.

    30. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      If one is running any of the myriad of systems that allow for communication between devices you will soon discover that a corporation has a server somewhere in the cloud which violates your private space. In time these companies amalgamate you into monopolies. Why should a cloud server in china be in control of my smart plugs? IPv4 is why. GET RID OF IT!!!

    31. Re:No support for dynamic address assignment?!? by sjames · · Score: 1

      Any situation likely to benefit from subnets in a v6 network will already call for static assignments.

    32. Re:No support for dynamic address assignment?!? by Anonymous Coward · · 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 be assigned the corrects settings (And not just an address!)

      It's shit like this that keeps v6 from being adopted. (We should have been there a decade ago) Proselytizing form old, out of touch "experts" (With four digit slashdot IDs no less) with a vision for how networks work that didn't work, and is no longer relevant either.

    33. Re:No support for dynamic address assignment?!? by bbn · · Score: 4, 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.

    34. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Yeah, right. Unfortunately, every IPv6 address a node has potentially adds one more multicast group to the switch multicast table, due to the MLDv2 multicast functionality *and* the NDP (neighbour discovery protocol) process.

      Then you add RFC-4941 privacy addresses, so a node will have not only two, but potentially a large number of addresses, which will _not_ collide in the multicast IPv6 -> MLDv2 ethernet multicast group mapping, therefore _always_ taking up at least one multicast entry per ipv6 address. And RFC-4941 extensions are enabled by default in mobile devices worth their weight.

      When the network goes haywire, you finally remember most switches can barely handle more than a few hundred multicast groups. They're now either dropping NDP packets (causing extremely annoying network issues to users at random), or broadcasting everything.

      It is also extremely annoying to have L3 addresses of end stations changing when you are forced to replace a NIC or desktop or laptop. It is no wonder it is used on 99,5% of the enterprise LAN IPv6 deployments I've heard of.

      However, since you cannot depend on either SLAAC or DHCPv6 to serve all users, you end up forced to enable *both* for maximum device compatibility in the Wifi network. Instant mess.

    35. Re:No support for dynamic address assignment?!? by Cramer · · Score: 1

      It didn't originally -- because the committee HATED DHCP (bootp). But it was added to the standard some years later. Google has flat refused to implement that part of the standard for many years now.

    36. Re:No support for dynamic address assignment?!? by Cramer · · Score: 1

      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. The "MAC" of the device can change, btw. (different NIC, wireless vs. wired, etc.) And a MAC isn't the only thing the server can use. (in fact, I'm cursing Sun for the ALOM using the serial number instead of MAC for it's client-id.)

    37. Re: No support for dynamic address assignment?!? by Cramer · · Score: 1

      Comcast uses DHCPv6-PD; you can get more than a single ::/64. An RA can announce any sized network. Only the brain damage that is SLAAC that REQUIRES the prefix length to be 64.

    38. Re:No support for dynamic address assignment?!? by Cramer · · Score: 2

      Or stateless DHCPv6. Or in other words: they don't support DHCPv6 AT ALL.

    39. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      That's excellent news for those 15 users.

      Please be more specific. The 15 Windows Phone users or the 15 IPv6 users?

    40. Re:No support for dynamic address assignment?!? by currently_awake · · Score: 1

      One of the selling points of open source software is that if the company that provides it won't fix something, you can do it yourself.

    41. Re:No support for dynamic address assignment?!? by unixisc · · Score: 1

      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 not sure whether DHCPv6 can be used to configure Link Local Addresses - speaking of which, those are the ONLY ones that use EUI-64.

      TFA, what does Android have outside Linux that refuses to implement DHCPv6?

    42. Re:No support for dynamic address assignment?!? by unixisc · · Score: 1

      My router - a netgear - supports DHCPv6, if I enable IPv6. If I use that in conjunction w/ Comcast's modem and get a /64 from Comcast, how is my router prevented upstream by Comcast from using DHCPv6? (I have Charter, not Comcast, and they don't support IPv6 so far, although they do have published plans to do it, but my router is ready for it whenever they choose to flip the switch).

    43. Re:No support for dynamic address assignment?!? by unixisc · · Score: 1

      SLAAC is only used w/ Link Local Addresses. I've not heard about it being used w/ Unique Local or Global Unicast addresses. Anybody who does it that way is asking to be screwed.

    44. Re:No support for dynamic address assignment?!? by Cramer · · 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 such a network, there are PLENTY of others that HAVE. And the standard dictates that it be supported. Plus, it doesn't have to be a one-device-one-address-only system. If you need more than one address, ask for more than one. If you want to tether a network behind you, ask for an additional prefix, or bridge them into the same network and let them RA/DHCP for themselves. If you cannot get the additional space, you cannot support whatever feature required it. That's a very different experience than "no fucking connection?!? WTF!!!" (which is exactly where this is headed, and the network operator answer (per NANOG) is that your device is crap, you should complain to the idiots at Google -- one in particular, actually.)

    45. Re: No support for dynamic address assignment?!? by Cramer · · 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.

    46. Re: No support for dynamic address assignment?!? by hackwrench · · Score: 1

      You don't appear to know how NAT works. Private addresses are not routable to the internet. All devices have to talk to the machine handing out the private addresses which then replaces the private address with it's own public address for sending across the internet. Internet routers do not forward packets with a from or to address that is in one of the ranges set aside for private addresses. There is a session ID so that the device handing out private addresses knows which private address to send return packets to and ports can be set to one machine with a private address using port forwarding for connections initiated by outside machines.

    47. Re:No support for dynamic address assignment?!? by Cramer · · 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 their builds -- so we know, for a fact, it can be done, and rather trivially to boot.

    48. Re:No support for dynamic address assignment?!? by unixisc · · Score: 3, 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.

    49. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      actually the prefix assignment support is hardly 'great'.

      i really like the part where intermediate systems snoop the dhcpv6 traffic to update their routing tables
      by using a proxy

    50. Re: No support for dynamic address assignment?!? by unixisc · · Score: 1

      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 to your toys. Your iPad gets one, your laptop gets another and now it's time for your Android phone to take what's given to it. But it doesn't, since Google has configured Android in such a way as to reject the addresses your router is giving it.

    51. Re:No support for dynamic address assignment?!? by Pentium100 · · Score: 1

      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.

    52. Re:No support for dynamic address assignment?!? by Pentium100 · · Score: 1

      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).

    53. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Isn't NAT and private address space a method of overcoming the limitations of IPv4? Shouldn't IPv6 be able to enable new home routers to be designed to avoid some private addresses where needed, specifically for the purposes of allowing access to our things. Old routers seem to be needed in order to circumvent our privacy. Until this is answered then no employee of a cloud based service would be expected to come clean about why they use such external servers. In other words aren't old IPv4 routers underpinning the current business model for any home device that needs to be accessed from outside?

    54. Re:No support for dynamic address assignment?!? by marka63 · · Score: 2

      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.

    55. Re:No support for dynamic address assignment?!? by arth1 · · Score: 1

      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.

    56. Re: No support for dynamic address assignment?!? by mellon · · Score: 1

      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.

    57. Re: No support for dynamic address assignment?!? by mellon · · Score: 1

      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.

    58. Re:No support for dynamic address assignment?!? by mellon · · Score: 1

      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.

    59. Re:No support for dynamic address assignment?!? by mellon · · Score: 1

      Right. So what do you want to do with DHCPv6 that you can't do because Android doesn't support DHCPv6 IA_NA?

    60. Re:No support for dynamic address assignment?!? by mellon · · Score: 1

      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 can reach over IPv6, and I'd like people to deploy carefully and correctly, not just think they're doing a drop-in replacement of IPv4 with IPv6 as if they were both the same thing.

    61. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      The negative feature is DHCPv6. You ought to be using SLAAC and NDP and not stick to old v4 technology adapted to v6. We need to be rid of the broken structure before it plagues us further. These "IT Pros" need to crawl into a hole and die.

    62. Re:No support for dynamic address assignment?!? by mellon · · Score: 1

      Yeah, ND needs work, and is being worked on.

    63. Re:No support for dynamic address assignment?!? by unixisc · · Score: 1

      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 needed in the address translation.)

      So by endorsing NAPT, the IETF came up w/ one mechanism for not just network abstraction and load balancing, but also ONE standard way for NAT lovers to implement their favorite rebel protocol in IPv6. This way, even NAT is cleaner on IPv6 than in IPv4, where you have static NAT, dynamic NAT and PAT, and what's used is usually the third.

      One thing I do agree w/ you - I think the /64 assignment as the subnet size is insane, and leaves the prefix size wanting. While ARIN is generous w/ /48 assignments, both APNIC and RIPE see a potential of running out of space, and are therefore more conservative in their assignments, usually assigning /56. I happen to think that had the subnet boundary been fixed at the 96:32 mark, that would have allowed for a more rational allocation of space to the ISPs, while still allowing autoconfiguration, albeit somewhat less unique (1 in 4 billion still). The only thing ISPs would have gotten would have been /56-64s, but they'd have had the choice to allocate their customers /80 or /96, depending on how much they needed. Also, it would have been easier to organize the IPv6 internet into a globally routable hierarchy w/ really compact routing tables, and also, organizations that needed PI addresses could have gotten their own /64s which they could have then split and assigned geographically, and maybe administered/allocated directly by the IANA, as opposed to individual RIRs

    64. Re:No support for dynamic address assignment?!? by mellon · · Score: 1

      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.

    65. Re: No support for dynamic address assignment?!? by Demena · · Score: 1

      You are correct. It is a feature. Avoiding NAT and DHCP were some of the main reasons for creating it way back when, IIRC.

    66. Re:No support for dynamic address assignment?!? by mellon · · Score: 1

      Actually RFC 6434 explicitly states that there is no such requirement.

    67. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Just because you want to do things one way doesn't make it a requirement.

      You should tell this to the guy at Google who refuses to add DHCPv6 to Android. (The point of the TFA)

    68. Re: No support for dynamic address assignment?!? by Demena · · Score: 1

      You were told that without NAT we would run out of addresses. This pretty much happened. NAT and DHCP were written as stop gaps for which there *should* be no need with IP6.

    69. Re:No support for dynamic address assignment?!? by unixisc · · Score: 1

      If you use an Android phone or tablet to tether another device, it would become a de-facto IPv6 router. Which is when the above scenario kicks in

    70. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      the only thing that's semi-annoying about SLAAC, that i've found, is an inability to map the dynamic privacy-extensions addresses to the corresponding device on my network (for monitoring purposes). but otherwise, yeah, no need for DHCP... fine by me.

    71. Re: No support for dynamic address assignment?!? by unixisc · · Score: 1

      DHCP was never seen as the albatross that NAT was. Just that DHCPv6 was so different from DHCPv4 that the former was perceived as being a lot less essential in IPv6 than its counterpart in IPv4. However, the IETF always seriously defined DHCPv6 as a part of the standard, although it may have been far down the totem pole in importance. In the case of NAT, however, the IETF was dragged kicking & screaming due to the few use cases that made NAT popular, namely load balancing and multi-homing.

    72. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Actually, arth1, Cramer s right.

      The MAC is not needed -- a client identifier is used. It just so happens that most DHCP clients use the MAC as this client identifier. Furthermore in no case do "you" provide the MAC unless you are configuring the server with a reservation for a particular IP for that MAC. The DHCP Discover and request packets sent by the client provide the MAC but "you" don't.

    73. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      The only question is why did Google decide to push this negative feature?

      Because it's irrelevant to 99% of the userbase.
      As in, nobody runs IPv6 on their home wifi network and nearly nobody uses IPv6 at work on internal networks & there's no pressure to support a feature nearly nobody needs.
      If you think about it for 10 seconds it's kinda obvious. When was the last time you got an IPv6 address on a private network either at home or work?

    74. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Probably why nobody other than braindead academics and neckbeards give a rats ass about IPv6.

      -- lead architect at a ~450gbps ISP with no IPv6 pollution :)

    75. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      It's only required if the network admin has an address layout plan and wishes to implement it - that's when DHCPv6 is needed.

      And I would argue that isn't an "IT Pro" but an idiot that doesn't understand IPv6 and may even lack a basic grasp on probability.

    76. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      If DHCP is your solution to management prior to address assignment....I have an 802.1x to beat you over the head with.

    77. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Pretty much everything in my house gets an IPv6 address. A fairly sizable portion of Comcast's customers are using IPv6 and don't even realize they are doing so.

      I have a cock to stick in your mouth now.

    78. Re:No support for dynamic address assignment?!? by toejam13 · · Score: 1

      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.

      Sure you do. You can enable logging of neighbor discovery protocol (NDP) packets and logging on dynamic host registration. It isn't as simple as a DHCP lease, but it can be done. And given that IPv6 addresses tend to be fairly static, Bob and Fred will probably have the same address day after day.

    79. Re: No support for dynamic address assignment?!? by SuricouRaven · · Score: 1

      It's only getting worse. Even some ISPs now have had to resort to NATing their customers. In a few more years you might not be able to get a public IP address unless you fork over the money for a business connection.

    80. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      But it's "everyone else involved in making it work" that are still dragging their feet. Some of us have been requesting IPv6 prefixes for years, and keep being told "we don't have any plans for that".

    81. Re:No support for dynamic address assignment?!? by locofungus · · Score: 1

      I'll put this here for want of a better place to ask the question:

      Are there any good resources (newsgroups, mailing lists, forums) for people trying to setup ipv6 networks and trying to understand the best way to do it? The debian ipv6 mailing list is (almost) devoid of traffic.

      My home network has three ipv4 subnets but I've discovered that it's non-trivial to use the same design on ipv6. It's possible but I don't want to go there unless it's the right way to do it in ipv6. My ipv4 network is the culmination of years and years of experimenting.

      Reading through the other comments here, it sounds like many ISPs are thinking of assigning a /128 or maybe a /120 to their end users which I think is such a shame. At minimum they should be assigning a /64 and, ideally a /56 or even /48.

      Apart from anything else, if they start assigning anything smaller than a /64 then it's going to be easy to collect ipv6 addresses to attack and it's going to be hard to impossible for end users to mitigate this.

      --
      God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
    82. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Try to get an IPv4 allocation and THEN tell me how there was no impact.

      At least it's possible. Trying to get an IPv6 allocation gets a response of "no plans for IPv6" from every ISP around here.

    83. Re:No support for dynamic address assignment?!? by Macfox · · Score: 1

      DHCP client sends the DHCPRequest message, containing the MAC address of the client, to the limited IP broadcast address 255.255.255.255 and to the MAC-level broadcast address. The DHCP Server/ Relay Agent receives this packet and replies with a reservation or forwards it as a directed IP packet to the configured DHCP server or servers.

      --
      Area51 - We are watching...
    84. Re:No support for dynamic address assignment?!? by sjames · · Score: 1

      The right way is to get a /63 from your ISP and subnet it into 2 /64s. Failing that, you can segregate using whitelist on the internal vlan and brouting based on ARP table.

      I will concede that DHCPv6 might be a helpful tool given an ISP that can not or will not do the right thing and give you a /63.

    85. Re:No support for dynamic address assignment?!? by sjames · · Score: 1

      That is a pain as well in many places, but you do have the option of 6to4 or a tunnel to v6.

    86. Re:No support for dynamic address assignment?!? by bbn · · Score: 1

      Except for cellular carriers, almost all ISPs are assigning multiple /64. Most are doing either /56 or /48.

      The way to structure your internal network with three subnets is very simple. You will use three /64 out of the /56 or /48 that you got from your ISP.

      There are many reasons that ISPs will not be assigning /64 or smaller. That is simply very hard on the ISP equipment. So have no fear, that will not become common.

    87. Re:No support for dynamic address assignment?!? by UberLord · · Score: 2

      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 Microsoft, but I do know that Android uses an old version of dhcpcd.
      dhcpcd has supported DHCPv6 for a long time now, so they just have to upgrade it to get it to work, which means this is purely a political rather than technical problem.

    88. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      That's just as much of a hack as NAT.

    89. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      You talk about required protocol behavior as "hand off" and an optional client-side, unenforceable addressing scheme as though it provides more control to administrators. Please consider that you're demanding a different KIND of control, not simple MORE control, and that the difference isn't about who wants to do what to their network, but how they want to accomplish it.

    90. Re:No support for dynamic address assignment?!? by bbn · · Score: 1

      I do not know about APNIC, but RIPE accepts /48 assignments to end users. All ISPs in my country, which are doing IPv6 (which few of them are), are handing out /48 to users. So that is kind of the standard here.

      Even the smallest ISP can get a /29 allocation from RIPE. That is a half a million of /48 assignments to give on to end users.

      The problem with the idea of a global hierarchy routing is that the internet is not a hierarchy. BGP simply does not work like that. Solving that (if it needs solving) requires something more. One proposal is LISP.

    91. Re: No support for dynamic address assignment?!? by mikael_j · · Score: 1

      Yup, my ISP sneakily moved their customers over to carrier-grade NAT a few months ago. Wound up having to call them to get a public IP address again.

      --
      Greylisting is to SMTP as NAT is to IPv4
    92. Re:No support for dynamic address assignment?!? by bbn · · Score: 1

      Android does not support DHCPv6 at all. Proposing that they should implement IA_PD but not IA_NA is silly. Doing that might very well break PD on networks where there is a requirement that the next hob for the PD is known and stable. Such as ours...

      What you can't do? You can't do tethering except on 3G/4G networks. Why you would want to? Dunno, but I notice that not every Android device is a phone. There could be use cases for that.

      Also there are universities and large companies that simply wont let you do SLAAC. I have no experience running such networks, so I can not tell if they are right in doing that. I imagine they could have some of the same issues that we have in our ISP network (ND cache exhaustion etc). A simple defense could be to use a /120 or /112 with DHCPv6.

    93. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Using it now. My work delivers IPv6 addresses via DHCPv6 (ofc together with IPv4) dns is also v4 only

    94. Re:No support for dynamic address assignment?!? by locofungus · · Score: 1

      The way to structure your internal network with three subnets is very simple. You will use three /64 out of the /56 or /48 that you got from your ISP.

      Yeh, right. And then it starts sending traffic with one ipv6 /64 address over a different interface, which makes sense because ipv6 addresses are globally routable - except that my firewall thinks "hey this is spoofed traffic" and blocks it.

      I have a WLAN which, from the PoV of my LAN is equivalent to "the internet" and I have a VPN. Wifi devices that want to talk to my LAN need to connect via my VPN. Except that I then find the device using the VPN ip via the WLAN IF.

      I know how to resolve this, I just don't know the best way to resolve it. My network is small enough that I could just staticly configure everything - but then I'm potentially going to get headaches in the future with devices that don't let you configure the default policy table.

      --
      God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
    95. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      Not without rooting the device.

    96. Re:No support for dynamic address assignment?!? by bbn · · Score: 1

      Typically your firewall is also the device that is handling the DHCP-PD with upstream and assigning /64s to your downstream routers or to different ports on the device. It will just work. It will not think that the traffic is spoofed. It will also do connection tracking and know exactly what is spoofed and what is not.

      Devices will pick the correct IP from the outgoing interface. If your laptop has a Wifi connection, it will use the Wifi address when initiating connections that way. And the LAN address when sending out traffic on the wired network.

      Applications can override that behavior but then you are dealing with misconfiguration or broken applications.

      Trouble with devices connected to two subnets (links in IPv6 terms) at the same time are basically the same with IPv4 and IPv6.

    97. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      No. So much no.

      IPv6 is more about stateless autoconfiguration, not stateful.

      In the IPv6 world, one or more routers say "Hi, this is me, and this is my network information. Use this information to generate your IPv6 configuration. I don't really care what your address is, just find one that works and isn't being used."

      On a side note, DHCPv6 was not designed to do what you think it was, and when the original RFC for DHCPv6 was published in 2003, dial-up was still the dominant internet access method, with roughly twice as many connections as broadband.

      And if you're trying to control/audit users based on DHCP, you're doing it wrong.

    98. Re: No support for dynamic address assignment?!? by johnw · · Score: 1

      IPv6 is not just IPv4 with 2^96 more addresses.

      Nor even 2^128 - 2^32 more addresses (a significantly larger number)

    99. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      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.

      NAT is evil, they are right, it breaks the end-to-end model, and people confuse/misuse it for security.

      That being said, there are cases where NAT is useful, and NPT (network prefix translation) works quite well for IPv6 - i.e. you just staticly swap out the /64 network prefix, so you always have a 1-to-1 NAT, and do not need to track state in connection tables.

    100. Re:No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      What ISP's are issuing /64's?

      Every one I've seen issues at least a /56, and more commonly a /48.

      You shouldn't need to split a /64 down. (Apart from things like /127's etc being used on statically configured point to point links).

    101. Re:No support for dynamic address assignment?!? by locofungus · · Score: 1

      You see, this is why I'm looking for a good newsgroup, etc.

      The ipv4 problems are solved with routing tables and the VPN handing out routes for places that the VPN can reach. But all the /64s are currently in the same /48 so, IIUC, every /64 is equally close to the other /64s.

      When I naively map my ipv4 setup to ipv6 it doesn't work.

      My laptop, for example, acquires acquires a ::3/64 and ::4/64 address via wifi and vlan. The same way it acquires a x.x.3/24 and x.x.4/24 ipv4 address.

      Now, when I ping6 a ::2/64 address it will decide to use the ::3/64 address regardless of whether I ping via the vlan or wifi interface. Or it might decide to use the ::4/64 address on both interfaces instead - it seems to be random which ip it picks but once it's picked one it's persistent for a time at least.

      Which makes sense. But doesn't "just work". There are multiple possible ways to resolve it.

      Update the default policy table - now it will use the ::3 on the wifi and ::4 on the vpn interfaces. This works but involves setting up the default policy table on the client which I want to avoid if possible. Maybe it's possible to hand out this with the router advertisements - if so I don't know how.

      Update the firewall to allow traffic via the vpn interface to the lan even if it comes from the wifi address. But I'm not so sure about the opposite route, allowing vpn ip traffic via the wifi interface - because then someone could spoof the vpn ip and effectively become part of my lan.

      Have some sort of hierarchical network structure so that the vpn subnet looks closer to the lan subnet than the wifi one does - hopefully then it will pick the "right" ip over the "right" interface depending on which interfaces are up or down. (I'm guessing a bit with this one)

      My home network is "unnecessarily complicated." But my experience with it has put me in good stead when dealing with networking issues on larger networks because I understand what my network is doing and why and so I have a good handle on investigating issues when something isn't working. I'd like to gain the same experience with ipv6. I am not, and have no desire to be, a professional networking engineer but it's very useful to have a good handle on what is going on when I need to talk to them.

      --
      God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
    102. Re: No support for dynamic address assignment?!? by Anonymous Coward · · Score: 0

      And in 5 years time when Google realises they made a mistake and finally start supporting it in Android, all existing devices won't work properly on many networks due to the Android fragmentation problem.

    103. Re:No support for dynamic address assignment?!? by bbn · · Score: 1

      That is not what should happen if you have it configured proper.

      Say your prefix is 2001:db8:1::/48

      Your LAN is 2001:db8:1:1::/64
      Your WIFI is 2001:db8:1:2::/64

      Your laptop has 2001:db8:1:1::10 on the LAN and 2001:db8:1:2::20 on the WIFI.

      Now if you type ping6 2001:db8:1:1::42 it will automatically prefer the LAN interface and use the 2001:db8:1:1::10 IP address. It will not use the WIFI address unless you force it.

      On the other hand if you ping6 2001:db8:1:2::42 it will select the WIFI interface and use 2001:db8:1:2::20 as source address.

      If you ping something on the internet or if you ping 2001:db8:1:3::99 (assuming the laptop is not connected directly to that), it will first select an outgoing interface (either LAN or WIFI) and then pick the source address from that interface. Again unless you force it to do something different. These are the default address selection rules.

    104. Re:No support for dynamic address assignment?!? by Dagger2 · · Score: 2

      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.

    105. Re:No support for dynamic address assignment?!? by IamTheRealMike · · Score: 2

      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.

      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 Android team build what is primarily a consumer product. When they make decisions, they think in terms of what is best for ordinary consumers. They also consider the needs of software developers. Therefore they highly prise qualities like "it just works" and "my apps don't break" and "I can tether without restriction". From this perspective as far as I can tell, Lorenzo's position is 100% correct. The founding vision of IPv6 was that you should always have as many addresses as you need for whatever purpose, and we should never need bizarre technical hacks to work around a lack of addresses ever again.

      The network admins on that thread are building what they perceive as a 'take it or leave it' service, often, provided to a captive audience like a university campus or enterprise. Therefore they highly value qualities like "I can satisfy the legal department" and "I can use my existing hardware that only supports feature X" and "I can block tethering to my network to implement some security policy". They care relatively little about user or developer experience, as evidence by the number of comments on the thread of the form "If we can't get our way we'll just ban all Android devices" or "The device should tell the user that 464xlat is unavailable and let apps break" or "the device should tell the user that tethering is forbidden". They care little about application reliability or complexity as long as they can tick some boxes at the end of the day and satisfy various policies. From their perspective Android is just making their jobs harder and Lorenzo is therefore being mind-numbingly unreasonable.

      This situation is somewhat confused and hard to distill because there seem to be multiple different things being discussed on the same thread, e.g. DHCPv6 PD which is apparently unrelated to address allocation.

      Now, frankly, having read and understood many of these comments, I find myself siding (weakly) with Lorenzo, and not just because I know him. As an Android user and an app developer, my priorities are more closely aligned with that of the Android team. I do not wish to experience apps breaking or "tethering denied" messages in future due to some lawyer buttcovering that was translated into a network setup with the absolute minimum of effort by a monopolist IT department. If that means I fall back to IPv4 for a while instead, well, so be it. If that means my phone cannot reach the small number of IPv6 only networks when connected to some random university campus, OK, I'll use my LTE connection. And then I'll complain to the IT office and tell them "just buy an iPhone" is not an acceptable answer, so they had better get on it and allow my device to grab as many devices as it wants without having to go through a DHCPv6 server. Just like my home and mobile ISPs do. And if that means they have to do more work to satisfy the next BSA audit - well, that's why they get paid the big bucks.

    106. Re: No support for dynamic address assignment?!? by sjames · · Score: 1

      Yes, it absolutely is. It is a dirty hack allowing you to go around an ISP that's living in the last century. And done right, it's still better than NAT if you want to actually access your machines at home when you are out.

    107. Re:No support for dynamic address assignment?!? by arth1 · · Score: 1

      The DHCP Discover and request packets sent by the client provide the MAC but "you" don't.

      That's semantics. Whether the client app inserts it or the network stack adds it does not matter in this context - the DHCP server receives it, and needs it for all directed communication until after the client has received an IP address.

      If a client does not send a client ID, the MAC is also normally used to generate a unique but repeatable client ID. Gleaned from the network packets, where it assuredly is present, no matter how you define "you".

    108. Re:No support for dynamic address assignment?!? by dave420 · · Score: 1

      I use it all the time. My ISP has a full IPv6 service, and all my home computers & network gear use it.

    109. Re: No support for dynamic address assignment?!? by Coren22 · · Score: 1

      AC appears to understand exactly how NAT works. The reason for servers that sit in the cloud to handle smart plugs and the like is because those devices can't be connected directly to because of NAT and port limitations. If there is no NAT, there is no need for the server in the cloud as your phone or whatever could connect to the IoT item directly instead of utilizing the company's server in the middle. IPv6 would be great for the IoT, though I don't think it will truely get rid of NAT as NAT is more secure by default for users who don't understand networking enough to setup firewall rules.

      I however would love to be able to have more than one system behind my firewall be listening on the same port. I have run into this need with Steam dedicated servers, you can't have multiple systems running dedicated servers as they won't be listed in the server lists, only one of them can talk back to the central Steam server list.

      --
      APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
    110. Re:No support for dynamic address assignment?!? by Coren22 · · Score: 1

      When did Google become Comcast? Google doesn't support DHCPv6, what does that have to do with Comcast supporting or not DHCPv6?

      FiOS still doesn't support IPv6 though, which makes me sad.

      --
      APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
    111. Re:No support for dynamic address assignment?!? by bobbied · · Score: 1

      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. The "MAC" of the device can change, btw. (different NIC, wireless vs. wired, etc.) And a MAC isn't the only thing the server can use. (in fact, I'm cursing Sun for the ALOM using the serial number instead of MAC for it's client-id.)

      For heaven's sake, so are we doing away with ARP tables now? Read what I wrote.. IF YOU CARE about which phone is which, then MAC's are something you will need to know at some level.

      Look, in order to respond to ANY DHCP request (or pass ANY packets over layer 2 for that matter) you MUST know the MAC address of the destination (or be doing a broadcast to everybody on the segment). IPv6 doesn't mess with layer 2, you still need to know the MAC of the destination you are trying to send that packet to. If you care who's phone is who's, then you (at some level) will need to know the MAC address of each.

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    112. Re:No support for dynamic address assignment?!? by sjames · · Score: 1

      Sure, it can be done and IMHO, should be done. However, it's not fair to claim stock Android has no ability to handle dynamic addresses. And all of that about legal requirements was 100% grade A BS.

    113. Re: No support for dynamic address assignment?!? by Geordish · · Score: 1

      IPv6 would be great for the IoT, though I don't think it will truely get rid of NAT as NAT is more secure by default for users who don't understand networking enough to setup firewall rules.

      You are confusing a NAT with a firewall.

      Today people buy, or get sent from their ISP a router with NAT and a firewall enabled. The NAT does the bodge for addresses. The firewall protects you. The default settings are a default deny inbound, and a reflective default accept outbound.

      There is no reason why this couldn't be enabled on IPv6 by default also. This part works pretty much the same.

    114. Re:No support for dynamic address assignment?!? by Geordish · · Score: 1

      Now, with IPv6 things look better with pretty much unlimited addresses, however:
      1. If I have at least one Android device, I either have to set up static IPs or ask the ISP for more subnets, as if /64 could not be split into smaller subnets. Oh, right, the devicewants to put its MAC addressas part of the IP - yay for tracking? Oh and why the ISP should give me more subnets for free? So, I guess I'd better start putting money into the suitcase...

      Nonsense. Privacy extensions are enabled by default on all modern operating systems. And I'm even including windows XP in this! The general accepted policy is to provide a /56 or /48 per site. This should give you more than enough networks to stick to the recommended /64 boundary. Oh, also if you are a bit of a hippy, breaking a /64 down smaller is possible.

      2. No NAT means the internal IPs change if the ISP decides so or I change ISPs. DNS is not an option since it can fail just as well as DHCP can. Also, even with DNS it would be a PITA to change all the records to point to new IPs. Also, firewall configurations need to be updated.

      If you MUST have IP addresses that don't change, you can use NAPT. This is a 1:1 mapping of IPv6 addresses from global scope to local scope. If you don't want to do this, then tools will come along (or already exist!) to assist managing things like DNS, firewalls etc. At the end of the day, its only the first 64 bits that change. The last 4 stay the same, so worst case s/// would do the trick for most things.

      3. Private ASs are discouraged, apparently they mess up the routing tables. So, now I do not have redundancy and the ISP can cause real problems for me because of #2. Or I have to work out a three sided deal between me and two competing ISPs. I guess I'd better find another suitcase for the money...

      I'm not sure where you heard this? Private ASs (private isn't even the correct term here. There is a range of 'private' AS numbers that are for use within a network) are not discouraged at all. If anything they are encouraged. (I'm in the RIPE region, my viewpoint is based on their policies)

      If you want an AS number. Just apply.

      You also don't require an AS number to have your own address space. There is a thing called Provider Independent space. Address space, but no AS number (I believe this is the route ARIN require you to take to get an AS number) Contact your local ISP, and ask them to help you out with that. You can then multihome with it, and even take it with you to a different ISP.

    115. Re:No support for dynamic address assignment?!? by Pentium100 · · Score: 1

      Split the /64 into smaller networks -- SLAAC no longer works -- Android devices have to be manually configured with static IPs since they do not support DHCPv6.

      But don't private ASs and Provider Independent addresses conflict with the "neat routing tables" goal when I take my AS to another ISP which may be in another country?

    116. Re:No support for dynamic address assignment?!? by locofungus · · Score: 1

      I decided to take some more time to investigate this.

      It turns out I'm a victim of this bug:

      https://bugs.debian.org/cgi-bi...

      Sometimes (not always) the VPN /64 ends up assigned to the wrong interface on the client - leading to traffic apparently being sent out on the wrong interface for the source address that is supplied.

      This gets doubly confusing because the source address is chosen based on the interface it _should_ be routed through. So if my route to 2001:db8:1:3::99 should be via the wifi interface then it will pick 2001:db8:1:2::20 as the source address even if you tell ping6 to use the LAN interface instead.

      And you can have one client successfully connected via the VPN and all is well. Another client connects, radvd starts advertising via the wrong interface and suddenly the working client acquires another /64 on the wlan interface and stops working when it starts picking a different source address. Grrr. Oh well. At least I know what is wrong now.

      I _think_ restarting radvd fixes the problem - so a quick fix might be to bounce radvd every time an interface comes up (and possibly goes down too)

      --
      God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
    117. Re: No support for dynamic address assignment?!? by Geordish · · Score: 1

      True, SLAAC does require a /64 boundary. I would not recommend deploying anything other than that on a network. Android currently does have a problem. One of two things will happen.

      1) Google will implement dhcpv6. There are 2 versions stateful, which works much the same as the v4 variant, and stateless, which is used to provide extra information like a DNS server when configuring via SLAAC.

      2) everyone standardises on something else like RDNSS.

      I predict that the first option will occur.

      As for 'neat routing tables' there is no such thing. One aim was to reduce fragmentation, which it may do. People owning their own address space is not a big problem though.

      Also IP addresses and AS numbers are not tied to a location. ISPs are already crossing international borders without any complaints. Move your prefix where you want to.

      Please stop calling them 'private AS numbers'. They are a thing, but not what you are referring to. They are not routable on the internet. You just want a normal AS number. Same as everyone else.

    118. Re:No support for dynamic address assignment?!? by Ingenium13 · · Score: 1

      By default it will use a random privacy address (I believe RFC 4941). So the address will change daily, or every time the device reconnects to wifi, whichever happens first.

    119. Re:No support for dynamic address assignment?!? by Cramer · · Score: 1

      so you are going to need to know, in advance, who's MAC is who's. You'd need that knowledge for a DHCP server too...

      One does not pre-program the DHCP server with a list of MACs, nor does every client identify itself by MAC -- the client-id can be many things, MAC being but one of them.

      In order for you to get the reply back from the DHCP server, it needs your MAC address.

      *sigh* No it doesn't. A unicast reply needs a destination MAC, either the end client or a relay agent. A broadcast reply, however, DOES. NOT.

    120. Re:No support for dynamic address assignment?!? by Cramer · · Score: 1

      Using the MAC as an ID is a flawed method. Devices come and go, MACs change (because the NIC changed, etc.) Ultimately -- and here's the end of it -- you'd have to be maintaining a registry of every device's MAC within your network to know what's what, where, and who's using it. Just gleaning a "list of mac's" is simple enough, albeit a tedious pain in the ass: arp tables, cam tables, watching broadcast traffic, etc. Knowing the location of each device gets a lot more tricky; sure wired devices will be tethered somewhere off a switch port, but that's not always enough. Wireless devices, on the other hand, can be anywhere. And none of that addresses who's device it is, who's using it, and exactly what it is. (OUI's only go so far, and assume no one is forging their MAC.)

      When someone carries a device into the office, does something questionable with it, and then leaves, tracking the who/what/where/when becomes much harder. When the questionable act isn't mentioned for weeks or months, it can become impossible.

      Case in point, I had to trace down a "hacker box" in the network. It was a lot easier because it was ON and ACTIVE at the time. Looking through cam tables, I could only go so far as an unmanaged hub. (yes, this company still used far too many hubs. even in 2003.) Careful inspection of the hub (and unplugging one port at a time), localized it to a desk. An unoccupied cubical, in fact. By the time I got to that desk, the machine had been turned off (it was still warm), the "warez" hard drive had been removed (windows registry remembers it), and the non-company 3com nic had been removed (again, registry -- which is how I knew 100% that's the machine I'm looking for.) That was the company computer for that desk, which is the only reason it was still there. Had he used one of his own machines, it could've simply disappeared without a trace. Moral of the story: I had a MAC, and it didn't tell me shit. The "who" was only discovered because his coworkers ratted him out :-) ("Who's been using X's computer?" They didn't know he was doing anything stupid with it.) And that only worked because it was in real time; had it been brought up a month later (nothing to trace) (and there not been a hub muddying the picture), any history logs would simply have ended with "I don't know. It was something at X's desk" [X having left the company many months ago. X's computer official off since it's builtin NIC, registered in company inventory, wasn't being used.]

    121. Re:No support for dynamic address assignment?!? by Cramer · · Score: 1

      Stock android has no means to handle DHCPv6. It's not there. At all. You can (maybe) root your device and (maybe) add it yourself. But that's beyond 99% of android users. ("root, run custom rom downloaded from internet" - lots of people do that.)

      You can call it BS all you want, but there are environments where legal accountability is a requirement. Could you side-step their tracking voodoo? Probably, but that's even more tinkering with your android device.

    122. Re:No support for dynamic address assignment?!? by arth1 · · Score: 1

      *sigh* No it doesn't. A unicast reply needs a destination MAC, either the end client or a relay agent. A broadcast reply, however, DOES. NOT.

      *sigh* This is wrong on so many levels.

      1: The DHCP protocol mandates that every packet contains the hardware address (for ethernet, the MAC address) in the chaddr field.

      2: It's the client's call to DHCP servers that discloses the client's MAC address. What replies do is irrelevant.

      3: Even if that weren't the case, all packets including replies still contains the client's hardware address in the chaddr field. Without it, bootp dhcp relays would not work, as they do not parse the data segment of the dhcp packages and would not know what the client identifier key is set to.

      4: Even if that weren't the case, the DHCPOFFER, DHCPACK and DHCPNAK packets from the server to the client are almost always unicast. No dhcp client in use today will set the broadcast flag on its DHCPDISCOVER or DHCPREQUEST messages - the RFC is pretty clear that only clients that cannot receive unicast replies should set the broadcast bit, all others should clear it. You may find an old Sun box from the 1990s with a bootp client that needs to use broadcasts exclusively before its network stack comes up, but that corner case is so small that it can be ignored for this purpose. And even then, the client must fill in the chaddr field, and the server leave it as is in replies.

      But to sum it up, yes, you tell the DHCP server your MAC address.

      And modern DHCP servers use that information too, not just the client uid. For one thing, combined with turning off broadcast replies, it allows for restrictions on how many IP addresses can be given to any client (a fairly common attack back when was to keep on requesting and accepting addresses, exhausting the pool).

    123. Re:No support for dynamic address assignment?!? by Cramer · · Score: 1

      RFC2131, Section 4.4.1

      The client MUST include its hardware address in the 'chaddr' field, if necessary for delivery of DHCP reply messages.

      The word used is SHOULD. There are still plenty of DHCP systems that request (require) a broadcast reply. Go listen to the broadcast traffic on your cablemodem.

      And I'm FAR TOO well aware of systems using the wrong hardware address in their requests -- more than one nic, and it uses the MAC from the first nic in all queries no matter which nic it's asking about or using. (and this is from an ISC DHCP client!)

      TL;DR chaddr [Client Hardware ADDRess] is 16 bytes of whatever the client puts there.

      (Replies in my network are broadcast so the boot agent can see them.)

    124. Re:No support for dynamic address assignment?!? by sjames · · Score: 1

      But it will use a constant MAC address which can be logged with the associated IP address.

    125. Re:No support for dynamic address assignment?!? by sjames · · Score: 1

      And it will STILL find itself a non-conflicting IP address given a router announcement. One might even say it's a DYNAMIC IP address.

      That does nothing to prevent legal accountability if you know the devices MAC address, you can log each and every contact with the outside world. It's not the legal accountability that's BS, it's the claim that DHCP is necessary for it or even that it exists under it.

    126. Re: No support for dynamic address assignment?!? by Plumpaquatsch · · Score: 1

      What a waste of address space... That many PUBLIC IP's? What a mess that must be.

      Hey, if you own a Class B net (or even Class A), why would you skimp on public addresses? You have them. Not using them would waste them.

      --
      Of course news about a fake are Fake News.
    127. Re: No support for dynamic address assignment?!? by Plumpaquatsch · · Score: 1

      Isn't NAT and private address space a method of overcoming the limitations of IPv4? Shouldn't IPv6 be able to enable new home routers to be designed to avoid some private addresses where needed, specifically for the purposes of allowing access to our things. Old routers seem to be needed in order to circumvent our privacy. Until this is answered then no employee of a cloud based service would be expected to come clean about why they use such external servers. In other words aren't old IPv4 routers underpinning the current business model for any home device that needs to be accessed from outside?

      First of all: you mean PAT, not NAT. Port address translation. And that leads to tons of problems (on top of those plain NAT brings) network admins would like to avoid - by using IPv6. Google for "NAT traversal" and "Application Level Gateway" for just a small part of the problem.

      --
      Of course news about a fake are Fake News.
    128. Re:No support for dynamic address assignment?!? by unixisc · · Score: 1

      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.

      That's DHCPv4. In case of DHCPv6, the DHCP server proactively gives addresses to everybody it discovers in its network through router advertisements. The process is reversed here - the server gives the client addresses first, as opposed to the client asking for it first.

    129. Re:No support for dynamic address assignment?!? by unixisc · · Score: 1

      But you don't have broadcasts in IPv6. The equivalent that you have is a multicast to all nodes of that subnet, so the equivalent of x.x.x.255 would be ff02::1 i.e. a multicast to all nodes in the local link multicast group. Also, in IPv6, since the client can automatically create its own link local address - fe80::[EUI-64], can't the router automatically use that to assign a subnet address once it finds that node within the network? In other words, all communication can be layer 3 only, instead of having to go through layer 2?

    130. Re: No support for dynamic address assignment?!? by unixisc · · Score: 1

      So does ND and DAD - those 2 too would break if you tried a prefix length of, say, 96.

    131. Re:No support for dynamic address assignment?!? by unixisc · · Score: 1

      There are a lot of reasons why a network admin might want control on his address mapping scheme, that has nothing to do w/ either probability (irrelevant here, since DAD eliminates the possibility of duplicate addresses) nor the convenience of auto-configuration or an 'understanding of IPv6'.

    132. Re:No support for dynamic address assignment?!? by bobbied · · Score: 1

      Well.... Could I strongly suggest layer 2 security on your network?

      Look, your story, which I believe fully, just tells me that your company has some serious issues with physical security AND network security. You got darn lucky if you ask me. That you found anything is a wonder, but your perp was pretty stupid in how they went about this and left tracks. A more thoughtful offender wouldn't leave any traces, given your security. A couple of things you should seriously consider doing:

      1. NEVER leave equipment which is unused laying about. Lock that stuff up so it doesn't walk away.

      2. NEVER leave unused network ports wired to anything. Go into the wiring closet and disconnect any/all unused ports physically, or failing that put them onto a VLAN that goes nowhere. You simply cannot allow unauthorized and uncontrolled physical access to your network. (Your wiring closet does LOCK right?)

      3. ALWAYS put Layer 2 ingress security in place. If the device isn't a known MAC on the expected port, don't pass traffic from it. (see #2) There may be exceptions to this rule in conference rooms and such, but MONITOR these if you leave them open.

      4. Have policies in place to forbid employees from bringing stuff in from home. No personal hardware touches company computers, no personal software get's installed without approval etc. I know it doesn't prevent anything, but it gives the company justification for dealing swiftly and harshly with this kind of thing. Enforce the policy!

      5. MONITOR YOUR NETWORK - Somehow, monitor your network. Look for new and unexplained MAC's, run a local DNS cache and monitor what's being hit, monitor firewall logs etc, I know monitoring systems are expensive, but do what you can with what you have.

      So, where the MAC didn't get you much in your investigation, it was KEY in tracing down how the traffic entered your network. It might not have helped you that much, but that's more about your company's security posture than MAC addresses. Shame on you if you let a rouge MAC address onto your network through some wired port on a cheap hub and have issues tracing it down....

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    133. Re:No support for dynamic address assignment?!? by Bengie · · Score: 1
      DHCPv6. Google it

      DHCPv6 provides more control to the administrator in assigning addresses. If you really want that sort of control over your IPv6 addresses, you don't understand IPv6 yet.

      You're doing it wrong!

    134. Re:No support for dynamic address assignment?!? by Bengie · · Score: 1

      CGN is more expensive, more complicated, and reduces customer satisfaction. Perfect for anyone who wants to become a Comcast or Verizon as one of the worst ISPs.

    135. Re:No support for dynamic address assignment?!? by Bengie · · Score: 1

      Just you wait. ICANN is changing policies and will soon start taking back IP blocks from people and drastically raising prices. Need a /24 so you can multi-home? Too bad! We can't be wasting those large IP blocks, yoink. Well shit, your company no longer has failover. Get ready.

    136. Re: No support for dynamic address assignment?!? by Bengie · · Score: 1

      Stick me behind carrier grade NAT will you. I guess I'm going to test out my resilience to DDOS attacks. What's my IP. OK, launch a 110Mb/s attack. It's my listed IP, bugger off.

    137. Re:No support for dynamic address assignment?!? by Bengie · · Score: 1

      Also, even with DNS it would be a PITA to change all the records to point to new IPs.

      Mine just works. Out of the box, Stock PFSense picks up the machines name and adds it to the DNS records. My 5 year old wireless $40 printer even works with DNS and no configuration at all on my part.

    138. Re:No support for dynamic address assignment?!? by Bengie · · Score: 1

      They changed their stance on enforcing hierarchical routing. They now allows non-hierarchical routing only for the purpose of multi-homing. You need special IP addresses.

    139. Re:No support for dynamic address assignment?!? by allo · · Score: 1

      for many devices it is no default. AFAIK even the ubuntu bug about using PE as default is still open.

    140. Re:No support for dynamic address assignment?!? by allo · · Score: 1

      Bullshit. SLAAC hands out public space most the time, sometimes private space. Link local is only the route to the gateway, which is intended that way.

  2. Not Needed by Anonymous Coward · · Score: 0

    DHCP in IPv6 isn't really needed because devices can derive their own addresses and the network will automatically handle collisions.

    1. Re:Not Needed by jandrese · · 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. This makes it far from ideal when you want to allow for client to client communications. It also lacks any sort of authentication mechanism which makes it vulnerable to spoofing attacks. Router autodiscovery is a really incomplete solution.

      --

      I read the internet for the articles.
    2. Re:Not Needed by Anonymous Coward · · 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)

      Whether devices honor them is another issue.

    3. Re:Not Needed by pjtp · · Score: 1

      RFC 6106 adds the ability to specify DNS server addresses in router advertisements; unfortunately, it is not widely adopted. Even then, it is not a replacement for DHCPv6 and only serves to make stateless auto-configuration more useful.

    4. Re:Not Needed by mellon · · Score: 2

      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.

    5. Re:Not Needed by mellon · · Score: 3, 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.

    6. Re:Not Needed by Pentium100 · · Score: 1

      It's a neat hack, but hardly anybody uses it.

      IPv4 IPs are much easier to remember than IPv6 IPs.

    7. Re:Not Needed by Cramer · · Score: 1

      It's not so much the client OSes that are the problem (they are, but a smaller one.) The real issue is updating the routing hardware with modern compliant software. For the home user, that's a real issue because they know nothing about any of this networking IPvWhatever crap, or their ISP or vendor hasn't or isn't making any updates. In the enterprise, they turned to DHCPv6 years ago and don't give a single shit about the further convolutions of the protocol -- too little, too late. ("What? We have to throw away $mil in hardware to upgrade to IOS 16.5XT to get $New-Knob-X that Windows 11 requires?!? Screw that mess." Also, that's big (read: F'ing HUGE) reason why IPv6 adoption has been so glacial. It's a never-finished protocol that's poorly suited to the way we actually use networks. I have gear that's nearly 30 years old, and it still works perfectly fine with modern IPv4 (TCP) systems -- 30yo network stack, but windows 10 can telnet to it just fine. An IPv6 stack from just a decade ago doesn't fair so well; an original '90s stack won't work at all.)

    8. Re:Not Needed by Cramer · · Score: 1

      DHCPv6 also lacks an authentication mechanism ... in fact ICMPv6 has RA guard

      Neither does ICMPv6 RA. And RA Guard is a layer-2 hack to block the packets -- i.e. must be supported by your switches, unmanaged switches (99.999999999% of home hardware) by definition cannot implement it, older switches never will.

      (For the record, IPv4 had the same thing: ICMP Router Advertisement. It was abandoned before most of us were even aware of "IP", as a colossally bad idea. A completely non-authenticatable system of broadcasting "hey! I'm a router, give me all your traffic"; the networking equiv of the Free Candy Van. Why not do away with routers entirely and go back to proxy-arp!)

    9. Re:Not Needed by unixisc · · Score: 1

      DHCP in IPv6 isn't really needed because devices can derive their own addresses and the network will automatically handle collisions.

      Problem is that not everybody will be comfortable w/ randomly assigned addresses, especially for devices where they'll want to use the raw IP addresses instead of DNS, just like in IPv4. B'cos there are sometimes that DNS adds just another layer of complexity and if an application doesn't work, it's sometimes easier for an implementer to just work w/ the IP addresses. In the past, it might have been something like 192.0.2.57, while now it would be something 128 bits. If the admin can manually assign it, it can be something as simple as 2001:db8:2:23::5. With RAs and NDs and DADs, it could end up like 2001:db8:3ea5:9g4e:8bac:6ecb:a79f:b1a7. Good luck w/ adaption if admins have no control over what sort of addresses get generated.

    10. Re:Not Needed by UberLord · · Score: 1

      Why is DNSSL a Very Bad Idea?

    11. Re:Not Needed by UberLord · · Score: 1

      DHCPv6 also lacks an authentication mechanism

      This is not true. As you wrote RFC3315, I'm surprised you forgot avout Section 21 which is all about authentication.
      https://tools.ietf.org/html/rf...

    12. Re:Not Needed by Anonymous Coward · · Score: 0

      I'd argue that's only if you're lucky enough to get really handy IPv4 addresses or a big allocation. One of the benefits of IPv6 is that I get enough addresses that I can often put important hosts at $PREFIX::2 or some similarly memorable address, and $PREFIX is available via RA broadcasts, so I don't even need to remember that.

    13. Re:Not Needed by Anonymous Coward · · Score: 0

      It's a neat hack, but hardly anybody uses it.

      Only Microsoft Active Directory, so yeah, probably 'hardly anybody'...

    14. Re:Not Needed by Pentium100 · · Score: 1

      I manage the networks of several ISPs (the usually have several /22 allocations) and the company I work for (a single /23) and can remember quite a few IPs, even though the ends are not the same (say, a cacti server IP is x.y.z.5 for one ISP and a.b.c.192 for another). That's usually because I use the IPs to connect instead of DNS names, since I can type 93.184.216.34 faster than www.example.com and the IP works even if the DNS server has failed.

  3. So what? by Anonymous Coward · · Score: 0

    IPv6 is great for the Internet, but your local network doesn't need it.

    1. Re:So what? by Anonymous Coward · · Score: 0

      And the road is great for your car, but you don't need a driveway from your garage to the road. Your car looks great sitting in that garage.

      So tell me smart-ass, just how do I get my "local network" nodes onto the Internet without IPv6 in my local network?

    2. Re:So what? by jandrese · · Score: 1

      True, unless you intend to connect your local network to the Internet, which I think most people are planning to do. You also don't need a global IPv4 address unless you want to connect to the Internet.

      --

      I read the internet for the articles.
    3. Re:So what? by Anonymous Coward · · Score: 0

      So you're saying Android devices can't access the Internet?

    4. Re:So what? by Anonymous Coward · · Score: 0

      Uhm. No. How did you ever get that interpretation from my post?

      I said, in response to the previous poster's comment about the Internet being IPv6, but the LAN doesn't need to be, that if you want your local network to connect to the Internet it will need to be IPv6 also.

    5. Re:So what? by Anonymous Coward · · Score: 0

      You are a fucking idiot.

    6. Re:So what? by AK+Marc · · Score: 1

      Apparently not easily on IPv6.

    7. Re:So what? by Anonymous Coward · · Score: 0

      OK, so you're saying that Google had better upgrade Android before IPv4 goes away? Kind of takes the wind out of the sails of TFS.

    8. Re:So what? by viperidaenz · · Score: 1

      RFC7040?
      RFC6333?
      Lightweight 4over6?

    9. Re:So what? by mellon · · Score: 1

      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.

    10. Re:So what? by mellon · · Score: 1

      My Android phone works just fine on IPv6 networks.

    11. Re:So what? by Anonymous Coward · · Score: 0

      Gaming on Android? Oh my.

    12. Re:So what? by AK+Marc · · Score: 1

      So then, what's the article about?

    13. Re:So what? by bobbied · · Score: 1

      Gaming on Android? Oh my.

      He did say it was for losers...

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    14. Re:So what? by Anonymous Coward · · Score: 0

      No, really. If you want to get your local network devices on the Internet, how do you do that if the Internet is IPv6 and your local network is not?

      Now who is the fucking idiot?

    15. Re:So what? by unixisc · · Score: 1

      It's about Android devices not being able to

      • - accept an IPv6 address from a router where DHCPv6 is the chosen mechanism for distributing addresses
      • - act as CPEs and be tethered if needed if given a DHCPv6 assigned address

      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 issues if DHCPv6 is the preferred mechanism of address assignment

    16. Re:So what? by AK+Marc · · Score: 1

      So IPv6 address assignment works on mobile, but not WiFi. That is much more clear, simple, and shorter than "IT Pros Blast Google Over Android's Refusal To Play Nice With IPv6"

    17. Re:So what? by AndroSyn · · Score: 2

      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 regards to Android phones more than anything.

    18. Re:So what? by Anonymous Coward · · Score: 0

      So you're just talking about a weird hypothetical future world where the Internet has dropped IPv4 support and Android hasn't been upgraded yet?

    19. Re:So what? by Anonymous Coward · · Score: 0

      Actually it works just fine with WiFi.
      I am using it in my local network using radvd to announce the prefix and the DNS.
      Android is using multiple IPv6 addresses.
      The one derived from the mac address (by which you could "predictably" reach it, like when you use it as a server), then another "random" one for privacy (that is used for outbound connections that are initiated by the device)

      The only issue about android and IPv6 I know is that android doesn't seem to be able to operate in a pure IPv6 environment (it uses/requires the IPv4 nameservers), however that information might already be outdated.

      So this issue is about people whining "I want to do it like I did with IPv4" (i.e. assgining individual addresses instead of letting the devices get their own static(based on mac) AND dynamic addresses)

    20. Re:So what? by rl117 · · Score: 1

      Have you actually looked at what's going on over IPv6 on your local network right now? Lots of stuff will do autodiscovery and communicate over IPv6 link-local even if you don't have any outside connectivity or global addressing.

      And for a local network, all-IPv6 is quite a bit nicer than NATed IPv4; and you can use NAT64/DNS64 to talk to the outside IPv4 world without having any IPv4 networking internally. Rather than being dual-stack, you can be IPv6-only and push IPv4 outside. My ISP explicitly supports this setup.

    21. Re:So what? by bbn · · Score: 1

      Try using tethering while you have that Android on Wifi (tethering using bluetooth to a laptop). That wont work because that requires DHCPv6. Why would you want to? I don't know, but that is what is broken here.

      It works while using cellular internet because they effectively have an alternative to DHCP-PD to assign a /64 prefix to the phone. They new LTE standard is switching to DHCP-PD so I wonder what Google will do then.

    22. Re:So what? by Anonymous Coward · · Score: 0

      I wonder what Google will do then.

      Update android whenever they feel like it to support it. It's not hard to support, they just need to do it.

  4. Google's IPv6 SMTP servers by Anonymous Coward · · 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.

    1. Re:Google's IPv6 SMTP servers by Anonymous Coward · · Score: 0

      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".

    2. Re:Google's IPv6 SMTP servers by Yenya · · Score: 3, 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.

      --
      -Yenya
      --
      While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
    3. Re:Google's IPv6 SMTP servers by Macfox · · Score: 1

      Is this Google Apps or Consumer Gmail? Have you raised this issue with Google? https://productforums.google.c... https://productforums.google.c...

      --
      Area51 - We are watching...
    4. Re:Google's IPv6 SMTP servers by Peer · · Score: 1

      In my opinion it's actually something nice. They cannot stop accepting mail from all 'improperly' configured servers. So they decided to impose their standards by making you comply with them once you turn on IPv6. So they are using the IPv6 transition to make sure everybody sets up SPF records and such. In the long run this might help fight spam. However their total lack of feedback on why mail gets blocked is frustrating. There's probably some reason for rejecting your legitimate mail, but the unwillingness to tell you what that reason is totally sucks.

  5. Static by Anonymous Coward · · Score: 0

    Isn't half the point of IPv6 that we can just give EVERYTHING a static IP? Who needs dynamic assignment?

    1. Re:Static by jandrese · · Score: 3, Insightful

      Anybody who moves between networks, like a cell phone? You still do route aggregation in IPv6, so even if your host ID (lower 64 bits of the address) don't change, the network ID (upper 64 bits) will when you move between networks. Otherwise you would need to propagate every single device in the world into the global routing table, and that doesn't scale.

      --

      I read the internet for the articles.
    2. Re:Static by ganjadude · · Score: 1

      static IP 6 address has the devices MAC address in it. Therefore tracking becomes an issue for some

      --
      have you seen my sig? there are many others like it but none that are the same
    3. Re:Static by Mostly+a+lurker · · Score: 1

      With a mobile device (which most Android devices are) that are continually switching between networks, static IP addresses are not ideal. The "static" IP address (for most protocols) needs to be routable. This means the address must change when switching networks. Support for DHCPv6 is arguably the easiest way to do this. Having routers need to recognize when random addresses are generated inside their networks and correctly route them without security concerns is not ideal.

    4. Re:Static by amorsen · · Score: 2

      This makes no sense. Routers do not care how addresses are assigned, they use neighbour discovery to find the hosts.

      --
      Finally! A year of moderation! Ready for 2019?
    5. Re:Static by amorsen · · Score: 1

      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.

      --
      Finally! A year of moderation! Ready for 2019?
    6. Re:Static by darkain · · Score: 1

      Good thing that was already solved back in 2001. https://tools.ietf.org/html/rf...

    7. Re:Static by ganjadude · · Score: 1

      must have happened after i got done with my training because we were never aware of it (and i honestly havent kept up with it either) Thanks for that

      --
      have you seen my sig? there are many others like it but none that are the same
    8. Re:Static by Anonymous Coward · · Score: 0

      With a mobile device (which most Android devices are) that are continually switching between networks, static IP addresses are not ideal. The "static" IP address (for most protocols) needs to be routable. This means the address must change when switching networks.

      In my case, it's not an Android device - it's a server running postfix under Debian living in a data center with a /28 IPv4 block and a /64 IPv6 block. The addresses are truly static and routable. My gripe is with Google's handling of mail servers' delivery (or not, as is often the case) of mail via IPv6. The server had to be set up to always use IPv4 in order to get mail to the gmail.com domain because they continually reject IPv6 connections.

    9. Re:Static by mellon · · Score: 2

      Anyone who wants privacy?

    10. Re:Static by mellon · · Score: 1

      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.

    11. Re:Static by ganjadude · · Score: 1

      thank you for the correction. you are right

      --
      have you seen my sig? there are many others like it but none that are the same
    12. Re:Static by sjames · · Score: 1

      Actually the point is to give everyone a public IP, not necessarily static.

    13. Re:Static by Cramer · · 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 up the entire 128bit address to find the assigned block (a ::/48 or ::/32 most likely), but beyond there, you rather literally have to be there.

    14. Re:Static by unixisc · · Score: 1

      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/ IP addresses issue, but the whole idea is that there shouldn't be any address shortages of any type holding up any technology adaptions.

    15. Re:Static by unixisc · · Score: 1

      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.

    16. Re:Static by ganjadude · · Score: 1

      what does a MAC address have to do with an ethernet card???

      --
      have you seen my sig? there are many others like it but none that are the same
    17. Re:Static by unixisc · · Score: 1

      Ethernet cards are the ones that have those 48-bit MAC addresses. Other network interface cards follow different standards

    18. Re:Static by unixisc · · Score: 1

      All IPv6 routers that I know of assume the 64/64 split - regardless of whether or not they're using SLAAC. Violate that, and you're breaking not just auto-configuration, but also things like RAs, NDs, DADs, et al

    19. Re:Static by jandrese · · Score: 1

      While technically true, in practice everybody does the 64/64 split, especially once you get out onto the Internet. Sure you can do whatever you like on your local network, but don't expect it to go beyond your border router.

      --

      I read the internet for the articles.
    20. Re: Static by Anonymous Coward · · Score: 0

      Also: WiFi uses them.

      But the point stands when you're on 3/4G only

    21. Re:Static by BitZtream · · Score: 1

      Most don't, some do actually.

      Either way, MAC (Media Access Control) addresses are not exclusive to ethernet. Pretty much every layer 2 protocol or higher level protocol that emulates layer 2 uses a mac address.

      The industry has pretty much standardized on a 48 bit MAC as a valid locally unique ID.

      Any 802 standard for networking uses a MAC address regardless of the physical media its running on top of.

      Cell communications are essentially point to point comms with the tower even though its a shared infrastructure. As such, they don't use MAC addresses in their protocol, in which case you just borrow the MAC from your wifi card or auto generate one at boot based on IMEI as you mentioned.

      If tracking is an issue, and you're afraid your mac allows you to be tracked, you know so little about what your really being tracked by that having a conversation about it is almost certainly wasted on you and no amount of education is going to fix your problem (not you so much as the GP post) They don't need you to use the same MAC on your cell phone, your IP is always going to point directly to a specific phone thats easily traceable for the cell phone provider, instantly. Or just using your finger print of browsing activity you can be correlated with trivial effort.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    22. Re:Static by Anonymous Coward · · Score: 0

      Maybe they should use MongoDB, that's web scale. Right?

    23. Re:Static by Cramer · · Score: 1

      No. No sane person assumes the size of a non-local network. A lot of the world does, in fact, bow to the stupid that is SLAAC, but it's not "everywhere", nor do hardware vendors worth their salt make any such assumptions or impose restrictions -- your network can be any size you wish. Your ISP is likely to assign you a ::/64 (60, or 56) because it's the lowest common denominator. (and because they tend to use cheap trash for CPEs.) Giving you anything smaller, while technically feasible, creates hurdles for people with little to no networking expertise.

      And if you have android devices, it's the only way to get the damned things on your IPv6 network.

    24. Re:Static by Cramer · · Score: 1

      *sigh* Those devices ARE BROKEN! And the entire networking world knows it. SLAAC still requires ::/64, as far as I'm aware. However, privacy extensions no longer mandate this brain damage.

      Hundreds of people have warned, just as I have, that people can be (and WILL be) stupid, and thus make these blanket assumptions.

  6. It's not just DHCPv6... by QuietLagoon · · Score: 3, Informative

    I use router advertisement on my home network. All the other devices, except Android-powered devices play nicely with router advertisements. The Android devices lose the IPv6 address when they go to sleep, and do not re-obtain the IPv6 address when they wake up. The Android devices are the only devices with this problem on my home network.

    1. Re:It's not just DHCPv6... by Anonymous Coward · · Score: 0

      Do the other devices go to sleep? Isn't there some timeout that you need to respond to every n seconds in order to keep that address? Don't remember if it's the reachable time or something... It might be problematic to exit sleep mode every n seconds, bring up the wifi device, send a packet and then go back to sleep again. Well, I suppose it's possible but I guess the batteries would drain much faster.

    2. Re:It's not just DHCPv6... by amorsen · · Score: 1

      That is a vendor-specific bug unfortunately.

      --
      Finally! A year of moderation! Ready for 2019?
    3. Re:It's not just DHCPv6... by AK+Marc · · Score: 1

      By Default DHCP holds addresses for 24 hours, and a device with a DHCP assignment running out will essentially request the same address. It takes a broken client, or a deliberately sabotaged server (some ISPs do it to force clients to change IPs frequently, otherwise an always-on DHCP-served router is a static IP) for the IPs of clients to change frequently.

      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 the one assigned it. The client will use the IP for 12 hours before trying to get a renew of it, and will use the assigned IP for 24 hours, then lose its IP after 24 hours. If the renewal response is "yes" but with a new IP, the client, with a "broken" server, could change IPs once every 12 hours with a 24 hour assignment.

      "Sleep" shouldn't lose the IP. What may happen is that "sleep" loses the network connection, so the OS starts a new network connection, and wipes the assignment already given. That's wrong, but understandable for a device that expects to be on a new network every time it's turned on.

    4. Re:It's not just DHCPv6... by Anonymous Coward · · Score: 0

      I was not talking about DHCP. I was talking about neighbor discovery and router advertisment and I think that's what the post I replied to also was.

    5. Re:It's not just DHCPv6... by Anonymous Coward · · Score: 0

      I applaud you.. I agree, it's definately Vendor / Carrier specific.. Not an android problem at all.

    6. Re:It's not just DHCPv6... by Anonymous Coward · · Score: 0

      I've had a variety of Android devices on my home network. I use router advertisement to "allocate" IPv6 addresses. None of them "lose" their IPv6 addresses under any circumstances. Contact your device or Android ROM vendor; this sounds like a really stupid bug.

    7. Re:It's not just DHCPv6... by complete+loony · · Score: 1

      This sounds like a symptom of how android deals with clocks and timeouts in native code. If you call poll with a timeout, and the CPU suspends, the poll timeout stops decreasing.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    8. Re:It's not just DHCPv6... by unixisc · · Score: 1

      But the lifetime of the addresses, or them being demoted to 'deprecated' and all that - all that is done only if there is a DHCP server, no? If it was using SLAAC, it would be static. And even for transient addresses, it would need some sort of DHCP service to keep the prefix fixed, while toggling the Interface ID

  7. That's pretty surprising for 2015 Android IMO by Anonymous Coward · · Score: 1

    All this talk of v4 address space about to expire for the last 2 years... Are they holding back an ipv6 flavor for some reason?

    1. Re:That's pretty surprising for 2015 Android IMO by elwinc · · Score: 1

      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 stateless auto configuration. Also, none of these options exclude any others: IPv6 assumes devices will have multiple addresses at the same time. Finally, IPv4 and IPv6 are not mutually exclusive. If you are behind a firewall, using addresses like 10.x.y.z or l192.168.x.y, then your device is capable of using IPv4 and IPv6 simultaneously.

      On my android 4.1 phone, connected via Verizon, I can see both an IPv4 address and an IPv6 address. On my phone, tap Settings, scroll to the bottom, tap About phone, then tap Status, and you'll see a field of two IP addresses. With wifi turned on, I have a 192.168.x.y address on my home wifi network. If I turn wifi off, I get an address that begins 100.71, presumably assigned by Verizon and globally routable. With or without wifi, I have a second address with 8 fields, much longer, beginning 2600:1000. That's clearly an IPv6 address assigned by Verizon. Whether or not Verizon will route my IPv6 packets is another question.

      --
      --- Often in error; never in doubt!
    2. Re:That's pretty surprising for 2015 Android IMO by mishehu · · Score: 2

      There may be not requirement for DHCPv6 in IPv6, but that's not to say that DHCPv6 does not have merits to it. And DHCPv6 still requires router advertisement.

    3. Re:That's pretty surprising for 2015 Android IMO by Anonymous Coward · · Score: 0

      100.71 is part of the 100.64.0.0/10 CGNAT block, so actually it's not globally routable. But good on them for using the CGNAT block instead of squatting on unadvertised space (25.0.0.0/8 is very popular unadvertised squat space for example).

    4. Re:That's pretty surprising for 2015 Android IMO by unixisc · · Score: 1

      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.

    5. Re:That's pretty surprising for 2015 Android IMO by Anonymous Coward · · Score: 0

      If you can't use it with WiFi it is basically the WiFi's fault for using DHCPv6 instead of just using e.g. radvd.

      For me it is basically the other way. Within my WiFi I have IPv6 without problems, but the mobile carrier network still is using IPv4 only.

      I think a bigger issue was when android did not support RDNSS .. https://code.google.com/p/android/issues/detail?id=32629
      this seems to be fixed in lollipop

  8. Fanboy detected by Anonymous Coward · · Score: 0

    Google's wildly popular Android devices – which accounted for 78% of all smartphones shipped worldwide in the first quarter of this year

    Shipped doesn't mean sold. And of course it's wildly popular, the bottom-of-the-barrel, can-barely-run-the-OS, weak low-end devices are either free with a contract or under $100.

    That doesn't mean it's superior in any way.

    1. Re:Fanboy detected by Anonymous Coward · · Score: 0

      Google's wildly popular Android devices – which accounted for 78% of all smartphones shipped worldwide in the first quarter of this year

      Shipped doesn't mean sold. And of course it's wildly popular, the bottom-of-the-barrel, can-barely-run-the-OS, weak low-end devices are either free with a contract or under $100.

      That doesn't mean it's superior in any way.

      FANBOY DETECTED!!!

      desperate one at that

    2. Re:Fanboy detected by Anonymous Coward · · Score: 0

      Looks like we got a Phil "The Shill" Shiller fat piece of shit lard ass wannabe here.

  9. Fuck this shit by Anonymous Coward · · Score: 0

    RDNSS is the way, fuck this ipv4 relic.

  10. Meta: dynamic what? by Yenya · · Score: 4, 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.

    --
    -Yenya
    --
    While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
    1. Re:Meta: dynamic what? by Anonymous Coward · · Score: 1

      They probably looked it up and were excited to share what they learned.

    2. Re:Meta: dynamic what? by Anonymous Coward · · Score: 0

      The best part is the title of the page reads "IT PROS" blast Google.. . And there's nothing there which says "IT PROS" blast their mobile carriers anywhere.

    3. Re:Meta: dynamic what? by Anonymous Coward · · Score: 0

      Now you know why geeks write horrid OSS user documentation.

    4. Re:Meta: dynamic what? by Bing+Tsher+E · · 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.

    5. Re:Meta: dynamic what? by Anonymous Coward · · Score: 0

      > 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.

      Wow am I so old school that I didn't notice "configuration" supplanted "control" in the acronym?

      http://www.linux.org/threads/tcp-ip-protocol-dynamic-host-control-protocol-dhcp.4847/

      When did geniuses decide to switch it up?

    6. Re:Meta: dynamic what? by Anonymous Coward · · Score: 0

      The C has always been Configuration, since the original RFC published in October 1993: https://tools.ietf.org/html/rfc1531

    7. Re:Meta: dynamic what? by Anonymous Coward · · Score: 0

      But if they didn't do that, there would be some derp-tard in the comments bitching about how they can't be expected to know every acronym in every field they're not familiar with, and that the summary was written by a moron that didn't include explanations about it. Yes, even about something as common as DHCP.

  11. No support for what? by Anonymous Coward · · Score: 0

    The black box behind the number of posts hides the title.

  12. DHCPv6 is NOT a central component of ipv6 by rubycodez · · Score: 3, Insightful

    DHCPv6 is a bad bolt-on, IPV6 always had superior solutions designed since the 90s (when it had another name)

    1. Re:DHCPv6 is NOT a central component of ipv6 by unixisc · · Score: 2

      DHCPv6 is nothing like DHCPv4. It was designed from the ground up differently, just like IPv6 itself was. It's the only mechanism out there that an IPv6 network admin has to control which devices get which addresses. Denying a DHCPv6 solution just forces people into a 2 sizes fit all, which is far from ideal. Also, DHCPv6 is the only thing that allows one to have, say /96 subnets (assuming that they don't give a fuck to SLAAC) or even a /128 assignment.

    2. Re:DHCPv6 is NOT a central component of ipv6 by rastos1 · · Score: 1

      What other solution updates my DNS server dynamically?

    3. Re:DHCPv6 is NOT a central component of ipv6 by BitZtream · · Score: 1

      RADNS?

      Router Advertised DNS servers.

      Just like Router Advertised default routes.

      RFC 6106 - https://tools.ietf.org/html/rf...

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    4. Re:DHCPv6 is NOT a central component of ipv6 by tlhIngan · · Score: 1

      DHCPv6 is nothing like DHCPv4. It was designed from the ground up differently, just like IPv6 itself was. It's the only mechanism out there that an IPv6 network admin has to control which devices get which addresses. Denying a DHCPv6 solution just forces people into a 2 sizes fit all, which is far from ideal. Also, DHCPv6 is the only thing that allows one to have, say /96 subnets (assuming that they don't give a fuck to SLAAC) or even a /128 assignment.

      And there are many valid uses of DHCP where IPv6 doesn't exist, or is insufficient. RA and RADNS works for the most basic case, but enterprise needs are far more varied.

      I mean, think desktop management - it's not unusual to have DHCP right now give the PC an IP and boot it off the network (DHCP options for boot-server and boot-file) - otherwise known as PXE, as well as in an OS environment for the OS to pick up which is the authentication server it should use (LDAP, Active Directory, etc) and so on.

      I suppose IPv6's way is to have those services announce themselves over the network, but then it becomes limited to a network segment and you start filling the network up with broadcasts. Plus, it's a lot harder to manage - for example, you can give someone a new PC by noting its MAC address and the OS install/download/etc happen automatically by plugging it in and booting it up. to that configuration.

    5. Re:DHCPv6 is NOT a central component of ipv6 by rastos1 · · Score: 1

      As far as I know, RADNS tells the client what DNS server and DNS suffix to use. But it does not tell the DNS server that client with address 2a00::1 is now known as foo.example.org. Which means that other machines in the LAN cannot resolve foo.example.org name to back to address 2a00::1.

      I admit that I'm no expert in this area, so if I'm wrong I would gladly learn how it really works.

    6. Re:DHCPv6 is NOT a central component of ipv6 by rubycodez · · Score: 1

      DHCP doesn't update your DNS server, it's not a part of DHCP. Things such as Dynamic DNS for example can do it, as does Microsofts DNS Client (which often double dips assignments I've found in every place I've ever worked that used it, by the way)

    7. Re:DHCPv6 is NOT a central component of ipv6 by rastos1 · · Score: 1

      It's not part of the protocol, but it is usually part of the DHCP server implementation.

    8. Re:DHCPv6 is NOT a central component of ipv6 by unixisc · · Score: 1

      I was talking only about DHCPv6, not DHCPv4

  13. My Android phone works fine on IPv6 by Anonymous Coward · · Score: 0

    Because it uses IPv6 stateless auto-config like it's supposed to.

    1. Re:My Android phone works fine on IPv6 by unixisc · · Score: 1

      Only on a mobile network. How would a WiFi use any SLAAC mechanism, since only a subset of devices would have Ethernet and thereby EUI-64? Any SLAAC mechanism that one comes up w/ has to account for all the devices that may live on that network.

    2. Re:My Android phone works fine on IPv6 by Anonymous Coward · · Score: 0

      WiFi MAC addresses are 48 bits too

  14. Mod Parent Up by elwinc · · Score: 0

    Mod parent up!

    --
    --- Often in error; never in doubt!
  15. A perspective of an ISP by bbn · · Score: 4, 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.

    1. Re:A perspective of an ISP by unixisc · · Score: 1

      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.

    2. Re:A perspective of an ISP by unixisc · · Score: 1

      Also, how would using SLAAC expose 2^64 addresses? I can understand how it could expose the MAC address if EUI-64 is used, but how would it risk exposing that many addresses? You won't have anything even close to that many devices on that network at any time.

    3. Re:A perspective of an ISP by Anonymous Coward · · Score: 0

      With privacy extensions, a device can generate a new IP every hour or two, while still keeping the old ones around in case something is still using it. In 24 hours, that's up to 24 IP addresses... for one device... multiply that by the number of customers an ISP has and the number of devices a typical customer may have (PC, phone, tablet, laptop, another phone, etc) and you can see their ND cache fill up pretty fast.

    4. Re:A perspective of an ISP by unixisc · · Score: 1

      But if you're using SLAAC, the address of that interface will be static. It won't change, since its assignment mechanism would be EUI-64 or whatever other static assignment mechanism is being used. Privacy extensions imply that SLAAC is no longer being used, and then the scenario that you describe would play out. Plus, wouldn't deprecated addresses be flushed out of cache pretty quickly?

    5. Re:A perspective of an ISP by Anonymous Coward · · Score: 0

      Parent is referring to NDP exhaustion attacks, where the router attached to that /64 will need to support neighbor discovery for any one of the 2^64 addresses.

      They are "exposed" in the sense that an attacker could trigger neighbor discovery for up to 2^64 addresses, with the goal of exhausting your ND cache.

      Many have taken to configuring /120s (or longer) to mitigate.

    6. Re:A perspective of an ISP by bbn · · Score: 1

      Privacy extensions is an extension to SLAAC. All major operating systems come with privacy extensions enabled by default, which means they will do a dosen of adresses per device. If you enable SLAAC in the provider network and do not use DHCPv6-PD, most CPEs will bridge IPv6. That means the ISP switch/router has to track every single device inside your household multiplied by number of addresses used for privacy extensions.

      But it is a problem even with no device actually using the address. If someone starts mapping your address space (eg. using nmap) the ISP router has to start NDP discovery on every single address that someone sends a ICMP ping to. There is no way the ISP router can know that there is no device with that address. The only defense is to limit the number of active cache entries per customer, but then you just made it very simple to DoS the customer with trivial amount of ICMP traffic.

      For this reason the sane way to implement IPv6 as to do DHCPv6-PD and assign either 0 or 1 IPv6 address on the link interface. Zero is possible because IPv6 can use link local addresses for routing, but it will screw up your traceroute and arguably it prevents the CPE from sending back mandatory ICMP packets such as MTU changes.

    7. Re:A perspective of an ISP by l_bratch · · Score: 1

      > assign either 0 or 1 IPv6 address on the link interface

      As in, zero or one *global* addresses? Presumably you need at least one IPv6 address. I think you clarified that in your next sentence, I just wanted to check.

      My ISP uses DHCPv6 to provide a /64 prefix and a separate link local address, and indeed outgoing traceroutes from internal hosts behind the router always have one unresolvable hop between the CPE and the ISP. Incoming traceroutes are fine though.

    8. Re:A perspective of an ISP by bbn · · Score: 1

      Yes zero global addresses on the link (GUA). You will of course have the link local address, which will be used for routing.

    9. Re:A perspective of an ISP by l_bratch · · Score: 1

      Thanks. I might ask my ISP if they'll consider switching from a /64 to a /56 prefix + a /128 global address. Doesn't seem likely, but worth a go!

    10. Re:A perspective of an ISP by IamTheRealMike · · Score: 1

      For this reason the sane way to implement IPv6 as to do DHCPv6-PD and assign either 0 or 1 IPv6 address on the link interface.

      From reading the linked bug report/discussion, it seems the Android team are open to implementing DHCPv6-PD. Their objection is basically to the notion that a lazily run network might use DHCPv6 to try and ensure devices only get a single IP address, thus forcing app/OS developers and users to deal with the crappy flakyness of NAT all over again. They are worried about snatching defeat from the jaws of victory, in other words.

      So I think your position is not so incompatible with Google's. Though if/when they plan to support DHCPv6-PD I do not know.

    11. Re:A perspective of an ISP by unixisc · · Score: 1

      But DHCPv6 would only assign the addresses for 1 or more subnets within the network. Like if the admin has a 2001:db8:bead::/60, DHCP would manage the 16 subnets within that network. But if there was a tablet on that network that also accessed 2001:db8:d0g:a1e:/64, the DHCP wouldn't touch the addresses that that tablet got from this other network. That tablet would have to be separately administered and configured, and if it is set up to accept connections to other networks, there it is. Granted, it's another security issue, but one very separate from the question of whether a device should only be allowed 1 or more IP addresses.

  16. "DHCP" is _not_ an acronym by msk · · Score: 1

    It's an abbreviation.

    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.

    1. Re:"DHCP" is _not_ an acronym by windwalkr · · Score: 1

      Wikipedia disagrees with you, fwiw, although it does note that some people follow that.

      https://en.wikipedia.org/wiki/...

    2. Re:"DHCP" is _not_ an acronym by oojah · · Score: 1

      I believe that "initialism" is the correct word.

      http://www.oxforddictionaries....

      --
      Do you have any better hostages?
    3. Re:"DHCP" is _not_ an acronym by BitZtream · · Score: 1

      Well, good thing people are stupid enough to use Wikipedia as an authoritative source instead of a dictionary.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    4. Re:"DHCP" is _not_ an acronym by BitZtream · · Score: 1

      And for examples:

      U.R.L. is an initialism.
      Saying EARL would make it an acronym (and it makes you sound like a douche when you say it :)

      C.O.B for close of business
      COB (like corn cob) is an acronym.

      And also, for reference, turning initialisms with no vowels in them into acronyms makes you a douche as well.

      Its W.S.D.L. NOT wiz-dull. Its V.o.I.P. not voip. Its S.Q.L. Not Sequel. Yes, many people turn these perfectly valid initialisms into acronyms and in the process make the rest of the world dumber and themselves sound retarded. Exception: MSSQL Server is Sequel Server, all others are pronounced letter by letter, not as a word.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    5. Re:"DHCP" is _not_ an acronym by Anonymous Coward · · Score: 0

      Well, good thing people are stupid enough to use Wikipedia as an authoritative source instead of a dictionary.

      Ok, let's see what the dictionary says:

      a set of initials representing a name, organization, or the like, with each letter pronounced separately; an initialism.

      That's the #2 definition for acronym. In other words, it says the same thing as Wikipedia with less context.

    6. Re:"DHCP" is _not_ an acronym by Anonymous Coward · · Score: 0

      See definition #2 for acronym.

      Rule #1 for being a pedant is to be correct. Being a wrong pedant just makes you an idiot.

  17. Supports Stateless Autoconfiguration by Bruha · · Score: 1

    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 as much as possible shoots this into the foot.

    However Verizon and AT&T and others are not getting more IPv4 ip's so they'll make sure IPv6 works on the phones.

  18. What about Ubuntu? by Anonymous Coward · · Score: 0

    14.04 LTS has dhcpv6 so broken up t might as well not even be there.... Which is pretty sad.

  19. Wasn't there dynamic configuration in IPv6 by defa by Anonymous Coward · · Score: 0

    Im trying to recall the feature. Something about discovering routers for network address and using the mac address as the unique component.
    I recall that dhcp is irrelevant for ipv6

  20. IPv6 by ledow · · Score: 1

    I went out the other day and bought a new router for home after my WRT54G that had been doing the job for years started to show its age.

    I decided to buy a PROPER router, with multiple gigabit, multi-connection failover, IPv6, VLAN, VoIP, VPN, LDAP, QoS, wireless access point management, all the trimmings.

    The IPv6 config has a myriad of options. I got bored looking into all of them. 6rd, 6in4, DHCPv6, TSPC, AICCU, RADVD, god knows what.

    Fact was, I got bored of trying to figure out which/how to use. Some required sign-ups and were basically IPv6 VPN's with all kinds of monitoring and restrictions, most needed ISP support to provide details, IP ranges, or some catch-all IP, and none were offering anything different to my eyes. In the end, it was all moot - my ISP offered no support for IPv6 at all (probably because of several competing and basically identical-to-the-end-user standards), and the other stuff requires me to sign up with a third party that will then take all my IP traffic and subject it to god-knows-what-jurisdiction.

    The problem with IPv6 is not that it doesn't work. It's that it's not plug-and-play for whatever setup you have (transit over IPv4 or IPv6 native, for example).

    If I get bored working out what to choose, I'm sure everyone else will not bother to support them until we choose just one either.

    1. Re:IPv6 by Alphager · · Score: 1

      Your situation is "My ISP doesn't provide IPv6" and you are angry that it isn't plug&play?! That's like having an ISP that only provides IPX and complaining that IPv4 doesn't work. IPv6 works out-of-the-box on ISPs that provide IPv6.

    2. Re:IPv6 by Anonymous Coward · · Score: 0

      Your situation is "My ISP doesn't provide IPv6" and you are angry that it isn't plug&play?!
      That's like having an ISP that only provides IPX and complaining that IPv4 doesn't work.

      IPv6 works out-of-the-box on ISPs that provide IPv6.

      That was not the comment. He said it is NOT that is not plug and play. It was about too many competing protocols to choose from.

    3. Re:IPv6 by ledow · · Score: 1

      So what you're saying is that all ISPs have to support IPv6, they all have to do so in a standardised (or EVERY POSSIBLE) way, and there's no way to do anything until they get off their butt.

      That's what 6-in-4, and the various tunnels were made for, because the ISP's aren't getting off their backside because if they support 6rd but your router was made before that and so doesn't support it, then as far as the users are concerned they don't support IPv6 at all.

      But even there, that's FOUR WAYS to do the same thing. All involving third-parties.

      What about what *I* would like to do to combat a third-party not supporting IPv6? What if my router didn't support ALL those protocols independently and completely? What if my ISP never adds IPv6, how do I get on the IPv6 network even with all the above?

      When you have so many different and competing standards, some EXPRESSLY designed so that the ISP doesn't have to be IPv6-ready, and STILL there's so much choice that your router has to support them ALL in order to claim IPv6 in any significant way, then you're onto a loser.

      I don't care about PnP. I care about it being able to be done. But I'm an IT guy. I don't need it to be PnP and I can sort that out for my users. But not without all the ISP's we use onboard, not without explicit support for all the protocols (What if my ISP changes from DHCPv6 to another method? Can they still claim IPv6 compatibility even if my hardware no longer works?), not without having to know how all the standards and protocols work, and not without having to do all the legwork.

      With IPv4, you have basically two options - DHCP which is a way of automatically plugging in all the information you would require for the alternate, which is a list of static addresses of various services. With IPv6, there are six, seven, eight protocols that all need different levels of information and co-operation from your ISP, assign different kinds of IPv6 addresses to you, (6rd, or 6in4, or local IPv6, or global IPv6? Who knows?) all work differently, may or may out just route out via a 6in4 address to the wider Internet via any route they like, rather than being provided by your ISP directly, etc. etc. etc.

      It's a damn mess. And I have a router that I bought specifically to do this, have enough knowledge to set any or all of them up, could easily sign up to even tunnel provider available, and you know what - I can't be bothered because of the hassle of all that junk.

      My websites and external servers are all IPv6 and accept mail over it on a daily basis. I just set up a static, it routes, off we go. My hosting providers provide NONE of the above automatic configuration services. My ISP provides NONE of the above and won't get out static IPv6 ranges.

      What you have is a complete deadlock and mess until someone picks a standard and sticks with it. Because if I were an ISP, I'd just say "Sod it, I'm not going to provide ALL those methods and then be accused of missing one out, so I may as well provide none and let the user worry about it". And that's exactly what ISP's are doing.

      You know what my solution was? I set up an OpenVPN link to my external servers and just talk via IPv4 to it, sending pure IPv6 through the VPN for a globally-routable IPv6 address that I've reserved for that purpose. It was easier to set it up myself using YET ANOTHER way of doing it than faff with any of the services available, supported or not.

  21. Is it really needed? by Anonymous Coward · · Score: 0

    Some operator-based prefix, plus the phone's IMEI or the SIM card's IMSI. Or perhaps just the phone number in the international format. There. Unique and permanent addresses for everyone.

  22. if you have IPv6 ... by Skapare · · Score: 1
    if you have IPv6 then let google know it by using their DNS resolvers:

    nameserver 2001:4860:4860::8888
    nameserver 2001:4860:4860::8844

    --
    now we need to go OSS in diesel cars
  23. it's a Samsung bug by Anonymous Coward · · Score: 0

    http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=239890

  24. What I wrote's nonsense dave420? by Anonymous Coward · · Score: 0

    "I just reply to you when I see you spamming Slashdot with your nonsense"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)

    Why'd you agree w/ my points on hosts then? Quoting you here:

    "I'm not denying all those things" - by dave420 (699308) on Wednesday September 17, 2014 @11:39AM (#47927435) FROM -> http://yro.slashdot.org/commen...

    Of course you're not: It's impossible to dispute FACT on HOSTS FILES superiority to other methods!

    Since my points of fact in favor of hosts SINGLE FILE native kernelmode faster part show hosts doing more, with less, vs. so-called 'competitors' many part messagepassing + other overheads laden slower usermode FAR MORE COMPLEX 'solutions' doing less than hosts do for more security, speed, reliability, + anonymity online!

    I make creating a superior more efficient solution EASIER!

    (Which is more than a mere trolling stalking harassing "ne'er-do-well" like yourself could *EVER* manage).

    ---

    "I'm simply pointing out that it takes an AdBlocker to block your spamming"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)

    Then WHY DON'T YOU DO THAT & use 'em? Answer that!

    (You stalk/harass me instead!)

    I bother you? Use them!

    OBVIOUSLY, you don't & you're just a "ne'er-do-well" troll, OR you have "other motivations" (see next):

    * DO YOU WORK FOR AN ADVERTISING FIRM, or ARE YOU A WEBMASTER/WEBCODER, or ARE YOU A MALWARE MAKER, or ARE YOU AFFILIATED WITH 1 OF MY COMPETITORS?

    Answer that! No, instead as per your usual, you'll avoid every question, or lie!

    (You must be involved with 1 of those above, especially since you can't EVER "get the best of me" & you know it, witness the above - & their "so-called 'solutions' are INFERIOR TO MINE on TONS of levels, OR YOU'D USE THEM, merely evidencing their stupidity in & of itself via inferior designwork!)

    APK

    P.S.=> SEE Dave420 SQUIRM - evasions galore from him will ensue, guaranteed... apk

  25. It's not only DHCPv6 that's bad, it's also DHCPv4 by Anonymous Coward · · Score: 0

    They managed to screw up DHCPv4 as well: https://code.google.com/p/android/issues/detail?id=6111
    Somehow, for every OS on the planet you can give it a meaningful hostname either manually or via DHCP, except for android where that can be achieved only via rooting and adb-shell. Ever wondered why your networked devices are called android-deadbeefdec0dedfadedcaca? It's because they still haven't fixed this bug in 5 major releases. It's not that iOS has this, even Windows NT has this. Yes, on most android devices you can't set the bloody hostname and ironically they call it a networked OS.

  26. Wifi Switching and Shotgunning by Anonymous Coward · · Score: 0

    10x more important than IPv6. My router can handle that. My phone company can handle that. My device itself, doesn't need to handle that.

    Who really has non-NAT access on their phone.

    Article. Is. Dumb.