Yep. The "New IP, Shaping Future Network" presentation was made to the ITU.
The shutdown you're thinking of was from the IETF [0], who of were publicly responding to the presentation publicly forwarded to them by the ITU [1].
Of course IETF are incentivized to think the process of protocol evolution they coordinate is the right place and way to set standards (but that doesn't mean they're wrong). Now ITU stakeholders are chiming in, and we can expect to see more over the coming months.
Can someone explain? From what I understand, they don't plan to replace TCP/IP. The body of text merely states it has been a staple of internet protocols, somehow saying it's been even further proven during covid-19.
The EU is responding to an ITU proposal that is both a combination of light on technical details about new network protocol(s), and more importantly would substantially upend the process for internet protocol development process. The mention of TCP/IP is because the "New IP, Shaping Future Network" presentation make sketchy statements about incapabilities of current Internet design. There are also concerns about the level of top-down control of the network the new protocol is set to enable.
In other words, this ITU participant is telling Huawei if they think their tech is such hot shit then go write an RFC and get bottom-up adoption of their idea like everyone else.
Personally, I would not trust anything Huawei produces because of their history of design flaws and bad software practices, as well as their ties to the Chinese government. However, I do see value in reworking some systems, such as BGP and DNS, which have been patched with optional additions to compensate for the trusting nature of its designers back when ARPAnet was small and contained little reason to execute hijacks of resources.
Protections for existing protocols are available though, so instead of reworking protocols and creating telecom-only protocols, perhaps enforcing certain features (BGP security, DNSSEC, etc.) for a provider to be able to name their service "5G" (or "6G" or whatever the next standard is) to make companies give a damn about security. The same tactic can also enforce proper filtering to prevent spoofed phone calls on the backbone that American wireless carriers seem to be so awful at.
Not sure why the ITU isn't it another body the ratifies RFC's
Might well use lobbying of smaller ITU member nations to try and get this through. Oh all that debt for that port we built as part of the belt and road.
And the optics of China putting pressure on the WHO in the early stages of the pandemic not looking good.
I don't have the exact links available right now but my position comes from claimed "backdoors" in their software and hardware.
Research found no backdoors, but all reported vulnerabilities were due to unsafe coding practices, many many different version of the same library being reused across the software of their devices with many of those versions being outdated and just generally a crummy job at coding. There was very little malice found, only bad practices.
This was compared to vendors like Cisco where secret passwords and backdoors were hidden obfuscated in their code, which can only mean the company intended for the backdoor to be there. Personally, I'd buy Huawei before Cisco given that incompetence is easier to forgive than straight-out malice in my opinion, but the conclusion remains that Huawei software isn't always up to snuff which can be a problem when you're trying to push a replacement for the core of the internet for your software.
Call me a Xenophobe but the Chinese connections to Huawei are sketchy but perhaps with international involvement we can make it a good rework of the network stack. Is there any opportunity for input from outsiders or is this a take-it-or-leave-it thing?
That has nothing to do with xenophobic, but if you really trust china/russia/us you should probably learn from the past, they have their own agenda and not a single point of it has something to do with your privacy or security.
And to be honest, china can give a really big shit about 'international' they are the producers of goods for the world and or payed them self into other country's, so its take it or leave it, and Huawei has the best router's for that new shit ;)
Since this doesn't really mention what the issue is, I would refer readers to Engadget for an explanation[1]. It seems that Huawei is proposing a new protocol that would allow for greater control of network traffic, among other things. As to be expected, this likely is a privacy nightmare waiting to happen should it actually be implemented.
I would like to make a proposal that everyone wear fluffy pink hats every third Wednesday of the month. And I would like to use this standards organization to promote this by writing a fancy document.
The way I read their proposal is them saying: "we're doing this new thing in our network gear. we can either standardize on it or you're going to have to deal with integrating with our proprietary systems yourself."
So to me, the real question is whether huawei has large enough presence to force everyone to "wear fluffy pink hats every third Wednesday of the month". Their strong presence in developing countries seems to suggest so.
If I could waive a magic wand I'd rework TCP/IP as follows:
- reduce routing table sizes by using explicit AS routing
- have src and dst AS numbers in IP packet headers
and route based on explicit AS numbers
- that would require a decent network prefix to AS
number lookup service
- maybe reduce IPv6 address sizes to 64 bits
- complete deployment of rpsec
- make TCP a bit more dynamic (e.g., change window
scaling after handshake)
- fix IPsec -- specifically get RFC5660 implemented
everywhere, add channel binding support
>reduce routing table sizes by using explicit AS routing
>that would require a decent network prefix to AS number lookup service
I don't see the advantage of this. All you're doing is offloading the routing table to every client device rather than at core routers only. Also, the "AS number lookup service" would be like a DNS request, which adds latency to every connection.
> - maybe reduce IPv6 address sizes to 64 bits
why? The only advantage I can think of is that it's easier to remember/enter for humans, which isn't really a good reason because there's DNS anyways.
>why? The only advantage I can think of is that it's easier to remember/enter for humans, which isn't really a good reason because there's DNS anyways.
It'd reduce the size of the IPv6 header, allowing more data per 1500 mtu packet. There's a lot of situations that are bound by packet rate limits, not bandwidth concerns.
BTW, if we're going to radically reimagine the internet, we should really push for a 9000+ MTU.
I think the point of 128 bit addresses in IPv6 is that it is effectively unlimited and thus won't cause problems and can make address allocation simpler.
It's a bit like the maxima in ZFS.
Current technology allows to pick maxima so large that we can just forget about them, so why not do it?
>It'd reduce the size of the IPv6 header, allowing more data per 1500 mtu packet. There's a lot of situations that are bound by packet rate limits, not bandwidth concerns.
So in cases where we're packet limited and not bandwidth limited we'd get a 1.1% throughput boost (1460 IP payload vs 1476). Seems like a fair tradeoff for never having to worry about NAT or address exhaustion ever again.
How does that work with connections (eg. consumer ISPs) that use <= 1500 MTU? If there's even one router in your path that doesn't accept high MTUs, any benefits will evaporate. So basically high MTUs are only really useful for datacenter <-> datacenter connections, where you can reliably get high MTUs throughout the entire path.
> I don't see the advantage of this. All you're doing is offloading the routing table to every client device rather than at core routers only. Also, the "AS number lookup service" would be like a DNS request, which adds latency to every connection.
The better way to do it is to forget about a lookup service and make the AS number a part of the IP address. This is why you do want 128-bit addresses. You could make the AS the first 32 bits of the address and then each AS would have four billion /64 networks.
But in practice this is basically what you get with IPv6 anyway. The problem with IPv4 is that because there aren't enough addresses, you have people wanting to add dozens of network prefixes to the same AS because they couldn't get a single contiguous block large enough for their needs. With IPv6 you can give every AS a /32 with 96 bits worth of addresses in it and they'd never need another one.
Well, sure, if address portability doesn't matter. Which... it kinda doesn't, so, sure. But AS numbers don't need to be much bigger than 24 bits, so 64 bits for addresses is plenty :)
Existing AS numbers are 32-bit, but sure, 24 is probably enough.
The problem is with 64-bit addresses you'd only have 40 bits left for the whole AS. They'd quickly run out if they gave each customer a 32-bit block, so they'd have to use 20-bit blocks or so.
Then you have corporate customers who want to do complex internal subnetting, for which 20-bit wide blocks are administratively burdensome. 10.0.0.0/8 is 24-bit and they already run into problems there. They start having to use variable-sized subnets because the main office needs a 14-bit wide block but you don't have enough addresses to give every office that many, and then you have to renumber any time the size of an office changes, and probably renumber two other offices to free up a large enough contiguous address block.
That all goes away if you can give every customer billions of addresses and they don't have to worry about their subnets being "too big" which means they never end up being too small.
IPv6 gives you a ridiculously large number of different IPs... but they are all in the same /64, which you can pretty much treat as a single location. So, all these IPs aren’t really adding much to protect someone’s privacy.
The claim was that it made it worse. How is sharing the same /64 worse than sharing the same IPv4 address?
On top of that, you don't actually know that it's a /64. The customer could have a /56. The customer could have a /128, which some mobile ISPs do. The customer could have a /128 with the ability to request arbitrarily many of them from the ISP, allowing the same trick with one IP per outgoing connection but causing the pool to be shared across all the ISP's customers. The ISP could, in principle, allow the customer to request an arbitrary number of non-contiguous address ranges of an arbitrary size and use them for an arbitrary duration before reassignment to a different customer. Nothing really requires it to be a single /64 forever.
I wouldn't bother with AS numbers in IP packet headers because it requires a mechanism of syncronising AS routes on the client side while the client should not be bothered with routing.
The idea of BGP works fine but needs to have the proper security measures in place. I don't think TCP/IP should contain complex routing systems like that.
I'd love to have IPsec to become the HTTPS for all protocols but there's no way that's going to happen without a proper mechanism to support random connections. My attempts at making IPsec work for communication between devices (so not just L2TP VPNs) so far have all been thwarted by complicated software configurations and outdated guides with questionable security recommendations.
Of having AS numbers in the IP packet isn't actually all that bad. It's just a matter of where. This comment (https://news.ycombinator.com/item?id=23418691) from elsewhere on the thread suggests making the ASN the top 32 bits of the IPv6 address, which would solve a whole slew of issues.
Clients don't (and shouldn't) care about the routing information built into the address, but building the ASN into the IP address isn't so bad. And to keep things compact, the ASN could be in little endian order.
I would definitely shorten IPv6. If IPv6 had been 64-bit it would already have replaced IPv4. The loooooooong addresses are a huge usability problem, and usability is the largest influencing component for adoption.
Advocates seem to respond by saying "use DNS," which shows me that they've never really done any IT work or are forgetting their experience. Every IT person knows "its always DNS." When DNS is down, the first thing you have to do is type IPs. You also have to type IPs a lot when setting things up, often on keyboards hanging off things in data centers and other inconvenient spots. Don't get me started on embedded stuff.
If IPv6 continues to stall, I think it might be worth introducing an RFC to retroactively shorten it. You'd leave the addresses the same really but you'd re-interpret the first 64 bits as the IP and the last 64 bits as a kind of extended port field. Specifying those bits is optional and they default to zero.
Then change assignment recommendations so every ISP endpoint gets at least a /48 (/40 preferred, /32 for business and larger links) and deprecate SLAAC in favor of DHCP6.
Lastly change the representation to something like:
feed.d00d.dead.beef[.deadbeefcafebabe]
(that's valid hex for anyone who doesn't know that's valid hex)
Anything whose least significant bits are all zero like feed.d00d.0.0 would of course be an IPv4 address.
There are various ways to make this less painful. To start with, use anycast DNS so you don't have to type the address of your DNS server(s) into anything, and have a local DNS server with your local names in it so they all still work even if upstream is down.
Then give important machines simple addresses. Assigning your DHCP server [network prefix]::3 and your file server [network prefix]::4 instead of [network prefix]:[64-bit random number] simplifies things a lot. You can also do this with link-local addresses, so then your local file server can be accessed as fe80::4, or something not too far away from that with ULAs if it's not on the same network segment, e.g. fc00:abcd::4.
That sounds complex. That's fine for large operations or operations with deep technical talent, but what about the vast majority of people who have less expertise and less time/resources to deploy complex configurations?
Also what about the vast, vast number of cases where you want to address private backplane networks and do things like "ping 10.0.0.2"? People still largely use V4 there even if they have V6 because V6 is too inconvenient.
DNS fixes this problem on connected, configured systems when everything is working property. It does not fix the problem when there are issues or when things are being set up, developed with, debugged, etc.
Private backplane networks would presumably be using static ULAs. What's so hard about "ping fc00:abcd::2"?
> what about the vast majority of people who have less expertise and less time/resources to deploy complex configurations?
"Simple things should be simple and complex things should be possible."
There exist IPv6 ISPs that give you a modem/router that you plug your stuff into and there is nothing else to configure. They could all do that. That covers the large majority of people who just want to internet as quickly as possible.
If you want to have complex internal subnets and backplane networks and things like that, this is a thing that requires technical knowledge to begin with.
I suspect the reason people continue to use IPv4 for such things is simply that they're more familiar with it and it still works. And so what's wrong with that? The primary advantage of IPv6 is that it gives every device a globally routed address. It still does that if people carry on using dual stack with IPv4 until the end of time. Or however many decades until IPv6 has enough penetration that people have gotten used to it and start to turn IPv4 off.
You can use IPv6 long before IPv4 ceases to exist.
I'm deeply suspicious of this, not only because Huawei seems to have a lot of Chinese government influence, but because it's from a corporate entity. Corporate entities appear to not be able to refrain from making things centralized for the purposes of obtaining monopoly rents.
Informed by this fact of wanting to be a rent seeker, one can guess that Huawei would want big dollar for a copy of the standard, and maybe a small license fee for every client. I'd also bet money that there'd be a large license fee to run a server, and that there's a protocol-level division between "server" and "client", something that just doesn't exist in TCP or IP. It's possible to centralize control by means of "Intellectual Property" law and standards organization, just as it's possible to centralize control with built-in kill switches.
Oh, yeah: I used to think (in 1990-2000 timeframe) that maybe Microsoft would be the corporate entity to try to pull this sort of thing off. I often speculated about "MSTCP" being the thing to put the Internet's genie back in the bottle. I was wrong about that.
It may be a reaction to Google trying to replace TCP with their own protocols for their HTTP services. The performance advantage is under 10%, but it puts Google in control.
In fact, the proposal really is strikingly similar to X.25. On the other hand for the breath of problems that they try to solve it makes sense.
On the other hand there really is no reason to create one unified protocol to solve all that at once. IETF's “all that can be done on IP and this is how” is kind of bold statement, as there are applications where only reason to involve IP is marketing, eg. there is little reason to involve IP in various hard-realtime-ish short range IoT-ish things (that one popular hard-realtime safety critical industrial automation protocol involves not only IP but DCOM on top of slightly non-standard ethernet to solve problem that is perfectly solved by RS-485 based bus is another thing)
"Just always do IP" is because of the existing ecosystem of tools, techniques and so on, which all assume IP because IP is very popular. Almost every application can benefit from this†
For every single problem there will be a hypothetical ideal solution that's custom in every way like a bespoke suit, but you (or your customers) probably can't afford that solution and so that's the wrong solution.
If IP isn't good enough, I would strongly urge you to go help it be better rather than sit on the sidelines saying people shouldn't bother using IP. Mostly for self-preservation reasons, if it can be done somebody is going to do it, and that might as well be you - if it can't be done you'll end up the expert on why not.
† Really often these applications says they use IP to benefit from this ecosystem but they aren't on the Internet, and when you look closer - oops, nobody told the people implementing them about not being on the Internet, so they actually are on the Internet, peeking out from unexpected places.
That is essentially my point with the exception that there are things that are inherently L2 and thus you don't want to bother with IP or for that mater any other L3 protocol.
I have to wonder why this would be brought up at the ITU and not the IETF. The ITU in general regulates spectrum usage and the modulation on top of that, which are more or less restricted to L1 in modern networks. Unless there's something I'm missing?
I'm pretty sure this is the "New IP, Shaping Future Network" proposal that was unceremoniously squashed by the IETF a few months ago; that was discussed here at the time: https://news.ycombinator.com/item?id=22776749
I recently read a TechCrunch article about the CCP's plan to restructure global standards over the next decade. Is this proposal a product of that plan?
My purely technology oriented take on that is that telecom manufacturers had really embraced the idea “everything is IP over Ethernet” during the development of LTE and then during first deployments found out, that such approach does not realy work on real networks with mixed generations of both infrastructure and user terminals (this is the reason for existence of VoLTE). And on other hand everybody found out that “computer networking” hardware is commodity thing that is cheap.
So, Huawei knows that they need something which is not IP and tries to make hardware that supports it commodity product instead of niche telco weirdness by trying to push their thing as end-all solution to everything networking. In fact, from this PoV this is somewhat reminiscent of late 90's and ATM.
A bit offtopic but I was thinking that it might actually be possible for some companies to replace TCP/IP. Let's say Apple. They probably have enough money to do the SpaceX thing and have a network of satellites in orbit that could replace the mobile network all iPhones connect to worldwide. Since they control all the devices that connect to this network, they would have full control over the internet protocol it uses and could invent their own, from scratch. Actually, SpaceX could probably do the same if they run SpaceXnet in parallel with TCP/IP and sell their own hardware (or do a TCP/IP over SpaceXnet protocol that they use between ground stations)
A StarLink style satellite array actually has good latency even when compared to traditional fiber networks[1].
I recall some calculations that showed a decrease in latency over long distances because light travels slightly faster in a vacuum, there are fewer intermediate nodes over that distance, and a more direct path can be used than in our existing wired networks.
The biggest issue with current satellite connections is that the satellites are in geostationary orbits which imposes a minimum theoretical latency of something like half a second. It's physically impossible to send signals any faster[2].
Google did just that. They added the protocols SPDY and QUIC to Chrome and tried to get server owners to adopt them. Given that they control YouTube which is the world's largest site both by unique users and bandwidth usage they could easily force their own protocol through.
All Huawei has to do is get it adopted as a standard in China. Then suddenly Samsung, Apple, Sony, and all the other non-Chinese companies have to add it to their devices to keep a billion customers. Then it gets used outside of China because it is ubiquitous.
This is a classic embrace, extend, extinguish play.
Problem is...you (the chip-maker) pay licenses to the satellite-owners, if your chip does not work outside china, no money. The Chinese 'GPS' is probably just for military or for the independence from other systems.
Yes, but hardware vendors need to decide if they put the chip in all devices and reduce manufacturing/design/testing costs, or put the chip on a Geo specific model and incur higher mfg/design/testing costs.
It's always a tradeoff and the cost of the chip in itself is not the sole decision driver.
No..not really, standard's in a single nation (especially china) will NOT swap over to other nations, Apple etc will probably make a dual-stack, but to give up IP-Support just to run after china is really not a option for most of the country's.
Apple made "sign in with apple" mandatory for all apps with third-party sign in options, which also ends up spreading beyond their app ecosystem into the web since user's who start with the app wouldn't be able to log in elsewhere otherwise.
This would be a step beyond that, but what if China mandated phones can't be sold there unless manufacturer's phones in other regions support their standard.
This is like how some people wanted to remove some protections afforded by TLS 1.3 with PFS, so they went to ETSI who ratified eTLS. The ITU has nothing to do with the internet so this is just another publicity stunt. The internet works because everybody agrees on a common set of RFC's. It is nigh on impossible for a single entity to force a change.
90 comments
[ 2.9 ms ] story [ 129 ms ] threadThe shutdown you're thinking of was from the IETF [0], who of were publicly responding to the presentation publicly forwarded to them by the ITU [1].
Of course IETF are incentivized to think the process of protocol evolution they coordinate is the right place and way to set standards (but that doesn't mean they're wrong). Now ITU stakeholders are chiming in, and we can expect to see more over the coming months.
[0] https://datatracker.ietf.org/liaison/1677/ [1] https://datatracker.ietf.org/liaison/1653/
In other words, this ITU participant is telling Huawei if they think their tech is such hot shit then go write an RFC and get bottom-up adoption of their idea like everyone else.
Personally, I would not trust anything Huawei produces because of their history of design flaws and bad software practices, as well as their ties to the Chinese government. However, I do see value in reworking some systems, such as BGP and DNS, which have been patched with optional additions to compensate for the trusting nature of its designers back when ARPAnet was small and contained little reason to execute hijacks of resources.
Protections for existing protocols are available though, so instead of reworking protocols and creating telecom-only protocols, perhaps enforcing certain features (BGP security, DNSSEC, etc.) for a provider to be able to name their service "5G" (or "6G" or whatever the next standard is) to make companies give a damn about security. The same tactic can also enforce proper filtering to prevent spoofed phone calls on the backbone that American wireless carriers seem to be so awful at.
Might well use lobbying of smaller ITU member nations to try and get this through. Oh all that debt for that port we built as part of the belt and road.
And the optics of China putting pressure on the WHO in the early stages of the pandemic not looking good.
Do you have references to what you're referring to?
You can also search this site for "huawei". Almost none of the submissions paint them in a good light.
Research found no backdoors, but all reported vulnerabilities were due to unsafe coding practices, many many different version of the same library being reused across the software of their devices with many of those versions being outdated and just generally a crummy job at coding. There was very little malice found, only bad practices.
This was compared to vendors like Cisco where secret passwords and backdoors were hidden obfuscated in their code, which can only mean the company intended for the backdoor to be there. Personally, I'd buy Huawei before Cisco given that incompetence is easier to forgive than straight-out malice in my opinion, but the conclusion remains that Huawei software isn't always up to snuff which can be a problem when you're trying to push a replacement for the core of the internet for your software.
And to be honest, china can give a really big shit about 'international' they are the producers of goods for the world and or payed them self into other country's, so its take it or leave it, and Huawei has the best router's for that new shit ;)
[1] https://www.engadget.com/2020-03-30-china-huawei-new-ip-prop...
So to me, the real question is whether huawei has large enough presence to force everyone to "wear fluffy pink hats every third Wednesday of the month". Their strong presence in developing countries seems to suggest so.
>that would require a decent network prefix to AS number lookup service
I don't see the advantage of this. All you're doing is offloading the routing table to every client device rather than at core routers only. Also, the "AS number lookup service" would be like a DNS request, which adds latency to every connection.
> - maybe reduce IPv6 address sizes to 64 bits
why? The only advantage I can think of is that it's easier to remember/enter for humans, which isn't really a good reason because there's DNS anyways.
It'd reduce the size of the IPv6 header, allowing more data per 1500 mtu packet. There's a lot of situations that are bound by packet rate limits, not bandwidth concerns.
BTW, if we're going to radically reimagine the internet, we should really push for a 9000+ MTU.
It's a bit like the maxima in ZFS.
Current technology allows to pick maxima so large that we can just forget about them, so why not do it?
So in cases where we're packet limited and not bandwidth limited we'd get a 1.1% throughput boost (1460 IP payload vs 1476). Seems like a fair tradeoff for never having to worry about NAT or address exhaustion ever again.
IPv6 already mandates path MTU discovery and min MTU of 1280.
The better way to do it is to forget about a lookup service and make the AS number a part of the IP address. This is why you do want 128-bit addresses. You could make the AS the first 32 bits of the address and then each AS would have four billion /64 networks.
But in practice this is basically what you get with IPv6 anyway. The problem with IPv4 is that because there aren't enough addresses, you have people wanting to add dozens of network prefixes to the same AS because they couldn't get a single contiguous block large enough for their needs. With IPv6 you can give every AS a /32 with 96 bits worth of addresses in it and they'd never need another one.
Edit: OK, not sure why that got a downvote. Did somebody think I was being sarcastic or something?
The problem is with 64-bit addresses you'd only have 40 bits left for the whole AS. They'd quickly run out if they gave each customer a 32-bit block, so they'd have to use 20-bit blocks or so.
Then you have corporate customers who want to do complex internal subnetting, for which 20-bit wide blocks are administratively burdensome. 10.0.0.0/8 is 24-bit and they already run into problems there. They start having to use variable-sized subnets because the main office needs a 14-bit wide block but you don't have enough addresses to give every office that many, and then you have to renumber any time the size of an office changes, and probably renumber two other offices to free up a large enough contiguous address block.
That all goes away if you can give every customer billions of addresses and they don't have to worry about their subnets being "too big" which means they never end up being too small.
On top of that, you don't actually know that it's a /64. The customer could have a /56. The customer could have a /128, which some mobile ISPs do. The customer could have a /128 with the ability to request arbitrarily many of them from the ISP, allowing the same trick with one IP per outgoing connection but causing the pool to be shared across all the ISP's customers. The ISP could, in principle, allow the customer to request an arbitrary number of non-contiguous address ranges of an arbitrary size and use them for an arbitrary duration before reassignment to a different customer. Nothing really requires it to be a single /64 forever.
2. its impossible to uniquely globally tag each person with an ip
The idea of BGP works fine but needs to have the proper security measures in place. I don't think TCP/IP should contain complex routing systems like that.
I'd love to have IPsec to become the HTTPS for all protocols but there's no way that's going to happen without a proper mechanism to support random connections. My attempts at making IPsec work for communication between devices (so not just L2TP VPNs) so far have all been thwarted by complicated software configurations and outdated guides with questionable security recommendations.
Clients don't (and shouldn't) care about the routing information built into the address, but building the ASN into the IP address isn't so bad. And to keep things compact, the ASN could be in little endian order.
A better way would’ve been to just used bullets and newlines.
Advocates seem to respond by saying "use DNS," which shows me that they've never really done any IT work or are forgetting their experience. Every IT person knows "its always DNS." When DNS is down, the first thing you have to do is type IPs. You also have to type IPs a lot when setting things up, often on keyboards hanging off things in data centers and other inconvenient spots. Don't get me started on embedded stuff.
If IPv6 continues to stall, I think it might be worth introducing an RFC to retroactively shorten it. You'd leave the addresses the same really but you'd re-interpret the first 64 bits as the IP and the last 64 bits as a kind of extended port field. Specifying those bits is optional and they default to zero.
Then change assignment recommendations so every ISP endpoint gets at least a /48 (/40 preferred, /32 for business and larger links) and deprecate SLAAC in favor of DHCP6.
Lastly change the representation to something like:
feed.d00d.dead.beef[.deadbeefcafebabe]
(that's valid hex for anyone who doesn't know that's valid hex)
Anything whose least significant bits are all zero like feed.d00d.0.0 would of course be an IPv4 address.
Then give important machines simple addresses. Assigning your DHCP server [network prefix]::3 and your file server [network prefix]::4 instead of [network prefix]:[64-bit random number] simplifies things a lot. You can also do this with link-local addresses, so then your local file server can be accessed as fe80::4, or something not too far away from that with ULAs if it's not on the same network segment, e.g. fc00:abcd::4.
Also what about the vast, vast number of cases where you want to address private backplane networks and do things like "ping 10.0.0.2"? People still largely use V4 there even if they have V6 because V6 is too inconvenient.
DNS fixes this problem on connected, configured systems when everything is working property. It does not fix the problem when there are issues or when things are being set up, developed with, debugged, etc.
> what about the vast majority of people who have less expertise and less time/resources to deploy complex configurations?
"Simple things should be simple and complex things should be possible."
There exist IPv6 ISPs that give you a modem/router that you plug your stuff into and there is nothing else to configure. They could all do that. That covers the large majority of people who just want to internet as quickly as possible.
If you want to have complex internal subnets and backplane networks and things like that, this is a thing that requires technical knowledge to begin with.
I suspect the reason people continue to use IPv4 for such things is simply that they're more familiar with it and it still works. And so what's wrong with that? The primary advantage of IPv6 is that it gives every device a globally routed address. It still does that if people carry on using dual stack with IPv4 until the end of time. Or however many decades until IPv6 has enough penetration that people have gotten used to it and start to turn IPv4 off.
You can use IPv6 long before IPv4 ceases to exist.
You know that they are totally separate protocols, right?
Informed by this fact of wanting to be a rent seeker, one can guess that Huawei would want big dollar for a copy of the standard, and maybe a small license fee for every client. I'd also bet money that there'd be a large license fee to run a server, and that there's a protocol-level division between "server" and "client", something that just doesn't exist in TCP or IP. It's possible to centralize control by means of "Intellectual Property" law and standards organization, just as it's possible to centralize control with built-in kill switches.
Oh, yeah: I used to think (in 1990-2000 timeframe) that maybe Microsoft would be the corporate entity to try to pull this sort of thing off. I often speculated about "MSTCP" being the thing to put the Internet's genie back in the bottle. I was wrong about that.
On the other hand there really is no reason to create one unified protocol to solve all that at once. IETF's “all that can be done on IP and this is how” is kind of bold statement, as there are applications where only reason to involve IP is marketing, eg. there is little reason to involve IP in various hard-realtime-ish short range IoT-ish things (that one popular hard-realtime safety critical industrial automation protocol involves not only IP but DCOM on top of slightly non-standard ethernet to solve problem that is perfectly solved by RS-485 based bus is another thing)
For every single problem there will be a hypothetical ideal solution that's custom in every way like a bespoke suit, but you (or your customers) probably can't afford that solution and so that's the wrong solution.
If IP isn't good enough, I would strongly urge you to go help it be better rather than sit on the sidelines saying people shouldn't bother using IP. Mostly for self-preservation reasons, if it can be done somebody is going to do it, and that might as well be you - if it can't be done you'll end up the expert on why not.
† Really often these applications says they use IP to benefit from this ecosystem but they aren't on the Internet, and when you look closer - oops, nobody told the people implementing them about not being on the Internet, so they actually are on the Internet, peeking out from unexpected places.
Sigh I could have had such a cool email address if that had taken off C=UK CN=Nickname - I was third line support for the UK x.400 ADMD and had admin
Not to mention, in my opinion, the ITU is far less transparent and more prone to backroom dealing.
https://www.save2m.org/2019/08/france-defeated-thales-and-th...
https://techcrunch.com/2020/04/11/chinas-next-plan-to-domina...
So, Huawei knows that they need something which is not IP and tries to make hardware that supports it commodity product instead of niche telco weirdness by trying to push their thing as end-all solution to everything networking. In fact, from this PoV this is somewhat reminiscent of late 90's and ATM.
I recall some calculations that showed a decrease in latency over long distances because light travels slightly faster in a vacuum, there are fewer intermediate nodes over that distance, and a more direct path can be used than in our existing wired networks.
The biggest issue with current satellite connections is that the satellites are in geostationary orbits which imposes a minimum theoretical latency of something like half a second. It's physically impossible to send signals any faster[2].
1: https://arstechnica.com/information-technology/2020/03/musk-...
2: https://en.wikipedia.org/wiki/Satellite_Internet_access#Sign...
This is a classic embrace, extend, extinguish play.
Phones and devices can support that, but if outside China, it has no one to talk to.
Though, even in that case it can lead to backdoors.
https://en.wikipedia.org/wiki/BeiDou
If !(in China) _disable_
Although even that will cause unnecessary headache for hardware and OS vendors and will/might still lead to new security issues and backdoors.
It's always a tradeoff and the cost of the chip in itself is not the sole decision driver.
https://appleinsider.com/articles/19/06/03/sign-in-with-appl...
This would be a step beyond that, but what if China mandated phones can't be sold there unless manufacturer's phones in other regions support their standard.
And that sign-in is just for china, not outside of it.