blocks|key|1340988|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<blockquote>
<ol>
<li>MAC addresses are assigned by manufacturers. Do manufacturers also
assign EUI-64 addresses nowadays?</li>
</ol>
</blockquote>
The IEEE protocols use MAC addressing. Some of the IEEE protocols use 48-bit MAC addresses (MAC-48 or EUI-48), and some use 64-bit MAC addresses (EUI-64).
<blockquote>
<ol start="2">
<li>If answer to 1 is no, then is EUI-64 just logical and always
produced from 48 bit MAC address?</li>
</ol>
</blockquote>
The answer to 1 is actually, yes, for some protocols.
<blockquote>
<ol start="3">
<li>However answer to first doubt shouldnt be no, because otherwise it
would have made no sense to give first mapping as given by first
diagram</li>
</ol>
</blockquote>
You are confusing some things, and that book is out of date. The original IPv6 SLAAC used MAC addressing, or another unique host identifier, to create a 64-bit IPv6 IID, known as a Modified EUI-64 Format Interface Identifier. Most OSes do not do this anymore, but use random addressing with privacy extensions. Most IPv6 networks will be <code>/64</code>, meaning the IID will be 64 bits, and most IEEE protocols use 48-bit MAC addresses, so a standard method to convert a 48-bit MAC address to a 64-bit IID was needed for the original SLAAC.
The specification for creating Modified EUI-64 Format Interface Identifiers is detailed in <a href="https://www.rfc-editor.org/rfc/rfc4291#page-20" rel="nofollow noreferrer">RFC 4291, IP Version 6 Addressing Architecture, Appendix A: Creating Modified EUI-64 Format Interface Identifiers</a>. Notice that it covers both 48-bit and 64-bit MAC addresses, as well as other protocols that may not use MAC addressing:
<blockquote>
Appendix A: Creating Modified EUI-64 Format Interface Identifiers
Depending on the characteristics of a specific link or node, there are
a number of approaches for creating Modified EUI-64 format interface
identifiers. This appendix describes some of these approaches.
Links or Nodes with IEEE EUI-64 Identifiers
The only change needed to transform an IEEE EUI-64 identifier to an
interface identifier is to invert the &quot;u&quot; (universal/local) bit. An
example is a globally unique IEEE EUI-64 identifier of the form:
<pre><code>|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
</code></pre>
where &quot;c&quot; is the bits of the assigned company_id, &quot;0&quot; is the value of
the universal/local bit to indicate universal scope, &quot;g&quot; is
individual/group bit, and &quot;m&quot; is the bits of the manufacturer-
selected extension identifier. The IPv6 interface identifier would be
of the form:
<pre><code>|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
</code></pre>
The only change is inverting the value of the universal/local bit.
Links or Nodes with IEEE 802 48-bit MACs
[EUI64] defines a method to create an IEEE EUI-64 identifier from an
IEEE 48-bit MAC identifier. This is to insert two octets, with
hexadecimal values of 0xFF and 0xFE (see the Note at the end of
appendix), in the middle of the 48-bit MAC (between the company_id
and vendor-supplied id). An example is the 48-bit IEEE MAC with
Global scope:
<pre><code>|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+
</code></pre>
where &quot;c&quot; is the bits of the assigned company_id, &quot;0&quot; is the value of
the universal/local bit to indicate Global scope, &quot;g&quot; is
individual/group bit, and &quot;m&quot; is the bits of the manufacturer-
selected extension identifier. The interface identifier would be of
the form:
<pre><code>|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
</code></pre>
When IEEE 802 48-bit MAC addresses are available (on an interface or a
node), an implementation may use them to create interface identifiers
due to their availability and uniqueness properties.
Links with Other Kinds of Identifiers
There are a number of types of links that have link-layer interface
identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples
include LocalTalk and Arcnet. The method to create a Modified EUI-64
format identifier is to take the link identifier (e.g., the LocalTalk
8-bit node identifier) and zero fill it to the left. For example, a
LocalTalk 8-bit node identifier of hexadecimal value 0x4F results in
the following interface identifier:
<pre><code>|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+----------------+----------------+----------------+----------------+
</code></pre>
Note that this results in the universal/local bit set to &quot;0&quot; to
indicate local scope.
Links without Identifiers
There are a number of links that do not have any type of built-in
identifier. The most common of these are serial links and configured
tunnels. Interface identifiers that are unique within a subnet prefix
must be chosen.
When no built-in identifier is available on a link, the preferred
approach is to use a universal interface identifier from another
interface or one that is assigned to the node itself. When using this
approach, no other interface connecting the same node to the same
subnet prefix may use the same identifier.
If there is no universal interface identifier available for use on the
link, the implementation needs to create a local-scope interface
identifier. The only requirement is that it be unique within a subnet
prefix. There are many possible approaches to select a
subnet-prefix-unique interface identifier. These include the
following:
<pre><code> Manual Configuration 
 Node Serial Number 
 Other Node-Specific Token 
</code></pre>
The subnet-prefix-unique interface identifier should be generated in a
manner such that it does not change after a reboot of a node or if
interfaces are added or deleted from the node.
The selection of the appropriate algorithm is link and implementation
dependent. The details on forming interface identifiers are defined in
the appropriate &quot;IPv6 over &quot; specification. It is strongly
recommended that a collision detection algorithm be implemented as
part of any automatic algorithm.
Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be
inserted to create an IEEE EUI-64 identifier from an IEEE MAC- 48
identifier. The 0xFF and 0xFE values are used when starting with an
IEEE EUI-48 identifier. The incorrect value was used in earlier
versions of the specification due to a misunderstanding about the
differences between IEEE MAC-48 and EUI-48 identifiers.
This document purposely continues the use of 0xFF and 0xFE because it
meets the requirements for IPv6 interface identifiers (i.e., that they
must be unique on the link), IEEE EUI-48 and MAC-48 identifiers are
syntactically equivalent, and that it doesn't cause any problems in
practice.
</blockquote>

I was reading <a href="https://www.amazon.in/Data-Communications-Networking-Forouzan/dp/1259064751" rel="nofollow noreferrer">Forouzan's book</a>. It says following:

<blockquote>
 In IPv4 addressing, there is not a specific relation between the hostid (at the IP level) and link-layer address (at the data-link layer) because the link-layer address is normally much longer than the hostid. The IPv6 addressing allows this relationship. A link-layer address whose length is less than 64 bits can be embedded as the whole or part of the interface identifier, eliminating the mapping process. Two common linklayer addressing schemes can be considered for this purpose: the 64-bit extended unique identifier (EUI-64) defined by IEEE and the 48-bit link-layer address defined by Ethernet.
 
 Mapping EUI-64 
 To map a 64-bit physical address, the global/local bit of this format needs to be changed
 from 0 to 1 (local to global) to define an interface address, as shown in figure below:
 <a href="https://i.stack.imgur.com/jIEEV.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/jIEEV.png" alt="enter image description here"></a>
 
 Mapping Ethernet MAC Address 
 We need to change the local/global bit to 1 and insert an additional 16 bits. The additional
 16 bits are defined as 15 ones followed by one zero, or FFFE16.
 <a href="https://i.stack.imgur.com/QjTu8.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/QjTu8.png" alt="enter image description here"></a>
</blockquote>

I have some doubts:

<ol>
<li>MAC addresses are assigned by manufacturers. Do manufacturers also assign EUI-64 addresses nowadays? (I have this doubt because I never came across 64 bit physical address when I run <code>ipconfig -all</code> on PC. Did I miss it?)</li>
<li>If answer to 1 is no, then is EUI-64 just logical and always produced from 48 bit MAC address?</li>
<li>However answer to first doubt shouldnt be no, because otherwise it would have made no sense to give first mapping as given by first diagram.</li>
</ol>

Understanding EUI-64

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我在读福鲁赞的书。它说：在IPv4寻址中，连接层地址(在IP层)和链路层地址(在数据链路层)之间没有特定的关系，因为链路层地址通常比hostid长得多。IPv6地址允许这种关系。长度小于64位的链路层地址可以作为接口标识符的全部或部分嵌入，从而消除映射过程。为此，可以考虑两种常见的链路层寻址方案: IEEE定义的64位扩展唯一标识符(EUI-64)和以太网定义的48位链路层地址。要映射64位物理地

问理解EUI-64
EN

回答 1

Network Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问理解EUI-64EN