ipv6 packet does not have any port field. ports are on the level of tcp and udp, and you don't have to use tcp or udp on top of ipv6. ipv4 packet does not have any port information as well.
tcp6 is a thing though, was created at the same time as ipv6, and it does have ports, along with udp6. But if you really want one ip per stream and just hardwire port 1 or something, it's not like IPv6 does anything to stand in the way of that. Mght have performance issues on some OS's binding thousands of IPs to one interface, but that's on them to fix. Bigger lift would be the APIs that would need to change to manage whole prefixes at a time instead of single IPs.
Yes, that's why I said I know it was mixing of layers.
However ports are a layer violation in a strict sense, introduced as a workaround because there was no easy way to just add thousands of new IPs to a single host back in the IPv4 days. No need to continue a workaround that causes grief on a daily basis.
What do you mean? You’ll still have to use TCP or UDP over IPv6, and both of those protocols use ports. Nothing is stopping you from creating a transport protocol that doesn’t use ports if you want to, but that has nothing to do with the network layer.
I mean that to connect to a service you wouldn't need to know the port, the IPv6 address would be enough.
This is why I consider ports a layer violation of sorts. You never talk to a machine with TCP/UDP, you talk to a service on a machine. And so as it is the full address to the service isn't just the layer 3 address.
As I mentioned this would be especially interesting when hosting multiple services, same or different, on the same machine since there would be no port conflict.
Yeah, but I mean you just have to have something on the transport layer, you can't just encapsulate application layer into network skipping network, that's not how the network stack works.
Perhaps it's because I'm tired but I can't make sense of your objection.
As I said you could implement it by having TCP/UDP as is, just with a fixed port number. This wouldn't be unlike the myriad of other conventions that litter IPv6, such as using /64 for a host or ULA's having a certain prefix.
Got it, makes sense. It just seems more like an architectural decision to me than something related to the network stack - that's why I got confused. You can come up with your own convention and use it within a local network. One of the downsides of this approach - it will clutter up the routing table, but that’s probably not a big deal.
I usually prefer to use some kind of demultiplexer, like a reverse proxy, to handle the conversions.
this is a nice idea, but
idk why, in macos if i do
`nc -l 127.0.0.1 gopher`
and then try to open url "http://127.0.0.1:gopher/" - safari does not open it, no requests visible in the `nc` output.
* URL rejected: Port number was not a decimal number between 0 and 65535
* Closing connection
curl: (3) URL rejected: Port number was not a decimal number between 0 and 65535
so the ports are named, it is nice, but in practice it does not make life easier.
This is not possible since it is ambiguous. It is impossible to parse “http://127.0.0.1:gopher/“ since that would be valid as either “scheme://user:host/“ or “scheme://host:portname/“.
I know you're trying to be funny but ... technically it's 100% clear: You should talk HTTP, because that's the URL scheme here. The port makes no difference. You just happened to use a port by name. For all we know I run my HTTP server on some NFS related port so all the script kiddies try all the wrong exploits on it or something ;)
i chose gopher port just as an example. try with any other service name mapped to a port number from /etc/services and the result will be the same. the OP's goal was to use many http/https services, so we are talking about many http(s) services.
i just wanted to make the point that even if you have service names in /etc/services, it is not possible to use that names easily to host/access http(s) services.
The names are the kind of servers that listen on those ports (by default) like ssh, telnet, http, and smtp. They are not subdomains or for URI parsing.
URI contains ":port" tho, but practically it is only digital number.
the OP made a tool which helps them to avoid using port numbers. people commented in a way that looked like laughing at him, like he reinvented the wheel, and talking about /etc/services. well ok, i decided to try using /etc/services for the purpose of using names instead of port numbers.
would it be possible to add "myapp 60001/tcp" to /etc/services and then work with "http://localhost:myapp"? NO! browsers do not translate these names into port numbers. netcat does. curl does not.
so probably the OP's solution is not that questionable and really solved their need? and "good old friend /etc/services" is not useful for this? i dont know what it is useful for as running services on non-standard ports actually helps with hiding from security/vuln scanners and is practiced widely.
Maybe the joke has gotten too far, but the point that most people have been trying to say is that the issue that the OP is trying to solve has been solved for years. It's called a reverse proxy. Doing the configuration automatically like OP does does not alter the fact that it is a reverse proxy. `/etc/services` serve a different purpose.
Also URL parsing is a completely different matter. Browsers are primarily an HTTP(s) client. If you do not mention the ":port", it will try to connect to 80 (HTTP) or HTTPS (443). Because that the default ports for a web server. Other services have different port. So if your URL has the ftp scheme, the default port would be 21.
Well, the entire context of this is https so anything else is immaterial. The only reason it would be gopher is if you didn't read the post or don't understand the basics of https.
if you configure sshd to listen on port 443, does it become an https server? i was just trying to demondtrate: pick any port from /etc/services and try to use the name instead of port number. no, it does not work well when trying to use for local-hosting http(s) services. so to address the irony and sarcasm of the messages i was replying to:
zdw: It's like someone should make a file... maybe in /etc ... and put short names for services in it... maybe it could be called /etc/services...
tolciho: And then they might code up some sort of service lookup tool thingy to use on the train wreck that is the modern web.
$ getent services gopher
gopher 70/tcp
Many clients also do not support getservent(3) or portmap or DNS SRV records or NIS or LDAP or ActiveDirectory so one might wonder why there are so many half-baked, failed, or overy complicated attempts at solving whatever the problem is here even before "AI has entered the chat".
i know, but the OP's goal was to host/access http(s) services with names and avoid port numbers, and gopher service name was chosen by me as an example. my point was that /etc/services cannot be used for the OP's need.
if you host an http(s) service on port 11111 you can reach it with url http://127.1:11111, but url http://127.1:vce/ would not work in most software.
Try http://127.0.0.1:hkp instead of http://127.0.0.1:11371 for an OpenPGP HTTP keyserver. HTTP will work, but using the service name won't. Does that make what they're trying to say clearer?
> it’s a pretty basic hex viewer that runs in your browser
excuse me? "basic" and "runs in your browser" together sound very contradictory to me. while doing things i actually feel (yes, emotionally) much better when there is no browser open on my machine, but only text editors, vcs gui and file managers, and terminals of course. and sometimes i reject an idea to start a browser just thinking how much ram it will take (ha, what a progress we have done - one github issue tab, with text only and no images, takes 180mb of ram).
please provide a proof. if this is the case, then telegram is not to be trusted. but it needs to be proven. otherwise a lot of people trust their business and personal data to telegram.
i guess the point of having a tag in the shape of a card is to prevent a thief from throwing the obvious airtag away, the card tag may look like an ordinary bank card and kept in the wallet longer
reply