16

My understanding is there are 2^32 - 1 possible IPv4 addresses, and 2^16 - 1 possible ports. Which gives ~2^48 addresses.

The additional 2^16 additional ports seem almost insignificant considering the IPv6 address space is 2^80 times larger than the number of IPv4 addresses * ports. With the 2^128 possible IPv6 addresses, why do we need ports at all?

Why not assign each application, tab, etc... its own public IPv6 address?

Josh
  • 263
  • 2
  • 6
  • 1
    Ports are addresses for _some_ transport protocols. TCP and UDP use ports, but they are not the same ports despite using the same port number range. TCP port 12345 is _not_ UDP port 12345. Other transport protocols may use other or no addressing. Unfortunately, the NAT variant, NAPT, only supports TCP, UDP, and ICMP, stifling existing and new protocols and innovation. IPv6 restores the IP end-to-end paradigm, allowing other existing and yet-to-be-developed transport protocols. – Ron Maupin Aug 31 '22 at 17:03
  • 7
    Note that this mentality of ‘we have _plenty_ of space’ is part of why we’ve run out of IPv4 addresses. – Austin Hemmelgarn Sep 01 '22 at 01:28
  • 3
    I think the answer here is twofold: 1. Existing software should work mostly the same and there are entrenched patterns of working with ports. 2. General complexity creep: on top of addresses and ports, IPv6 added scopes, to make things more fun (https://en.wikipedia.org/wiki/IPv6_address#Scoped_literal_IPv6_addresses_(with_zone_index)) – oakad Sep 01 '22 at 06:20
  • 1
    But wouldn't that mean we just allocate 128 bits (for ip+port) of routing information instead of 144 bits? Why go back and limit ourselves more? – Gizmo Sep 01 '22 at 08:27
  • 3
    The real question here is: What would even be the advantage or rather what problem is OP trying to solve? I think the question stems from a misunderstanding of what IP addresses and ports (TCP/UDP) are and how they relate, which the given answer already addresses. – Num Lock Sep 01 '22 at 08:30
  • 1
    @Gizmo, routing happens at layer-3 (IP), not layer-4 (transport protocol). IP has no idea what is in the payload; it could be any transport PDU, including one that does not use ports or uses some other addressing. Also, to which port do you refer (TCP, UDP, SCTP, etc. because they are all different, even if they are the same number)? IP gets you to the host, the transport protocol and its port number or other addressing get you to the process inside the host. The IP process is separate and distinct from the transport process. – Ron Maupin Sep 01 '22 at 12:31
  • 2
    My original thinking was that, conceptually, it makes more sense for the application/process to be the addressable entity rather than the hardware device it happens to be running on. Ports seem to be a workaround, similar to NAT devices, for reducing our use of IP addresses? – Josh Sep 01 '22 at 18:41
  • Not all transport protocols use ports, so you are forcing changes to things like routing protocols (OSPF, EIGRP, etc. that have other transport protocols that do not use ports). As I explained above, "_Ports are addresses for some transport protocols. TCP and UDP use ports, but they are not the same ports despite using the same port number range. TCP port 12345 is not UDP ports 12345. Other transport protocols may use other or no addressing._" You will stifle the innovation that IPv6 restores to us. Your vision is too narrow, focusing only on current home Internet use – Ron Maupin Sep 01 '22 at 22:06
  • @Josh I think I got that intention. Rather than having *applications* deal with IP address handling (allocation), that is firmly situated in the IP stack. It's been established that an application may *select* from a pool of local addresses but it mainly deals with allocating *ports*. Changing that paradigm wouldn't really gain anything but lose a lot. NA(P)T is a completely different beast because it breaks the original end-to-end transparency and requires stateful routing. – Zac67 Sep 02 '22 at 07:21
  • Obligatory xkcd reference: https://xkcd.com/865/ – Florian F Sep 02 '22 at 17:38
  • @AustinHemmelgarn Note we have the same mentality in IPv6! Wasting a whole 64 bits and giving another 16 bits per customer - we only have 2^13 more networks to give out in IPv6 than addresses in IPv4! – user253751 Sep 03 '22 at 14:36
  • You can imagine port is like physical port, like HDMI, USB, etc. Same like logical port, you will see port that is intended for web server (port 80), ssh (port 22), DNS (port 53) and etc. While IP Address, you can imagine it's an identity of every device, for example a laptop has IP x.x.x.x, a smartphone has IP y.y.y.y. laptop and smartphone can run webserver in port 80 at same time but different webserver device (different IP). – Muhammad Ikhwan Perwira Sep 03 '22 at 15:21
  • OS processes should be addressable, but hosts should be addressable too. Addresses of OS processes has form (IP address, port). Such addresses are even compatible with DNS: you can point a domain name to an OS process with an SRV DNS record. – beroal Apr 26 '23 at 10:12

5 Answers5

24

An IP address targets a host on the network layer. Transport layer ports multiplex an L4 protocol within a host (to different processes/services). Both are different things on different layers.

Basically, if you'd repurpose IPv6 addresses (or bits) for host-level multiplexing you'd gain very little but you'd break logic compatibility between IPv4 and IPv6. A transport layer protocol works the same way on any IP version.

manish ma
  • 1,591
  • 9
  • 15
Zac67
  • 81,287
  • 3
  • 67
  • 131
  • 5
    With IPv6, it's very normal for a single host to have many addresses and create them on-the-fly. You would gain some protocol simplicity, as well as some privacy. – user253751 Sep 01 '22 at 00:41
  • 4
    It'd also make it very hard to support multiple protocols from a single domain name. For example, the host(s) at the IP(s) that www.example.com resolved to could support HTTP or HTTPS, but not both (at least without doing unpleasant things to the protocols). With ports, I can run HTTP, HTTPS, SMTP, POP, IMAP, IMAPS, SSH, etc services all under a single domain name if I want to. – Gordon Davisson Sep 01 '22 at 07:25
  • 1
    @GordonDavisson I think the OP referred to something in the line of using part of the IPv6 address for L4 multiplexing. Also, domain names don't necessarily relate to IP addresses - you can run thousands of WWW or SMTP domains behind a single IP address. – Zac67 Sep 01 '22 at 08:01
  • 3
    @GordonDavisson a separate issue really - SRV records solve this (if only they'd be enabled to all protocols) – user253751 Sep 01 '22 at 08:53
  • 3
    @Zac67 I think this is the closest answer, I disagree with the "gain nothing" but agree that what is gained is very small compared to the cost/effort associated with completely changing how IP works... – Josh Sep 02 '22 at 08:25
  • @Josh I think we can agree on "gain very little" - I've adapted the wording. – Zac67 Sep 02 '22 at 10:57
  • @Zac67 I suspect there's enough flexibility that OPs idea could actually be done today, if somebody wanted to write a new networking protocol. My linux PC already claims some 5-10 IPv6 address. It could probably claim 100s and route each one to an application, if somebody wanted to write the kernel modules. – mbrig Sep 03 '22 at 04:26
  • @mbrig I wasn't implying that it's not possible. But it would contradict clean layering and kill backward compatibility. – Zac67 Sep 03 '22 at 06:18
  • 1
    @GordonDavisson we should have forced adoption of SRV DNS records in conjunction with IPv6. Being unable to route protocols separately (without fancy routers) makes it more difficult to manage load balancing in large environments. – Martin Kealey Sep 03 '22 at 13:15
  • Future protocols might still decide to dispense with ports and use addresses instead. – user253751 Sep 03 '22 at 14:36
  • @GordonDavisson There's nothing stopping you from binding each service to a dedicated address, so you can route them individually. It's just that it's in addition to L4 ports, not instead of. – Zac67 Sep 04 '22 at 09:47
  • I mean what does that practically look like? How are you going to allocate for a single user all 65535 ports with this idea? One idea I have is to say - okay this is the base ipv6 address... the range is the base + 65535, so if you see any traffic within this range, send it to this user. Calculating that also just becomes a huge pain with the more users you add... and don't even bother with subnets... what happens if a user's ports falls within 2 subnets!? Sounds like a monstrosity, but maybe it isn't. Maybe there is a nice work around that I don't see. – Shmack Sep 06 '22 at 16:58
6

I think the OP is not so much saying that we should roll ports specifically into the routable address scheme of the internet, but instead why not give every application/process/thread its own unique, routable address?

It's definitely a valid question, and you're not the first person to wonder this - to quote John Day "Networking is IPC and ONLY IPC".

Currently, this kind of thing has to be handled at the application layer - if I'm visiting Facebook on my phone over cell signal and then my phone switches over to WiFi, technically my source IP address (and port) has changed completely from Facebook's perspective, and it's only the tokens passed by my browser that are accepted as being the same (application-level) session.

But why stop at doing away with ports? Consider the situation with phone numbers - a phone number is just a poor proxy for specifying the identity of the person you want to speak to. That's why phones have contact lists - phone numbers are just a leaky bit of implementation that we want to ignore as quickly as possible. It's why DNS was invented - the authors of the Internet protocols chose to implement a centralized/hierarchical naming authority system versus your phone's local contact list, but same idea.

What you will want to read about are alternative Internet protocol proposals like John Day's Recursive Internetwork Architecture (RINA), where he critiques several historically accumulated design flaws in TCP/IP and the rest of the Internet protocol stack and proposes RINA as a solution.

Specifically to your question, a couple of bullet points out of John Day's critiques are relevant:

  • Multihoming: the IP address and port number are too low-level to identify an application in two different networks. DNS doesn't solve this because hostnames must resolve to a single IP address and port number combination, making them aliases instead of identities. Neither does LISP, because i) it still uses the locator, which is an IP address, for routing, and ii) it is based on a false distinction, in that all entities in a scope are located by their identifiers to begin with;[3] in addition, it also introduces scalability problems of its own.[4]
  • Mobility: the IP address and port number are also too low-level to identify an application as it moves between networks, resulting in complications for mobile devices such as smartphones. Though a solution, Mobile IP in reality shifts the problem entirely to the Care-of address and introduces an IP tunnel, with attendant complexity.

Whether you agree with him or not (as far as I know this proposal doesn't have a ton of traction), the flaws he points to and solutions he proposes are quite thought provoking.

Blackhawk
  • 161
  • 2
  • "_the flaws he points to and solutions he proposes are quite thought provoking_" and extremely cost prohibitive, requiring many billions of dollars to replace existing infrastructure, and applications. Simply trying to replace IPv4 with IPv6 (going on almost 30 years) is a piece of cake compared to the thought provoking solutions. – Ron Maupin Sep 01 '22 at 22:14
  • 2
    @RonMaupin No doubt, but still worth thinking about - many existing net technologies are stuck in a suboptimal state because of adoption critical mass, and IPv6 is a stark example of how painful it is to change even when it's necessary. At least recognizing flaws in existing protocols allows us to reimagine the use of existing protocols, like REST reusing the verbs of http. – Blackhawk Sep 01 '22 at 23:33
  • 1
    @RonMaupin do you think it would be worth making that point explicitly in the answer for posterity? i.e. that proposing a replacement of the existing internet protocol suite is infeasible, but that reimagining or repurposing has found some success? – Blackhawk Sep 01 '22 at 23:42
5

Why do we need ports with IPv6?

As Zac67 already said, it was intended to make IPv6 as compatible to IPv4 as possible to ensure that existing programs need not to be changed too much.

Keep in mind, that in IPv4, the destination port of a TCP connection also specifies the type of higher-layer protocol:

80 for HTTP, 443 for HTTPS, 23 for Telnet and so on.

So we need the TCP port in IPv6 as indication of the higher-layer protocol type if we want to be compatible to IPv4.

Why not assign each application, tab, etc... its own public IPv6 address

I was already thinking about this: Doing this would allow implementing certain additional security and privacy features. So I can imagine that this will actually be done in the future.

And of course: We can get rid of URLs like https://example:8443/: Instead of using different ports (8443) on server side, we can simply use multiple IPv6 addresses.

However, it would still not allow us to get rid of the source port of a TCP connection:

I rembember some web-based application that requires two HTTP(S) connections to be established between the client and the server at the same time.

In this case, the server will surely check if both connections come from the same client (this means: same source IP address).

However, this means that both connections have the same two IP addresses and the same destination port (443 in the case of HTTPS). Therefore, they must have a different source port.

And if IPv6 should be compatible with IPv4, this web-based application must work the same way with IPv6 as it works with IPv4.

Martin Rosenau
  • 2,326
  • 6
  • 10
  • 2
    The predecessor of IP actually included the TCP function in the network protocol, but that proved to be a problem (for example, it was unusable for real-time protocols.)., so it was separated in IP to allow the use of other transport protocols. Unfortunately, we got stuck with only TCP and UDP because of NAPT. Many people would love to use SCTP or build a new transport protocol. You cannot use most routing protocols across NAPT, and have to create tunnels to get around that. IPv6 solves all that by restoring the IP end-to-end paradigm. – Ron Maupin Sep 01 '22 at 12:39
  • @RonMaupin Isn't UDP the same as IP with ports? So NAPT isn't a restriction. – beroal Apr 26 '23 at 10:06
  • 1
    @beroal What does "IP with ports" mean? An IP packet contains a field that specifies the type of data in the packet (UDP, TCP, GRE, ICMP ...). Because this field has a value in the range 0...255 and none of these values means "raw data", you cannot just send "raw data" over IP. (The closest you can do is specifying your own UDP-like protocol that uses 0 instead of 8 bytes UDP header.) On the other hand, UDP does not contain any information about which kind of data is sent, so you always send "raw data" over UDP. – Martin Rosenau Apr 26 '23 at 17:29
  • @beroal, IP, neither IPv4 nor IPv6, has any idea about ports. Ports are transport protocol addresses for _some_ transport protocols (not all transport protocols use ports). Also, while the port number range for transport protocols like TCP, UDP, SCTP, DCCP, etc. is the same (0 to 65535 because it is a 16-bit unsigned integer), the port numbers of one transport protocol are not the same as those of another, despite being the same number. For example, TCP port 12345 is not UDP port 12345, nor is it SCTP port 12345. – Ron Maupin Apr 26 '23 at 21:13
  • @beroal, NAPT must maintain a table for each protocol, which is why it is restricted to TCP, UDP, and ICMP. There is a table for TCP port translations, a table for UDP port translations, and a table for ICMP Query ID translations. Trying to add other protocols to NAPT translations would involve changing NAPT devices all over the world, and it would be even more resource intensive than NAPT already is, often requiring more RAM and/or a faster CPU, and NAPT may use dedicated hardware needing replacement for other protocols. The three protocols it does support are deemed "good enough" for now. – Ron Maupin Apr 26 '23 at 21:19
2

You need something to say "this bit of data coming in from the NIC needs to go to this process."

This is different than "which host/network does this data need to go".

IP addresses are processed by your router and potentially other carrier grade routers to determine where to move your data.

Those devices do not have the ability to, for example, reach into your PC and deposit the network data directly into the process's RAM, so they don't need to care which process on the destination wants it.

This is like adding "Give this to your cat at 2pm" as part of the address of a package you want delivered. The people processing the package don't really need to know that, they just need the address, so it's better if you put those instructions inside the package.

LawrenceC
  • 161
  • 3
  • 2
    My home router doesn't know how to get to google's webserver either, it doesn't reach out and deliver my packets directly. It passes it along a chain of things that look through their routing tables, until it eventually gets to something that does know where to deliver it. An OS could likewise have a "routing table" that turned address into applications, analogous to how it "routes" port numbers to applications – mbrig Sep 03 '22 at 04:03
  • An OS already does, it's called the TCP/IP stack running on that system. If your system has 1 NIC, and you have multiple processes that want to receive traffic via that NIC at the same time, what is the benefit to external routing hardware to know anything beyond the address of the NIC? – LawrenceC Sep 06 '22 at 14:06
0

Frame Challenge: Once The ports are folded into IP addresses, you'll be burning IP addresses for a singular device, and run the risk of actually running out of IP addresses.

Currently in IPv4, the number of valid ports is 65,535 - but 0 - 1023 are restricted or reserved port numbers (Often reserved by specific company processes as well - for example, apparently Apple QuickTime, and Remote Desktop Protocol does.

Natural Address Translation takes advantage of the fact that, for most users, which unrestricted and unreserved port being used generally doesn't matter for the average use case, and doesn't need to be aligned between client and server, so we can re-map them. But what made it required to be a thing that we went with was that IP address blocks were bought by companies in large, "We'll never run out of numbers to assign!", well...numbers. Large enough to run out.

On top of this, once machines move around and switch ISPs, then they would run through more IP addresses, and their previous one would have to be expired when routing to them.

With a single IP address per machine, you can "keep" that old IP address assigned to that older device, even if it temporarily leaves where it was assigned the IP address from for a short time (More likely to be a mobile machine, or a laptop), and keeping those lower will help.

Granted, 2^128 is a lot of IP addresses, but ports will allow us to avoid running into a similar version of the problem with IPv4 thinking it had more than enough IP addresses for everyone and their dog.

Alexander The 1st
  • 101
  • 1
  • 1
    There are three port ranges. "_Port numbers are assigned in various ways, based on three ranges: System Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private Ports (49152-65535)"_ and "_System Ports are assigned by the "IETF Review" or "IESG Approval" procedures described in [RFC8126]. User Ports are assigned by IANA using the "IETF Review" process, the "IESG Approval" process, or the "Expert Review" process, as per [RFC6335]. Dynamic Ports are not assigned._" and "_Assigned ports both System and User ports SHOULD NOT be used without or prior to IANA registration._" – Ron Maupin Sep 02 '22 at 22:39
  • 1
    Also, the first and last port number in each of the three ranges is reserved and should not be used. `0`, `1023`, `1024`, `49151`, `49152`, and `65535`. – Ron Maupin Sep 02 '22 at 22:42
  • @RonMaupin: If I'm reading that correctly then, what you're saying is that depending on the use case, we may only have 16381 dynamically assignable ports, and slightly less than the full 65535 count considering the first and last ranged ports that are unused in all cases, including System and User ports? I'm not 100% sure how that specifically plays out, because as I recall, port 80 is intended for HTTP/HTTPS browser traffic, as I recall. – Alexander The 1st Sep 02 '22 at 22:54
  • 1
    IANA maintains the _[Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)_. Each port listed includes the transport protocol, and it is quite possible that the same port number has a different purpose for different transport protocols. – Ron Maupin Sep 02 '22 at 23:02
  • 1
    Port numbers are addresses for some transport protocols, and despite the same number range, each transport protocol port is only for that protocol. TCP port number 12345 goes to the TCP process, and UDP port 12345 goes to the UDP process, and each of those processes could have completely different applications using the same port number because the are not the same ports. – Ron Maupin Sep 02 '22 at 23:02
  • 1
    I don't think running out of addresses is a concern, no matter what you do with ports. IPv6 is *deliberately* wasteful with addresses. My home network is assigned a /64, and the recommendation is actually to go further, and give end consumers a /56 (they apparently backed away from /48). The 16 bits of ports could be absorbed without anyone noticing. – mbrig Sep 03 '22 at 04:11
  • @mbrig: Possibly, but my point is more that the guidance is being intentionally cautious because I'm pretty sure the same thing was said about IPv4 back in the day. – Alexander The 1st Sep 03 '22 at 04:21
  • 2
    @AlexanderThe1st maybe, but on the other hand, see the 4th to last paragraph of an old answer of Ron's [here](https://networkengineering.stackexchange.com/a/53937/41799). IPv6 is supposed be liberal with addresses, and its deliberately trying to break the v4 habits of "conservation"... – mbrig Sep 03 '22 at 04:29
  • Thanks for the answer, however, the space argument is the least convincing for me. If we will run out of space without ports, we will surely also run out of space with ports. The only way this argument makes sense is if the total number of addressable entities lies between 2^128 and 2^144 (IPv6 space * port space), and I see no reason this would be the case... – Josh Sep 03 '22 at 09:30
  • @Josh: Unlike IPv4, IPv6 has enough address space that we *don't* have to try to make sure it's densely populated. IPv6 is designed to have enough space that every subnet will have enough space for potential future growth, even if most others only have a few devices and leave a lot of addresses unused. So 2^128 hosts is not the intended goal. But still at least 2^56 (times average number of devices per ISP), so this isn't a strong argument against the point you're making; if every machine already has room to use 2^16 addresses, at least the way we currently deploy IPv6, not a problem. – Peter Cordes Sep 03 '22 at 12:04
  • @Josh, you simply cannot include the port number with the IP address because the port number is an address for _some_ transport protocols. Not all transport protocols use port numbers. and of those that do, the port number is specific to that transport protocol and no other. If you simply send something to
    +, which transport protocol do you mean (TCP, UDP, SCTP, etc.). What about ICMP, IGMP, OSPF, EIGRP, etc. That do not use or have any concept of port numbers? Why not go all the way and include the MAC address in your scheme? Not all data-link protocols use MAC addressing.
     – Ron Maupin Sep 03 '22 at 19:15