Skip to content
This repository has been archived by the owner on Sep 17, 2021. It is now read-only.

Algorithm yields colliding IP addresses #6

Open
colindean opened this issue Feb 14, 2016 · 2 comments
Open

Algorithm yields colliding IP addresses #6

colindean opened this issue Feb 14, 2016 · 2 comments

Comments

@colindean
Copy link
Member

This is probably a known issue. Looks like the fourth octet isn't accounted for.

This is from the output of mm-commotion-mac2ip.tests:

DC:9F:DB:3F:14:BA resolved to 100.127.20.186
DC:9F:DB:7F:14:BA resolved to 100.127.20.186
DC:9F:DB:BF:14:BA resolved to 100.127.20.186
DC:9F:DB:FF:14:BA resolved to 100.127.20.186
DC:9F:DB:08:CE:C6 resolved to 100.72.206.198
DC:9F:DB:48:CE:C6 resolved to 100.72.206.198
DC:9F:DB:88:CE:C6 resolved to 100.72.206.198
DC:9F:DB:C8:CE:C6 resolved to 100.72.206.198
DC:9F:DB:3C:23:B6 resolved to 100.124.35.182
DC:9F:DB:7C:23:B6 resolved to 100.124.35.182
DC:9F:DB:BC:23:B6 resolved to 100.124.35.182
DC:9F:DB:FC:23:B6 resolved to 100.124.35.182
DC:9F:DB:1B:CD:02 resolved to 100.91.205.2
DC:9F:DB:5B:CD:02 resolved to 100.91.205.2
DC:9F:DB:9B:CD:02 resolved to 100.91.205.2
DC:9F:DB:DB:CD:02 resolved to 100.91.205.2
DC:9F:DB:34:C2:C3 resolved to 100.116.194.195
DC:9F:DB:74:C2:C3 resolved to 100.116.194.195
DC:9F:DB:B4:C2:C3 resolved to 100.116.194.195
DC:9F:DB:F4:C2:C3 resolved to 100.116.194.195
DC:9F:DB:35:AD:A3 resolved to 100.117.173.163
DC:9F:DB:75:AD:A3 resolved to 100.117.173.163
DC:9F:DB:B5:AD:A3 resolved to 100.117.173.163
DC:9F:DB:F5:AD:A3 resolved to 100.117.173.163

There are obviously a lot more of them. This is just a few at the beginning of the test.

@jasonkhanlar
Copy link
Member

As I began developing this, I have been trying to establish an understanding of what is expected. Initially following closely to information available at #3 including initial posts with inaccurate information, I eventually concluded or it was agreed upon that duplicated ip address should be calculated from mac addresses so that all possible mac addresses would fit into the limited ipv4 range. 256 * 256 * 256 mac address possibilities (for each of the valid first three octets) to fit into only 64 * 256 * 256 ipv4 address possibilities, for the moment each ipv4 address generated is duplicated 4 times.

Let me know if some other calculation is expected.

@Protagonistics
Copy link
Contributor

I'll reiterate for clarity.

We're converting mac addresses into the 100.6.0.0/10 subnet. This range begins with 100.64.0.0 and ends at 100.127.255.255.

In the example DC:9F:DB:F5:AD:A3, the first 3 mac numbers are ignored leaving us with F5:AD:A3.

Now, the last 2 mac numbers AD and A3 are valid in their full range. We can DIRECTLY convert them to their decimal value. So AD is 173 and A3 is 163. So we now know that our end IP address will be 100.?.173.163.

For the second octet we need to calculate the octet in modulo. When F5 is converted to decimal it is 245 which is out of the range of 64-127. That octet needs to be reliably converted in modulo to it's rightful octet which, according to the long list of IPs in #3 is 117 leaving us with a valid IP address of 100.117.173.163 as Colin correctly showed us earlier.

Questions?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants