7 ms·

Perhaps the impulse is cruel but for me, the fact that humans can't remember IPv6 addresses is a selling point. It forces people into what I believe are better

Perhaps the impulse is cruel but for me, the fact that humans can't remember IPv6 addresses is a selling point. It forces people into what I believe are better practices (indirection through dns, using tagging in firewalls and load balancers, auto-assigning IPs, copy-pasting addresses in the cases where they're actually needed).

JMTQp8lwXL 7y ago
Yeah, but to set up an AAAA record, you still need the IP address. The usability still leaves something to be desired. At least we should never run out of IPv6 addresses.
- denkmoon 7y ago
  If you're setting up a AAAA once, you can deal with the copy paste. If you're updating them a lot, or a lot all at once, you should probably use a dynamic DNS updater.
- thaumasiotes 7y ago
  > At least we should never run out of IPv6 addresses. This is true in terms of the raw total number of IPv6 addresses. Everything I've seen discussing them assumes they'll be assigned hierarchically, though, which is a great way to ensure most of them are never used. Block assignments through a hierarchy can chew through any number of addresses no matter how big the space is.
  - deleted 7y ago
    [deleted]
  - deleted 7y ago
    [deleted]
  - waste_monk 7y ago
    Heirarchical assignment allows route summarisation. Imagine how much TCAM you'd need for unsummarized IPv6.
    - thaumasiotes 7y ago
      Yes, you're correct. But at the same time hierarchical assignment allows organization, including route summarization, it undermines the argument that there are too many addresses to exhaust. Addresses can easily be (in fact, are guaranteed to be) exhausted by the organizational system without ever being in use. The goals are in conflict.
      - Dagger2 7y ago
        They are being used -- for the purpose of allowing the internet to scale. But yes, we do need to be careful not to assign blocks that are too large. We're doing a good job of this (see any /8s being assigned?). We're also doing allocations only from 2000::/3, and there are five more completely untouched /3s available, so if we do somehow run out of space in 2000::/3 then we can start over with tighter allocation polices... five times over.
  - mlyle 7y ago
    As said by others, you need hierarchy to avoid routing tables becoming excessively large-- that's the real limit. Since an IPv6 subnet can hold effectively any number of hosts, and it's easier to give bigger chunks of networks, the chances that a given org needs multiple assignments is much lower. In turn we use that real limit (routing table size) more responsibly. If routing tables can be much bigger in the future, we also have a whole lot more room to grow / allocate it differently. The chunk from which allocation is occurring (2000/3, plus the multicast and link local blocks, etc) is less than 1/4th the space; furthermore, more than half of the space within this is reserved. https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml https://www.iana.org/assignments/ipv6-unicast-address-assign...
roenxi 7y ago
> It forces people into ... better practices I've got no beef with IPv6; it seems pretty great there being enough addresses that everybody gets one. That said, being unmemorable is not a feature. Doing nothing is an alternative to doing things 'the right way' and people will choose it. The situation will backslide a little bit - with IPv4 people would do things, with IPv6 some people won't. Unless the goal is to configure IPv6 systems for their own sake, this is an unfortunate and unwanted side effect.
- twblalock 7y ago
  Do you know the IP addresses of your servers? You shouldn't know them. That reveals a lack of automation at a pretty low level of your infrastructure. IP addresses change all the time in cloud environments and container orchestration systems. Even if they didn't change, you get better systems if you pretend they might. It doesn't matter if you use containers or not -- if you assume IP addresses could change at any time, you end up with infrastructure that is tied to your service graph rather than your hardware.
  - yardstick 7y ago
    What about when the host is your domains dns server, and you need to ssh to it to fix a broken dns configuration. But because dns is broken the hostname you would use isn’t resolving anymore.
    - vidarh 7y ago
      If a public domain, there needs to be NS records pointing at it from the registry, and they need to either have glue records giving the IP and/or at least one ought to be on a domain your name server itself is not the authoritative dns for. If a private domain and/or the server is only reachable from private IPs, then its IP should be in an asset management system somewhere (it should be if it is public too); be that a full blown orchestration system, if cloud servers or containers, or some form of asset register - even if only a spreadsheet - if it is physical servers in your own data centers. If properly automated, that asset register should drive configuration deployment - you shouldn't ssh to it to fix a broken dns configuration, you should run your deployment with a fixed config. I get that this is an idealized setup and that a lot of the time things intervenes and it's quicker and easier to do things manually then and there. Been there, done that, but in the long run it pays to invest the time in then cleaning that up (up to and including wiping clean setups that have been manually updated to verify that the automated setups are correct and complete).

JMTQp8lwXL 7y ago

Yeah, but to set up an AAAA record, you still need the IP address. The usability still leaves something to be desired. At least we should never run out of IPv6 addresses.

denkmoon 7y ago
If you're setting up a AAAA once, you can deal with the copy paste. If you're updating them a lot, or a lot all at once, you should probably use a dynamic DNS updater.
thaumasiotes 7y ago
> At least we should never run out of IPv6 addresses. This is true in terms of the raw total number of IPv6 addresses. Everything I've seen discussing them assumes they'll be assigned hierarchically, though, which is a great way to ensure most of them are never used. Block assignments through a hierarchy can chew through any number of addresses no matter how big the space is.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
- waste_monk 7y ago
  Heirarchical assignment allows route summarisation. Imagine how much TCAM you'd need for unsummarized IPv6.
  - thaumasiotes 7y ago
    Yes, you're correct. But at the same time hierarchical assignment allows organization, including route summarization, it undermines the argument that there are too many addresses to exhaust. Addresses can easily be (in fact, are guaranteed to be) exhausted by the organizational system without ever being in use. The goals are in conflict.
    - Dagger2 7y ago
      They are being used -- for the purpose of allowing the internet to scale. But yes, we do need to be careful not to assign blocks that are too large. We're doing a good job of this (see any /8s being assigned?). We're also doing allocations only from 2000::/3, and there are five more completely untouched /3s available, so if we do somehow run out of space in 2000::/3 then we can start over with tighter allocation polices... five times over.
- mlyle 7y ago
  As said by others, you need hierarchy to avoid routing tables becoming excessively large-- that's the real limit. Since an IPv6 subnet can hold effectively any number of hosts, and it's easier to give bigger chunks of networks, the chances that a given org needs multiple assignments is much lower. In turn we use that real limit (routing table size) more responsibly. If routing tables can be much bigger in the future, we also have a whole lot more room to grow / allocate it differently. The chunk from which allocation is occurring (2000/3, plus the multicast and link local blocks, etc) is less than 1/4th the space; furthermore, more than half of the space within this is reserved. https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml https://www.iana.org/assignments/ipv6-unicast-address-assign...

roenxi 7y ago

> It forces people into ... better practices I've got no beef with IPv6; it seems pretty great there being enough addresses that everybody gets one. That said, being unmemorable is not a feature. Doing nothing is an alternative to doing things 'the right way' and people will choose it. The situation will backslide a little bit - with IPv4 people would do things, with IPv6 some people won't. Unless the goal is to configure IPv6 systems for their own sake, this is an unfortunate and unwanted side effect.

twblalock 7y ago
Do you know the IP addresses of your servers? You shouldn't know them. That reveals a lack of automation at a pretty low level of your infrastructure. IP addresses change all the time in cloud environments and container orchestration systems. Even if they didn't change, you get better systems if you pretend they might. It doesn't matter if you use containers or not -- if you assume IP addresses could change at any time, you end up with infrastructure that is tied to your service graph rather than your hardware.
- yardstick 7y ago
  What about when the host is your domains dns server, and you need to ssh to it to fix a broken dns configuration. But because dns is broken the hostname you would use isn’t resolving anymore.
  - vidarh 7y ago
    If a public domain, there needs to be NS records pointing at it from the registry, and they need to either have glue records giving the IP and/or at least one ought to be on a domain your name server itself is not the authoritative dns for. If a private domain and/or the server is only reachable from private IPs, then its IP should be in an asset management system somewhere (it should be if it is public too); be that a full blown orchestration system, if cloud servers or containers, or some form of asset register - even if only a spreadsheet - if it is physical servers in your own data centers. If properly automated, that asset register should drive configuration deployment - you shouldn't ssh to it to fix a broken dns configuration, you should run your deployment with a fixed config. I get that this is an idealized setup and that a lot of the time things intervenes and it's quicker and easier to do things manually then and there. Been there, done that, but in the long run it pays to invest the time in then cleaning that up (up to and including wiping clean setups that have been manually updated to verify that the automated setups are correct and complete).