跳转到内容

IPv4：修订间差异

本页使用了标题或全文手工转换
维基百科，自由的百科全书
以互动方式浏览历史
←上一版本
删除的内容 添加的内容
可视化wikitext
Jerrywujunlin（留言 | 贡献）
56次编辑
小无编辑摘要
127.1..1 => 127.1.1
 
（未显示29个用户的44个中间版本）
第1行： 第1行：
{{NoteTA
{{NoteTA
|G1=IT
|G1=IT
|1=zh-hans:网络掩码; zh-hant:網路遮罩;
|1=zh-hans:掩码; zh-hant:遮罩;
|2=zh-hans:报文; zh-hant:封包;
|2=zh-hans:报文; zh-hant:封包;
|3=zh-hans:地址; zh-hant:位址;
|3=zh-hans:地址; zh-hant:位址;
|4=zh-hans:链路层; zh-hant:;}}
|4=zh-hans:链路层; zh-tw:連結層; zh-hk:鏈結層;
|5=zh-hans:网络; zh-tw:網路; zh-hk:網絡;}}
{{IPstack}}
{{IPstack}}
'''网际协议版本4'''（{{lang-en|'''I'''nternet '''P'''rotocol '''v'''ersion '''4'''}}，'''IPv4'''），又稱'''網際網路通訊協定第四版'''，是[[网际协议]]开发过程中的第四个修订版本，也是此协议第一个被广泛部署的版本。IPv4是互联网的核心，也是使用最广泛的网际协议版本，其後繼版本為[[IPv6]]，直到2011年，[[IANA]] IPv4位址完全用盡時，IPv6仍处在部署的初期。
'''网际协议版本4'''（{{lang-en|'''I'''nternet '''P'''rotocol '''v'''ersion '''4'''}}，缩写：'''IPv4'''，又稱'''網際網路通訊協定第四版'''）是[[网际协议]]开发过程中的第四个修订版本，也是此协议第一个被广泛部署和使用的版本。其後繼版本為[[IPv6]]，直到2011年，[[IANA]] IPv4位址完全用盡時，IPv6仍处在部署的初期。


IPv4在[[IETF]]于1981年9月发布的 RFC 791 中被描述，此RFC替换了于1980年1月发布的 RFC 760。
IPv4在[[IETF]]于1981年9月发布的 RFC 791 中被描述，此RFC替换了于1980年1月发布的 RFC 760。
第13行： 第14行：


== 地址 ==
== 地址 ==
IPv4使用32位（4字节）地址，因此[[地址空间]]中只有4,294,967,296（2<sup>32</sup>）个地址。不过，一些地址是为特殊用途所保留的，如[[专用网络]]（约1800万个地址）和[[多播]]地址（约2.7亿个地址），这减少了可在互联网上路由的地址数量。随着地址不断被分配给最终用户，[[IPv4地址枯竭问题]]也在随之产生。基于[[分类网络]]、[[无类别域间路由]]和[[网络地址转换]]的地址结构重构显著地减少了地址枯竭的速度。但在2011年2月3日，在最后5个地址块被分配给5个[[区域互联网注册管理机构]]之后，IANA的主要地址池已经用尽。
IPv4使用32位（4字节）地址，因此[[地址空间]]中只有約四十億（4,294,967,296，2<sup>32</sup>）个地址。不过，一些地址是为特殊用途所保留的，如[[专用网络]]（约1800万个地址）和[[多播]]地址（约2.7亿个地址），这减少了可在互联网上路由的地址数量。随着地址不断被分配给最终用户，[[IPv4地址枯竭问题]]也在随之产生。基于[[分类网络]]、[[无类别域间路由]]和[[网络地址转换]]的地址结构重构显著地减少了地址枯竭的速度。但在2011年2月3日，在最后5个地址块被分配给5个[[区域互联网注册管理机构]]之后，IANA的主要地址池已经用尽。


这些限制刺激了仍在开发早期的[[IPv6]]的部署，这也是唯一的长期解决方案。
这些限制刺激了仍在开发早期的作为目前唯一的长期解决方案的[[IPv6]]的部署。


=== 地址格式 ===
=== 地址格式 ===
IPv4地址可被写作任何表示一个32位整数值的形式，但为了方便人类阅读和分析<ref>{{cite web|last1=Onsem|first1=Willem Van|title=What is the purpose of dot-decimal notation?|url=http://stackoverflow.com/questions/28574048/what-is-the-purpose-of-dot-decimal-notation|website=Stack Overflow|accessdate=2016-10-06|archiveurl=https://web.archive.org/web/20150929035914/http://stackoverflow.com/questions/28574048/what-is-the-purpose-of-dot-decimal-notation|archivedate=2015-09-29|date=2015-02-18}}</ref>，它通常被写作[[点分十进制]]的形式，即四个字节被分开用[[十进制]]写出，中间用点分隔。
IPv4地址可被写作任何表示一个32位整数值的形式，但为了方便人类阅读和分析<ref>{{cite web|last1=Onsem|first1=Willem Van|title=What is the purpose of dot-decimal notation?|url=http://stackoverflow.com/questions/28574048/what-is-the-purpose-of-dot-decimal-notation|website=Stack Overflow|accessdate=2016-10-06|archiveurl=https://web.archive.org/web/20150929035914/http://stackoverflow.com/questions/28574048/what-is-the-purpose-of-dot-decimal-notation|archivedate=2015-09-29|date=2015-02-18|dead-url=no}}</ref>，它通常被写作[[点分十进制]]的形式，即四个字节被分开用[[十进制]]写出，中间用点分隔。


下表展示了几种不同的格式：
下表展示了几种不同的格式：
第50行： 第51行：
|}
|}


此外，在点分格式中，每个字节都可用任意的进制表达。如，<tt>192.0x00.0002.235</tt>是一种合法（但不常用）的表示。
此外，在点分格式中，每个字节都可用任意的进制表达。如，<tt>192.0x00.0002.235</tt>是一种合法（但不常用）的表示。点分格式也支持零省略的写法，例如<tt>127.1.1</tt>等同于<tt>127.1.0.1</tt>。

=== 常规分类 ===
{| class="wikitable mw-collapsible"
|+IPv4地址分类
!描述
!'''A类IPv4地址'''
!'''B类IPv4地址'''
!'''C类IPv4地址'''
!'''D类IPv4地址'''
!'''E类IPv4地址'''
|-
!'''网络标志位'''
|0
|10
|110
|1110
|1111
|-
!'''IP地址范围'''
|0.0.0.0~127.255.255.255
|128.0.0.0~191.255.255.255
|192.0.0.0~223.255.255.255
|224.0.0.0~239.255.255.255
|240.0.0.0~255.255.255.255
|-
!'''可用IP地址范围'''
|1.0.0.1~127.255.255.254
|128.0.0.1~191.255.255.254
|192.0.0.1~223.255.255.254
|
|
|-
!'''是否可以分配给主机使用'''
|是
|是
|是
|否
|否
|-
!'''网络数量（个）'''
|126 (2<sup>7</sup>-2)
|16384 (2<sup>14</sup>)
|2097152 (2<sup>21</sup>)
| ---
| ---
|-
!'''每个网络中可容纳主机数（个）'''
|16777214 (2<sup>24</sup>-2)
|65534 (2<sup>16</sup>-2)
|254 (2<sup>8</sup>-2)
| ---
| ---
|-
!'''适用范围'''
|大量主机的大型网络
|中等规模主机数的网络
|小型局域网
|留给Internet体系结构委员会(IAB)使用
[[多播|多播]]地址
|保留，仅作为搜索、Internet的实验和开发用
|-
!备注
|0.0.0.0为特殊地址，表示本网主机
|
|
|
|255.255.255.255为特殊地址，用于定向广播
|}
'''说明：D类与E类IPv4地址不区分网络地址与主机地址'''
{| class="wikitable"
|+特殊IP地址
!网络号
!主机号
!是否可以作为源地址
!是否可以作为目的地址
!备注/描述
|-
|全为0
|全为0
|允许
|禁止
|表示本网主机
|-
|全为0
|Host ID
|允许
|禁止
|表示特定主机
|-
|全为1
|全为1
|禁止
|允许
|定向广播地址
|-
|127
|任意合法的值
|允许
|允许
|迂回地址，用于本地测试
|-
|Network ID
|全为1
|禁止
|允许
|直接广播地址
|}


=== 分配 ===
=== 分配 ===
第56行： 第164行：


为了克服这个限制，在随后出现的[[分类网络]]中，地址的高位字节被重定义为网络的''类''(Class)。这个系统定义了五个类別：A、B、C、D和E。A、B和C类有不同的网络类別长度，剩余的部分被用来识别网络内的主机，这就意味着每个网络类別有着不同的给主机编址的能力。D类被用于[[多播]]地址，E类被留作将来使用。
为了克服这个限制，在随后出现的[[分类网络]]中，地址的高位字节被重定义为网络的''类''(Class)。这个系统定义了五个类別：A、B、C、D和E。A、B和C类有不同的网络类別长度，剩余的部分被用来识别网络内的主机，这就意味着每个网络类別有着不同的给主机编址的能力。D类被用于[[多播]]地址，E类被留作将来使用。
{| class="wikitable"

|+IPv4地址空间分类<ref>{{cite book|author=Wendell Odom|title=CCENT/CCNA ICND1 100-105 Official Cert Guide|url=https://archive.org/details/ccentccnaicnd1100000odom|publisher=Cisco Press|year=2016|pages=89页|isbn=978-1-58720-580-4}}</ref>
!前8位地址范围
!类
!路由形式
!占地址总空间的比例
|-
|0-127
|A
|[[单播]]
|1/2
|-
|128-191
|B
|[[单播]]
|1/4
|-
|192-223
|C
|[[单播]]
|1/8
|-
|224-239
|D
|[[多播]]
|1/16
|-
|240-255
|E
| -
|1/16
|}
1993年，[[无类别域间路由]]（CIDR）正式地取代了[[分类网络]]，后者也因此被称为“有类别”的。
1993年，[[无类别域间路由]]（CIDR）正式地取代了[[分类网络]]，后者也因此被称为“有类别”的。


第62行： 第201行：


=== 特殊用途的地址 ===
=== 特殊用途的地址 ===
{| class="wikitable"
{| class="wikitable sortable"
|+ 保留的地址块
|+ 保留的地址块
|-
|-
! [[CIDR]]地址块 || 描述 || 参考资料
! [[CIDR]]地址块 || 描述 || 参考资料
|-
|-
| 0.0.0.0/8 || 本网络（仅作为源地址时合法） || RFC 5735
| 0.0.0.0/8 || 本网络（仅作为源地址时合法） ||RFC 6890
|-
|-
| 10.0.0.0/8 || [[专用网络]] || RFC 1918
| 10.0.0.0/8 || [[专用网络]] || RFC 1918
|-
|-
| 100.64.0.0/10 || [[网络地址转换|地址共享]] || RFC 6598
| 100.64.0.0/10 || [[电信级NAT]] || RFC 6598
|-
|-
| 127.0.0.0/8 || [[Localhost|环回]] || RFC 5735
| 127.0.0.0/8 || [[Localhost|环回]] || RFC 5735
|-
|-
| 169.254.0.0/16 || [[Zeroconf|链路本地]] || RFC 3927
| 169.254.0.0/16 || [[链路本地地址|链路本地]] || RFC 3927
|-
|-
| 172.16.0.0/12 || [[专用网络]] || RFC 1918
| 172.16.0.0/12 || [[专用网络]] || RFC 1918
第97行： 第236行：
| 240.0.0.0/4 || 保留（之前的E类网络） || RFC 1700
| 240.0.0.0/4 || 保留（之前的E类网络） || RFC 1700
|-
|-
| 255.255.255.255 ||[[受限广播]]|| RFC 919
| 255.255.255.255/32 ||[[受限广播]]|| RFC 919
|}
|}


第117行： 第256行：


==== 虚拟专用网络 ====
==== 虚拟专用网络 ====
{{专业术语过多}}
{{Main|虚拟专用网}}

通常情况下，路由器根据数据报文的目的地址决定转发数据报文的下一跳地址。使用专用网络地址作为目的地址的数据包通常无法被公共路由器正确送达，因为公共路由器没有相应的路由信息，即无法得知如何才能转发到该IP地址。因此，这就需要通过一种方法，将指引数据报文转发的下一跳地址和真正要传输的目的地址分离开。于是就使用[[虚拟专用网]]，将IP报文封装在其他报文内，以便于通过公网上的公共路由器，达到能处理该封包内层数据的网络设备上解除封包后，该数据包可以被继续转发到目的地址。


将数据报文封装的过程中，可以将数据报文封装于IP报文中，也可以使用[[多协议标签交换]]协议等，通过其他协议引导数据报文转发。也可以封装同时加密数据，以保护数据内容。
以专用网络地址作目的地址的报文会被所有公共路由器忽略，因此在两个专用网络之间直接通信是不可能的。这需要使用IP隧道或专用网络。在网络上创建连接专用网络的隧道，在这种功能主机将封装在网路上可以接受的报文，可以被送达另一端在附加的协议层被去掉，报文也被送达其原定的目的地。此外封装过的报文也可能被加密以保证其在网络上传安全性。


=== 链路本地地址 ===
=== 链路本地地址 ===
{{Main|链路本地地址}}
{{Main|链路本地地址}}


RFC 5735中将地址块169.254.0.0/16保留为特殊用于链路本地地址，这些地址仅在链路上有效（如一段本地网络或一个端到端连接）。这些地址与专用网络地址一样不可路由，也不可作为公共网络上报文的源或目的地址。链路本地地址主要被用于地址自动配置：当主机不能从DHCP服务器处获得IP地址时，它会用这种方法生成一个。
RFC 5735<nowiki/>中将地址块169.254.0.0/16保留为特殊用于链路本地地址，这些地址仅在链路上有效（如一段本地网络或一个端到端连接）。这些地址与专用网络地址一样不可路由，也不可作为公共网络上报文的源或目的地址。链路本地地址主要被用于地址自动配置：当主机不能从DHCP服务器处获得IP地址时，它会用这种方法生成一个。


当这个地址块最初被保留时，地址自动配置尚没有一个标准。为了填补这个空白，[[微软]]创建了一种叫'''自动专用IP寻址'''（APIPA）的实现。因微软的市场影响力，APIPA已经被部署到了几百万机器上，也因此成为了事实上的工业标准。许多年后，[[IETF]]为此定义了一份正式的标准：RFC 3927，命名为“IPv4链路本地地址的动态配置”。
当这个地址块最初被保留时，地址自动配置尚没有一个标准。为了填补这个空白，[[微软]]创建了一种叫'''自动专用IP寻址'''（APIPA）的实现。因微软的市场影响力，APIPA已经被部署到了几百万机器上，也因此成为了事实上的工业标准。许多年后，[[IETF]]为此定义了一份正式的标准：RFC 3927，命名为“IPv4链路本地地址的动态配置”。


=== 环回地址(Loopback Address) ===
=== 环回地址（Loopback Address） ===
{{main|127.0.0.1}}
{{main|127.0.0.1}}
地址块127.0.0.0/8被保留作环回通信用。此范围中的地址绝不应出现在主机之外，发送至此地址的报文被作为同一虚拟网络设备上的入站报文（环回），主要用于检查TCP/IP协议栈是否正确运行和本机对本机的链接。
地址块127.0.0.0/8被保留作环回通信用。此范围中的地址绝不应出现在主机之外，发送至此地址的报文被作为同一虚拟网络设备上的入站报文（环回），主要用于检查TCP/IP协议栈是否正确运行和本机对本机的链接。
第164行： 第305行：
== 地址空間枯竭 ==
== 地址空間枯竭 ==
{{Main|IPv4地址枯竭}}
{{Main|IPv4地址枯竭}}
從20世紀80年代起，一個很明顯的問題是IPv4地址在以比設計時的預計更快的速度耗盡。<ref>{{cite web
從20世紀80年代起，一個很明顯的問題是IPv4地址在以比設計時的預計更快的速度耗盡。<ref>{{cite web
|title=World 'running out of Internet addresses'
|title=World 'running out of Internet addresses'
|url=http://technology.inquirer.net/infotech/infotech/view/20110121-315808/World-running-out-of-Internet-addresses
|url=http://technology.inquirer.net/infotech/infotech/view/20110121-315808/World-running-out-of-Internet-addresses
第171行： 第312行：
|archiveurl=https://web.archive.org/web/20110125195711/http://technology.inquirer.net/infotech/infotech/view/20110121-315808/World-running-out-of-Internet-addresses
|archiveurl=https://web.archive.org/web/20110125195711/http://technology.inquirer.net/infotech/infotech/view/20110121-315808/World-running-out-of-Internet-addresses
|archivedate=2011-01-25
|archivedate=2011-01-25
}}</ref> 這是創建[[分類網絡]]、[[無類別域間路由]]，和最終決定重新設計基於更長地址的互聯網協議（[[IPv6]]）的誘因。
}}</ref> 這是創建[[分類網絡]]、[[無類別域間路由]]，和最終決定重新設計基於更長地址的互聯網協議（[[IPv6]]）的誘因。


一些市場力量也加快了IPv4地址的耗盡，如：
一些市場力量也加快了IPv4地址的耗盡，如：
第186行： 第327行：
* 對互聯網初期分配的大地址塊的回收。
* 對互聯網初期分配的大地址塊的回收。


隨著[[IANA]]把最後5個地址塊分配給5個RIR，其主地址池在2011年2月3日耗盡。<ref>{{cite web|url=http://twitter.com/theiana/status/33170437856825344 |title=102, 103, 104, 179 and 185 have been allocated. No unicast IPv4 /8s remain unallocated. |author=IANA |date=2011-02-03 |accessdate=2011-02-03}}</ref> 許多地址分配和消耗的模型都預測第一個耗盡地址的RIR會在2011年的下半年出現。<ref>{{cite web|last=Huston |first=Geoff|title=IPv4 Address Report, daily generated|url=http://www.potaroo.net/tools/ipv4/index.html|accessdate=2011-01-31}}</ref>
隨著[[IANA]]把最後5個地址塊分配給5個RIR，其主地址池在2011年2月3日耗盡。<ref>{{cite web |url=http://twitter.com/theiana/status/33170437856825344 |title=102, 103, 104, 179 and 185 have been allocated. No unicast IPv4 /8s remain unallocated. |author=IANA |date=2011-02-03 |accessdate=2011-02-03 |archive-date=2011-02-07 |archive-url=https://web.archive.org/web/20110207013420/http://twitter.com/theiana/status/33170437856825344 |dead-url=no }}</ref> 許多地址分配和消耗的模型都預測第一個耗盡地址的RIR會在2011年的下半年出現。<ref>{{cite web|last=Huston|first=Geoff|title=IPv4 Address Report, daily generated|url=http://www.potaroo.net/tools/ipv4/index.html|accessdate=2011-01-31|archive-date=2009-04-01|archive-url=https://web.archive.org/web/20090401001902/http://www.potaroo.net/tools/ipv4/index.html|dead-url=no}}</ref>ARIN在2015年用完可用的供应，APNIC、LACNIC和AFIC根据其社区政策定量供应<ref>{{Cite web |title=IPv4 exhaustion {{!}} APNIC |url=https://www.apnic.net/manage-ip/ipv4-exhaustion/ |language=en-AU |access-date=2022-09-24 |archive-date=2022-11-30 |archive-url=https://web.archive.org/web/20221130213406/https://www.apnic.net/manage-ip/ipv4-exhaustion/ |dead-url=no }}</ref>。


廣泛被接受且已被標準化的解決方案是遷移至[[IPv6]]。IPv6的地址長度從IPv4的32位增長到了128位，以此提供了更好的路由聚合，也為最終用戶分配最小為2<sup>64</sup>個主機地址的地址塊成為可能。遷移過程正在進行，但其完成仍需要相當的時間。
廣泛被接受且已被標準化的解決方案是遷移至[[IPv6]]。IPv6的地址長度從IPv4的32位增長到了128位，以此提供了更好的路由聚合，也為最終用戶分配最小為2<sup>64</sup>個主機地址的地址塊成為可能。遷移過程正在進行，但其完成仍需要相當的時間。
第214行： 第355行：
| colspan="4"| 首部长度
| colspan="4"| 首部长度
| colspan="6"| 区分服务
| colspan="6"| 区分服务
| colspan="2"| [[显式拥塞通告]]
| colspan="2"| [[显式拥塞通知]]
| colspan="16"| 全长
| colspan="16"| 全长
|-
|-
第236行： 第377行：
| colspan="32" bgcolor="#FFBBBB"| 选项（如首部长度>5）
| colspan="32" bgcolor="#FFBBBB"| 选项（如首部长度>5）
|-
|-
! 160<br />or<br />192+
! 160<br />或<br />192+
| colspan="32"| &nbsp;<br />数据<br />&nbsp;
| colspan="32"| &nbsp;<br />数据<br />&nbsp;
|}
|}
第247行： 第388行：


; 区分服务（Differentiated Services，DS）
; 区分服务（Differentiated Services，DS）
: 占8bit，最初被定义为[[服务类型]]字段，实际上并未使用，但爱1998年IETF重定义为区分服务RFC 2474。只有在使用区分服务时，这个字段才起作用，在一般的情况  下都不使用这个字段。例如需要实时数据流的技术会应用这个字段，一个例子是[[VoIP]]。
: 占6bit，最初被定义为[[服务类型]]字段，实际上并未使用，但1998年被IETF重定义为区分服务RFC 2474。只有在使用区分服务时，这个字段才起作用，在一般的情况  下都不使用这个字段。例如需要实时数据流的技术会应用这个字段，一个例子是[[VoIP]]。


; 显式拥塞通告（ Explicit Congestion Notification，ECN）
; 显式拥塞通告（ Explicit Congestion Notification，ECN）
第253行： 第394行：


; 全长（Total Length）
; 全长（Total Length）
: 这个16位字段定义了报文总长，包含首部和数据，单位为字节。这个字段的最小值是20（20字节首部+0字节数据），最大值是2<sup>16</sup>-1=65,535。IP规定所有主机都必须支持最小576字节的报文，这是假定上层数据长度512字节，加上最长IP首部60字节，加上4字节富裕量，得出576字节，但大多数现代主机支持更大的报文。当下层的数据链路协议的[[最大传输单元]]（MTU）字段的值小于IP报文长度时间，报文就必须被分片，详细见下个标题。
: 这个16位字段定义了报文总长，包含首部和数据，单位为字节。这个字段的最小值是20（20字节首部+0字节数据），最大值是2<sup>16</sup>-1=65,535。IP规定所有主机都必须支持最小576字节的报文，这是假定上层数据长度512字节，加上最长IP首部60字节，加上4字节富裕量，得出576字节，但大多数现代主机支持更大的报文。当下层的数据链路协议的[[最大传输单元]]（MTU）字段的值小于IP报文长度时，报文就必须被分片，详细见下个标题。


; 标识符（Identification）
; 标识符（Identification）
第279行： 第420行：
: RFC 1071
: RFC 1071


; 源地址
; 源地址（Source address）
: 一个IPv4地址由四个字节共32位构成，此字段的值是将每个字节转为二进制并拼在一起所得到的32位值。
: 一个IPv4地址由四个字节共32位构成，此字段的值是将每个字节转为二进制并拼在一起所得到的32位值。
: 例如，10.9.8.7是00001010000010010000100000000111。
: 例如，10.9.8.7是00001010000010010000100000000111。
: 但请注意，因为NAT的存在，这个地址并不总是报文的''真实''发送端，因此发往此地址的报文会被送往NAT设备，并由它被翻译为真实的地址。
: 但请注意，因为NAT的存在，这个地址并不总是报文的''真实''发送端，因此发往此地址的报文会被送往NAT设备，并由它被翻译为真实的地址。


; 目的地址
; 目的地址（Destination address）
: 与源地址格式相同，但指出报文的接收端。
: 与源地址格式相同，但指出报文的接收端。


; 选项
; 选项（Options）
: 附加的首部字段可能跟在目的地址之后，但这并不被经常使用，从1到40个字节不等。请注意首部长度字段必须包括足够的32位字来放下所有的选项（包括任何必须的填充以使首部长度能够被32位整除）。当选项列表的结尾不是首部的结尾时，EOL（选项列表结束，0x00）选项被插入列表末尾。下表列出了可能
: 附加的首部字段可能跟在目的地址之后，但这并不被经常使用，从1到40个字节不等。请注意首部长度字段必须包括足够的32位字来放下所有的选项（包括任何必须的填充以使首部长度能够被32位整除）。当选项列表的结尾不是首部的结尾时，EOL（选项列表结束，0x00）选项被插入列表末尾。下表列出了可能
{| class="wikitable"
{| class="wikitable"
第331行： 第472行：


== 分片和组装 ==
== 分片和组装 ==
{{Main|IP分片}}互联网协议（IP）是整个互联网架构的基础，可以支持不同的物理层网络，即IP层独立于链路层传输技术。不同的链路层不仅在传输速度上有差异，还在帧结构和大小上有所不同，不同[[MTU]]参数描述了数据帧的大小。为了实现IP数据包能够使用不同的链路层技术，需要将IP数据包变成适合链路层的数据格式，IP报文的[[分片]]即是IP数据包为了满足链路层的数据大小而进行的分割。
{{Main|IP分片}}互联网协议（IP）是整个互联网架构的基础，可以支持不同的物理层网络，即IP层独立于链路层传输技术。不同的链路层不仅在传输速度上有差异，还在帧结构和大小上有所不同，不同[[最大传输单元|MTU]]参数描述了数据帧的大小。为了实现IP数据包能够使用不同的链路层技术，需要将IP数据包变成适合链路层的数据格式，IP报文的[[分片]]即是IP数据包为了满足链路层的数据大小而进行的分割。


在IPv6不要求路由器执行分片操作，而是将检测路径最大传输单元大小的任务交给了主机。
在IPv6不要求路由器执行分片操作，而是将检测路径最大传输单元大小的任务交给了主机。
第369行： 第510行：
|}
|}


现在，假设下一跳的MTU为1,500字节，那么每一个分片都会被再次分成两片(由于数据片段只有在目的主机才重新被组成数据报，因此再次分片是针对每个在网络中传输的数据帧)：
现在，假设下一跳的MTU为1,500字节，那么每一个分片都会被再次分成两片（由于数据片段只有在目的主机才重新被组成数据报，因此再次分片是针对每个在网络中传输的数据帧）：
{| class="wikitable" style="text-align:center"
{| class="wikitable" style="text-align:center"
|-
|-
第421行： 第562行：
* [[无类别域间路由]]
* [[无类别域间路由]]
* [[互联网号码分配局]]
* [[互联网号码分配局]]
* [[已分配的/8地址块列表]]
* [[已分配的/8 IPv4地址块列表]]
* [[区域互联网注册管理机构]]
* [[区域互联网注册管理机构]]
* [[各國IPv4位址分配列表]]
* [[各國IPv4位址分配列表]]
第431行： 第572行：
* RFC 791 — Internet Protocol{{en}}
* RFC 791 — Internet Protocol{{en}}
* RFC 3344 — IPv4 Mobility{{en}}
* RFC 3344 — IPv4 Mobility{{en}}
* [http://www.iana.org IANA] — 互联网地址分配局官方网站{{en}}
* [https://web.archive.org/web/20170920185613/http://www.iana.org/ IANA] — 互联网地址分配局官方网站{{en}}
* [http://www.networksorcery.com/enp/protocol/ip.htm IP Header Breakdown, including specific options]{{en}}
* [http://www.networksorcery.com/enp/protocol/ip.htm IP Header Breakdown, including specific options]{{Wayback|url=http://www.networksorcery.com/enp/protocol/ip.htm |date=20110514231900 }}{{en}}
* [https://web.archive.org/web/20100608114541/http://www.networkworld.com/news/2010/060710-tech-argument-ipv6-nat.html IPv6 vs. carrier-grade NAT/squeezing more out of IPv4]{{en}}
* [https://web.archive.org/web/20100608114541/http://www.networkworld.com/news/2010/060710-tech-argument-ipv6-nat.html IPv6 vs. carrier-grade NAT/squeezing more out of IPv4]{{en}}
* [http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml IPv4特殊用途地址] {{en}}
* [http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml IPv4特殊用途地址]{{Wayback|url=http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml |date=20161123090347 }} {{en}}


地址耗尽：
地址耗尽：
* [https://web.archive.org/web/20110109025511/http://www.ripe.net/rs/news/ipv4-ncc-20031030.html RIPE report on address consumption as of October 2003]
* [https://web.archive.org/web/20110109025511/http://www.ripe.net/rs/news/ipv4-ncc-20031030.html RIPE report on address consumption as of October 2003]
* [http://www.iana.org/assignments/ipv4-address-space Official current state of IPv4 /8 allocations, as maintained by IANA]
* [https://web.archive.org/web/20100430190605/http://www.iana.org/assignments/ipv4-address-space/ Official current state of IPv4 /8 allocations, as maintained by IANA]
* [http://www.potaroo.net/tools/ipv4/ Dynamically generated graphs of IPv4 address consumption with predictions of exhaustion dates — Geoff Huston]
* [http://www.potaroo.net/tools/ipv4/ Dynamically generated graphs of IPv4 address consumption with predictions of exhaustion dates — Geoff Huston]{{Wayback|url=http://www.potaroo.net/tools/ipv4/ |date=20110219132954 }}
* [https://web.archive.org/web/20110629000602/http://www.apnic.net/community/about-the-internet-community/internet-governance/articles/ip-addressing-in-china-2004 IP addressing in China and the myth of address shortage]
* [https://web.archive.org/web/20110629000602/http://www.apnic.net/community/about-the-internet-community/internet-governance/articles/ip-addressing-in-china-2004 IP addressing in China and the myth of address shortage]
* [http://www.inetcore.com/project/ipv4ec/index_en.html Countdown of remaining IPv4 available addresses] (estimated)
* [http://www.inetcore.com/project/ipv4ec/index_en.html Countdown of remaining IPv4 available addresses]{{Wayback|url=http://www.inetcore.com/project/ipv4ec/index_en.html |date=20110327122343 }} (estimated)


{{Authority control}}
{{Authority control}}

2024年11月27日 (三) 09:50的最新版本

網際網路协议套組
應用層
傳輸層
網路層
連結層

网际协议版本4（英語：Internet Protocol version 4，缩写：IPv4，又稱網際網路通訊協定第四版）是网际协议开发过程中的第四个修订版本，也是此协议第一个被广泛部署和使用的版本。其後繼版本為IPv6，直到2011年，IANA IPv4位址完全用盡時，IPv6仍处在部署的初期。

IPv4在IETF于1981年9月发布的 RFC 791 中被描述，此RFC替换了于1980年1月发布的 RFC 760。

IPv4是一种无连接的协议，操作在使用分组交换的链路层（如以太网）上。此协议会尽最大努力交付数据包，意即它不保证任何数据包均能送达目的地，也不保证所有数据包均按照正确的顺序无重复地到达。这些方面是由上层的传输协议（如传输控制协议）处理的。

地址

[编辑]

IPv4使用32位（4字节）地址，因此地址空间中只有約四十億（4,294,967,296，232）个地址。不过，一些地址是为特殊用途所保留的，如专用网络（约1800万个地址）和多播地址（约2.7亿个地址），这减少了可在互联网上路由的地址数量。随着地址不断被分配给最终用户，IPv4地址枯竭问题也在随之产生。基于分类网络、无类别域间路由和网络地址转换的地址结构重构显著地减少了地址枯竭的速度。但在2011年2月3日，在最后5个地址块被分配给5个区域互联网注册管理机构之后，IANA的主要地址池已经用尽。

这些限制刺激了仍在开发早期的作为目前唯一的长期解决方案的IPv6的部署。

地址格式

[编辑]

IPv4地址可被写作任何表示一个32位整数值的形式，但为了方便人类阅读和分析[1]，它通常被写作点分十进制的形式，即四个字节被分开用十进制写出，中间用点分隔。

下表展示了几种不同的格式：

格式 值 从点分十进制转换
点分十进制 192.0.2.235 不适用
点分十六进制[2] 0xC0.0x00.0x02.0xEB 每个字节被单独转换为十六进制
点分八进制[2] 0300.0000.0002.0353 每个字节被单独转换为八进制
十六进制 0xC00002EB 将点分十六进制连在一起
十进制 3221226219 用十进制写出的32位整数
八进制 030000001353 用八进制写出的32位整数

此外，在点分格式中，每个字节都可用任意的进制表达。如，192.0x00.0002.235是一种合法（但不常用）的表示。点分格式也支持零省略的写法，例如127.1.1等同于127.1.0.1。

常规分类

[编辑]
IPv4地址分类
描述 A类IPv4地址 B类IPv4地址 C类IPv4地址 D类IPv4地址 E类IPv4地址
网络标志位 0 10 110 1110 1111
IP地址范围 0.0.0.0~127.255.255.255 128.0.0.0~191.255.255.255 192.0.0.0~223.255.255.255 224.0.0.0~239.255.255.255 240.0.0.0~255.255.255.255
可用IP地址范围 1.0.0.1~127.255.255.254 128.0.0.1~191.255.255.254 192.0.0.1~223.255.255.254
是否可以分配给主机使用 是 是 是 否 否
网络数量（个） 126 (27-2) 16384 (214) 2097152 (221) --- ---
每个网络中可容纳主机数（个） 16777214 (224-2) 65534 (216-2) 254 (28-2) --- ---
适用范围 大量主机的大型网络 中等规模主机数的网络 小型局域网 留给Internet体系结构委员会(IAB)使用

多播地址

保留，仅作为搜索、Internet的实验和开发用
备注 0.0.0.0为特殊地址，表示本网主机 255.255.255.255为特殊地址，用于定向广播

说明：D类与E类IPv4地址不区分网络地址与主机地址

特殊IP地址
网络号 主机号 是否可以作为源地址 是否可以作为目的地址 备注/描述
全为0 全为0 允许 禁止 表示本网主机
全为0 Host ID 允许 禁止 表示特定主机
全为1 全为1 禁止 允许 定向广播地址
127 任意合法的值 允许 允许 迂回地址，用于本地测试
Network ID 全为1 禁止 允许 直接广播地址

分配

[编辑]

最初，一个IP地址被分成两部分：網路識別碼在地址的高位字节中，主機識別碼在剩下的部分中。

为了克服这个限制，在随后出现的分类网络中，地址的高位字节被重定义为网络的类(Class)。这个系统定义了五个类別：A、B、C、D和E。A、B和C类有不同的网络类別长度，剩余的部分被用来识别网络内的主机，这就意味着每个网络类別有着不同的给主机编址的能力。D类被用于多播地址，E类被留作将来使用。

IPv4地址空间分类[3]
前8位地址范围 类 路由形式 占地址总空间的比例
0-127 A 单播 1/2
128-191 B 单播 1/4
192-223 C 单播 1/8
224-239 D 多播 1/16
240-255 E - 1/16

1993年，无类别域间路由（CIDR）正式地取代了分类网络，后者也因此被称为“有类别”的。

CIDR被设计为可以重新划分地址空间，因此小的或大的地址块均可以分配给用户。CIDR创建的分层架构由互联网号码分配局（IANA）和区域互联网注册管理机构（RIR）进行管理，每个RIR均维护着一个公共的WHOIS数据库，以此提供IP地址分配的详情。

特殊用途的地址

[编辑]
保留的地址块
CIDR地址块 描述 参考资料
0.0.0.0/8 本网络（仅作为源地址时合法） RFC 6890
10.0.0.0/8 专用网络 RFC 1918
100.64.0.0/10 电信级NAT RFC 6598
127.0.0.0/8 环回 RFC 5735
169.254.0.0/16 链路本地 RFC 3927
172.16.0.0/12 专用网络 RFC 1918
192.0.0.0/24 保留（IANA） RFC 5735
192.0.2.0/24 TEST-NET-1，文档和示例 RFC 5735
192.88.99.0/24 6to4中继 RFC 3068
192.168.0.0/16 专用网络 RFC 1918
198.18.0.0/15 网络基准测试 RFC 2544
198.51.100.0/24 TEST-NET-2，文档和示例 RFC 5737
203.0.113.0/24 TEST-NET-3，文档和示例 RFC 5737
224.0.0.0/4 多播（之前的D类网络） RFC 3171
240.0.0.0/4 保留（之前的E类网络） RFC 1700
255.255.255.255/32 受限广播 RFC 919

专用网络

[编辑]
主条目：专用网络

在IPv4所允许的大约四十亿地址中，三个地址块被保留作专用网络。这些地址块在专用网络之外不可路由，专用网络之内的主机也不能直接与公共网络通信。但通过网络地址转换（NAT），使用这些地址的主机可以像拥有共有地址的主机在互联网上通信。

下表展示了三个被保留作专用网络的地址块（RFC 1918）：

名字 地址范围 地址数量 有类别的描述 最大的CIDR地址块
24位块 10.0.0.0–10.255.255.255 16,777,216 一个A类 10.0.0.0/8
20位块 172.16.0.0–172.31.255.255 1,048,576 连续的16个B类 172.16.0.0/12
16位块 192.168.0.0–192.168.255.255 65,536 连续的256个C类 192.168.0.0/16

虚拟专用网络

[编辑]
主条目：虚拟专用网

通常情况下，路由器根据数据报文的目的地址决定转发数据报文的下一跳地址。使用专用网络地址作为目的地址的数据包通常无法被公共路由器正确送达，因为公共路由器没有相应的路由信息，即无法得知如何才能转发到该IP地址。因此，这就需要通过一种方法，将指引数据报文转发的下一跳地址和真正要传输的目的地址分离开。于是就使用虚拟专用网，将IP报文封装在其他报文内，以便于通过公网上的公共路由器，达到能处理该封包内层数据的网络设备上解除封包后，该数据包可以被继续转发到目的地址。

将数据报文封装的过程中，可以将数据报文封装于IP报文中，也可以使用多协议标签交换协议等，通过其他协议引导数据报文转发。也可以封装同时加密数据，以保护数据内容。

链路本地地址

[编辑]
主条目：链路本地地址

RFC 5735中将地址块169.254.0.0/16保留为特殊用于链路本地地址，这些地址仅在链路上有效（如一段本地网络或一个端到端连接）。这些地址与专用网络地址一样不可路由，也不可作为公共网络上报文的源或目的地址。链路本地地址主要被用于地址自动配置：当主机不能从DHCP服务器处获得IP地址时，它会用这种方法生成一个。

当这个地址块最初被保留时，地址自动配置尚没有一个标准。为了填补这个空白，微软创建了一种叫自动专用IP寻址（APIPA）的实现。因微软的市场影响力，APIPA已经被部署到了几百万机器上，也因此成为了事实上的工业标准。许多年后，IETF为此定义了一份正式的标准：RFC 3927，命名为“IPv4链路本地地址的动态配置”。

环回地址（Loopback Address）

[编辑]
主条目：127.0.0.1

地址块127.0.0.0/8被保留作环回通信用。此范围中的地址绝不应出现在主机之外，发送至此地址的报文被作为同一虚拟网络设备上的入站报文（环回），主要用于检查TCP/IP协议栈是否正确运行和本机对本机的链接。

以0或255结尾的地址

[编辑]

一个常见的误解是以0或255结尾的地址永远不能分配给主机：这仅在子網路遮罩至少24位元长度时（旧的C类地址，或CIDR中的/24到/32）才成立。

在有类别的编址中，只有三种可能的子網路遮罩：A类：255.0.0.0，B类：255.255.0.0，C类：255.255.255.0。如，在子網路192.168.5.0/255.255.255.0（即192.168.5.0/24）中，網路識別碼192.168.5.0用来表示整个子網路，所以它不能用来标识子網路上的某个特定主机。

广播地址允许数据包发往子網路上的所有设备。一般情況下，廣播位址是藉由子網路遮罩的位元反码並和網路識別碼執行 OR 的位元運算得到，即广播地址是子網路中的最后一个地址。在上述例子中，广播地址是192.168.5.255，所以为了避免歧义，这个地址也不能被分配给主机。在A、B和C类网络中，广播地址总是以255结尾。

但是，这并不意味着每个以255结尾的地址都不能用做主机地址。比如，在B类子网192.168.0.0/255.255.0.0（即192.168.0.0/16）中，广播地址是192.168.255.255（主机位全1）。在这种情况下，尽管可能带来误解，但192.168.1.255、192.168.2.255等地址可以被分配给主机。同理，192.168.0.0作为網路識別碼不能被分配，但192.168.1.0、192.168.2.0等都是可以的。

随着CIDR的到来，广播地址不一定总是以255结尾（广播地址是指主机位都为1的地址，255只是其中一种情况）。比如，子網路203.0.113.16/28的广播地址是203.0.113.31。过程如下：

网络：203.0.113.16

掩码：255.255.255.240

掩码反码：0.0.0.15

OR操作：

00010000 | 00001111 = 00011111 =31

一般情況下，子網路的第一个和最后一个地址分别被作为網路識別碼和广播地址，任何其它地址都可以被分配给其上的主机。

地址解析

[编辑]
主条目：域名系统

互联网上的主机通常被指定，但IP报文的路由是由IP地址而不是这些名字决定的。这就需要将域名翻译（解析）成地址。

域名系统（DNS）提供了域名转换为IP地址的服务。与CIDR相像，DNS是层级结构。

地址空間枯竭

[编辑]
主条目：IPv4地址枯竭

從20世紀80年代起，一個很明顯的問題是IPv4地址在以比設計時的預計更快的速度耗盡。[4] 這是創建分類網絡、無類別域間路由，和最終決定重新設計基於更長地址的互聯網協議（IPv6）的誘因。

一些市場力量也加快了IPv4地址的耗盡，如：

隨著互聯網的增長，各種各樣的技術隨之產生以應對IPv4地址的耗盡，如：

隨著IANA把最後5個地址塊分配給5個RIR，其主地址池在2011年2月3日耗盡。[5] 許多地址分配和消耗的模型都預測第一個耗盡地址的RIR會在2011年的下半年出現。[6]ARIN在2015年用完可用的供应，APNIC、LACNIC和AFIC根据其社区政策定量供应[7]。

廣泛被接受且已被標準化的解決方案是遷移至IPv6。IPv6的地址長度從IPv4的32位增長到了128位，以此提供了更好的路由聚合，也為最終用戶分配最小為264個主機地址的地址塊成為可能。遷移過程正在進行，但其完成仍需要相當的時間。

网络地址转换

[编辑]
主条目：网络地址转换

对地址的快速分配和其造成的地址短缺促成了许多有效应用地址的方法，其中一种就是网络地址转换（NAT）。

报文结构

[编辑]

IP报文包含IP首部和数据部分

首部

[编辑]

IPv4报文的首部包含14个字段，其中13个是必须的，第14个是可选的（红色标出），并命名为：“选项”字段。首部中的字段均以大端序包装，在以下的图表和讨论中，最高有效位（Most Significant bit）被标记为0。

位偏移 0–3 4–7 8–13 14-15 16–18 19–31
0 版本 首部长度 区分服务 显式拥塞通知 全长
32 标识符 标志 分片偏移
64 存活时间 协议 首部检验和
96 源IP地址
128 目的IP地址
160 选项（如首部长度>5）
160
或
192+ 		 
数据
 
版本（Version）
版本字段占4bit，通信双方使用的版本必须一致。对于IPv4，字段的值是4。
首部长度（Internet Header Length， IHL）
占4bit，首部长度说明首部有多少32位字（4字节）。由于IPv4首部可能包含数目不定的选项，这个字段也用来确定数据的偏移量。这个字段的最小值是5（二进制0101），相当于5*4=20字节（RFC 791），最大十进制值是15。
区分服务（Differentiated Services，DS）
占6bit，最初被定义为服务类型字段，实际上并未使用，但1998年被IETF重定义为区分服务RFC 2474。只有在使用区分服务时，这个字段才起作用，在一般的情况  下都不使用这个字段。例如需要实时数据流的技术会应用这个字段，一个例子是VoIP。
显式拥塞通告（ Explicit Congestion Notification，ECN）
在RFC 3168中定义，允许在不丢弃报文的同时通知对方网络拥塞的发生。ECN是一种可选的功能，仅当两端都支持并希望使用，且底层网络支持时才被使用。
全长（Total Length）
这个16位字段定义了报文总长，包含首部和数据，单位为字节。这个字段的最小值是20（20字节首部+0字节数据），最大值是216-1=65,535。IP规定所有主机都必须支持最小576字节的报文，这是假定上层数据长度512字节，加上最长IP首部60字节，加上4字节富裕量，得出576字节，但大多数现代主机支持更大的报文。当下层的数据链路协议的最大传输单元（MTU）字段的值小于IP报文长度时，报文就必须被分片，详细见下个标题。
标识符（Identification）
占16位，这个字段主要被用来唯一地标识一个报文的所有分片，因为分片不一定按序到达，所以在重组时需要知道分片所属的报文。每产生一个数据报，计数器加1，并赋值给此字段。一些实验性的工作建议将此字段用于其它目的，例如增加报文跟踪信息以协助探测伪造的源地址。[8]
标志 （Flags）
这个3位字段用于控制和识别分片，它们是：
  • 位0：保留，必须为0；
  • 位1：禁止分片（Don’t Fragment，DF），当DF=0时才允许分片；
  • 位2：更多分片（More Fragment，MF），MF=1代表后面还有分片，MF=0 代表已经是最后一个分片。
如果DF标志被设置为1，但路由要求必须分片报文，此报文会被丢弃。这个标志可被用于发往没有能力组装分片的主机。
当一个报文被分片，除了最后一片外的所有分片都设置MF为1。最后一个片段具有非零片段偏移字段，将其与未分片数据包区分开，未分片的偏移字段为0。
分片偏移 （Fragment Offset）
这个13位字段指明了每个分片相对于原始报文开头的偏移量，以8字节作单位。
存活时间（Time To Live，TTL）
这个8位字段避免报文在互联网中永远存在（例如陷入路由环路）。存活时间以秒为单位，但小于一秒的时间均向上取整到一秒。在现实中，这实际上成了一个跳数计数器：报文经过的每个路由器都将此字段减1，当此字段等于0时，报文不再向下一跳传送并被丢弃，最大值是255。常规地，一份ICMP报文被发回报文发送端说明其发送的报文已被丢弃。这也是traceroute的核心原理。
协议 （Protocol）
占8bit，这个字段定义了该报文数据区使用的协议。IANA维护着一份协议列表（最初由RFC 790定义），详细参见IP协议号列表。
首部检验和 （Header Checksum）
这个16位检验和字段只对首部查错，不包括数据部分。在每一跳，路由器都要重新计算出的首部检验和并与此字段进行比对，如果不一致，此报文将会被丢弃。重新计算的必要性是因为每一跳的一些首部字段（如TTL、Flag、Offset等）都有可能发生变化，不检查数据部分是为了减少工作量。数据区的错误留待上层协议处理——用户数据报协议（UDP）和传输控制协议（TCP）都有检验和字段。此处的检验计算方法不使用CRC。
RFC 1071
源地址（Source address）
一个IPv4地址由四个字节共32位构成，此字段的值是将每个字节转为二进制并拼在一起所得到的32位值。
例如，10.9.8.7是00001010000010010000100000000111。
但请注意，因为NAT的存在，这个地址并不总是报文的真实发送端，因此发往此地址的报文会被送往NAT设备，并由它被翻译为真实的地址。
目的地址（Destination address）
与源地址格式相同，但指出报文的接收端。
选项（Options）
附加的首部字段可能跟在目的地址之后，但这并不被经常使用，从1到40个字节不等。请注意首部长度字段必须包括足够的32位字来放下所有的选项（包括任何必须的填充以使首部长度能够被32位整除）。当选项列表的结尾不是首部的结尾时，EOL（选项列表结束，0x00）选项被插入列表末尾。下表列出了可能
字段 长度（位） 描述
备份 1 当此选项需要被备份到所有分片中时，设为1。
类 2 常规的选项类别，0为“控制”，2为“查错和措施”，1和3保留。
数字 5 指明一个选项。
长度 8 指明整个选项的长度，对于简单的选项此字段可能不存在。
数据 可变 选项相关数据，对于简单的选项此字段可能不存在。
  • 注：如果首部长度大于5，那么选项字段必然存在并必须被考虑。
  • 注：备份、类和数字经常被一并称呼为“类型”。
宽松的源站选路（LSRR）和严格的源站选路（SSRR）选项不被推荐使用，因其可能带来安全问题。许多路由器会拒绝带有这些选项的报文。

数据

[编辑]

数据字段不是首部的一部分，因此并不被包含在首部检验和中。数据的格式在协议首部字段中被指明，并可以是任意的传输层协议。

一些常见协议的协议字段值被列在下面：

协议字段值 协议名 缩写
1 互联网控制消息协议 ICMP
2 互联网组管理协议 IGMP
6 传输控制协议 TCP
17 用户数据报协议 UDP
41 IPv6封装 ENCAP
89 开放式最短路径优先 OSPF
132 流控制传输协议 SCTP

参见IP协议号列表以获得完整列表。

分片和组装

[编辑]
主条目：IP分片

互联网协议（IP）是整个互联网架构的基础，可以支持不同的物理层网络，即IP层独立于链路层传输技术。不同的链路层不仅在传输速度上有差异，还在帧结构和大小上有所不同，不同MTU参数描述了数据帧的大小。为了实现IP数据包能够使用不同的链路层技术，需要将IP数据包变成适合链路层的数据格式，IP报文的分片即是IP数据包为了满足链路层的数据大小而进行的分割。

在IPv6不要求路由器执行分片操作，而是将检测路径最大传输单元大小的任务交给了主机。

分片

[编辑]

当设备收到IP报文时，分析其目的地址并决定要在哪个链路上发送它。MTU决定了数据载荷的最大长度，如IP报文长度比MTU大，则IP数据包必须进行分片。每一片的长度都小于等于MTU减去IP首部长度。接下来每一片均被放到独立的IP报文中，并进行如下修改：

  • 总长字段被修改为此分片的长度；
  • 更多分片（MF）标志被设置，除了最后一片；
  • 分片偏移量字段被调整为合适的值；
  • 首部检验和被重新计算。

例如，对于一个长20字节的首部和一个MTU为1,500的以太网，分片偏移量将会是：0、(1480/8)=185、(2960/8)=370、(4440/8)=555、(5920/8)=740、等等。

如果报文经过路径的MTU减小了，那么分片可能会被再次分片。

比如，一个4,500字节的数据载荷被封装进了一个没有选项的IP报文（即总长为4,520字节），并在MTU为2,500字节的链路上传输，那么它会被破成如下两个分片：

# 总长 更多分片（MF）？ DF 分片偏移量
首部 数据
1 2500 是 0 0
20 2480
2 2040 否 0 310
20 2020

现在，假设下一跳的MTU为1,500字节，那么每一个分片都会被再次分成两片（由于数据片段只有在目的主机才重新被组成数据报，因此再次分片是针对每个在网络中传输的数据帧）：

# 总长 更多分片（MF）？ DF 分片偏移量
首部 数据
1 1500 是 0 0
20 1480
2 1020 是 0 185
20 1000
3 1500 是 0 310
20 1480
4 560 否 0 495
20 540

第3和4片是从原始第2片再次分片而来，所以除了分片后的最后一个分片外MF为都为1。

重组

[编辑]

当一个接收者发现IP报文的下列项目之一为真时：

  • DF标志为0；
  • 分片偏移量字段不为0。

它便知道这个报文已被分片，并随即将数据、标识符字段、分片偏移量和更多分片标志一起储存起来。

当接受者收到了更多分片标志未被设置的分片时，它便知道原始数据载荷的总长。一旦它收齐了所有的分片，它便可以将所有片按照正确的顺序（通过分片偏移量）组装起来，并交给上层协议栈。

辅助协议

[编辑]

互联网协议定义并激活了网络层，它使用一个逻辑地址系统。IP地址并不以任何永久的方式绑定到硬件，而且事实上一个网络接口可以有许多IP地址。为了正确地交付一份报文，主机和路由器需要其它机制来识别设备接口和IP地址之间的关联。地址解析协议（ARP）为IPv4执行这种IP地址到物理地址（MAC地址）的转换。

此外，反向操作有时候也是必须的，比如，一台主机在启动时需要知道自己的IP地址（除非地址已经被管理员预先设置）。目前被用于这一用途的协议有动态主机设置协议（DHCP）、引导协议（BOOTP）和比较不常用的RARP。

参见

[编辑]

参考文献

[编辑]
  1. ^ Onsem, Willem Van. What is the purpose of dot-decimal notation?. Stack Overflow. 2015-02-18 [2016-10-06]. （原始内容存档于2015-09-29）. 
  2. ^ 2.0 2.1 INET(3) man page. [2010-11-28]. 
  3. ^ Wendell Odom. CCENT/CCNA ICND1 100-105 Official Cert Guide. Cisco Press. 2016: 89页. ISBN 978-1-58720-580-4. 
  4. ^ World 'running out of Internet addresses'. [2011-01-23]. （原始内容存档于2011-01-25）. 
  5. ^ IANA. 102, 103, 104, 179 and 185 have been allocated. No unicast IPv4 /8s remain unallocated.. 2011-02-03 [2011-02-03]. （原始内容存档于2011-02-07）. 
  6. ^ Huston, Geoff. IPv4 Address Report, daily generated. [2011-01-31]. （原始内容存档于2009-04-01）. 
  7. ^ IPv4 exhaustion | APNIC. [2022-09-24]. （原始内容存档于2022-11-30） （澳大利亚英语）. 
  8. ^ Savage, Stefan. Practical network support for IP traceback. [2010-09-06]. 

外部链接

[编辑]

地址耗尽：

检索自“https://zh.wikipedia.org/zhwiki/w/index.php?title=IPv4&oldid=85116015”