| 1 |
On Sat, Apr 21, 2012 at 11:16 AM, Stroller |
| 2 |
<stroller@××××××××××××××××××.uk> wrote: |
| 3 |
> |
| 4 |
> On 20 April 2012, at 18:21, Michael Mol wrote: |
| 5 |
>> … |
| 6 |
>> The inet6 address listed is |
| 7 |
>> |
| 8 |
>> fe80::be5f:f4ff:fe19:ad18 |
| 9 |
>> |
| 10 |
>> and your MAC is |
| 11 |
>> |
| 12 |
>> bc:5f:f4:19:ad:18 |
| 13 |
>> |
| 14 |
>> … |
| 15 |
>> |
| 16 |
>> be:5f:f4:19:ad:18 |
| 17 |
>> |
| 18 |
>> Which is your MAC. |
| 19 |
> |
| 20 |
> And then we just convert all incidences of the letter "e" to "c"? Is there some rule for this part? |
| 21 |
> |
| 22 |
> Perhaps I'm missing something here. |
| 23 |
|
| 24 |
Whups. Missed a spot. Thank you for so graciously pointing it out. |
| 25 |
|
| 26 |
So, on this laptop, here's the output of |
| 27 |
|
| 28 |
ip -6 addr show wlan0 |
| 29 |
|
| 30 |
6: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 |
| 31 |
link/ether 4c:ed:de:93:63:a0 brd ff:ff:ff:ff:ff:ff |
| 32 |
inet 192.168.83.146/27 brd 192.168.83.159 scope global wlan0 |
| 33 |
inet6 2001:470:c5b9:beef:4eed:deff:fe93:63a0/64 scope global dynamic |
| 34 |
valid_lft 86100sec preferred_lft 14100sec |
| 35 |
inet6 fe80::4eed:deff:fe93:63a0/64 scope link |
| 36 |
valid_lft forever preferred_lft forever |
| 37 |
|
| 38 |
So you can see my MAC is |
| 39 |
|
| 40 |
4c:ed:de:93:63:a0 |
| 41 |
|
| 42 |
and that I have a couple IPv6 addresses: |
| 43 |
|
| 44 |
fe80::4eed:deff:fe93:63a0 |
| 45 |
2001:470:c5b9:beef:4eed:deff:fe93:63a0 |
| 46 |
|
| 47 |
(They look like they have different lengths, but that's because the |
| 48 |
bits between fe80 and 4eed in the first one are all 0s, and so are |
| 49 |
collapsed by using ::) |
| 50 |
|
| 51 |
Take only the host portion of those addresses, and you get: |
| 52 |
|
| 53 |
4eed:deff:fe93:63a0 |
| 54 |
|
| 55 |
Remove the ff:fe from the middle, and redistribute the : delimiters to |
| 56 |
be every byte. |
| 57 |
|
| 58 |
43:ed:de::93:63:a0 |
| 59 |
|
| 60 |
Compare with my MAC: |
| 61 |
4c:ed:de:93:63:a0 |
| 62 |
|
| 63 |
And, yeah, that second digit is different again. That's because bit 7 |
| 64 |
is inverted. From RFC4291: |
| 65 |
|
| 66 |
Modified EUI-64 format interface identifiers are formed by inverting |
| 67 |
the "u" bit (universal/local bit in IEEE EUI-64 terminology) when |
| 68 |
forming the interface identifier from IEEE EUI-64 identifiers. In |
| 69 |
the resulting Modified EUI-64 format, the "u" bit is set to one (1) |
| 70 |
to indicate universal scope, and it is set to zero (0) to indicate |
| 71 |
local scope. The first three octets in binary of an IEEE EUI-64 |
| 72 |
identifier are as follows: |
| 73 |
|
| 74 |
0 0 0 1 1 2 |
| 75 |
|0 7 8 5 6 3| |
| 76 |
+----+----+----+----+----+----+ |
| 77 |
|cccc|ccug|cccc|cccc|cccc|cccc| |
| 78 |
+----+----+----+----+----+----+ |
| 79 |
|
| 80 |
written in Internet standard bit-order, where "u" is the |
| 81 |
universal/local bit, "g" is the individual/group bit, and "c" is the |
| 82 |
bits of the company_id. Appendix A, "Creating Modified EUI-64 Format |
| 83 |
Interface Identifiers", provides examples on the creation of Modified |
| 84 |
EUI-64 format-based interface identifiers. |
| 85 |
|
| 86 |
-- |
| 87 |
:wq |
Archives