赞
踩
网络网络层之(5)IPv6协议
Author: Once Day Date: 2024年5月12日
一位热衷于Linux学习和开发的菜鸟,试图谱写一场冒险之旅,也许终点只是一场白日梦…
漫漫长路,有人对你微笑过嘛…
全系列文档可参考专栏:通信网络技术_Once-Day的博客-CSDN博客。
参考文章:
随着互联网的快速发展,IPv4地址空间面临耗尽的问题。为了解决这一问题,互联网工程任务组(IETF)在20世纪90年代初开始研究下一代互联网协议。经过多年的努力,IPv6协议最终于1998年12月由IETF正式发布。
IPv6(互联网协议版本6)是互联网协议(IP)的最新版本,旨在解决IPv4地址枯竭问题,并为未来互联网的发展提供更好的支持。
主要特点如下:
与IPv4的区别和联系:
IPv6是互联网协议的未来,它解决了IPv4地址枯竭问题,并为未来互联网的发展提供了更好的支持。
这些协议族协同工作,构建了一个完整的IPv6网络架构,每个协议都有其特定的功能和用途:
IPv6基本协议(RFC 8200),定义了IPv6数据包的格式和处理规则,包括地址格式、报文头结构、扩展头等。
ICMPv6(互联网控制消息协议版本6,RFC 4443),用于传递错误消息和控制信息,包括邻居发现、路径MTU发现、多播侦听器发现等功能。
NDPv6(邻居发现协议版本6,RFC 4861),用于发现同一链路上的邻居节点,包括路由器发现、前缀发现、地址解析、重复地址检测等功能
DHCPv6(动态主机配置协议版本6,RFC 8415),用于自动分配IPv6地址和配置网络参数,包括有状态和无状态两种模式。
IPsec(互联网安全协议,RFC 4301),提供了Authentication Header(AH)和Encapsulating Security Payload(ESP)两种安全机制,用于保护IPv6数据包的完整性、机密性和真实性。
MLD(多播侦听器发现协议,RFC 3810),用于IPv6组播管理,允许主机向路由器报告其所在的多播组,类似于IPv4中的IGMP协议。
SEND(安全性增强的邻居发现协议,RFC 3971),为NDPv6提供安全性增强,防止欺骗攻击。
移动IPv6(RFC 6275),支持移动节点在不同网络之间漫游,保持通信连续性。
流量标签(RFC 3697),用于标识一个流,以便网络设备提供特定的服务质量(QoS)。
隧道协议(如6to4、6rd、ISATAP等),用于在IPv4网络上传输IPv6数据包,实现IPv6过渡。
以下是与IPv6相关的主要RFC文档:
RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification,定义了IPv6协议的基本规范,包括地址格式、报文格式等。
RFC 4291 - IP Version 6 Addressing Architecture,描述了IPv6的地址体系结构,包括地址类型、格式和分配方式。
RFC 4443 - Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,定义了ICMPv6协议,用于传递错误消息和控制信息。
RFC 4861 - Neighbor Discovery for IP version 6 (IPv6),描述了IPv6的邻居发现协议(NDP),用于发现同一链路上的邻居节点。
RFC 4862 - IPv6 Stateless Address Autoconfiguration,定义了IPv6的无状态地址自动配置(SLAAC)机制。
RFC 3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6),描述了DHCPv6协议,用于自动分配IPv6地址和配置网络参数。
RFC 4301 - Security Architecture for the Internet Protocol,定义了IPsec协议,为IPv6提供安全性保护。
RFC 3810 - Multicast Listener Discovery Version 2 (MLDv2) for IPv6, 描述了MLDv2协议,用于IPv6组播管理。
RFC 3971 - SEcure Neighbor Discovery (SEND),为NDP提供安全性增强,防止欺骗攻击。
RFC 6275 - Mobility Support in IPv6,描述了移动IPv6协议,支持移动节点在不同网络之间漫游。
RFC 3697 - IPv6 Flow Label Specification,定义了IPv6流量标签,用于标识一个流,提供服务质量(QoS)。
RFC 5095 - Deprecation of Type 0 Routing Headers in IPv6,废弃了IPv6中的0型路由头,以提高安全性。
RFC 7045 - Transmission and Processing of IPv6 Extension Headers,规定了IPv6扩展头的传输和处理规则。
RFC 8200 - Internet Protocol, Version 6 (IPv6) Specification,更新了RFC 2460,是当前IPv6协议的最新规范。
RFC 2460和RFC 8200都是关于IPv6协议规范的文档,但RFC 8200是RFC 2460的更新版本:
文档状态,RFC 2460是IPv6的原始规范,发布于1998年12月。RFC 8200是IPv6的更新规范,发布于2017年7月,废弃了RFC 2460。
扩展头的处理,RFC 2460中,节点必须按照扩展头在报文中出现的顺序依次处理每个扩展头。RFC 8200中,节点只需查看目标地址之前的扩展头,处理顺序不再严格要求。
逐跳选项扩展头的处理,RFC 2460要求所有节点都必须处理逐跳选项扩展头。RFC 8200允许中间节点在转发数据包时忽略逐跳选项扩展头,以提高性能。
路由头的处理,RFC 2460定义了0型路由头(RH0),但后来发现RH0存在安全漏洞。RFC 8200明确禁止使用RH0,并引用了RFC 5095关于弃用RH0的规定。
分片头的处理,RFC 2460中,分片头可以出现在扩展头链的任意位置。RFC 8200要求分片头必须紧跟在目标地址之后,以简化分片处理。
校验和的计算,RFC 2460和RFC 8200对IPv6报文校验和的计算方法做了一些细微的调整,以适应扩展头处理方式的变化。
RFC 8200在保持IPv6协议基本不变的情况下,对一些细节做了优化和调整,以提高协议的安全性、效率和实现的灵活性。
IPv6数据包由两部分组成:IPv6基本首部和有效载荷。IPv6基本首部是固定长度的40字节。
IPv6首部字段介绍如下:
IPv6首部相对于IPv4首部进行了一些字段的删除和更改:
IPv6首部中的流标签(Flow Label)字段是一个20位的标识符,用于标识一个特定的数据流。流标签的主要功能是为IPv6数据包提供一种特殊的处理方式,以满足某些应用或服务的需求。
服务质量(QoS)支持,流标签可以用于识别需要特定服务质量的数据流,如实时音视频、在线游戏等。
流量工程(Traffic Engineering),流标签可以用于实现流量工程,即根据网络状态和策略,将特定的数据流导向指定的网络路径。
负载均衡(Load Balancing),流标签可以用于实现负载均衡,即将同一数据流的数据包分配到不同的网络路径或服务器上处理。
流量统计和分析,流标签可以用于识别和统计特定的数据流,如用户会话、应用流量等。
流量加密和认证,流标签可以与IPsec等安全机制结合使用,为特定的数据流提供加密和认证服务。
需要注意的是,流标签的使用是可选的,并非所有的IPv6数据包都必须使用流标签。流标签的值由源节点生成,并在数据包的整个生命周期内保持不变,中间节点不能修改流标签的值,但可以根据流标签提供特定的处理。
参考华为产品支持文档:IP 报文格式大全 (huawei.com)
扩展报头。IPv6取消了IPv4报头中的选项字段,并引入了多种扩展报文头,在提高处理效率的同时还增强了IPv6的灵活性,为IP协议提供了良好的扩展能力。当超过一种扩展报头被用在同一个分组里时,报头必须按照下列顺序出现:
除了目的选项扩展报头出现两次(一次在路由扩展报头之前,另一次在上层扩展报头之前),其余扩展报头只出现一次。不是所有的扩展报头都需要被转发路由设备查看和处理的。路由设备转发时根据基本报头中Next Header值来决定是否要处理扩展头。
IPv6逐跳选项和目的选项都是IPv6扩展头部,用于在IPv6数据包中携带额外的信息。它们的编码格式如下:
|动作(2位)|chg(1位)|类型子字段(5位)|选项数据长度(8位)|选项数据.....
|----- Type(选项类型) ------|
选项类型的前两位“动作”字段用于确定不识别选项时的处理方式:
下面是携带在逐跳选项(H)或者目的地选项(D)扩展头部中的IPv6选项:
选项名 | 头部(H/D) | 动作 | 改变 | 类型 | 长度 | RFC文档 |
---|---|---|---|---|---|---|
填充1(Pad1) | H/D | 00 | 0 | 0 | N/A | RFC 8200 |
填充N(PadN) | H/D | 00 | 0 | 1 | 可变 | RFC 8200 |
超大有效载荷(Jumbo Payload) | H | 11 | 0 | 194 | 8 | RFC 2675 |
隧道封装限制(Tunnel Encapsulation Limit) | D | 00 | 0 | 4 | 4 | RFC 2473 |
路由器警告(Router Alert) | H | 00 | 0 | 5 | 4 | RFC 2711 |
快速启动(Quick-Start) | H | 00 | 1 | 6 | 8 | RFC 4782 |
家乡地址(Home Address) | D | 01 | 0 | 201 | 16 | RFC 6275 |
CALIPSO | D | 00 | 0 | 7 | 8-256 | RFC 5570 |
表格说明:
IPv6超大有效载荷(Jumbo Payload)选项是一种IPv6逐跳选项,用于支持长度超过65535字节的IPv6数据包。在IPv6基本头部中,有效载荷长度字段为16位,最大值为65535。当数据包长度超过此限制时,就需要使用Jumbo Payload选项。
使用场景:
IPv6隧道封装限制(Tunnel Encapsulation Limit)选项是一种IPv6目的地选项,用于限制IPv6数据包在封装隧道中的嵌套深度。当IPv6数据包通过多个隧道传输时,每个隧道都会为数据包添加一层新的封装。如果嵌套深度过大,可能会导致数据包处理延迟增加、网络性能下降,甚至出现环路。
使用场景:
IPv6路由头部(Routing Header)是一种IPv6扩展头部,用于指定数据包在到达最终目的地之前经过的一个或多个中间节点。通过使用路由头部,源节点可以控制数据包的转发路径,实现诸如源路由、移动IPv6等功能。
|下一个头部(1字节)|头部扩展长度(1字节)|路由类型(1字节)|剩余部分(1字节)|保留(4字节)|N个IPv6地址...
常见的路由类型:
处理流程:
过度使用路由头部可能会引入安全风险(如IP欺骗、DOS攻击等)和性能问题,一些路由类型(如类型0)由于安全问题已被弃用。
IPv6分片头部(Fragment Header)是一种IPv6扩展头部,用于支持IPv6数据包的分片和重组功能。当一个IPv6数据包的大小超过传输路径的MTU(最大传输单元)时,需要对数据包进行分片。分片头部包含了分片相关的信息,以便目的节点能够正确地重组分片。
|下一个头部(8位)|保留0(8位)|分片偏移(13位)|Res(2位)|M(1位)|标识符(32位)
处理流程:
IPv6的分片功能与IPv4有所不同。在IPv6中,只有源节点可以执行分片,中间节点不允许对数据包进行分片。这种设计可以简化网络处理,提高效率。
也信美人终作土,不堪幽梦太匆匆......
如果这篇文章为您带来了帮助或启发,不妨点个赞
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。