IPv4
| 网络协议 | |
|---|---|
| 应用层 | |
| DHCP (DHCP · DHCPv6) · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTP ·RTSP · SDP · SOAP · GTP · STUN · NTP · SSDP · 更多 | |
| 传输层 | |
|
TCP · UDP · TLS/SSL · DCCP · SCTP RSVP · PPTP · 更多 |
|
| 网络层 | |
|
IP (IPv4 · IPv6) · ICMP · ICMPv6 · IGMP · IS-IS · IPsec · BGP · RIP · OSPF ·ARP · RARP · 更多 |
|
| 数据链路层 | |
|
Wi-Fi(IEEE 802.11) · WiMAX(IEEE 802.16) · ATM · DTM · 令牌环 · 乙太網路 · FDDI · 帧中继 · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN ·STP · 更多 |
|
| 物理层 | |
| 以太网 · 调制解调器 · 电力线通信(PLC) · SONET/SDH · G.709 · 光导纤维 · 同轴电缆 · 双绞线 · 更多 | |
互联网协议版本4(英语:Internet Protocol version 4,IPv4)是互联网协议开发过程中的第四个修订版本(網際網協四版),也是此协议第一个被广泛部署的版本。IPv4与IPv6均是标准化互联网络的核心部分。IPv4依然是使用最广泛的互联网协议版本,直到2011年,IPv6仍处在部署的初期。
IPv4在IETF于1981年9月发布的RFC 791中被描述,此RFC替换了于1980年1月发布的RFC 760。
IPv4是一种无连接的协议,操作在使用分组交换的链路层(如以太网)上。此协议会尽最大努力交付分组,意即它不保证任何分组均能送达目的地,也不保证所有分组均按照正确的顺序无重复地到达。这些方面是由上层的传输协议(如传输控制协议)处理的。
目录 |
地址 [编辑]
IPv4使用32位(4字节)地址,因此地址空间中只有4,294,967,296(232)个地址。不过,一些地址是为特殊用途所保留的,如专用网络(约18百万个地址)和多播地址(约270百万个地址),这减少了可在互联网上路由的地址数量。随着地址不断被分配给最终用户,IPv4地址枯竭问题也在随之产生。基于分类网络、无类别域间路由和网络地址转换的地址结构重构显著地减少了地址枯竭的速度。但在2011年2月3日,在最后5个地址块被分配给5个区域互联网注册管理机构之后,IANA的主要地址池空了。
这些限制刺激了仍在开发早期的IPv6的部署,这也是唯一的长期解决方案。
地址格式 [编辑]
IPv4地址可被写作任何表示一个32位整数值的形式,但为了方便人类,它通常被写作点分十进制的形式,即四个字节被分开用十进制写出,中间用点分隔。
下表展示了几种不同的格式:
| 格式 | 值 | 从点分十进制转换 |
|---|---|---|
| 点分十进制 | 192.0.2.235 | 不适用 |
| 点分十六进制[1] | 0xC0.0x00.0x02.0xEB | 每个字节被单独转换为十六进制 |
| 点分八进制[1] | 0300.0000.0002.0353 | 每个字节被单独转换为八进制 |
| 十六进制 | 0xC00002EB | 将点分十六进制连在一起 |
| 十进制 | 3221226219 | 用十进制写出的32位整数 |
| 八进制 | 030000001353 | 用八进制写出的32位整数 |
此外,在点分格式中,每个字节都可用任意的进制表达。如,192.0x00.0002.235是一种合法(但很不常用)的表示。
分配 [编辑]
最初,一个IP地址被分成两部分:網路識別碼在地址的高位字节中,主機識別碼在剩下的部分中。这使得创建最多256个网络成为可能,但很快人们发现这样是不够的。
为了克服这个限制,在随后出现的分类网络中,地址的高位字节被重定义为网络的类(Class)。这个系统定义了五个类別:A、B、C、D和E。A、B和C类有不同的网络类別长度,剩余的部分被用来识别网络内的主机,这就意味着每个网络类別有着不同的给主机编址的能力。D类被用于多播地址,E类被留作将来使用。
在1993年左右,无类别域间路由(CIDR)正式地取代了分类网络,后者也因此被称为“有类别”的。
CIDR被设计为可以重新划分地址空间,因此小的或大的地址块均可以分配给用户。CIDR创建的分层架构由互联网号码分配局(IANA)和区域互联网注册管理机构(RIR)进行管理,每个RIR均维护着一个公共的WHOIS数据库,以此提供IP地址分配的详情。
特殊用途的地址 [编辑]
| CIDR地址块 | 描述 | 参考资料 |
|---|---|---|
| 0.0.0.0/8 | 本网络(仅作为源地址时合法) | RFC 5735 |
| 10.0.0.0/8 | 专用网络 | RFC 1918 |
| 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 | 广播 | RFC 919 |
专用网络 [编辑]
在IPv4所允许的大约四十亿地址中,三个地址块被保留作专用网络。这些地址块在专用网络之外不可路由,专用网络之内的主机也不能直接与公共网络通信。但通过网络地址转换,他们即能做到后者。
下表展示了三个被保留作专用网络的地址块(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隧道或虚拟专用网络(VPN)。
VPN在公共网络上创建连接两个专用网络的隧道。在这种功能中,隧道一端的主机将报文封装在一个公共网路上可以接受的协议层中,然后这些报文就可以被送达隧道的另一端,在那里,附加的协议层被去掉,报文也被送达其原定的目的地。
此外,封装过的报文也可能被加密以保证其在公共网络上传输时的安全性。
链路本地地址 [编辑]
RFC 5735中将地址块169.254.0.0/16保留为特殊用于链路本地地址,这些地址仅在链路上有效(如一段本地网络或一个端到端连接)。这些地址与专用网络地址一样不可路由,也不可作为公共网络上报文的源或目的地址。链路本地地址主要被用于地址自动配置:当主机不能从DHCP服务器处获得IP地址时,它会用这种方法生成一个。
当这个地址块最初被保留时,地址自动配置尚没有一个标准。为了填补这个空白,微软创建了一种叫自动专用IP寻址(APIPA)的实现。因微软的市场影响力,APIPA已经被部署到了几百万机器上,也因此成为了事实上的工业标准。许多年后,IETF为此定义了一份正式的标准:RFC 3927,命名为“IPv4链路本地地址的动态配置”。
环回地址(Loopback Address) [编辑]
地址块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。在这种情况下,尽管可能带来误解,但192.168.1.255、192.168.2.255等地址可以被分配给主机。同理,192.168.0.0作为網路識別碼不能被分配,但192.168.1.0、192.168.2.0等都是可以的。
随着CIDR的到来,广播地址不一定总是以255结尾。比如,子網路203.0.113.16/28的广播地址是203.0.113.31。
一般情況下,子網路的第一个和最后一个地址分别被作为網路識別碼和广播地址,任何其它地址都可以被分配给其上的主机。
地址解析 [编辑]
互联网上的主机通常被其名字(如zh.wikipedia.org、www.berkeley.edu等)而不是IP地址识别,但IP报文的路由是由IP地址而不是这些名字决定的。这就需要将名字翻译(解析)成地址。
域名系统(DNS)提供了这样一个将名字转换为地址和将地址转换为名字的系统。与CIDR相像,DNS也有一个层级的结构,使不同的名字空间可被再委托给其它DNS服务器。
域名系统经常被描述为电话系统中的黄页:在那里人们可以把名字和电话号码对应起来。
地址空間枯竭 [编辑]
從20世紀80年代起,一個很明顯的問題是IPv4地址在以比設計時的預計更快的速度耗盡。[2] 這是創建分類網絡、無類別域間路由,和最終決定重新設計基於更長地址的互聯網協議(IPv6)的誘因。
一些市場力量也加快了IPv4地址的耗盡,如:
隨著互聯網的增長,各種各樣的技術隨之產生以應對IPv4地址的耗盡,如:
- 網絡地址轉換(NAT);
- 專用網絡的使用;
- 動態主機設置協議(DHCP);
- 基於名字的虛擬主機;
- 區域互聯網註冊管理機構對地址分配的控制;
- 對互聯網初期分配的大地址塊的回收。
隨著IANA把最後5個地址塊分配給5個RIR,其主地址池在2011年2月3日耗盡。[3] 許多地址分配和消耗的模型都預測第一個耗盡地址的RIR會在2011年的下半年出現。[4]
廣泛被接受且已被標準化的解決方案是遷移至IPv6。IPv6的地址長度從IPv4的32位增長到了128位,以此提供了更好的路由聚合,也為最終用戶分配最小為264個主機地址的地址塊成為可能。遷移過程正在進行,但其完成仍需要相當的時間。
网络地址转换 [编辑]
对地址的快速分配和其造成的地址短缺促成了许多有效应用地址的方法,其中一种就是网络地址转换(NAT)。NAT设备将一整个专有网络隐藏在一个公共IP地址“之后”。许多拥有很多用户的ISP都依赖这一技术。
报文结构 [编辑]
一份IP报文包含一个首部和一份数据,
首部 [编辑]
IPv4报文的首部包含14个字段,其中13个是必须的,第14个是可选的(在表中用红色标出),并贴切地命名为:“选项”。首部中的字段均以大端序包装,在以下的图表和讨论中,最高有效位被标记为0,因此例如版本字段实际上可在第一个字节的前四高有效位中被找到。
| 位偏移 | 0–3 | 4–7 | 8–13 | 14-15 | 16–18 | 19–31 | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 版本 | 首部长度 | DSCP | 显式拥塞通告 | 全长 | |||||||||||||||||||||||||||
| 32 | 标识符 | 标志 | 分片偏移 | |||||||||||||||||||||||||||||
| 64 | 存活时间 | 协议 | 首部检验和 | |||||||||||||||||||||||||||||
| 96 | 源IP地址 | |||||||||||||||||||||||||||||||
| 128 | 目的IP地址 | |||||||||||||||||||||||||||||||
| 160 | 选项(如首部长度>5) | |||||||||||||||||||||||||||||||
| 160 or 192+ |
数据 |
|||||||||||||||||||||||||||||||
- 版本
- IP报文首部的第一个字段是4位版本字段。对IPv4来说,这个字段的值是4。
- 全长
- 这个16位字段定义了报文总长,包含首部和数据,单位为字节。这个字段的最小值是20(20字节首部+0字节数据),最大值是65,535。所有主机都必须支持最小576字节的报文,但大多数现代主机支持更大的报文。有时候子网会限制报文的大小,这时报文就必须被分片。
- 标识符
- 这个字段主要被用来唯一地标识一个报文的所有分片。一些实验性的工作建议将此字段用于其它目的,例如增加报文跟踪信息以协助探测伪造的源地址。[5]
- 标志
- 这个3位字段用于控制和识别分片,它们是:
- 位0:保留,必须为0;
- 位1:禁止分片(DF);
- 位2:更多分片(MF)。
- 如果DF标志被设置但路由要求必须分片报文,此报文会被丢弃。这个标志可被用于发往没有能力组装分片的主机。
- 当一个报文被分片,除了最后一片外的所有分片都设置MF标志。不被分片的报文不设置MF标志:它是它自己的最后一片。
- 分片偏移
- 这个13位字段指明了每个分片相对于原始报文开头的偏移量,以8字节作单位。
- 存活时间(TTL)
- 这个8位字段避免报文在互联网中永远存在(例如陷入路由环路)。存活时间以秒为单位,但小于一秒的时间均向上取整到一秒。在现实中,这实际上成了一个跳数计数器:报文经过的每个路由器都将此字段减一,当此字段等于0时,报文不再向下一跳传送并被丢弃。常规地,一份ICMP报文被发回报文发送端说明其发送的报文已被丢弃。这也是traceroute的核心原理。
- 首部检验和
- 这个16位检验和字段用于对首部查错。在每一跳,计算出的首部检验和必须与此字段进行比对,如果不一致,此报文被丢弃。值得注意的是,数据区的错误留待上层协议处理——用户数据报协议和传输控制协议都有检验和字段。
- 因为生存时间字段在每一跳都会发生变化,意味着检验和必须被重新计算,RFC 1071这样定义计算检验和的方法:
- The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.
- 源地址
- 一个IPv4地址由四个字节共32位构成,此字段的值是将每个字节转为二进制并拼在一起所得到的32位值。
- 例如,10.9.8.7是00001010000010010000100000000111。
- 这个地址是报文的发送端。但请注意,因为NAT的存在,这个地址并不总是报文的真实发送端,因此发往此地址的报文会被送往NAT设备,并由它被翻译为真实的地址。
- 目的地址
- 与源地址格式相同,但指出报文的接收端。
- 选项
- 附加的首部字段可能跟在目的地址之后,但这并不被经常使用。请注意首部长度字段必须包括足够的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封装 | - |
| 89 | 开放式最短路径优先 | OSPF |
| 132 | 流控制传输协议 | SCTP |
参见IP协议字段值列表以获得完整列表。
分片和组装 [编辑]
互联网协议是整个互联网架构的基础,使得不同的网络间交换流量成为可能。其设计容纳了物理条件不同的网络:其独立于其下的链路层传输技术。不同的链路层经常不仅在传输速度上有差异,还在结构和帧尺寸上有不同,这一整个被MTU参数描述。为了实现IP横越网络的角色,有必要实现一种自动调整传输单元大小的机制来适应其下的技术限制。这带出了IP报文的分片。在IPv4中,这个功能被放置在网络层,并由IPv4路由器完成。
与此不同的是,下一代互联网协议IPv6不要求路由器执行分片操作,而是将检测路径最大传输单元大小的任务交给了主机。
分片 [编辑]
当一个设备收到一个IP报文时,它阅读其目的地址并决定要在哪个设备上发送它。设备有与其关联的MTU来决定其载荷的最大长度,如报文长度比MTU大,那么设备必须进行分片。
设备将整个报文数据分成数片,每一片的长度都小于等于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)? | 分片偏移量 | |
|---|---|---|---|---|
| 首部 | 数据 | |||
| 1 | 2500 | 是 | 0 | |
| 20 | 2480 | |||
| 2 | 2040 | 否 | 310 | |
| 20 | 2020 | |||
现在,假设下一跳的MTU掉到1,500字节,那么每一个分片都会被再次分成两片:
| # | 总长 | 更多分片(MF)? | 分片偏移量 | |
|---|---|---|---|---|
| 首部 | 数据 | |||
| 1 | 1500 | 是 | 0 | |
| 20 | 1480 | |||
| 2 | 1020 | 是 | 185 | |
| 20 | 1000 | |||
| 3 | 1500 | 是 | 310 | |
| 20 | 1480 | |||
| 4 | 560 | 否 | 495 | |
| 20 | 540 | |||
事实上,数据的长度被保留了下来——1480+1000+1480+540=4500,最后一片的偏移量(495)*8(字节)加上数据——3960+540=4500也正好是数据长度。
值得注意的是,第3和4片是从原始第2片再次分片而来的。当一个设备必须分片最后一片时,它必须在除分出的最后一片外的其它片上设置更多分片标志。
组装 [编辑]
当一个接收者发现IP报文的下列项目之一为真时:
- 更多分片标志被设置;
- 分片偏移量字段不为0。
它便知道这个报文已被分片,并随即将数据、标识符字段、分片偏移量和更多分片标志一起储存起来。
当接受者收到了更多分片标志未被设置的分片时,它便知道原始数据载荷的总长。一旦它收齐了所有的分片,它便可以将所有片按照正确的顺序(通过分片偏移量)组装起来,并交给上层协议栈。
辅助协议 [编辑]
互联网协议定义并激活了网络层,它使用一个逻辑地址系统。IP地址并不以任何永久的方式绑定到硬件,而且事实上一个网络接口可以有许多IP地址。为了正确地交付一份报文,主机和路由器需要其它机制来识别设备接口和IP地址之间的关联。地址解析协议(ARP)为IPv4执行这种IP地址到物理地址(MAC地址)的转换。
此外,反向操作有时候也是必须的,比如,一台主机在启动时需要知道自己的IP地址(除非地址已经被管理员预先设置)。目前被用于这一用途的协议有动态主机设置协议(DHCP)、引导协议(BOOTP)和比较不常用的inARP。
参见 [编辑]
参考文献 [编辑]
- ^ 1.0 1.1 INET(3) man page. [2010-11-28].
- ^ World 'running out of Internet addresses'. [2011-01-23].
- ^ IANA. 102, 103, 104, 179 and 185 have been allocated. No unicast IPv4 /8s remain unallocated.. 2011-02-03 [2011-02-03].
- ^ Huston, Geoff. IPv4 Address Report, daily generated. [2011-01-31].
- ^ Savage, Stefan. Practical network support for IP traceback. [2010-09-06].
外部链接 [编辑]
- RFC 791 — Internet Protocol(英文)
- RFC 3344 — IPv4 Mobility(英文)
- IANA — 互联网地址分配局官方网站(英文)
- IP Header Breakdown, including specific options(英文)
- IPv6 vs. carrier-grade NAT/squeezing more out of IPv4(英文)
地址耗尽:
- RIPE report on address consumption as of October 2003
- Official current state of IPv4 /8 allocations, as maintained by IANA
- Dynamically generated graphs of IPv4 address consumption with predictions of exhaustion dates — Geoff Huston
- IP addressing in China and the myth of address shortage
- Countdown of remaining IPv4 available addresses (estimated)