* Posts by Nanashi

352 publicly visible posts • joined 19 Sep 2016

Page:

It could be 'five to ten years' before the world finally drags itself away from IPv4

Nanashi

Isn't that what I said when I mentioned sparse allocations and aggregation? Allocations are made hierarchically and in large blocks in order to minimize fragmentation and the number of routing table entries needed, and all of this consumes address space.

Essentially, a majority of IP addresses "go unused" in order to make routing on the internet more efficient (but those addresses are actually in use, they're just being used to make routing more efficient rather than being used for assignment to an end host).

...which is why it's not enough for the IP:person ratio to be equal to or only very slightly higher than the number of devices that each person owns. You need to consider the various layers of allocations above the end device.

Nanashi

Re: What has it got in its pocketses?

It means that one third of the people hitting Google do so from TCP (...or UDP...) connections that have a v6 source address.

How the traffic is transported around inside the ISP is irrelevant to Google, who can't see any of those details.

Nanashi

Re: Hostnames

Thanks for the suggestion... although I'm not entirely sure what I'd discover that could change anything I've said.

v6 is already in many typical homes. It got there by having the same level of out-of-the-box usefulness and security as v4 does.

NAT and firewalls are two separate things. NAT doesn't provide any level of security for poorly configured/secured devices on the home network, but the firewall does and that's how home routers secure the network behind them, on both v4 and v6. We're already at the point you're saying we need to be at.

Nanashi

Re: That's pretty much all it does

"IPv6 nutters"? "Ivory tower"? Are we really going there? Again?

The people who designed v6 knew full well what would be involved. We ended up with what we did because there wasn't any other way to do it. v4 doesn't support addresses bigger than 32 bits, and fixing that involves replacing the IP stack with one that does support bigger addresses, and then plumbing that support through to everything that deals with IP addresses.

There's simply no way around this. You have to touch every system, because v4 is the layer of the internet that touches every system. The only methods that would help (things like 6to4, NAT64 etc) were used for v6.

Designing something that takes into account the limitations of the existing technology and of what can be done... is the exact opposite of an ivory tower.

If you're looking for people in ivory towers, perhaps you should look at the people who insist there's a way to make v4 somehow be forwards-compatible with bigger addresses without making any changes to v4 or any v4 devices. The people who are ignoring how both v4 and v6 work. Those are the people who are ignoring reality.

Incidentally, if you do have a way of designing a new protocol that's easier to deploy than v6 is, then feel free to prove me wrong by posting it -- so long as a) it actually works, and b) it's not something that v6 already does, because if it doesn't meet those two requirements it's just going to be another in the long list of dumb suggestions that don't actually help.

Nanashi

Re: If Only...

Not if you're paying attention. Gaming forums are full of people trying to "fix their NAT type", and they don't have much success when behind CGNAT. Games are using UPnP where they can, but people here keep complaining that UPnP is a security risk, and in any case it doesn't work so well behind CGNAT either. When they can't get a direct connection, games are relaying through central servers which adds latency and means you need the server to stay up to play the game. Similar problems abound outside of gaming too.

Yes, there are workarounds for many of the problems caused by NAT, but they're workarounds. The problems are still there, and the workarounds are expensive, and it's not necessary to pay that cost to stop people from accessing a server on your network.

Nanashi

Re: If Only...

Probably not hackers or the GCHQ/NSA. It's more likely to be gamers, people using VoIP, people wanting to reach their Nextcloud install or similar. These people aren't hackers.

It's okay to not want people from the internet to be able to connect by default, and it's okay to not want to change that. But you don't need NAT to stop people connecting, and in fact can't use NAT to stop people connecting, so not using NAT doesn't constitute a change to whether or not people can connect.

Nanashi

Yes? That's how I learnt v4 too, and I'd be willing to tick the v4 box on the same basis. If you're that afraid of running a network, then you already can't work in IT.

The risks aren't as big as you think they are... and the rewards are bigger than you think they are too. But I suppose you're not the only person who's afraid of new things.

Nanashi

Re: IPv6 isn't a very good solution?

They're not 4 bytes though, they're 4 octets. For computing architectures with 8-bit bytes, which is indeed common today, that's exactly equal to the length of 4 bytes, but that doesn't mean that the length of an IP address will change if you change the length of your bytes.

I was replying to a suggestion to change the size of a byte in order to get more addresses. Not only is this a non-trivial change to make, it wouldn't change the length of v4 addresses. (And even if it did, your bigger addresses would have the exact same compatibility problems with existing machines that v6 does...)

Nanashi

It's not enough because we're talking about layer 3 here, not layer 2. We aren't talking about MAC addresses, but IP addresses. They aren't allocated densely, but rather sparsely. The sparse allocation is critically important because it's how we scale the internet up to the scale of the internet. This is the entire reason we have IP in the first place rather than relying only on MAC addresses, and you can't just ignore it.

You're suggesting to allocate one /8 to each country, i.e. to use 8 bits of the address space to identify a country. With my lower-end allocations to end users, I'm suggesting to allocate 16 bits of address space to each user for their networks. Out of 48 bits, that leaves us with 48-8-16 = 24 bits of address space for the ISPs in each country. There are many countries, perhaps even most of them, that wouldn't fit into 24 bits of address space even in v4 land where the default end-user allocation size is often no addresses. As such, 48 total bits seems like it might very well be too few bits now, let alone in the future. That's why I don't think it'll meet the goal of giving us too many addresses.

To answer your last question: layer 2 is 64 bits for new protocols, and layer 3's routing and aggregation consumes additional address space, so we need something like 80-96 bits at L3 to handle the full L2 address space.

Nanashi

Re: I keep trying...

Psychic debugging time: PMTUD clamping. You might have it enabled for v4 but not for v6.

(I mean, I'd be happy to do non-psychic debugging too -- post a wget output of the failing URLs if you want, or at least tell us the sites in question.)

Nanashi

It doesn't obsolete your knowledge, because a significant fraction of your v4 knowledge applies to v6. It doesn't require expensive training courses; I learnt it from random web pages. It doesn't require a wholesale replacement of your entire infrastructure; you can replace each component during your normal refresh cycle. The security risks are not really any different to v4, and people's brains mostly don't lock up when dealing with v4.

If IPv8 was IPv4 with an additional two octets, then IPv8 would be too small. Deploying a new layer 3 protocol is an extremely long and expensive process. We absolutely do not want to do it more than once, so deploying a protocol that's too small would be a bad idea.

I'm also not convinced that making the protocol too small would give you universal buy-in. A lot of complaints don't seem to be based on reality, and most of the real problems involved in upgrading v4 will still exist regardless of how many bits you add.

Nanashi

It's really hard to put a specific duration on it, because it depends on how much you're willing to give up and how much time and effort you're willing to spend working around address space limitations, and on far too many parameters to get a proper handle on. But let's see what I can do.

In v6, you're supposed to get something between a /56 and a /48, with each network being /64. In other words, 256 to 65536 networks of effectively infinite hosts each. If we took the lower end of network count (256 networks, 8 bits) and dramatically reduced the number of hosts per network to 256 (again, 8 bits) and allocated out of a 48-bit space, then each user would get a /32 and there would be 2^32 (4 billion) /32s available.

Well, the standard allocation to end users in v4 is already either /32 or -- for phones or ISPs with CGNAT, which is probably billions of users -- absolutely nothing, and we're running out in v4, so with these allocation assumptions in a 48-bit space it seems like we'd be at least a significant fraction of the way to running out just with the current internet, let alone accommodating any future growth.

Deploying a new layer 3 protocol is an extremely long and expensive process. We only want to do it once, which means that providing far too many addresses is a design goal, so that we don't hit the point of having any reason to need another upgrade. I don't think 48 bits would meet that goal.

Nanashi

Re: What has it got in its pocketses?

Did anybody in your imagined conversation consider the cost of not rolling out v6? The cost of NAT, of dealing with RFC1918 clashes, of doing split DNS and VPNs and remapping, of the problems caused by CGNAT, of not being able to do things due to address exhaustion, of spending engineer time fixing problems in workarounds that just don't need to exist?

Probably not, since people ignore it constantly in the real world too, but that doesn't mean the cost isn't there.

Nanashi

Re: Not be simple

It's roughly the same design and architecture as v4, it just has longer addresses. There are some differences in the details but the overall design and architecture is unchanged. If you understand v4 then most of your knowledge of how it works can be transferred directly to v6.

v6 has many, many backwards compatibility methods. You can run both v4 and v6 side by side on the same networks. You've got NAT64, DS-lite, 6to4, Teredo and a number of other ways to provide v6 connectivity over v4 and connectivity to v4 hosts from v6. How can you say it's not backwards compatible when you have a whole host of backwards compatibility methods to use?

I'm considering the option of staying silent, but how is that going to help when people are spreading so much ignorant misinformation? I'd like to correct their misunderstandings, and I'd definitely like to stop the misinformation from spreading, and I don't see how I can do that by staying silent.

Nanashi

In that case you just copy/paste the address out of your /etc/resolv.conf file. Or type it out from memory, because it's not that hard to remember v6 addresses like 2001:db8:abcd::1; it's just your prefix plus "1". Or put it into /etc/hosts if your DNS breaks so often that this is such a big problem for you. Or connect over v4 -- one of the benefits of dual stack is that you can connect over one address family when you break the other one.

Nanashi

We already rolled out the new IP stacks 20 years ago. Even Windows had the new stack in XP. The hold-up in deployment hasn't been in rolling out new IP stacks, it's been in getting support for bigger addresses into software and in getting people to actually use them. Your suggestion wouldn't have helped the part that's taken most of the time.

The translation you mention already exists in v6 -- it just doesn't help as much as you think it does.

v4 took more than 10 years to become dominant, and it wasn't trying to replace a massively-entrenched existing protocol across literally billions of devices, so I think reaching roughly one third of users in the 7 years or so that we've been seriously deploying v6 is not so much a sign of failure but rather a sign of how difficult it is to upgrade layer 3.

Nanashi

Re: Quick experiment

The televisions possibly, but I don't believe you have 8 computers and 4 laptops that don't support IPv6. It sounds like you disabled v4 without setting up any alternate backwards compatibility mechanism for reaching legacy v4-only hosts.

I'm trying your experiment here and things are still working, because I have NAT64 to handle the backwards compat.

Nanashi

That wouldn't even come close to providing the extra address space we need.

Nanashi

Re: Not be simple

And my point is that that's not the case. Like I said, v6 is already backwards compatible. For example, with NAT64 you can talk to a.b.c.d by sending v6 packets to 64:ff9b::a.b.c.d. You can also map the v4 space into any arbitrary /96, so you could for example map your RFC1918 space into 2001:db8:4242::192.168.1.x to allow inbound connections over v6 to your v4-only LAN devices.

None of this saves you from deploying v6 on your network though.

Some of the header changes were a choice (a choice which, I note, was done to reduce the overall header length and complexity), but it's impossible to avoid changes to the header format because the v4 header only allocates 32 bits to src and dest addresses. Changing the header is a requirement, not a choice. The header format can be translated anyway, so the additional changes don't introduce any more problems than we already had.

Nanashi

Re: That's pretty much all it does

48 bits won't be enough in the long run (possibly not even in the short run), and even if it was, deploying an address family that used 48-bit addresses would take the same amount of work that deploying v6 is taking. The work isn't proportional to the number of bits! You need to do the same amount of work to deploy any address family with a bigger address size.

NAT isn't a vital security tool. It provides no security, so it isn't a security tool, and if it's not a security tool then it certainly can't be a vital one. If anything, NAT complicates your network and thus makes it harder to secure.

Nanashi

Re: How many IP addresses do we actually need?

Because it's the smallest power of two that's bigger than 64.

The point of L3 is to provide a layer of routing and aggregation on top of L2. Routing and aggregation consumes address space. L2 is 64 bits for new protocols, so L3 needs to be bigger than 64 bits. The next power of two up is 128, so here we are at 128 bits.

We could perhaps have gone for 80 or 96 bits, but can you imagine the sheer amount of wailing and teeth gnashing that a non-power-of-two bit length would've caused?

Nanashi

Re: Hostnames

Are you seriously arguing that most members of the public don't know the alphabet? I'm reasonably sure literacy rates are higher than that, and in any case someone who doesn't know the alphabet isn't going to be reading through their router admin pages.

Most people don't monitor for valid IPs when setting a new router up. They plug it in, turn it on, connect their devices and just use it. Most people are so unfamiliar with networking that v4 confuses them too. It's not going to be any worse with v6, and in fact the general lack of NAT will make it easier to understand and configure than v4 where NAT is a de-facto requirement.

Nanashi

Re: Not be simple

You are way off base. IP addresses are a sequence of bits. Decimal vs hexdecimal is purely for the textual representation, and has no bearing whatsoever on the packet format. So no, you couldn't have made the system backwards compatible by writing the addresses differently. The suggestion is entirely nonsensical.

In fairness, you did mention that you might not know what you're talking about. But for some reason that didn't stop you from calling the IETF a "bunch of shit-for-brains engineers". Here we have the Dunning-Kruger effect at its finest.

IPv6 is backwards compatible, by the way. Unfortunately v4 isn't forwards-compatible with larger address spaces which limits what you can do, but v6 supports all of the forms of backwards compatibility that are actually compatible with the design of v4.

Nanashi

Re: What has it got in its pocketses?

And fortunately we have IPv6 for those people, although a lot of them will outsource all of the technical aspects to their ISPs anyway.

Nanashi

Re: IPv6 was designed for a world of servers. now everything is a client instead.

Yes, and that's exactly what we did, except it doesn't seem to have stopped people from complaining about how massive the differences are and how we should've done the things we did do...

You don't need to rewrite your software from scratch to support v6. It's just some relatively minor alterations, and those alterations are exactly the same as the ones we'd have to make if we only added the 16 bits you seem to be suggesting we should've added -- which, incidentally, would be by far insufficient for the internet and would lead to needing to replace the IP protocol a second time. Surely it's better to add enough addresses the first time around?

v6 also does the "all existing addresses sit inside the new address space" thing, and it can do the simple translator thing you describe. Again, it already does the things you're saying it should've done.

ASN length was a different beast, because we didn't have hard-coded 16-bit ASN fields in every piece of network-capable software and hardware on the planet. The vast majority of network devices don't know or care about AS numbers at all. It's not relevant to the challenges posed by upgrading the IP layer.

Nanashi

Re: Not be simple

Mr. and Mrs. Average Public aren't expected to deal with IPs. They're expected to use hostnames, which by the way also use the letters in the range g to z as well as numbers and yet we don't complain about how hard those are to use.

Mr. and Mrs. Average Public don't need or want a 128-bit address on their machines. They just want their machines to work; the 128-bit addresses are just part of the technical details for how we engineers make that happen, rather than something that the end-user cares about. All of this is by design.

The format you suggest can't accommodate v6's address space, so it wouldn't even be an option. At least the "idiot engineers at IEFT" understood the limits of what it and isn't possible.

Nanashi

You're not supposed to remember them, you're supposed to use DNS and remember the hostnames.

And yes, there is: you can't just "allow bigger numbers" in the textual representation of a v4 address. The addresses are actually a sequence of 32 bits and there's no space in there to represent anything outside of the set of 256^4 addresses that it can currently do.

Nanashi

Before IANA ran out in 2011, we were going through one /8 per month, and demand has only gone up since then. At that rate, a /16 would last for about 2 hours of allocations. Even if you could hunt down a few thousand of them, it's just not a lot of space compared to what we need.

At the end of the day, v4 is simply too small. No amount of unused allocations will change that.

Nanashi

Re: IPv6 isn't a very good solution?

That would... not be simple. Or rather, it displays a complete misunderstanding of how v4 addresses work. Addresses in v4 aren't 4 bytes, they're 4 octets (32 bits). Bytes don't have to be 8 bits long, but v4 addresses are a fixed 32 bits regardless of the byte length of your computer's architecture. (It has to be this way because IP is used to talk between computer systems that use different byte lengths.)

You could design a protocol that used 40 bit addresses if you wanted, but it would end up looking very much like v6. In particular it'd have all of the same problems deploying as v6 would, because its 40 bit addresses are longer than v4's 32-bit addresses and that's where all the problems come from in the first place. You'd still have to patch all OSs and software to handle the new address length, upgrade legacy devices, update DHCP, DNS etc etc etc.

On top of that, 40 bits is woefully insufficient even for today's internet, let alone the future internet. After you finished deploying your 40-bit address family, you'd have to turn around and do it all again to increase the address size further. It'd be a complete waste of effort since you'd be back to doing v6 anyway.

So... no, that wouldn't even be a solution, let alone a simple one.

Nanashi

Re: IPv6 isn't a very good solution?

That's pretty much all it does. Almost everything else works the same way v4 does. Routing works the same way, address assignment works the same, DNS works the same, it works over the same L2 links that v4 does, TCP, UDP and other L4 protocols work the same, link-local addresses are in v4, and v4 even had router advertisements already before v6 was out... what's actually different?

There's NDP instead of ARP, but they work the same general way, except broadcast is removed in favor of multicast. v4 already has multicast so if anything this is actually a simplification. SLAAC is new, but that's really simple. I'm struggling to think of anything else.

> At this point we need an ipv7 that replaces ipv6 and is simply ipv4 with a 64-bit address space.

That's one of the last things we need. 64 bits would be insufficient, and expanding the address space from 32 bits to 64 bits has all of the exact same problems that expanding it to 128 bits does, so it wouldn't actually help you any. You'd just be throwing away 20 years of software support and deployment to restart from scratch with something that's going to have the same trouble deploying, which doesn't seem like it would help much to me.

Nanashi

Re: Sign of mass adoption

Yes? v4 is expected to stick around for a while. Undeploying v4 comes after deploying v6.

Nanashi

Re: Doomed to eternal limbo

v6 isn't going to cause a bigger breakdown in the internet than it's fixing. There's somewhere around a billion people using v6, about a third of the total on the internet, and it hasn't broken down, and neither have the networks of the people that're using it.

Meanwhile various things are broken on v4 and cannot really be fixed due to address shortages.

Nanashi

Re: @cdegroot

When you're stuck behind CGNAT without v6, tunnelling out to a VPS is keeping it simple. (Although it would be better to get a VPS from someone that actually does v6 properly, e.g. Linode, rather than paying someone that can't do routed prefixes.)

Nanashi

We already have a protocol that's backwards-compatible with v4 though (namely IPv6). How would designing another one help? You'd just end up in the same situation v6 is, except 20 years behind in software support and development.

The compatibility problem with v4 and v6 is that v4 isn't forwards compatible with bigger address sizes. Designing a new protocol won't change v4's lack of forwards-compatibility.

Nanashi

Re: Doomed to eternal limbo

You're thinking of MAC addresses, not IP addresses. MAC addresses come burned into each device, and get distributed via ARP/NDP. IP addresses are assigned to each machine from the prefix on the network.

SLAAC is very simple to set up... but the vast majority of people don't need to do so, because their routers will ship with it configured automatically in the same way they ship with DHCPv4 servers configured automatically. If you do need to set it up yourself, it's easier than setting a DHCP server up by yourself.

Nanashi

Re: IPv6 isn't a very good solution?

It's different because the telephone network was designed around variable-length phone numbers from the start, whereas v4 was designed around a fixed address length.

As such, it's easy to make phone numbers longer but it's much harder to make IP addresses longer. Should it be this way? There's not much point discussing that now; it is this way. If you have complaints, take them to the people who designed v4.

Nanashi

Re: What has it got in its pocketses?

We're not criticizing v4 for not being forwards compatible. It's just a fact of life that it isn't. (Meanwhile, v6 has various methods of backwards compatibility so people complaining that it doesn't are wrong.)

You're not going to fix this by introducing a new protocol to which v4 is also not forwards compatible. The way to fix it is education, but there seems to be an endless supply of people who don't know what they're talking about but are happy to talk as if they did.

Watchdog slams Pentagon for failing – for a third time – to migrate US military to IPv6

Nanashi

Re: Plus which ...

If you moved on from the DOD that long ago, then you may have missed that computer networks and PCs have already become ubiquitous in the DOD. They're already using a "technology that potentially allows folks anywhere in the world to browser the contents of its computers if any of thousands of things go wrong".

All of the worries you bring up have already been addressed by their existing network teams for their existing network. They're essentially just FUD at this point.

Nanashi

Re: IPv6 was a great idea when it was invented

v6 doesn't require massive changes though, considering the scope of what it's doing. It requires something close to the minimal set of changes that are necessary to expand the address size.

The v6 networking model is pretty much identical to the v4 model; its main difference is that the addresses are longer than they are in v4. It's true that making the addresses longer requires a large set of changes, but... isn't that sort of unavoidable? v4 doesn't work with longer addresses, and those longer addresses are the reason we're doing this in the first place. How are you going to get them without making the changes needed to add support for them?

v6 already has widespread support and deployment. Dumping all of that in favor of something that still has to do most of the same work, from scratch with no existing support, would be incredibly counterproductive.

Nanashi

They interact with a lot of other entities, ones that don't have the largest allocation of v4 addresses to a single entity, and those other entities use a lot of RFC1918 space. That's going to lead to a lot of instances of needing to interoperate with networks that have overlapping RFC1918 space. RFC1918 overlaps are expensive to deal with, and are a security headache. I can understand not wanting to deal with them.

They're probably also interested in selling off some of that space.

Nanashi

Re: NAT is not a firewall

It may look an awful lot like one when combined with RFC1918 addresses, but it is not. Any inbound connection that's possible on a network that's not using NAT is also possible if you add NAT to the same network without changing anything else. NAT is applied only to outbound connections, not inbound ones.

I'm not saying that it "only blocks most" inbound connections here. It doesn't block any of them. That's why it's not a firewall, that's why you need a firewall and that's why you don't need NAT to have a firewall or to be secure. If anything, NAT is just going to confuse you into thinking you're secure when you're not.

Hopefully the DoD understands this better than the average El Reg commenter (who will now proceed to downvote me for calling out their misunderstandings of NAT).

Nanashi

Re: IPv6 in the UK...

Because if they don't, all of their customer traffic has to go over v4. They don't have enough v4 addresses for their customers, so that traffic has to be CGNATed, and CGNAT is expensive.

Doing v6 lowers their costs. EE are, in fact, doing v6 to their customers today for this reason.

There's also the part where you need v6 to reach v6-only servers, but even if you somehow thought that wasn't the case the cost situation is still there. (And no, v6 doesn't restrict their billing options. They can still see the traffic and know which customer generated it.)

Internet samurai says he'll sell 14,700,000 IPv4 addresses worth $300m-plus, plow it all into Asia-Pacific connectivity

Nanashi

Re: Civilian note

Start at /64 and expand leftwards every time the spammer demonstrates the ability to use adjacent unblocked addresses. You'll find the right size in O(log n) trials, not the O(n) that everybody seems to assume. Bonus points for expanding 4 bits at a time to keep on nibble boundaries, and for remembering the size on a per-ISP basis so you only have to do it once for each ISP.

Nanashi

Re: In 3.. 2.. 1..

The v6 equivalent could easily be "AD as ::250, ESX-01 as ::10, gateway as ::254". Is that really too much to handle?

Nanashi

Re: Civilian note

I see no reason why RBLs wouldn't work for v6 addresses (or more importantly, for v6 prefixes).

You. Drop and give me 20... per cent IPv6 by 2023, 80% by 2025, Uncle Sam tells its IT admins after years of slacking

Nanashi

Re: AAISP

That's a pretty trivial setup. DHCPv6-PD takes care of autoconfiguring both routers.

If you can't use DHCPv6-PD for whatever reason, it's still easy; you just need a static inbound route, which is no harder to do in v6 than in v4. If it's not working for you then you messed up the config, which isn't v6's fault.

Nanashi

It's because it's hard to do better than v6, especially at this stage. v6 is already very close to "v4 but with longer addresses", and it already has support in most networking hardware and software. If you tried to come up with something different, you'd be starting from scratch on deployment (which we've already established takes a long time), and you pretty much have a choice of coming up with something that looks very much like v6, or something which is more complicated. Neither of those are likely to improve on the current situation by enough to throw away all of the work we've already done on deploying v6.

> Who, aside from some enthusiasts, actually wants ipv6?

ISPs do. CGNAT is expensive. Deploying v6 moves over half of your traffic off of your CGNAT infrastructure, which immediately makes it cheaper and reduces the need for future upgrades. It's also less complex than CGNAT, which is another cost saving.

The complexity of NATed networks (taking RFC1918 clashes, split DNS, VPNs etc into account) is a driving force in many other places too.

Nanashi

Re: Crap

If you actually spend some time using v6, you'll find that v6 addresses can be parsed by a human easily enough. It's actually easier to parse subnet info out of them than with v4, because hex lines up with binary more readily than decimal does.

We are absolutely, definitively, completely and utterly out of IPv4 addresses, warns RIPE

Nanashi

You're going to pick addresses like "2001:db8:10d:1::2", which isn't really that much longer than "203.0.113.42+192.168.1.2". In fact it's 7 characters (a good 30%!) shorter.

Most people use DNS, but if you need to remember IPs then that's what you'll do.

Nanashi

I'm pretty sure I've explained to you before that v6 does deliver value even before every device supports it. It's delivering value right now, so we can already declare your prediction wrong.

NAT is not as capable as you think. There are many things it breaks, and many things that are still possible in the face of NAT but only with additional effort and expense. NAT is useful as a delaying tactic but is not a desirable end goal.

Page: