为什么MAC地址的第一个八进制总是以二进制0结尾？

Question

我无意中发现了GitHub：https://github.com/adeverteuil/bash-ula-generator/blob/master/gen-ula.sh上的一段代码

# Generate an EUI64 from the MAC address
# as described in RFC 3513
# https://tools.ietf.org/html/rfc3513

first=`echo $mac | cut -c1-1`
second=`echo $mac | cut -c2-2`
macu=`echo $mac | cut -c3-6`
macl=`echo $mac | cut -c7-12`

# reversing u/l bit
case $second in
    [13579bdf])
        die "MAC-address \"${mac}\" is a group MAC address"
        ;;
    0)
        second_rev=2
        ;;
    2)
        second_rev=0
        ;;
    4)
        second_rev=6;
        ;;
    6)
        second_rev=4;
        ;;
    8)
        second_rev=a;
        ;;
    a)
        second_rev=8;
        ;;
    c)
        second_rev=e;
        ;;
    e)
        second_rev=c;
        ;;
    *)
        #impossible
        die "MAC address \"${mac}\" is registered to the IEEE database, "\
            "but the first octet (${first}${second}) is regarded as invalid. "\
            "(probably a bug in this script...)"
esac
eui64="${first}${second_rev}${macu}fffe${macl}"

TLDR:在逆转MAC OUI的第7位以创建EUI-64时，作者假定第8位总是二进制0。我立即检查了我的DHCP服务器上的100多个客户端，奇怪的是，在第一个八进制中没有一个以奇数结尾--它们总是类似于：

• dc:0c:5c:c9:53:36
• 40:9f:38:4b:69:08
• 18:d7:17:55:61:d1
• 34:c3:d2:70:ad:be
• (等等)

为什么总是以二进制0结尾？

Answer 1

Answer 2

首先，字节中最右边的位是第一位(而不是第8位)。在IT领域，第一个意思是0，而不是1。

现在，为了回答您的问题，mac地址的第一个字节的bit 0设置为0，用于接收NIC的单播和用于x组播接收NIC的1。换句话说，如果将位设置为0，则只有一个网卡将接收帧。

我立即在我的DHCP服务器上检查了100多个客户端，奇怪的是，在第一个八进制中没有一个以奇数结尾。

因为您的DHCP分配单播IPv4地址。

为什么总是以二进制0结尾？

事实并非如此。IPv4组播以太网范围为01:00:5E (224.0.0.0/4)。作为一个例子，OSPF使用的一些多播IP为224.0.0.5和224.0.0.6。相关的MAC是01-00-5E-00-00-05和01-00-5 e-00-00-06(注意，bit 0设置为1)。广播MAC FF:FF是另一个例子(请注意，大多数交换机都以相同的方式处理多播和广播帧)。