18

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
  • 283
  • 2
  • 6
  • 2
    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
  • 2
    @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
  • 3
    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
  • 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

25

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,760
  • 10
  • 16
Zac67
  • 90,111
  • 4
  • 75
  • 141
6

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,366
  • 8
  • 10
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
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
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