作为带路专家的网络层

2020-07-06 约 5552 字预计阅读 12 分钟

在这里我们会认识到网络层提供的两种不同服务和网络层的核心也即–IP协议. 我们能够理解:

虚拟互连网络的概念.
IP地址与物理地址的关系
传统的分类的IP地址（包括子网掩码)

地址解析协议ARP

在实际应用中，我们经常会遇到这样的问题：已经知道了一个机器（主机或路由器）的IP地址，需要找出其相应的硬件地址。地址解析协议ARP就是用来解决这样的问题的。由于是IP协议使用了ARP协议，因此通常就把ARP协议划归网络层。但ARP协议的用途是为了从网络层使用的IP地址，解析出在数据链路层使用的硬件地址。

下面就介绍ARP协议的要点。

我们知道，网络层使用的是IP地址，但在实际网络的链路上传送数据帧时，最终还是必须使用该网络的硬件地址。但IP地址和下面的网络的硬件地址之间由于格式不同而不存在简单的映射关系（例如，IP地址有32位，而局域网的硬件地址是48位）。此外，在一个网络上可能经常会有新的主机加入进来，或撤走一些主机。更换网络适配器也会使主机的硬件地址改变。地址解析协议 ARP解决这个问题的方法是在主机ARP高速缓存中存放一个从IP地址到硬件地址的映射表，并且这个映射表还经常动态更新（新增或超时删除）。

每一台主机都设有一个ARP高速缓存（ARP cache），里面有本局域网上的各主机和路由器的IP地址到硬件地址的映射表，这些都是该主机目前知道的一些地址。那么主机怎样知道这些地址呢？我们可以通过下面的例子来说明。

当主机A要向本局域网上的某台主机B发送IP数据报时，就先在其ARP高速缓存中查看有无主机B的IP地址。如有，就在ARP高速缓存中查出其对应的硬件地址，再把这个硬件地址写入MAC帧，然后通过局域网把该MAC帧发往此硬件地址。

也有可能查不到主机B的IP地址的项目。这可能是主机B才入网，也可能是主机A刚刚加电，其高速缓存还是空的。在这种情况下，主机A就自动运行ARP，然后按以下步骤找出主机B的硬件地址。

1）ARP进程在本局域网上广播发送一个ARP请求分组. ARP请求分组的主要内容的一个例子是：“我的IP地址是209.0.0.5，硬件地址是00-00-C0-15-AD-18。我想知道IP地址为209.0.0.6的主机的硬件地址。”

2）在本局域网上的所有主机上运行的ARP进程都收到此ARP请求分组。

3）主机B的IP地址与ARP请求分组中要查询的IP地址一致，就收下这个ARP请求分组，并向主机A发送ARP响应分组，同时在这个ARP响应分组中写入自己的硬件地址。由于其余的所有主机的IP地址都与ARP请求分组中要查询的IP地址不一致，因此都不理睬这个ARP请求分组. ARP响应分组的主要内容是：“我的IP地址是209.0.0.6，我的硬件地址是08-00-2B-00-EE-0A。”请注意：虽然ARP请求分组是广播发送的，但ARP响应分组是普通的单播，即从一个源地址发送到一个目的地址。

4）主机A收到主机B的ARP响应分组后，就在其ARP高速缓存中写入主机B的IP地址到硬件地址的映射。

当主机A向B发送数据报时，很可能以后不久主机B还要向A发送数据报，因而主机B也可能要向A发送ARP请求分组。为了减少网络上的通信量，主机A在发送其ARP请求分组时，就把自己的IP地址到硬件地址的映射写入ARP请求分组。当主机B收到A的ARP请求分组时，就把主机A的这一地址映射写入主机B自己的ARP高速缓存中。以后主机B向A发送数据报时就很方便了。

可见ARP高速缓存非常有用。如果不使用ARP高速缓存，那么任何一台主机只要进行一次通信，就必须在网络上用广播方式发送ARP请求分组，这就使网络上的通信量大大增加。ARP把已经得到的地址映射保存在高速缓存中，这样就使得该主机下次再和具有同样目的地址的主机通信时，可以直接从高速缓存中找到所需的硬件地址而不必再用广播方式发送ARP请求分组。

ARP对保存在高速缓存中的每一个映射地址项目都设置生存时间（例如，10～20分钟）。凡超过生存时间的项目就从高速缓存中删除掉。设置这种地址映射项目的生存时间是很重要的。设想有一种情况。主机A和B通信。A的ARP高速缓存里保存有B的硬件地址。但B的网络适配器突然坏了，B立即更换了一块，因此B的硬件地址就改变了。假定A还要和B继续通信。A在其ARP高速缓存中查找到B原先的硬件地址，并使用该硬件地址向B发送数据帧。但B原先的硬件地址已经失效了，因此A无法找到主机B。但是过了一段不长的生存时间，A的ARP高速缓存中已经删除了B原先的硬件地址，于是A重新广播发送ARP请求分组，又找到了B。

请注意，ARP是解决同一个局域网上的主机或路由器的IP地址和硬件地址的映射问题。从IP地址到硬件地址的解析是自动进行的，主机的用户对这种地址解析过程是不知道的。只要主机或路由器要和本网络上的另一个已知IP地址的主机或路由器进行通信，ARP协议就会自动地把这个IP地址解析为链路层所需要的硬件地址。

ARP

IPv4

IP数据报的格式能够说明IP协议都具有什么功能。一个IP数据报由首部和数据两部分组成。首部的前一部分是固定长度，共20字节，是所有IP数据报必须具有的。在首部的固定部分的后面是一些可选字段，其长度是可变的。下面介绍首部各字段的意义。

版本(Version) 占4位，指IP协议的版本。通信双方使用的IP协议的版本必须一致。目前广泛使用的IP协议版本号为4（即IPv4）.
首部长度 　占4位，可表示的最大十进制数值是15。请注意，首部长度字段所表示数的单位是32位字（1个32位字长是4字节）。因为IP首部的固定长度是20字节，因此首部长度字段的最小值是5（即二进制表示的首部长度是0101）。而当首部长度为最大值1111时（即十进制数的15），就表明首部长度达到最大值15个32位字长，即60字节。当IP分组的首部长度不是4字节的整数倍时，必须利用最后的填充字段加以填充。因此IP数据报的数据部分永远在4字节的整数倍时开始，这样在实现IP协议时较为方便。首部长度限制为60字节的缺点是有时可能不够用。但这样做是希望用户尽量减少开销。最常用的首部长度是20字节（即首部长度为0101），这时不使用任何选项。
区分服务　占8位，用来获得更好的服务。这个字段在旧标准中叫做服务类型，但实际上一直没有被使用过。
总长度　总长度指首部和数据之和的长度，单位为字节。总长度字段为16位，因此数据报的最大长度为2 16 –1＝65535字节。然而实际上传送这样长的数据报在现实中是极少遇到的。

IP层转发分组的流程

我们知道在路由器中会有路由表,但是如果由路由表指出到每一台主机该如何转发,那样未免会使得路由表太过庞大, 但是如果路由表只是指出到某个网络该如何转发,那么该路由表就只会包括网络数的项目,这样就大大减小了需要储存的项目, 我们不必关心某个网络内部具体的拓扑以及具体有多少太设备连接在这个网络上, 因为是从一个路由器转发到下一个路由器.

路由表中的项目最主要的是以下两个信息: $$ (目的网络地址, 下一跳地址) $$

这里只是IP层怎样根据路由表的内容

网际控制报文协议–ICMP(Internet Control Message Protocol)

为了更有效地转发IP数据报和提高成功交付的机会,在网络层使用了ICMP协议. ICMP协议允许主机或路由器报告差错情况和提供有关异常情况的报告. 值得注意的是ICMP并不是高层协议, 反而仍然是网络层的协议,因为ICMP的报文装在IP数据报中,作为其中的数据部分.

在前面关于数据包首部结构的介绍中 “TOS” 和 “Protocol” 即是与ICMP 有关的.

教授slide中给出的描述也是极好的:

Das Internet Control Message Protocol (ICMP) dient dazu, • in derartigen Fällen den Absender über das Problem zu benachrichtigen und • stellt zusätzlich Möglichkeiten bereit, um z. B. • die Erreichbarkeit von Hosts zu prüfen („Ping“) oder • Pakete umzuleiten (Redirect).

ICMP报文的种类

IPv6

IPv6基本首部

IPv4的地址耗尽后,我们很自然需要拓展IP地址块,于是就有了IPv6. IPv6仍然支持无连接的传送,但将协议数据单元PDU称为分组,而不是IPv4的数据报.

IPv6的主要变化如下:

更大的地址空间,将IPv4的32位增大到4倍, 即增加到128位.
扩展的地址层次结构.
灵活的首部格式
改进的选项
允许协议继续扩充
IPv6首部改为8字节对齐 (即首部长度必须是8字节的整数倍),原来IPv4首部是4字节对齐.

与IPv4相比, IPv6对首部中的某些字段进行了如下的更改:

取消了首部的长度字段,因为其首部长度是固定的(40字节)
取消了服务类型(TOS)字段,因为优先级和流标号字段实现了服务类型字段的功能
取消了总字段长度,改用有效荷载长度字段
取消了标识, 标志和片偏移字段,但作用是一样的
取消了协议字段
取消了检验和字段
取消了可选字段

IPv4-Header (oben) und IPv6-Header (unten) im Vergleich

IPv6基本首部各段作用

版本(version) 占4位, 指明了协议的版本, 对IPv6该字段是6
通信量类(traffic class) 占8位. 这是为了区分不同的IPv6数据报的类别或优先级. 目前正在进行不同的通信量性能的实验.
流标号(flow label) 占20位. IPv6的一个新的机制是支持资源预分配,并且允许路由器把每一个数据报与一个给定的资源分配相联系. IPv6提出流(flow)的抽象概念. 所谓 “流"就是互联网络上从特定源点到特定终点(单播或多播)的一系列数据报(), 而在这个"流"所经过的路径上的路由器都保证指明的服务质量. 所有属于同一个流的数据报都具有同样的流标号. 因此, 流标号对于实时音频/视频数据的传送特别有用.
有效载荷长度(payload length) 占16位. 它指明IPv6数据报除基本首部以外的字节数(所有扩展首部都计算在有效载荷之内). 这个字段的最大值是64KB(65535字节)
下一个首部(next header) 占8位. 它相当于IPv4协议字段的的可选字段.
跳数限制(hop limit) 占8位. 用来防止数据报
源地址 占128位. 是数据报的发送端的地址.
目的地址 占128位. 是数据报的接收端的IP地址.

下面我们来介绍一下IPv6的拓展首部

大家知道，IPv4的数据报如果在其首部中使用了选项，那么沿着数据报传送的路径上的每一个路由器都必须对这些选项一一进行检查，这就降低了路由器处理数据报的速度。然而实际上很多的选项在途中的路由器上是不需要检查的（因为不需要使用这些选项的信息）。IPv6把原来IPv4首部中选项的功能都放在扩展首部中，并把扩展首部留给路径两端的源点和终点的主机来处理，而数据报途中经过的路由器都不处理这些扩展首部 （只有一个首部例外，即逐跳选项扩展首部），这样就**大大提高了路由器的处理效率 **。

我们大概会碰到这六种扩展首部:（1）逐跳选项；（2）路由选择；（3）分片；（4）鉴别；（5）封装安全有效载荷；（6）目的站选项。

每一个扩展首部都由若干个字段组成，它们的长度也各不同。但所有扩展首部的第一个字段都是8位的“下一个首部”字段。此字段的值指出了在该扩展首部后面的字段是什么。当使用多个扩展首部时，应按以上的先后顺序出现。高层首部总是放在最后面。

IPv6的地址

一般来说, 一个IPv6数据报的目的地址可以是以下三种基本类型地址之一:

单播(unicast) 单播就是点对点通信
多播(multicast)
任播(anycast)

IPv6把实现IPv6的主机和路由器均称为结点。由于一个结点可能会使用多条链路与其他的一些结点相连，因此一个结点可能有多个与链路相连的接口。这样，IPv6给结点的每一个接口指派一个IP地址。一个结点可以有多个单播地址，而其中任何一个地址都可以当作到达该结点的目的地址。

ICMPv6

和IPv4一样,IPv6也不保证数据报的可靠交付,因为互联网中的路由器可能会丢弃数据报. 因此IPv6也需要使用ICMP来反馈一些差错信息. 新的版本成为IPv6, 它比ICMPv4要复杂得多. 地址解析协议ARP和IGMP的功能都已被合并到ICMPv6中.

ICMPv6是面向报文的协议，它利用报文来报告差错，获取信息，探测邻站或管理多播通信。ICMPv6还增加了几个定义报文功能及含义的其他协议。在对ICMPv6报文进行归类时，不同的文献和RFC文档使用了不同的策略，有的把其中的一些报文定义为ICMPv6报文，而把另一些报文定义为邻站发现 ND（Neighbor-Discovery）报文, **使用NDP协议(Neighbor Discovery Protocol)**或多播听众交付 MLD（Multicast Listener Delivery）报文。其实所有这些报文都应当是ICMPv6报文，只是功能和作用不同而已。因此我们把这些报文都列入ICMPv6的不同类别。使用这种分类方法的原因是所有这些报文都具有相同的格式，并且所有报文类型都由ICMPv6协议处理。

ICMPv6报文的结构:

Routing

Longest Prefix Matching(最长前缀匹配)

在使用CIDR时，由于采用了网络前缀这种记法，IP地址由网络前缀和主机号这两个部分组成，因此在路由表中的项目也要有相应的改变。这时，每个项目由“网络前缀 ”和“下一跳地址 ”组成。但是在查找路由表时可能会得到不止一个匹配结果。这样就带来一个问题：我们应当从这些匹配结果中选择哪一条路由呢？

正确的答案是：应当从匹配结果中选择具有最长网络前缀的路由。这叫做最长前缀匹配（longest-prefix matching），这是因为网络前缀越长，其地址块就越小，因而路由就越具体(more specific)。最长前缀匹配又称为最长匹配或最佳匹配 .

Die Routingtabelle wird von längeren Präfixen (spezifischeren Routen) hin zu kürzeren Präfixen (weniger spezifische Routen) durchsucht. Der erste passende Eintrag liefert das Gateway (Next-Hop) eines Pakets. Diesen Prozess bezeichnet man als Longest Prefix Matching.

目录