5 ms·

> NAT, for all its problems, has more or less solved the IP address problem. A bunch of very large-scale network operators (like Comcast, T-Mobile USA, Verizon

by zkms 9y ago

> NAT, for all its problems, has more or less solved the IP address problem. A bunch of very large-scale network operators (like Comcast, T-Mobile USA, Verizon, and Facebook) seem to strongly disagree with that, given how eagerly they've deployed IPv6 to get away from the hell that is IPv4 NAT and CGN. Yes, IPv6 has lots of complexity/flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, prettyprinting / the colons, extension headers, etc.) that mostly only look good through the rose-tinted glasses of the 90s and significantly slowed down deployment -- and in the end mostly ended up as "difference for difference's sake". 128 bits of addressing space and getting away from IPv4 NAT were unambiguously good. 128 bits is a lot, but memory/bandwidth is just going to get cheaper (for slow links you should use header-compression anyway), and it was better to go whole hog and skip 64 and go to 128 to avoid a future 64->128 transition. Given how the 32->128 transition is going, this seems like it was an excellent decision.

nazgul17 9y ago
Could you expand on the flaws and why are they problematic?
- zkms 9y ago
  https://www.sinog.si/wp-content/uploads/2017/05/SINOG4_Job_Snijders_IPv6_Panel-1.pdf https://www.sinog.si/wp-content/uploads/2017/05/SINOG4_Job_S... and https://www.troopers.de/wp-content/uploads/2013/11/TROOPERS14-Why_IPv6_Security_is_so_hard-Structural_Deficits_of_IPv6_and_their_Implications-Enno_Rey.pdf https://www.troopers.de/wp-content/uploads/2013/11/TROOPERS1... and https://www.sinog.si/wp-content/uploads/2017/05/SINOG-IPv6-Keynote2_Ole.pdf https://www.sinog.si/wp-content/uploads/2017/05/SINOG-IPv6-K... are worth reading. TL;DR: * Multicast and mobility are shits * NDP an overcomplicated shit * The SLAAC / DCHPv6 thing is a ripe mess * getting IPv6 provider-independent space is too hard * extension headers are tricky, slow to parse, a source of tricky security issues, and thus are almost completely unused on the Internet in general Basically almost all the moving parts in ipv6 (beyond the wire format and its 128-bit addresses) that aren't dangerously convoluted / mostly unused are pretty much just NIH'd reimplementations of the corresponding IPv4 protocols (like ARP, say).
  - lmm 9y ago
    Provider-independent space ought to be impossible - addresses should be addresses. If you want multiple routing paths to you, get an AS number and participate in actual global routing. Otherwise, accept that when you move your address will change.
ra1n85 9y ago
From an operator's perspective, 128 bits is more difficult to troubleshoot compared to the 32 bits of IPv4. RFC5962 makes things easier, though only marginally.
- dingo_bat 9y ago
  Not to mention there is no int128_t in C. You have to use poorly defined byte arrays to pass the thing around. It's irritating af.
  - CountSessine 9y ago
    typedef struct { uint8_t[16] d; } ipv6addr;?
    - dingo_bat 9y ago
      Which is a byte array. When you pass this to a function, it does not fit in a single register. The equality operator doesn't work, nor do other logical operators. Everything has to be defined. 64 bit would have been so easy. And it would still have been enough. Edit: somebody replied and deleted their comment. Since I had written a response I am editing this comment. > Then your real complaint... is that you don't have 128-bit machine registers Agreed, although my real complaint is more towards IPv6, for not thinking about this real-life limitation. > what the urgent need to pass IPv6 addresses in machine registers It's much slower than IPv4 to deal with! 64 bit addresses wouldn't have had this problem and still would have enough space for everyone on earth. > And how is it "irritating af"? Apart from the speed concerns: > The equality operator doesn't work, nor do other logical operators. Everything has to be defined.
      - deleted 9y ago
        [deleted]
      - deathanatos 9y ago
        > When you pass this to a function, it does not fit in a single register. Depends on the architecture. On amd64 (the architecture I'm typing this comment on), a 128-bit struct, like defined above, will fit in registers — yes, in 64-bit registers. The amd64 ABI[1] will split them across two registers. For example, if we take the above struct and use it, void foo() { ipv6_addr addr = { { 1, 2, 3, 4, 5, 6, 7, 8, }, }; bar(addr); } This compiles to: movabsq $578437695752307201, %rdi xorl %esi, %esi jmp bar The nasty looking number is the initialization; it's easier to see in hex: In [1]: hex(578437695752307201) Out[1]: '0x807060504030201' That ends up in %rdi, the first of the amd64 arg-passing registers. The next half is zeros, so it goes in %rsi (the compiler just zeros it). Then we "call" bar. (There is tail-call optimization here) The non-optimized version is similar, but more drawn out: # for some reason we zero it first movq $0, -16(%rbp) movq $0, -8(%rbp) # then we init it again… okay gcc. movb $1, -16(%rbp) movb $2, -15(%rbp) movb $3, -14(%rbp) movb $4, -13(%rbp) movb $5, -12(%rbp) movb $6, -11(%rbp) movb $7, -10(%rbp) movb $8, -9(%rbp) # move the struct into rdx/rax movq -16(%rbp), %rdx movq -8(%rbp), %rax # just to move it into the arg-passing registers movq %rdx, %rdi movq %rax, %rsi # call the function call bar > It's much slower than IPv4 to deal with! 64 bit addresses wouldn't have had this problem and still would have enough space for everyone on earth. It's twice as wide, yes, but that doesn't necessarily mean you're needing to pass it in memory. > still would have enough space for everyone on earth. IP addresses aren't just numbers assigned to machines. They must also — effectively — encode the route to that machine; you can sort of imagine it as a tree, with each bit giving you successively more local directions on the Internet. Now, of course, that's not exactly how it works, but the point is that some parts of that tree are going to be sparsely populated. Having a wider address space means you can make bigger, but not necessarily full, allocations in the address space, allowing you to keep whole networks together in a common prefixes, which results in simpler routing tables. (At least, that's the idea as I understand it.) And it's not just 1 per person: I have more than one device, and I move between networks during the course of a day. If all of the networks I frequented actually had IPv6, I'd bog down at least 6–8 IPv6 addresses during the course of a boring day, and that's not counting stuff like networking equipment. It's not just a simple question of "are there enough bits to assign each person an address" > The equality operator doesn't work, nor do other logical operators. On amd64 at least, __int128_t exists, I believe, and I think it should come with operators. In higher-level languages, you can define < and == simply enough. Now, I grant that the above is highly architecture specific, and there definitely exist architectures where this doesn't apply. And those, yes, 128-bit will be slower than a theoretical 64-bit. I just don't think it's worth worrying about. [1]: https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf https://software.intel.com/sites/default/files/article/40212...

by zkms 9y ago

nazgul17 9y ago

Could you expand on the flaws and why are they problematic?

zkms 9y ago
https://www.sinog.si/wp-content/uploads/2017/05/SINOG4_Job_Snijders_IPv6_Panel-1.pdf https://www.sinog.si/wp-content/uploads/2017/05/SINOG4_Job_S... and https://www.troopers.de/wp-content/uploads/2013/11/TROOPERS14-Why_IPv6_Security_is_so_hard-Structural_Deficits_of_IPv6_and_their_Implications-Enno_Rey.pdf https://www.troopers.de/wp-content/uploads/2013/11/TROOPERS1... and https://www.sinog.si/wp-content/uploads/2017/05/SINOG-IPv6-Keynote2_Ole.pdf https://www.sinog.si/wp-content/uploads/2017/05/SINOG-IPv6-K... are worth reading. TL;DR: * Multicast and mobility are shits * NDP an overcomplicated shit * The SLAAC / DCHPv6 thing is a ripe mess * getting IPv6 provider-independent space is too hard * extension headers are tricky, slow to parse, a source of tricky security issues, and thus are almost completely unused on the Internet in general Basically almost all the moving parts in ipv6 (beyond the wire format and its 128-bit addresses) that aren't dangerously convoluted / mostly unused are pretty much just NIH'd reimplementations of the corresponding IPv4 protocols (like ARP, say).
- lmm 9y ago
  Provider-independent space ought to be impossible - addresses should be addresses. If you want multiple routing paths to you, get an AS number and participate in actual global routing. Otherwise, accept that when you move your address will change.

ra1n85 9y ago

From an operator's perspective, 128 bits is more difficult to troubleshoot compared to the 32 bits of IPv4. RFC5962 makes things easier, though only marginally.

dingo_bat 9y ago
Not to mention there is no int128_t in C. You have to use poorly defined byte arrays to pass the thing around. It's irritating af.
- CountSessine 9y ago
  typedef struct { uint8_t[16] d; } ipv6addr;?
  - dingo_bat 9y ago
    Which is a byte array. When you pass this to a function, it does not fit in a single register. The equality operator doesn't work, nor do other logical operators. Everything has to be defined. 64 bit would have been so easy. And it would still have been enough. Edit: somebody replied and deleted their comment. Since I had written a response I am editing this comment. > Then your real complaint... is that you don't have 128-bit machine registers Agreed, although my real complaint is more towards IPv6, for not thinking about this real-life limitation. > what the urgent need to pass IPv6 addresses in machine registers It's much slower than IPv4 to deal with! 64 bit addresses wouldn't have had this problem and still would have enough space for everyone on earth. > And how is it "irritating af"? Apart from the speed concerns: > The equality operator doesn't work, nor do other logical operators. Everything has to be defined.
    - deleted 9y ago
      [deleted]
    - deathanatos 9y ago
      > When you pass this to a function, it does not fit in a single register. Depends on the architecture. On amd64 (the architecture I'm typing this comment on), a 128-bit struct, like defined above, will fit in registers — yes, in 64-bit registers. The amd64 ABI[1] will split them across two registers. For example, if we take the above struct and use it, void foo() { ipv6_addr addr = { { 1, 2, 3, 4, 5, 6, 7, 8, }, }; bar(addr); } This compiles to: movabsq $578437695752307201, %rdi xorl %esi, %esi jmp bar The nasty looking number is the initialization; it's easier to see in hex: In [1]: hex(578437695752307201) Out[1]: '0x807060504030201' That ends up in %rdi, the first of the amd64 arg-passing registers. The next half is zeros, so it goes in %rsi (the compiler just zeros it). Then we "call" bar. (There is tail-call optimization here) The non-optimized version is similar, but more drawn out: # for some reason we zero it first movq $0, -16(%rbp) movq $0, -8(%rbp) # then we init it again… okay gcc. movb $1, -16(%rbp) movb $2, -15(%rbp) movb $3, -14(%rbp) movb $4, -13(%rbp) movb $5, -12(%rbp) movb $6, -11(%rbp) movb $7, -10(%rbp) movb $8, -9(%rbp) # move the struct into rdx/rax movq -16(%rbp), %rdx movq -8(%rbp), %rax # just to move it into the arg-passing registers movq %rdx, %rdi movq %rax, %rsi # call the function call bar > It's much slower than IPv4 to deal with! 64 bit addresses wouldn't have had this problem and still would have enough space for everyone on earth. It's twice as wide, yes, but that doesn't necessarily mean you're needing to pass it in memory. > still would have enough space for everyone on earth. IP addresses aren't just numbers assigned to machines. They must also — effectively — encode the route to that machine; you can sort of imagine it as a tree, with each bit giving you successively more local directions on the Internet. Now, of course, that's not exactly how it works, but the point is that some parts of that tree are going to be sparsely populated. Having a wider address space means you can make bigger, but not necessarily full, allocations in the address space, allowing you to keep whole networks together in a common prefixes, which results in simpler routing tables. (At least, that's the idea as I understand it.) And it's not just 1 per person: I have more than one device, and I move between networks during the course of a day. If all of the networks I frequented actually had IPv6, I'd bog down at least 6–8 IPv6 addresses during the course of a boring day, and that's not counting stuff like networking equipment. It's not just a simple question of "are there enough bits to assign each person an address" > The equality operator doesn't work, nor do other logical operators. On amd64 at least, __int128_t exists, I believe, and I think it should come with operators. In higher-level languages, you can define < and == simply enough. Now, I grant that the above is highly architecture specific, and there definitely exist architectures where this doesn't apply. And those, yes, 128-bit will be slower than a theoretical 64-bit. I just don't think it's worth worrying about. [1]: https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf https://software.intel.com/sites/default/files/article/40212...