The OpenBSD manual states:
For security reasons, OpenBSD does not route IPv4 traffic to an AF_INET6 socket, and does not support IPv4 mapped addresses, where IPv4 traffic is seen as if it comes from an IPv6 address like ::ffff:10.1.1.1. Where both IPv4 and IPv6 traffic need to be accepted, listen on two sockets.
However, there is no explanation concerning these "security reasons." What are they? I can't think of any security problems related to that mapping.
I don't know specifically what motivation OpenBSD used, but I know of at least one problem that can be a security concern, namely ACLs and specifically black lists.
Ponder that you have an incoming connection from 10.1.1.1. This address is blacklisted in your ACL, and thus you refuse the connection. But if you're using a mapped address, it will instead appear to come from ::ffff:10.1.1.1. Your blacklist might not be able to catch this and might let the connection through.
This can be solved with application logic, and since using a single socket might simplify the code, I personally believe OpenBSD's decision is unfortunate. It's possible to default v4mapped to off but allow it to be enabled via setsockopt.
They might have had more concerns though that I'm not aware of.
As far as I know the main reason is to keep the IPv4 and IPv6 stacks separate. It's the hacks necessary to handle packets coming in on one stack but being handled by the other that cause the security risks.
Related
Just as the title says,
Not all ISP in our country support IPv6 yet, some does, some doesnt,
I dont want to create a situation where players can only play our game only if
he/she has a certain "IPv6 enabled" ISP. That won't be great. The ISP I used support IPv6.
My server(pc) is set behind a series of NAT, (I dun know the architecture but port-forwarding from the router is not enough, it has its own "local" ipv4-address from its "parent"(I don't know the ip-address of the parent)). Also I have contacted them, to give me a public IPv4 but unfortunately, it didn't go well as planned.
At the start, I tried to use IPv4 address given by "whatismyip.com", but well it gives the IP address of my ISP, not my router or my PC.
And then, there is this, I can access the server via IPv6 connections. But can't via IPv4. so how can I establish the connection between the two? How can I solve it?
(Please feel free to ask about any more information that is needed, I just recently started to learn networking so they are lots of things i might be wrong about, sorry in advance)
Thanks in advance! UwU
What is the difference between a "tcp/socket" and "tcp/ip" connexion?
When you say that you use "tcp/ip", do you necessarily use a "tcp/socket"?
Thanks!
A socket is a general communication means provided by your
operating system.
There are many kinds of them, for very distinct purposes
(not only networking).
I guess that when you think about tcp/socket, you mean a
socket dedicated to the TCP protocol.
TCP/IP can be seen as two different things, depending on the context.
It can be the TCP/IP network stack as a whole: not only the TCP and IP
specific protocols but the set of protocols (and implementations) we
find around these.
Of course, the other way to see TCP/IP is to consider only the TCP
transport protocol relying on the IP network protocol.
The various operating systems implement many protocols
in the TCP/IP stack.
To use them, a programmer asks his/her operating system
a specific resource: a socket.
It's difficult to say more with few words.
Some books or online documentation could help go further.
I think you missing something in the question. Anyway in short...
TCP/IP is basically name given to protocol we (networking devices) follow it forms the fundamental of todays internet. It involves agreement between two devices how the want ro communicate eg. Which segment of a frame has what information as in the end its all just 10...
There are 5 layers (some argue 4) in this model one layer is Network Layer right at the middle of all and it generally uses IPv4.And just above this is our Transport Layer which may use TCP or UDP as protocol depending on service you want. So thats the summary of TCP/ IP as the most used set of protocols of all.
When connecting to a remote server your browser needs to know what kind of service he is about to get from that server eg. a video mail or file transfer or just a http page. Thats when a TCP/Socket comes into picture where there is a port no assigned for every service. Eg port 443 is for https and so on. All you need to do is open a socket connection over that port number on that machine
Remember if a particular port of a server is not in LISTEN mode you cannot connect to that application via that port
Eg. If a server serves its webpage it might not allow you to connect its port responsible for FTP.
Recently I was working with the Berkeley socket API for IPv6, and noticed that IPv6 addresses (sockaddr_in6) have a field called sin6_scope_id, which was not part of IPv4 addresses.
After searching around a bit, I’ve learned that scope_id is meant to identify the network interface, because multiple network interfaces can have the same link-local IPv6 address. This made sense, but then what I didn’t understand is how IPv4 handles this issue, if there’s no equivalent of scope ID there?
Is there a mechanism in the kernel that prevents multiple IPv4 interfaces from being assigned the same link-local address?
If that’s the case, then why was it necessary to invent scope ID for IPv6 instead of going with the same solution as IPv4?
Also, is the scope_id only used to distinguish between interfaces with identical link-local addresses, or are there other use cases too?
In short, no, there is no well-defined mechanism for handling link-local IPv4 addresses on hosts with multiple interfaces. There is nothing stopping the same link-local address being selected for two different interfaces (however if the two interfaces are on the same network link, then ARP-based conflict detection will cause at least one of them to be reassigned).
RFC 3927 section 3.2 covers the issues of "address ambiguity":
Given that the IP stack must have the outbound interface associated
with a packet that needs to be sent to a Link-Local destination
address, interface selection must occur. The outbound interface
cannot be derived from the packet's header parameters such as source
or destination address (e.g., by using the forwarding table lookup).
Therefore, outbound interface association must be done explicitly
through other means. The specification does not stipulate those
means.
And also in section 6.3:
Application software run on a multi-homed host that supports IPv4
Link-Local address configuration on more than one interface may fail.
This is because application software assumes that an IPv4 address is
unambiguous, that it can refer to only one host. IPv4 Link-Local
addresses are unique only on a single link. A host attached to
multiple links can easily encounter a situation where the same
address is present on more than one interface, or first on one
interface, later on another; in any case associated with more than
one host. Most existing software is not prepared for this ambiguity.
In the future, application programming interfaces could be developed
to prevent this problem.
This problem was solved in IPv6 by the introduction of a scope ID.
At present scope id is only used for link-local addressing.
I am using Objective-C and Java for this, but I think the question is language-neutral.
I have an iOS client that talks to a Java server over TCP/IP. Right now I need to tell at least one of the parties the IP address of the other. Is there a standard way that I can "discover" IP addresses (from one side or the other)?
Also, how would switching to UDP affect the answer?
There are many protocols for discovering other devices/servers on the network. One of the most commonly used in the iOS realm is "Bonjour". Look at Apple's sample apps.
Is there a standard way that I can "discover" IP addresses (from one side or the other)?
Yes, it's called "port sniffing" and will certainly get you in trouble since it's a common kind of attack.
You simply try all IP addresses in a range. Many firewall products will consider this an "intrusion" attempt and log you with the intrusion detection software.
We almost never "discover" addresses.
That's what "domain names" are for.
Why can't the server have a well known DNS name?
Is it possible to multiplex sa ocket connection?
I need to establish multiple connections to yahoo messenger and i am looking for a way to do this efficiently without having to hold a socket open for each client connection.
so far i have to use one socket for each client and this does not scale well above 50,000 connections.
oh, my solution is for a TELCO, so i need to at least hit 250,000 to 500,000 connections
i'm planing to bind multiple IP addresses to a single NIC to beat the 65k port restriction per IP address.
Please i would any help, insight i can get.
**most of my other questions on this site have gone un-answered :) **
Thanks
This is an interesting question about scaling in a serious situation.
You are essentially asking, "How do I establish N connections to an internet service, where N is >= 250,000".
The only way to do this effectively and efficiently is to cluster. You cannot do this on a single host, so you will need to be able to fragment and partition your client base into a number of different servers, so that each is only handling a subset.
The idea would be for a single server to hold open as few connections as possible (spreading out the connectivity evenly) while holding enough connections to make whatever service you're hosting viable by keeping inter-server communication to a minimum level. This will mean that any two connections that are related (such as two accounts that talk to each other a lot) will have to be on the same host.
You will need servers and network infrastructure that can handle this. You will need a subnet of ip addresses, each server will have to have stateless communication with the internet (i.e. your router will not be doing any NAT in order to not have to track 250,000+ connections).
You will have to talk to AOL. There is no way that AOL will be able to handle this level of connectivity without considering cutting your connection off. Any service of this scale would have to be negotiated with AOL so both you and they would be able to handle the connectivity.
There are i/o multiplexing technologies that you should investigate. Kqueue and epoll come to mind.
In order to write this massively concurrent and teleco grade solution, I would recommend investigating erlang. Erlang is designed for situations such as these (multi-server, massively-multi-client, massively-multithreaded telecommunications grade software). It is currently used for running Ericsson telephone exchanges.
While you can listen on a socket for multiple incoming connection requests, when the connection is established, it connects a unique port on the server to a unique port on the client. In order to multiplex a connection, you need to control both ends of the pipe and have a protocol that allows you to switch contexts from one virtual connection to another or use a stateless protocol that doesn't care about the client's identity. In the former case you'd need to implement it in the application layer so that you could reuse existing connections. In the latter case you could get by using a proxy that keeps track of which server response goes to which client. Since you're connecting to Yahoo Messenger, I don't think you'll be able to do this since it requires an authenticated connection and it assumes that each connection corresponds to a single user.
You can only multiplex multiple connections over a single socket if the other end supports such an operation.
In other words it's a function protocol - sockets don't have any native support for it.
I doubt yahoo messenger protocol has any support for it.
An alternative (to multiple IPs on a single NIC) is to design your own multiplexing protocol and have satellite servers that convert from the multiplex protocol to the yahoo protocol.
I'll trow in another approach you could consider (depending on how desperate you are).
Note that operating system TCP/IP implementations need to be general purpose, but you are only interested in a very specific use-case. So it might make sense to implement a cut-down version of TCP/IP (which only handles your use-case, but does that very well) in your application code.
For example, if you are using Linux, you could route a couple of IP addresses to a tun interface and have your application handle the IP packets for that tun interface. That way you can implement TCP/IP (optimised for your use-case) entirely in your application and avoid any operating system restriction on the number of open connections.
Of course, it's quite a bit of work doing the TCP/IP yourself, but it really depends on how desperate you are - i.e. how much hardware can you afford to throw at the problem.
500,000 arbitrary yahoo messenger connections - is your telco doing this on behalf of Yahoo? It seems like whatever solution has been in place for many years now should be scalable with the help of Moore's Law - and as far as I know all the IM clients have been pretty effective for a long time, and there's no pressing increase in demand that I can think of.
Why isn't this a reasonable problem to address with hardware plus traditional solutions?