Maybe it's me, but I think IPv6 should have been 8 bytes instead of 16 and somewhat backward compatible with IPv4.

Like how 2-byte Unicode was struggling and UTF-8 saved it.

deathanatos 4 days ago | parent | next [-]

> I think IPv6 should have been 8 bytes instead of 16

You don't state why you think this, but this is almost always due to the flawed thinking that the IP address is a simple identifier, and then looking at "how many IPs does the world need?" → "64 bits is enough". (IPs are like street addresses, in that they're routing instructions. Having the space not fragment — like v4's space is doing — is part of it, and helps things like routing tables remain small.)

> and somewhat backward compatible with IPv4.

The pigeon-hole principle makes backwards compatibility impossible. No matter what concrete scheme you might propose, it is effectively equivalent to IPv6.

▲

Dylan16807 4 days ago | parent | prev | next [-]

It's you.

8 versus 16 bytes barely matters for using the addresses, especially because if you're assigning IPs to your devices you can have the second half of the address start with 6-7 zero bytes and collapse them all with ::

And I challenge you to name a way to be "somewhat backward compatible" that would actually function and IPv6 doesn't already do.

▲

saulpw 4 days ago | parent [-]

The design of IPv6 is for computers, not for humans. How do you even say an IPv6 address aloud? You need to be able to communicate "192 dot 168 dot 50 dot 1" over a voice medium.

▲

Dylan16807 4 days ago | parent | next [-]

That has very little to do with 8 versus 16 bytes.

Edit: And not only can you make your own addresses short, if I look up some IPv6 addresses meant to be said/remembered (public DNS IPs), none of them make you type more than 8 bytes (and that one repeats a cluster to make it easier) and some make you type as little as 4 bytes.

▲

herczegzsolt 4 days ago | parent | prev [-]

If your IPv6 address is more complicated than your password, you have bigger problems.

Remembering and communicating mildly complex byte sequences should be an issue which is solved already.

▲

deathanatos 4 days ago | parent | next [-]

> Remembering and communicating mildly complex byte sequences should be an issue which is solved already.

It is solved already, it's called DNS.

▲

userbinator 4 days ago | parent [-]

...except when DNS doesn't work.

IPv4 addresses are not any more difficult to remember than phone numbers, but the same can't be said of IPv6.

▲

wredcoll 4 days ago | parent [-]

I agree, lets limit the total number of internet devices to 4 billion just in case we need to memorize one of the addresses.

The other 4 billion people on the planet don't really need internet connections do they?

▲

saulpw 4 days ago | parent [-]

The counter-proposal to IPv6's 128-bits was 64-bits. This is 16 quintillion devices, which seems fine.

Doubling the address space is a good strategy when you need more. Quadrupling it is over-engineering.

	▲	Dylan16807 4 days ago \| parent \| next [-]
		The extra space means you never have to calculate subnet sizes and you can let devices handle their own IPs. I think that's a pretty good tradeoff. 64 bits are already a pain in the ass to remember, and if you have specific memorization needs you can use small static IPs so that even with 128 bits available you only use about 64 of them.
	▲	Dagger2 3 days ago \| parent \| prev \| next [-]
		It's a good strategy if deploying a bigger address space is easy and cheap. When it's incredibly difficult and time consuming, you should pause and consider a bit more carefully. New L3 protocols on the Internet are firmly on the "incredibly difficult and time consuming" side.
	▲	wredcoll 3 days ago \| parent \| prev [-]
		What's the benefit to 64 bits? They're still hard to memorize and they're still not going to be backwards compatible.

▲

homebrewer 4 days ago | parent | prev [-]

Diceware is way easier to share over the phone than any IPv6 address (except for the few vanity ones like Google's 2001:4860:4860::8888 — then it's only slightly easier).

https://www.eff.org/dice

▲

saulpw 4 days ago | parent | prev | next [-]

It's not just you, I completely agree. 128-bit addresses are overkill. 64-bit would have been fine, and yes, backwards-compatible would have gotten us there that much sooner. For me, it's a deal-breaker that I can't reasonably speak an IPv6 address aloud (for instance when doing tech support over the phone).

	▲	simoncion 4 days ago \| parent \| next [-]
		How does your backwards-compatibility dream handle ASICs built to handle only IPv4 and shitty middleboxes hard-coded to drop or -worse- mangle any IP traffic that doesn't fit a particular subset of what's permissible for IPv4? Google and other big players go to huge lengths to build new Internet protocols on top of UDP because enough of the internet drops or mangles anything other than TCP or UDP that it's effectively impossible to use anything else on the Greater Internet. IPvNext by way of backwards-compatible IPv4 was (and continues to be) no easier than doing something that's backwards-incompatible. As a bonus, doing the backwards-incompatible thing bypasses all the bad behavior of existing shitty middleboxes and crummy ASICs.
	▲	Dagger2 3 days ago \| parent \| prev \| next [-]
		Overkill is good! It's impossible to get the size exactly correct; your only options are "too small" or "too big". Given how difficult it is to deploy a new L3 protocol, why wouldn't we pick the size that ensures we don't have to turn around and do it again immediately afterwards? > backwards-compatible would have gotten us there that much sooner v6 is already backwards compatible. Between dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6 and probably other things I'm forgetting, you could make a reasonable argument that it's too backwards compatible, even. If you meant "v4 being forwards-compatible would have gotten us there sooner", then yes, I agree. It's unfortunate it's not. That's entirely v4's fault though, not v6's.
	▲	wredcoll 4 days ago \| parent \| prev \| next [-]
		There is literally no way to get more than 4 bytes of address space out of midleware routers that limit the addresses to 4 bytes. There is no way to make that backwards compatible.
	▲	tenebrisalietum 4 days ago \| parent \| prev [-]
		You aren't supposed to be manually assigning addresses except in very small networks. You should have that centrally managed by DNS or any number of other things. No one should have to speak their address to you. You don't know what you're doing.

▲

yjftsjthsd-h 4 days ago | parent | prev [-]

> and somewhat backward compatible with IPv4.

How would it be at all backward compatible other than what NAT64 already does?

▲

sedawkgrep 4 days ago | parent [-]

I suspect the thinking is that all of IPv4 could have been a contained within the IPv6 space. Perhaps at at the very beginning or very end of it.

Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.

This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.

▲

yjftsjthsd-h 4 days ago | parent | next [-]

> I suspect the thinking is that all of IPv4 could have been a contained within the IPv6 space. Perhaps at at the very beginning or very end of it.

They actually went with 64:ff9b::/96 as the default (though IPv6 is so big that you can just pick another area if you want in ULA space or whatever).

> Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.

There are actually multiple implementations, depending on OS and whether you want it in kernel space or user space.

> This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.

They thought about it, named it NAT64 ( https://en.wikipedia.org/wiki/NAT64 ), published it, and it's in wide use. It frequently is combined with 464XLAT ( https://en.wikipedia.org/wiki/IPv6_transition_mechanism#464X... ) to make the transition mostly invisible to users/applications.

	▲	herczegzsolt 3 days ago \| parent [-]
		There are actually multiple areas already: ::ffff:0:0/96 IPv6-mapped This space is intended for an OS or network stack to map IPv4 addresses towards higher layers, so applications could technically be IPv6 only. The packet was/will be standard IPv4 when it reaches the network wire. ::/96 and ::ffff:0:0:0/96 IPv6-compatible/IPv6-mapped These were originally intended to be used on networks to differentiate IPv4 addresses depending on the capability of the target and decide who will do the translation. These are now deprecated, but the whole ::/8 is reserved, and these addresses are promised to never be assigned to anything else. 64:ff9b::/96 IPv6-translated This is the space for IPv6 to IPv4 NAT translators. Actually the whole /48 is reserved, so you can run address multiple private translators in a single network if required. This is widely used and supported. As a side note Teredo addresses (2001::/32) and 6to4 addresses (2002::/16) all embed the entire IPv4 address space, although they are more complex than a simple 1-to-1 mapping. They are rarely used.

▲

Ekaros 4 days ago | parent | prev [-]

Problem always is how to get packet back. The IPv4 host can get packet from somewhere. But if it simply does not have enough bits to represent the return address it cannot send packet back that actually arrives. Unless you do something like NAT that is get help form something on the way. And that something then has to keep track of whatever was done.