I have been trying to get the Odigo ( https://www.odigo.com/ ) IP range in order to whitelist their IPs to receive unified ticket reports using SFTP.
We've been asking them since two months, but they were unable to answer.
Does anyone have this info?
We are also considering spinning up a FTP server with no IP whitelisting, just to check from what IP the report they send comes from. But we are afraid this IP might change, so we probably need a range.
Thank you !
I'm developing on linux router to assign global IP for node linked. The node I am testing on is a Windows PC.
I managed to assign global IP by sending Router Advertisement as per rfc4861.
+---------+---------------+----------+
07:14:07,632,019 ETHER
|0 |33|33|00|00|00|01|ce|74|19|9a|07|a2|86|dd|60|00|00|00|00|38|3a|ff|fe|80|00|00|00|00|00|00|cc|74|19|ff|fe|94|01|9c|ff|02|00|00|00|00|00|00|00|00|00|00|00|00|00|01|86|00|a1|25|40|40|ff|ff|00|00|00|00|00|00|00|00|03|04|40|c0|ff|ff|ff|ff|ff|ff|ff|ff|00|00|00|00|fc|01|ab|ab|cd|cd|ef|e0|00|00|00|00|00|00|00|00|05|01|00|00|00|00|05|dc|
After sending this RA from router (link-local addr fe80::cc74:19ff:fe94:19c), the tested PC can be auto-configured with global addr fc01:abab:cdcd:efe0:e1fb:2297:51db:af84 and fc01:abab:cdcd:efe0:29e9:52fd:2527:dbca.
Above is background.
But how can I recycle(or flush) the global IP on the tested PC? I have tried sending RA with (M=0,O=0,Router Lifetime=0), to my understanding to rfc4861, but this doesn't work. After that still I can see the global IP assigned, checking by cmd ipconfig.
RFC4862 could answer this question:
A RA with short "preferred lifetime" (like 1s) could deprecate the old IPv6 address, but which still may count as valid address. Back to current question, the address is not easy to be flushed by short "valid lifetime" because the consideration of avoiding DOS attack.
If someone who does need to flush the old IP, please refer to RFC4862 5.5.3:
If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated (e.g., via Secure Neighbor Discovery [RFC3971]). If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option.
Here are my questions followed by some more information.
Is an IP Address considered PII (Personally Identifiable Information)?
We need to filter our measurement protocol traffic via the user's IP address, is there a way to do this?
We are using the Measurement Protocol to send custom event data to our Google Analytics account. All of the data is being sent via PHP cURL from the server. We have 3 different views setup in our account, (View #1) a view that is completely unfiltered, (View #2) another view that is filtering out internal traffic via IP addresses, and a final third view (View #3) for testing purposes.
View #2's filters have stopped working since we moved to this method of sending the event data to Google. I imagine that is because the requests are now coming from the server's IP address instead of each specific user. I have been told about a field that you can use to send the user's IP address to Google, the field is labeled "uip" however Google anonymizes this data and does seem to use it for filtering the views (what would the purpose of this field be then?).
I have a custom dimension setup in which I am sending a hashed IP address (as I am not sure if an IP is considered PII) I am then filtering the reports on those specific hashes ... however this leaves me unable to filter out IP ranges ... certain bot traffic can originate from different ranges of IP addresses and I would be unable to filter them from the reports.
I have been scouring the internet to try to determine whether or not it is a privacy concern for me to simply store the user IP (unhashed) in a custom dimension and setup our filtering rules based on that. This would allow me to create regex that filters out entire ranges of IP's. Most of the articles that say an IP is PII refer to Google's Universal Analytics Guidelines: https://support.google.com/analytics/answer/2795983 - but I have been all over those articles and I cannot see Google specifically stating anywhere whether or not an IP is PII.
Thank you for your time.
For the question of hashed vs. unhashed values - Google has two different policies on the question of hashing (as I only found out when I was researching your question).
For the question if IPs are PIIs - Google at document on "Best practices to avoid sendig PII":
https://support.google.com/analytics/answer/6366371?hl=en&ref_topic=2919631
which does not mention IP addresses. However Google does take some trouble to protect IP addresses (e.g. automatically anonymizing, not exposing them in the interface) so I'd suggest (based on gut feeling, not anything binding) that you do the same and at least hash them with a salted hash 8and filter by the hash).
Also part from the Google TOS there are national laws to consider (don't know where you are doing business, I live in Germany and here IP addresses are definitively PII. I think this is true for the rest of the EU as well).
My question stems from this process: Assume an application has a host or address field and would like to connect to some service at that address. Many applications will look at that address and guess if it is an ip address or a host name. This application may use a function like inet_pton() to do this checking. If the address does look like an ip address, the application would not perform a DNS lookup and use that ip address directly.
Now, I am not suggesting this is a good idea but what if some one defined a dns name that looked like 1.2.3.4. That looks like an ip address so the application above would use that as and ip address and not as a DNS name.
From observation, it seems most applications behave as described in the first paragraph. Which seems beneficial for a few reasons to me. Is there any documentation that states that DNS names that look like IP addresses should not be used. Or any documentation that says that even if some one defined a DNS name to look like an IP address it is OK to not honor it as such.
Others have answered already but I'll add and consolidate.
Relevant RFCs:
https://www.rfc-editor.org/rfc/rfc952 (Original)
https://www.rfc-editor.org/rfc/rfc1123 (Revised)
https://www.rfc-editor.org/rfc/rfc2606 (Extra)
Originally, a hostname could not begin with a number, to disambiguate between hostnames and IP addresses. In the revision, that was changed, and hostnames can begin with a number. Thus, domain names like 127.0.0.1.com are legal. TLDs cannot begin with a number (TLD stands for top level domain, of which .com, .net, .org, country codes, and others are members). Names must contain at least one character, must begin and end with alphanumeric characters, and may freely be up to 64 characters long (though the standard supports longer hostnames, systems are not required to support names longer than 64 characters).
Additionally, as described in the final RFC, some SLDs and TLDs are reserved and cannot be registered.
The relevant specification to look at is Section 2.1 of RFC 1123:
If a dotted-decimal number can be entered without such identifying delimiters, then a full syntactic check must be made, because a segment of a host domain name is now allowed to begin with a digit and could legally be entirely numeric (see Section 6.1.2.4). However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic.
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