请收藏！金融行业 IPv6 建设参考

请点击上面 一键关注！

（内容来源： twt企业IT社区 ）

为贯彻落实监管发文要求，加快推进基于IPv6的互联网在金融行业规模部署，促进互联网演进升级与金融领域的融合创新，各金融机构均在抓紧进行IPv6改造。在此整理了一些社区发布的内容，包括银行专家分享的 《中小银行IPv6建设规划与规模部署思路》 ，社区金融行业同行的探讨 《金融行业 IPv6 如何改造？》 ，以及我们需要了解的 《IPv4 过渡到 IPv6 必须懂的知识点》 。供大家参考。

中小银行IPv6建设规划与规模部署思路

【摘要】 本文根据《中国人民银行 中国银保监会 中国证监会关于金融行业贯彻〈推进互联网协议第六版（ IPv6 ）规模部署行动计划〉的实施意见》银发〔 2018 〕 343 号文件的要求，在充分调研与交流的基础上，结合中小银行信息系统 IT 基础架构情况，初步形成了中小银行 IPv6 建设规划与规模部署思路，即为了切实贯彻落实国家战略部署及行业监管要求，同时更好的支撑与保障银行业务发展，以“总体规划，分步实施，稳步推进”为总体思路，以实现双中心、双协议栈应用双活部署为总体目标，同时实现双协议栈的自动化控制及可视化监控。

【作者】 涛声依旧，金融信息化专家

一、背景

IP 地址是互联网的重要基础资源。众所周知，全球 IPv4 （互联网协议第四版）地址总库早在 2011 年已经分配完毕，目前我国 IPv4 地址规模基本维持自 2011 年的 3.4 亿左右不变，人均仅 0.42 个。根据 APNIC 统计我国在用 IPv4 地址已经攀升至总地址量的 90% 。详见图 1 所示。

图 1

互联网是关系国民经济和社会发展的重要基础设施，深刻影响着全球经济格局、利益格局和安全格局，加快推进 IPv6 规模部署，是加快网络强国建设、加速国家信息化进程、助力经济社会发展、赢得未来国际竞争新优势的紧迫要求。而现有 IPv4 地址资源与我国互联网发展需求严重不匹配，对我国 “ 互联网 +” 、 5G 、工业互联网、物联网、云计算、大数据、人工智能等信息化战略部署和实施造成严重制约。为保障国家战略部署， 2017 年 11 月 中共中央办公厅、国务院办公厅联合发文《推进互联网协议第六版 (IPv6) 规模部署行动计划》，明确了实施路线图和规模部署目标。从通信运营商、 CDN 内容分发服务商等基础服务端入手，开始全面推广 IPv6 建设，为全国范围全行业实现 IPv6 接入提供了基础支撑。从统计数据可以看到，无论是从实际分配 IPv6 地址数量还是从 IPv6 活跃用户数，从 2017 年开始均有了显著增长。详见图 2 。

图 2

2019 年 1 月 10 日，中国人民银行、银保监会、证监会联合发布《关于金融行业贯彻 < 推进互联网协议第六版（ IPv6 ）规模部署行动计划 > 的实施意见》，进一步明确了未来金融行业 IPv6 建设与规模部署的行动目标。

二、建设规划与规模部署思路

IPv4 和 IPv6 协议并不兼容，二者在 IP 地址格式 、网络架构、 DNS 解析过程、终端行为、主机系统、存量业务应用等层面不能直接通信，因此在其长期共存、阶段过渡、规模升级的过程中，应当充分考量网络和业务场景适应、技术风险控制、投资合理性及投资保护等方面因素，并遵循以下原则执行 IPv4 到 IPv6 的技术演进及规模部署 :

1、以不影响“现有 IPv4 存量业务”为前提

由于国内 IPv6 推广略有滞后，从 IT 基础设施的建设到运维经验的积累均需要时间和过程的积累。为避免由于 IPv6 建设过程中对 IPv4 存量业务造成影响，影响用户体验， IPv6 建设的相关设备与应用建议独立部署，不与 IPv4 共用基础架构。

2、遵循 343 号文 “ 三步走 ” 的实施路径要求

• 初期阶段：至 2019 年底，实现门户网站支持 IPv6 连接访问。

• 规模推广阶段：至 2020 年底，面向公众服务的互联网应用系统支持 IPv6 连接访问，并具备与 IPv6 改造前同等的业务连续性保障能力。

• 持续建设阶段：2021 年起，在做好面向公众服务的互联网应用系统 IPv6 改造基础上，持续推进 IPv6 规模部署，逐步构建高速率、广普及、全覆盖、智能化的下一代互联网。

3、以合理可控的成本渐进式改造部署

以较为合理的技术改造成本进行路线选型和规划，有效保护已有的投资，避免全网设备更替、业务重构；

4、把控运维管理风险

IPv6 的引入必然会对传统网络的可视化运营、自动化维护、安全管理带来新的挑战，规模升级 IPv6 要经历一个逐步成熟完善的过程，一方面需要确保可控可管的安全运维机制同步建立，另一方面尽可能降低共存演进时期场景复杂度带来的运维风险；

5、按步骤引入 IPv6 适配新业务

部署 IPv6 在保障支持现有用户业务的前提下，应逐步丰富 IPv6 建设与规模部署经验，带动存量设备和应用的加速演进，不断提升网络的承载能力和服务水平，促进创新网络安全保障手段，实现下一代互联网各环节平滑演进升级。

根据以上原则并结合中小银行现有 IT 基础架构，整体规划了以下建设技术思路：

在初期规划时选择新建单独 IPv6 接入区的方式实现业务发布。IPv6 接入区中通过智能 DNS 实现 AAAA 记录的发布以及流量的智能调度。在满足当前业务需求的前提下，为 2020 年实现更高的 IPv6 业务连续性提供架构保障。通过本地负载均衡 LTM 实现 IPv6 业务的发布和改造初期的应用适配。整体建设上将 IPv6 区域以灰度发布的思路进行部署， 对于业务最关键的价值是 IPv6 区域的故障完全不影响原 IPv4 区域业务的安全稳定运行。初期规划 既保证了 成本的合理可控，又为后续渐进式改造部署提供了灵活性及可拓展性。

DNS 智能引导的必要性

IPv6 规模建设初期，全国范围内实现运营商互通的骨干交换节点数量有限。运营商之间通信可能通过较长的路径到达数据中心，跨运营商通信的业务延迟将会对用户体验带来影响。因此在 DNS 解析层面需要实现智能的流量引导。其中最基本的原则是根据 LDNS 所属的运营商做智能的判断，返回给 LDNS 相同运营商的业务地址。DNS 设备在选型时需要考虑设备自身 IPv6 地址库的完整性、可自定义性和可更新性。在此基础上，还需要对运营商线路进行实时有效的监控，并可通过 DNS 设备反应出线路的故障，实现线路故障时平滑切换到其他 IPv6 或 IPv4 线路。初期 IPv6 上线过程中，可能存在没有申请全部运营商线路的情况，为了保证客户体验需 DNS 设备通过动态 RTT 监测，选择 RTT 最优的线路返回业务地址。总之，智能 DNS 作为流量引导的“大脑”，通过合理的算法组合确保终端用户能够以最优的路径访问到数据中心。

改造初期应用层适配

初期 IPv6 改造中重点需要考虑的应用层问题是客户端地址溯源和外链天窗的适配。IPv6 地址转换成 IPv4 地址后，对于 C/S 架构的应用可以将客户端真实地址插入到 TCP Option 中，后端程序需要开发相应的模块对 TCP Option 中的真实地址进行提取。对于 B/S 架构的应用，可以将客户端真实地址插入到 X-Forward-For 头中，后端程序针对相应的插入位置进行提取即可。如果后端程序提取 IPv6 地址存在困难，也可通过应用交付设备将地址转换前后的对应列表以日志的方式输出到外部日志平台。

IPv6 改造过程中的应用天窗问题关乎客户体验，也是不可忽视的一个环节。此问题可通过应用交付设备上的可编程功能功能来完美的实现适配，遵循的基本原则是将外链替换为数据中心自身的地址，通过应用交付设备代理客户端访问外链地址。在实际改造中会碰到一些负载的外链，例如多层 js 嵌套的外部链接，需要对 js 进行分析后进行相应的适配。通过外链天窗的适配，可以保证终端客户无感知的切换到 IPv6 服务。

三、下一步建设目标

IPv6 建设及规模部署将会是一个长期渐进的过程，根据 343 号文件要求，至 2020 年底，面向公众服务的中小银行互联网应用系统支持 IPv6 连接访问，并具备与 IPv6 改造前同等的业务连续性保障能力。针对 IPv6 长期建设的目标需要从纵向应用建设、横向多中心建设、自动化部署、运维可视化及 IPv6 信息安全几个方面进行规划。

从整体架构扩展的角度看，纵向应用建设是将 IPv6 改造从接入区逐渐纵向推进到 DMZ 区以及应用区，实现 IPv4 和 IPv6 业务区的独立部署。初期实践过程中会包括新增应用和已经完成 IPv6 改造的应用。原有只支持 IPv4 的应用仍在原有应用区部署和运行。协议栈之间的彼此通讯通过应用交付设备来实现，最终实现单一中心内双协议栈的并行运行。

横向多中心建设是指在单中心双协议栈运行稳定后，通过在同城中心部署相同的架构实现双中心双协议栈的应用双活。整体双活架构通过智能 DNS 进行调度，之前 IPv4 双活和 IPv6 运营经验可以帮助在双中心双协议栈双活建设中提供经验。进一步确保双协议栈下业务的高可用性。

由于 IPv6 地址长度的增加，人工配置和管理 IPv6 地址的挑战将会非常大，自动化部署在 IPv6 环境中变得必不可少。

在 IPv6 未来的自动化部署中可遵循以下流程实现配置的自动化和管理的标准化：

• IPv6 地址统一管理，统一规划

• 通过工单系统实现自动的 IPv6 地址申请

• 通过自动化平台自动配置 IPv6 地址到对应的网络设备、服务器或应用交付设备

• 业务发布通过自动化脚本实现

• 通过 DNS API 进行自动域名添加，实现域名与 IPv6 地址自动对应，便于管理

运维可视化展示平台可以体现未来双中心双协议栈的运营情况。双中心双协议栈运营情况下，通过对设备告警，设备状态以及业务数据进行收集，实现对告警基线，安全基线和业务基线的评估，从而根据这些基线实现基于大数据的智能运维。

针对运维可视化部分可以通过对所有设备实现统一的纳管和告警以及状态的收集实现运维大数据分析，实现智能告警和智能运维。通过 DNS 设备调度日志的收取，形成双中心和双协议栈的运营数据的展示；通过应用数据的收集，形成业务基线和安全基线，从而实现业务大数据的分和展现。

针对 IPv6 网络安全方面，坚持建设与安全并举，实现网络、应用、安全的协同，将 IPv6 改造与运维保障、网络安全工作同步规划、同步建设、同步运行，稳步推进 IPv6 规模部署。除了在访问控制、入侵检测防御、流量分析清洗、 WEB 安全防护方面保障 IPv6 网络安全防护能力外，同时还要不断跟踪 IPv6 安全现状，并借鉴先进同业做法，完善针对 IPv6 的网络安全和应用安全防范措施，提高安全应急演练。

四、结语

IPv6 是关乎国家战略的一项任重而道远的任务，在规模部署过程中我们要做到稳步前行逐渐推广。在实现 IPv6 业务发布的同时又不能够影响到现有 IPv4 业务的稳定性，而且在双协议栈运行的场景下要保证客户访问的体验，更要保护业务的安全。双中心双协议栈运行场景下，自动化和可视化将变为不可或缺的两个关键条件，在 IPv6 整体建设中也需要重点考虑 。

原文地址：https://www.talkwithtrend.com/Article/247713

金融行业 IPv6 如何改造？

【导读 】 为贯彻落实监管发文要求，加快推进基于IPv6的互联网在金融行业规模部署，促进互联网演进升级与金融领域的融合创新，各金融机构均在抓紧进行IPv6改造。以下是一些金融同行的分享和解读，包括困难和问题、策略与规划，后附 IPv4 过渡到 IPv6 应知知识点，供大家参考。

目标与现状

根据人行、银监等监管指导意见，截至 2019 年底，金融服务机构完成本单位总部及下辖机构门户网站 IPv6 改造工作，并在其首页标识该网站已支持 IPv6 。除有用户权限登录控制的定制应用系统外，门户网站主域名内全部静态页面、动态页面、多媒体资源和第三方应用插件等均支持 IPv6 连接访问；页面链接的全部子域名网站均完成 IPv6 改造。

IPv6 改造行业示范机构至少选择一个活跃用户规模在本机构内排名前 3 位（含）的移动 APP 应用系统，使其支持 IPv6 连接访问，并在其首页标示该应用已支持 IPv6 。到 2020 年底，金融服务机构完成所有面向公众服务的互联网应用系统相关软硬件基础设施的升级改造工作，所有软硬件基础设施均支持 IPv6 协议。金融服务机构所有面向公众服务的互联网应用系统，全部支持 IPv6 连接访问，并保证在 IPv6 和 IPv4 环境下，具备同等的业务连续性保障能力。

现状：数据中心软硬件基础设施大多支持双栈，但均为IPv4协议通讯，金融公司如已进行IPv6双栈支持，也仅通过外部互联网入口的负载均衡进行IPv6配置，数据中心内部仍为IPv4通讯。 （来自社区会员分享）

困难与问题

@gxcornflakes 某金融单位 信息技术经理 ：

整个应用系统架构涉及面众多，如外部资源（CDN、域名）、硬件资源（安全设备、网络设备、服务器、存储设备、负载均衡、DNS等）、软件资源包（操作系统、数据库、中间件）以及应用本身等，此外大规模集群（IaaS云、容器云、大数据），如何既能循序渐进地进行IPv6改造又能在改造过程中保障应用服务的稳定性，特别是硬件设施网络设备的改造可能涉及多数据中心、多网络区域通讯，影响面很大。但是这块又非常重要，国家发文必须要要让金融企业做一些成果出来，但是大家的经验应该都不够，希望看到大家的探讨。

@sirius118 某农商银行 网络工程师：

现在面临的问题有：

如何保证在国家或监管机构的规定时间内完成全部业务平台的改造，并对外提供 IPv6 服务？

如何保证在规定时间内完成全部设备的更换，满足双栈要求？

如何预估开通双栈后原有的设备是否能够满足开通双栈的性能要求？如何保证开通双栈后， IPv4 和 IPv6 互不影响？如何保证 IPv4 与 IPv6 数据的同步？

使用过渡技术如何保证页面的完整性，网站主域名内全部静态页面、动态页面、多媒体资源和第三方应用插件等的 IPv6 连接访问？

过渡技术能否支持页面链接的全部子域名网站升级？能否支持本网站引用的外部链接可访问、内容可呈现？能否支持所有面向公众服务的互联网应用系统的 IPv6 连接访问？

过渡技术如何保证业务系统，包括网络银行、手机银行 APP 等对外服务平台的 IPv6 改造后的业务保障能力？

如何保证升级后的应用系统能够支持业务系统的密码验证功能（ Ukey) 、能够支持 Http 、 Https 地址溯源、能够支持 IPv4/IPv6 网络切换会话保持？

过渡技术能否保证网络 IPv6 升级的递进式推进，实现应用系统改造及软硬件基础设施升级相结合，延长原有设备的生命力，从而保护已有网络资源及设备的投资？

@某银行 技术主管：

我是谨慎乐观的态度。 目前的顾虑主要在于：

设备的bug，我认为传统IPv4环境中的设备的bug算是经过了比较充分的测试（除了这个用户还有那个用户，总体的装机基数在），换成IPv6，可不好说有多少bug待我们去面对。bug不可怕，可怕的是业务中断的压力。

我们不是试点单位，今年只要网站改造。今年计划用CDN实现转换，CDN服务商解释说DNS部分，运营商会实现4-6的DNS的转换，这部分有点不明白，这个轰轰烈烈的改造，基础设施部分目前有没有权威的解释。IPv4部分么，传统的运营商、网络设备厂商、安全厂商等各有重叠，总之是基本覆盖全了，IPv6部分，看不清一个完整的景象。

策略与规划

@sirius118  某农商银行 网络工程师：

应对策略：

金融行业的 IPv6 改造是一项长期工作，针对目前 IPv6 部署困境，国家提出支持采用网络过渡技术创新方式。要全面、妥善地解决以上普遍存在的问题，建议按照路线图的安排，分步骤、分区域逐步实现对所有系统的 IPv6 改造。

在过渡初期， 通过 NAT64 等技术，在短时间内快速实现业务平台对外提供 IPv6 服务。解决双栈化升级周期长、难度大的业务痛点。

过渡中期， IPv4 与 IPv6 需要并存很长时间，有计划地改造业务平台软件以及数据库、 Web 服务器等支撑系统，部分对外提供纯 IPv6 服务的系统，也可通过 NAT64 做地址翻译，为 IPv4 用户提供服务，逐步实现全部平台均具备对外提供纯 IPv6 服务的能力，保证 IPv4 与 IPv6 数据的同步性。在过渡期，还有很多 IPv4 应用会出现难以升级，无法升级，或无法找到原厂升级等众多情况，这些无法升级的 IPv4 应用，也可以长期使用 NAT64 技术做转换服务。

过渡后期， 很多应用为开发便利，以单栈 IPv6 开发并发布，也可以将 IPv6 应用翻译成 IPv4, 为留存的 IPv4 用户提供访问服务。

@leodong 某银行 系统工程师：

根据监管要求，现在研发新上的应用业务软件、或者原有的业务系统维保以及硬件设备都会要求支持IPv6，早做准备。 目前正在规划实施阶段。

计划先对官网进行IPv6改造，从基础设施、操作系统、应用软件全部使用IPv6。然后再逐渐对网银、手机银行、微信银行等电子渠道逐渐进行改造，从互联网计入的负载->Web的负载->应用程序负载->数据库逐步向内改造。

目前交换机是否满足开启双栈的性能要求；同时目前IPv6的地址申请各个运营商目前还没有成熟完备的流程；IPv6地址的管理，需要更多的使用DNS；目前业务应用程序对IPv6的支持还不够全面。

@黄江 某银行 技术支持：

目前来说，主要是全局负载均衡与本地负载均衡厂家在进行配合与测试。

主要是分四个阶段进行：

第一阶段： 公网逐步改造， 公网逐渐进行IPv6的替换，此时应用交付可以通过NATPT(NAT44/NAT64)可实现将IPv6向IPv4自动切换，首先AD上发布IPv6业务地址，用户内网不做改动，适应运营商骨干网的业务改造。

第二阶段： 内网逐步改造， 内网逐渐进行IPv6的替换，业务内网并存IPv4和IPv6服务器，此时应用交付可以通过NATPT（NAT44/NAT66）实现IPv4和IPv6的业务转换，可同时兼容内网双栈改造。方便用户将IPv4、IPv6业务逻辑分离，可看出IPv6的业务分布情况和客户端流量等，便于服务器审计

第三阶段： 内网改造完成， 内网业务系统全面切换到IPv6， 此时应用交付可以通过NATPT（NAT46/NAT66）可兼容骨干网上未改造完成的IPv4业务。

第四阶段： 内外网完全改造， 内网完全完成IPv6的替换， 此时应用交付可以通过NATPT（NAT66）实现最终改造完成。

改造方式主要是两种：

改造方式一 ：

在整个互联网出口边界最外侧进行改造，从运营商引入IPv6出口，增加网站域名对应IPv6地址的域名解析。在出口增加两台负载均衡做IPv6改造,将新增的IPv6线路连接到新增的负载均衡设备上，使用NAT-PT技术将访问业务系统的IPv6报文转换为IPv4报文，保证从负载均衡向内网业务系统方向出去的数据报文全部转换为IPv4的报文，实现的效果是负载均衡设备以上的网络运行IPv6和IPv4双栈，负载均衡以下的设备运行仅IPv4地址。

优点：

改造实现简单，只需要出口网络设备和NAT设备（负载均衡）支持双协议栈即可，其他网络设备、安全设备以及业务系统无需调整。

缺点：

1.端到端的安全性无法保证，在攻击溯源、流量审计等方面存在较大隐患，难以定位和具体封堵攻击源；

2.原有运行逻辑，业务流程，防护层次被打破，运行监控体系无法发挥效果。

改造方式二：

从运营商引入IPv6出口，增加网站域名对应IPv6地址的域名解析。IPv6改造深入至业务边界，在业务负载均衡上配置IPv6虚地址（站点本地地址），在负载均衡设备上进行IPv6虚地址与IPv6实地址（全局单播地址）的一对一映射，在业务负载均衡上同时监听IPv4和IPv6的端口访问请求，通过业务负载均衡将IPv6访问请求转换为IPv4访问请求，发送给对应的业务系统。业务负载均衡设备及以上的网络运行IPv6和IPv4双栈，业务负载均衡设备及以下运行仅IPv4地址。

优点：

1.改造实现难度适中，只需要业务负载均衡及以上设备支持双协议栈即可，其他网络设备及业务系统无需调整；

2. 现有运行逻辑，业务流程，防护层次未发生改变，运行监控体系基本有效；

3. 能基本实现端到端的安全性法，在可以进行攻击溯源、流量审计，能够定位和具体封堵攻击源。

缺点：

1.改造难度较方式一略大；

2.需要评估现网中网络、安全以及负载均衡设备对IPv6的支持情况和性能压力；

3. 需要考虑外网安全设备针对IPv6网络安全防护情况，是否能够达到目前网络安全防护的要求。

@某银行 技术主管：

私以为金融机构在认真研读监管文件，满足监管要求的同时，最重要的是在当下开始在各个领域认真的做并重视去做IPv6的技术储备，IPv6未来都必须要转型到这里，但是目前技术储备对我们中小银行来说是非常重要的。IPv6绝非改个地址族那么简单，对整个基础架构、应用架构甚至企业IT规划都有深远的影响，如果想当然操之过急铺开来去做，一些不成熟的想法和做法往往会为后期长远的发展带来不利。至于具体的措施，家家有本难念的经，因为基础架构和应用架构的差异，其实能相互借鉴的只是大的方向，希望看看其他同僚的观点。

@yjw：

个人看法在整个银行网络中IPV4向IPV6在演进的过程中大的可以分为两步：

1、网络先行： 先把网络从V4演进到V6。然后，在逐步的修改应用。在网络先行中也可分为两步：数据中心和骨干网。从目前大行目前是先做的网络SRv6做骨干网。

2、业务先行： 先让业务支持v6。通过6to4 和4to6手段解决互通问题。比较繁琐。

*以上内容来自社区会员分享

IPv4 过渡到 IPv6 必须懂的知识点

网络是工程师的基础技能之一，毕竟没有网络我们什么也干不了！ 从各大公司的招聘要求上看，网络也是重点的考核部分。 今天就和大家一起复习下(还)大学里的课程(欠下的债)！ TCP/IP协议簇的IP协议。

理解网络模型

网络的设计大佬们想出了分层的设计，将各个功能分开，交付给不同的层，这样的好处是便于更新和维护(IPv6的到来并没有使整个网络重新设计)，也便于我们的学习和理解。下面是各个版本的网络体系的结构图：

让我们明确下 各层的工作职责(以五层协议为例):

• 应用层，该层协议主要负责各个应用程序之间交互的规则，如HTTP、DNS，其交互的数据单元可以称为”报文”。

• 运输层，为应用层提供通用的数据传输服务，为上层跑腿的。TCP、UDP均是运输层协议。

• 网络层，为网络中不同的主机提供通信服务，IP协议工作在该层。

• 数据链路层，负责相邻两点的数据传送。

• 物理层，传输比特流，0 或 1。每一层将数据封装成自己能理解的数据格式，交付给下一层，下一层将收到的作为自己的数据再次添加本层的必要数据，向下交付，直到链路层，传递到目的地后，每层再将该层的必要数据去掉，交付给上层。如下图：

理解IP协议

在理解了网络模型和各层直接的配合之后，下面进入正题：网际协议(IP)。

主要理解IP协议给我们提供的功能有哪些，说白了就是它能干嘛。

• 为网络中的主机(PC或路由或网关)提供身份证。

• 定义了网络主机的基本交流方式，从IP数据报的格式可以看出。

• 为路由寻址提供方便，从路由表结构可以看出。

任何一个协议都可以由语法，语义和同步三部分组成。

• 语法，交换信息的格式，对于IP协议，就是IP报文的格式。

• 语义，即需要发出何种控制信息，以及接收到信息后如何响应。

• 同步，对事件顺序的详细说明。

也就是定义了使用IP协议进行交流的法则 。

IPv4

IPv4是IP协议的第4个版本 ， 就是我们现在使用的。下面从多个方面了解下该版本 。

IP地址

网络上的主机都需要一个IP地址 ， 这样才能知道彼此的位置。IPv4地址由32bit构成，常使用点分十进制表示(192.168.1.1)。

分类

IP地址的分类就是把所有IP划分为若干类别，每一类都由固定长度的字段组成，分别为网络号和主机号。下面是各类地址组成示意图：

• A类地址，8位网络号，第一位固定为0,可用的网络号只有126个(2^7-2)，网络号从0到127。减去2是因为：IP地址全为0表示”本网络”，保留； 网络号为127作为软件回环测试使用，若主机发出目的地为127.0.0.1的数据时，该数据不会向任何网络上的主机发送。也就是说127开头的地址不能使用.。对于A类地址中的每一个网络号，对应的主机号有(2^24-2)个：主机号全0表示，其网络号对应的网络地址，全1表示所有主机的意思。

• B类地址网络号为16位 ， 但前面2位以固定为1 0。无论怎么取值 ， 无法出现全0或全1的情况。128.0.0.0的网络是不使用的 ， 实际使用的最小B类网络地址为128.1.0.0，所以B类的网络地址有(2^14-1)个。

• C类的地址有24位的网络号，最前面的3位固定为1 1 0.192.0.0.0的网络地址也是不使用的,，最小的C类地址为192.0.1.0。

总结如下:

分类的好处:

• 方便管理 ， IP地址管理机构只需管理网络号 ， 剩下的可以由下级管理。

• 路由寻址时根据网络地址转发分组 ， 减小路由表。

数据报格式

先看下IP数据报的基本格式：

可以看到IP数据报包含了首部和数据部分。其中首部包含固定的20字节和可变的部分 。 下面是各部分的解释：

• 版本，占4位 ， IP协议的版本号 ， 通信双方需要相同 。

• 首部长度 ， 占4位 ， 单位4字节 。 最大能表示(2^4-1) * 4 = 60字节 。 当IP分组的首部长度不是4的整数倍时 ， 需要使用填充字段填充 。

• 区分服务 ， 占8位 ， 表示服务类型 ， 未使用 。

• 总长度 ， 占16位 ， 表示首部和数据部分的总长度(单位字节).因此数据报的最大总长度为(2^16-1 = 65535)字节 。

• 标识(identification) ， 占16位 。 当数据报长度超过下层的MTU时，需要分片 ， 被分片的数据报的标识一样 ， 这样可以进行重组 。

• 标志(Flag) ， 占3位 ， 目前只有2位有意义

  最低位，MF(More Fragment) = 1 表示后面还有分片。MF = 0 表示分片中的最后一个。

  中间一位，DF(Don’t Fragment)，不要分片，只有当DF=0才允许分片

• 片偏移 ， 占13位.较长的分组在分片后 ， 某片在原分组的相对位置 。 必须是8字节的整数倍 。

• 生存时间 ， 占8位 ， Time To Live(TTL) ， 开始指生存的秒数,后来变为经过路由的跳数 ， 每经过一个路由 ， TTL减小1 ，