when i ask from DNS Server about somewhere.com it resolve 4 IP for me in this order:
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.4
and my question is what happen if first IP(192.168.1.1) doesn't work?
which service or protocol switch to next IP?
and what about other services like telnet,... (telnet somewhere.com 443)?
First, when the lookup is made, the returned list is not in any kind of order, it is somewhat random. This helps ensure one system is not overloaded.
What happens if the first address in list fails, will depend on how well the application is written.
What is supposed to happen, is that if the first IP address fails, then the application should then try the next and iterate though the list until the list is exhausted or a connection is made. You can see this with many pieces of software. However, many developers are lazy, and only try the first returned. I can think of quite a few applications where this happens.
It's not fun when you see applications request ANY expecting an IPv4 address and the returned list contains an IPv6 address, only for the software to barf.
Related
What I'm trying to do is get all the ip addresses in my network, and I thought, assuming I know the address of all subnets could use arp requests to achieve that if there was a way to forward these requests over different subnets.
For example , assume I had two hosts
192.168.0.2/24 and 192.168.1.2/24
connected via router using IP addresses 192.168.0.1/16 192.168.1.1/16.
I would like to send an arp request from 192.168.0.2/16 to 192.168.1.2/16.
I thought maybe if the arp request was encapsulated in layer 3 header containing 192.168.1.2/24, or 192.168.1.255/24 as the dsetination this will work.
If it is possible and you know a tool that does that I will be happy to know about this tool.
If it isn't, I would like to know what happens to a packet like the one I described above
I would like to know what happens to a packet like the one I described above
If you encapsulate some info into standard IP-packet, then, naturally, it will be routed to the IP-destination host. Yet if the remote host knew nothing about this non-standard packet, then nothing would happen.
If you really want to get something out of this, you need to have up and running some software server on that remote host, which is able to process your requests. That is, you need some Proxy ARP: either existing implementation, or made of your own.
If you don't have such "an agent" in the target subnetwork, then you're out of luck. Go with sequential IP-scanning until be banned by admin.
I was reading tod lammales CCNA study guide 6th edition and stumbled upon this,
One thing to remember is that if multiple hosts are communication to
the server using HTTP, they must all use a different source port
number.That is how the web server keep the data separated at the
transport layer. page 337
Can this be true ? Because i always thought Ip and port number makes a unique endpoint at TCP layer, but according to this even for incoming connections from different source IPs, source port must be different ! appreciate your ideas.
No it isn't true. But what you said isn't true either. TCP connections are identified by the tuple {local address, local port, remote address, remote port}, not by any one of those, or two. What you have quoted, if accurate, would be (a) complete nonsense and (b) entirely unimplementable. How are all those clients going to co-ordinate amongst themselves to always use different source ports?
I have 3 applications: a MasterServer, a Server and a Client.
The MasterServer is running on: 70.105.155.5:15555 (port forwarded with UPnP)
I create a server and let the MasterServer know I exist. The MasterServer keeps my public ip and port. The port that the MS gets is randomly assigned by my router (lets say: 70.105.155.5:16666). The server keeps messaging the MasterServer each 10sec to keep that same port open.
I open up the client, on which it asks the MasterServer for the public ip and port of a server. The MasterServer returns: 70.105.155.5:16666. I know 100% sure that the server's public port 16666 is still open because I can check that in my logs.
But all messages sent from Client => Server are never received. At the same time the Server is still getting messages from MasterServer through 16666.
So this is really puzzling. Am I forgetting something? Is my understanding of NAT punch flawed?
Thanks for any help!
There are multiple issues here, and it depends on the router's security configuration too, often in ways the user cannot control. The general excuse is that it's a security precaution, but really firewalling and NAT are two separate concerns. Anyway, most home users are stuck with whatever they've got. They do usually have the option to explicitly map a port, and UPnP can help you too if the router supports it.
But going back to NAT, to begin with you're likely to have a problem if your server and client are sitting behind the same NAT, which seems to be the case given the addresses you quoted above. Most NATs only rewrite incoming packets from the public interface - so packets that physically arrive on the private interface, even if they're addressed to the public IP, won't be forwarded. To support this configuration in the wild you need the devices to advertise their private addresses to the MasterServer, and detect when they want to talk to other devices behind the same NAT, and if so, use the private address rather than going through the NAT. This is flawed in many ways, especially with nested NATs, but I think it's the best you can do.
Beyond that, in the more common case where all the devices are behind different NATs, some routers will only allow incoming traffic on a forwarding port if it's from the place they originally sent the outgoing traffic to (which resulted in the port opening up in the first place). Some also require it to come from the same source port on the remote device.
The workaround is for the MasterServer to do a bit more work. The gist is that it should tell both peers to send a packet to each other; these may or may not get through, but simply sending the packet out through the Server's NAT to the Client's public IP address may be enough to get the Server's NAT to correctly forward later packets from the Client. And vice versa.
In practice it is even more complicated, because the Server's NAT may use a different port when talking to Client to what it used when talking to MasterServer. So while this may open up a port for the Client to talk back to the Server, but it might not be the one the Client is expecting to use. If the NAT behaves like this, then you need to look at how predictable its choice of port numbering is. Some just increase one by one (but bear in mind there may be other devices behind the same NAT causing the number to jump more than one step at a time). For these ones, the Client needs to spam a range of Server ports to try to figure out which one got opened up. Again the MasterServer is in the best position to coordinate this.
Others seem totally random in port allocations, and there's not much you can do with those. But it's only terminal if both ends are behind these random NATs. So long as one end is more amenable to being opened up, the random end won't matter.
Also note that some NATs use a different outgoing port for each port on the target - this also makes prediction a lot harder, even in the case that the ports are not randomly assigned. Again, so long as one end of the connection is flexible, you can tolerate these NATs but in a peer-to-peer context they will be a nightmare in the end because they just can't talk to each other.
Is 0.0.0.0 a valid IP address? I want my program to be able to store it as an indication that no address is in use, but this won't work if it's actually valid.
It is valid inasmuch as it contains four octets, each within the range 0 through 255 inclusive. However, it is not usable as a real IP address.
RFC1700 (a) states that 0.0.0.0/8 (0.<anything>.<anything>.<anything>) is reserved as a source address only. You can get into situation where it appears you have this address but that's normally because no address has been assigned to you (by DHCP, for example).
See also Wikipedia entry on IPv4.
(a) Although this RFC is now considered obsolete, it is still correct in terms of the given behaviour. Its replacement, https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml, still has the same text detailing use of the 0.0.0.0 address.
Lets look at the Question being asked here by the OP.
Is 0.0.0.0 a valid IP address?
Yes. This is technically a valid IP address, and the other answers describe many various uses of it (I am not going to repost wikipedia links here ... or maybe I am).
As such I believe paxdiablo's answer above is the most correct, but lets look at the context of your question as well.
I want my program to be able to store it as an indication that no address is in use, but this won't work if it's actually valid.
This entirely depends on your use case. Given that this is a programmers forum, lets consider that perspective.
If your software is storing actual internet addresses - server locations, visitors to your website, replication/mirror or backup sites, web service or database servers etc. - then this will be perfectly valid. No machine on the internet will ever have this address assigned, nor will it ever resolve to a valid connection.
If on the other hand you are writing firewall or router firmware, then this address does take on special meaning; default route, accept any IP source/destination, block all IP source/destination, fall-trough catch-all, etc. as outlined by everyone else. However, let me point out that if you are coding on this level you should have a good enough understanding of network protocols so as to not need to ask this question in the first place.
I am therefore going to assume that most people viewing this question fall into the first category, and suggest that this is a perfectly valid way of storing a null, empty or missing IP address, if there is some reason that an actual null value cannot be used. Even if you neglect validation checking and your software does try to connect to this IP address, it will simply not be able to make a connection.
The 0.0.0.0 is used to bind all IPv4 interfaces. So it's a special value just like 127.0.0.1.
Yes, it is an IP address but it is reserved.
0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network. Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network
It's reserved as the default route address.
It's common to see this via ipconfig when no address has been assigned to you.
for all intents and purposes, yes. Each of the four numbers separated by the period have a value ranging from 0-255, so 0.0.0.0 is technically valid.
I don't think that there would be anyone in the world who actually has that IP though.
EDIT: okay, it is reserved for the default route, but it is still valid.
You can use it in your application to represent that it does not have an IP address, Microsoft also uses 0.0.0.0 when the machine has no IP address.
the "Valid" scenarios talked about above are dependent on the specific scenarios where they have nothing to do with your application.
Doing a Network Whois query can also produce output that is quite helpful.
Example:
http://whois.arin.net/rest/nets;q=0.0.0.0?showDetails=true
Comment: The address 0.0.0.0 may only be used as the address of an outgoing packet when a computer is learning which IP address it should use. It is never used as a destination address. Addresses starting with "0." are sometimes used for broadcasts to directly connected devices.
As other answers have covered, 0.0.0.0 is a legal and valid for some purposes IP address.
If all values in a range are legal values, then any flag items you want to define must come from somewhere else. Otherwise you will overload a legal value with the meaning of a flag, and when using the overloaded value it won't be 100% possible to determine whether the legal value or the flag meaning was intended. This will lead to bugs which must be solved with a re-factor which can be an expensive endeavour.
Overloading legal values happens all the time, IP address and MAC addresses (yes, 00:00:00:00:00:00 is legal and allocated) are some of the most common victims.
Coincidentally, I am working on a system (not ethernet/IP based) now where the length of a frame is capped at about 40 bytes. Since a byte can represent lengths of 0 - 255 bytes, and the max length is 40 bytes, I can use some of the unused aka non-legal values (252 to 255) to represent flag items. These in-band flags are okay because there is no overloading.
of course it is.
it will not be valid for a single host on a network however. it is in the broadcast range for the local network. read here: https://www.rfc-editor.org/rfc/rfc1700
I'm working on a network client program that connects to public servers, specified by the user. If the user gives me a hostname to connect to that has both IPv4 and IPv6 addresses (commonly, a DNS name with both A and AAAA records), I'm not sure how I should decide which address I should connect to.
The problem is that it's quite common for machines to support both IPv4 and IPv6, but only to have global connectivity over IPv4. The most common case of this is when only IPv6 link-local addresses are configured. At the moment the best alternatives I can come up with are:
Try the IPv6 address(es) first - if the connection fails, try the IPv4 address(es); or
Just let the user specify it as a config setting ("prefer_ipv6" versus "prefer_ipv4").
The problem I can see with option 1 is that the connection might not fail straight away - it might take quite a while to time out.
Please do try IPv6. In the significant majority of installations, trying to create an IPv6 connection will fail right away if it can't succeed for some reason:
if the system doesn't support IPv6 sockets, creating the socket will fail
if the system does support IPv6, and has link-local addresses configured, there won't be any routing table entry for the global IPv6 addresses. Again, the local kernel will report failure without sending any packets.
if the system does have a global IP address, but some link necessary for routing is missing, the source should be getting an ICMPv6 error message, indicating that the destination cannot be reached; likewise if the destination has an IPv6 address, but the service isn't listening on it.
There are of course cases where things can break, e.g. if a global (or tunnel) address is configured, and something falsely filters out ICMPv6 error messages. You shouldn't worry about this case - it may be just as well that IPv4 connectivity is somehow broken.
Of course, it's debatable whether you really need to try the IPv6 addresses first - you might just as well try them second. In general, you should try addresses in the order in which they are returned from getaddrinfo. Today, systems support configuration options that let administators decide in what order addresses should be returned from getaddrinfo.
Subsequent to the question being asked the IETF has proposed an answer to this question with RFC6555, a.k.a. Happy Eyeballs.
The pertinent point being the client and server may both have IPv4 and IPv6 but a hop in between may not so it is impossible to reliably predict which path will work.
You should let the system-wide configuration decide thanks to getaddrinfo(). Just like Java does. Asking every single application to try to cater for every single possible IPv6 (mis)configuration is really not scalable! In case of a misconfiguration it is much more intuitive to the user if all or none applications break.
On the other hand you want to try to log annoying delays and time-outs profusely, so users can quickly identify what to blame. Just like every other delays ideally, including (very common) DNS time-outs.
This talk has the solution. To summarize;
Sometimes there are problems with either DNS lookups or the subsequent connection to the resolved address
You don't want to wait for connecting to an IPv6 address to timeout before connecting to the IPv4 address, or vice versa
You don't want to wait for a lookup for an AAAA record to timeout before looking for an A record or vice versa
You don't want to stall while waiting for both AAAA and A records before attempting to connect with whichever record you get back first.
The solution is to lookup AAAA and A records simultaneously and independently, and to connect independently to the resolved addresses. Use whatever connection succeeds first.
The easiest way to do this is to allow the networking API do it for you using connect-by-name networking APIs. For example, in Java:
InetSocketAddress socketAddress = new InetSocketAddress("www.example.com", 80);
SocketChannel channel = SocketChannel.open(socketAddress);
channel.write(buffer);
The slide notes say at this point:
Here we make an opaque object called an InetSocketAddress from a host
and port, and then when we open that SocketChannel, that can complete
under the covers, doing whatever is necessary, without the
application ever seeing an IP address.
Windows also has connect-by-name APIs. I don’t have code fragments for
those here.
Now, I’m not saying that all implementations of these APIs necessarily
do the right thing today, but if applications are using these APIs,
then the implementations can be improved over time.
The di!erence with getaddrinfo() and similar APIs is that they
fundamentally can’t be improved over time. The API definition is that
they return you a full list of addresses, so they have to wait until
they have that full list to give you. There’s no way getaddrinfo can
return you a partial list and then later give you some more.
Some ideas:
Allow the user to specify the preference on a per-site basis.
Try IPv4 first.
Attempt IPv6 in parallel upon the first connection.
On subsequent connections, use IPv6 if the connection was successful previously.
I say to try IPv4 first because that is the protocol which is better established and tested.