Running the stun command you can see that the description returned will indicate whether the port is a preserves port or a random port and that b0 will also indicate whether it is a preserves port or a random port.
And b3 is a description of whether the NAT type is symmetric or not symmetric?
As I understand it, all Cone type NATs are preserves port and all symmetric type ones are random port. Isn't this a duplicate description?
Can someone tell me what exactly is the difference between these two?
Symmetric type has many different algorithms as for realising, it depends on the kernel code, and it always shows like random or increase, you can see your OS' kernel code for deep understand.
Related
From my understanding, gRPC's protocol is http2 on top of TCP. Therefore, the maximum port that can be assigned is 65535, right? But it seems like if I set the server address to be something like "0.0.0.0:70040" which is out of the range, it is still working fine and the gRPC client is able to connect and communicate with the gRPC server. May I know what does this actually mean? Thank you.
builder.AddListeningPort("0.0.0.0:70040", grpc::InsecureServerCredentials());
I suspect the issue is that, the use of strings for the endpoint address limits the ability of the compiler to validate the unsigned 16-bit port address.
70040 by my early morning calculation is 10001000110011000 which is 17-bits. Ports must be 16-bits so one of these bits will be getting dropped, probably the most significant one (1).
Dropping that, yields 1000110011000 which corresponds to 4504 and it's likely the actual port that's being used.
You could try running the server on 70040 and connect to it from the the client using 4504.
I understand the end-to-end principle from the classic MIT paper, which states that executing a function between 2 remote nodes does not depend on the states of the in-between nodes.
But what is end-to-end encryption, end-to-end guarantees, end-to-end protocols, etc...? I couldn't find a precise definition of end-to-end. The term seems to be over-used.
In other words, when one describes a system property X as end-to-end, what does it mean? What is the opposite of end-to-end?
I don't think end-to-end is over-used. It merely says that the property holds from one end to the other. An "end" can be a node or a layer in the computing stack.
Consider three nodes: A, B and C. Node A wants to talk with C. B sits between A and C and forwards messages between them. B is, for example, a load balancer or a gateway.
Encryption is end-to-end if B cannot read and tamper messages sent from A to C. A concrete example is the following: A is your laptop, C is a remote machine in your network at home or work. B is a VPN gateway. The encryption here is not end-to-end because only the link between A and B is actually encrypted. An attacker sitting between B and C would be able to read the clear text. That might be fine in practice, but it is not end-to-end.
Another example. Say we don't care about encryption, but about reliable message transmission. You know that the network might corrupt bits of messages. Therefore, TCP and other protocols have a checksum field that is checked whenever messages are received. But the guarantees of these checksums is not necessarily end-to-end.
If A sends a message m to C relying on the TCP's checksum, a node B sitting in the middle could corrupt the message in an undetectable way. Abstracting most details, node B basically (1) receives m, (2) checks m's checksum, (3) finds the route to C and creates a new message with m's payload, (4) calculates a new checksum for m, and (5) sends m (with the new checksum) to C. Now, if node B corrupts the message after (2) but before step (4), the resulting message arriving on C is corrupted but that cannot be detected by looking at m's checksum! Therefore, such checksum is not end-to-end. Node B does not even have to be malicious. Such a corruption can be caused by hardware errors or more probably by bugs in node B. This has happened a couple of times in Amazon S3 service, for example: this case and this case and this case.
The solution is, obviously, to use application-level checksums, which are end-to-end. Here, a checksum of m's payload is appended to the payload before calculating the lower layer checksum.
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 need to programmatically determine the Router NAT type in my program. I did look at some of the STUN related answers and UPnP related information on SO. But did not get any definitive answers.
I looked at STUN RFC (rfc 5389) and it does not specify how to determine the NAT type. It does mention that it's previous version (RFC 3489) did provide the mechanism to determine NAT type. But also mentions that
Furthermore. classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
Given above, could you please advice on how I should go ahead with determination of router NAT type in my software. Further, now that RFC 3489 is obsoleted is there any other means?
Thanks in advance.
RFC 3489 was split into three different RFCs:
RFC 5389 - basic STUN protocol. Basic protocol of STUN binding request and binding response are largely the same as RFC 3489. The protocol header gets updated with a magic cookie occupying some of the transaction id field. Some STUN attributes get redefined. A few new ones added (specifically - XOR_MAPPED_ADDRESS). Some changes to how STUN auth is done. NAT behavior and classification discussion moved to RFC 5780.
RFC 5780 - "Nat Behavior discovery using STUN". The basic change to NAT type discovery was to distinguish NAT port mapping behavior separate from NAT filtering behavior. Whereas RFC 3489 would try to classify a NAT into one of several buckets ("cone", "port restricted", "symmetric") - which was just too generic to describe a NAT.
RFC 5769 - Just outlines what the hex dump of a few different STUN message types would look like.
Out of curiosity, I suppose knowing if your app is running behind a NAT is useful. But how would knowing the NAT's behavior influence your code path?
Shameless plug - Use my STUN Server code that is hosted on GitHub.
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