IPV6地址格式分析，谢谢

IPv6地址表达方式、寻址模型和地址空间
多年以来， IP地址被认为是可以在IP网络上最终唯一并持久的节点标识符。近年中，尤其是随着下一代IP技术的发展，对于IP地址的这种观点正在改变。如果我们仍像过去2 0年中所使用的方法来分配网络和节点地址，那将是一种不必要和低效的办法。
本章在介绍了RFC 2373(IPv6寻址体系结构)中描述的IP寻址体系结构之后，将首先介绍一些与IP寻址相关的议题。然后将介绍几种可能的地址分配方法。本章将IPv6寻址分成了以下几个部分： 1 2 8位地址的结构和命名及IPv6地址的不同类型(单播、组播和泛播)。
IPv6的设计者们可以只是简单地在IPv4寻址体系结构中扩大地址空间。但是这样一来将使我们丧失一个改进IP的巨大机会。对于整个寻址体系结构的修改所带来的巨大机会，不仅体现在提高地址分配的效率上，同时也体现在提高IP选路性能上。本章将介绍这些改进，第8章对于IPv6选路议题将有更加详细的介绍。而地址分配、移动网络技术和自动配置将在第11章中有详细讲解。
RFC 2373于1 9 9 8年7月发表，并废弃了最早于1 9 9 5年1 2月发表的RFC 1884(IPv6寻址体系结构)。其中大部分变化源自在最初的R F C发布后的两年半中被认为是必需要进行澄清、更正和修改之处。
地址
IPv4与IPv6地址之间最明显的差别在于长度： IPv4地址长度为3 2位，而IPv6地址长度为1 2 8位。RFC 2373中不仅解释了这些地址的表现方式，同时还介绍了不同的地址类型及其结构。IPv4地址可以被分为2至3个不同部分(网络标识符、节点标识符，有时还有子网标识符)，IPv6地址中拥有更大的地址空间，可以支持更多的字段。
IPv6地址有三类、单播、组播和泛播地址。下一节将对此作更详细的介绍。单播和组播地址与IPv4的地址非常类似；但IPv6中不再支持IPv4中的广播地址，而增加了一个泛播地址。本节介绍的是IPv6的寻址模型、地址类型、地址表达方式以及地址中的特例。
地址表达方式
IPv4地址一般以4部分间点分的方法来表示，即4个数字用点分隔。例如， 下面是一些合法的IPv4地址，都用十进制整数表示：
10531
127001
201199244101
IPv4地址也时常以一组4个2位的十六进制整数或4个8位的二进制整数表示，但后一种情况较少见。
IPv6地址长度4倍于IPv4地址，表达起来的复杂程度也是IPv4地址的4倍。IPv6地址的基本表达方式是X:X:X:X:X:X:X:X，其中X是一个4位十六进制整数( 16位)。每一个数字包含4位，每个整数包含4个数字，每个地址包括8个整数，共计1 2 8位( 4×4×8 = 128 )。例如，下面是一些合法的IPv6地址：
CDCD:910A:2222:5498:8475:1111:3900:2020
1030:0:0:0:C9B4:FF12:48AA:1A2B
2000:0:0:0:0:0:0:1
请注意这些整数是十六进制整数，其中A到F表示的是1 0到1 5。地址中的每个整数都必须表示出来，但起始的0可以不必表示。
这是一种比较标准的IPv6地址表达方式，此外还有另外两种更加清楚和易于使用的方式。
某些IPv6地址中可能包含一长串的0 (就像上面的第二和第三个例子一样)。当出现这种情况时，标准中允许用“空隙”来表示这一长串的0。换句话说，地址
2000:0:0:0:0:0:0:1
可以被表示为：
2000::1
这两个冒号表示该地址可以扩展到一个完整的1 2 8位地址。在这种方法中，只有当1 6位组全部为0时才会被两个冒号取代，且两个冒号在地址中只能出现一次。
在IPv4和IPv6的混合环境中可能有第三种方法。IPv6地址中的最低3 2位可以用于表示IPv4地址，该地址可以按照一种混合方式表达，即X:X:X:X:X:X:dddd，其中X表示一个1 6位整数，而d表示一个8位十进制整数。例如，地址
0:0:0:0:0:0:10001
就是一个合法的IPv4地址。把两种可能的表达方式组合在一起，该地址也可以表示为：
::10001
由于IPv6地址被分成两个部分—子网前缀和接口标识符，因此人们期待一个IP节点地址可以按照类似CIDR地址的方式被表示为一个携带额外数值的地址，其中指出了地址中有多少位是掩码。即，IPv6节点地址中指出了前缀长度，该长度与IPv6地址间以斜杠区分，例如：
1030:0:0:0:C9B4:FF12:48AA:1A2B/60
这个地址中用于选路的前缀长度为6 0位。
寻址模型
IPv6寻址模型与IPv4很相似。每个单播地址标识一个单独的网络接口。IP地址被指定给网络接口而不是节点，因此一个拥有多个网络接口的节点可以具备多个IPv6地址，其中任何一个IPv6地址都可以代表该节点。尽管一个网络接口能与多个单播地址相关联，但一个单播地址只能与一个网络接口相关联。每个网络接口必须至少具备一个单播地址。
这里有一个非常重要的声明和一个非常重要的例外。这个声明与点到点链路的使用有关。在IPv4中，所有的网络接口，其中包括连接一个节点与路由器的点到点链路(用许多拨号Internet连接中)，都需要一个专用的IP地址。随着许多机构开始使用点到点链路来连接其分支机构，每条链路均需要其自己的子网,这样一来消耗了许多地址空间。在IPv6中，如果点到点链路的任何一个端点都不需要从非邻居节点接受和发送数据的话，它们就可以不需要特殊的地址。即，如果两个节点主要是传递业务流，则它们并不需要具备IPv6地址。
为每个网络接口分配一个全球唯一的单播地址的要求阻碍了IPv4地址的扩展。一个提供通用服务的服务器在高需求量的情况下可能会崩溃。因此， IPv6地址模型中又提出了一个重要的例外：如果硬件有能力在多个网络接口上正确地共享其网络负载的话，那么多个网络接口可以共享一个IPv6地址。这使得从服务器扩展至负载分担的服务器群成为可能，而不再需要在服务器的需求量上升时必须进行硬件升级。
下面将要讨论的组播和泛播地址也与网络接口有关。一个网络接口可以具备任意类型的多个地址。
地址空间
RFC 2373中包含了一个IPv6地址空间“图”，其中显示了地址空间是如何进行分配的，地址分配的不同类型，前缀(地址分配中前面的位值)和作为整个地址空间的一部分的地址分配的长度。
在IPv6地址分配中需要注意几点。首先，在RFC 1884中，地址空间的四分之一被用于两类不同地址：八分之一是基于供应商的单播地址，而另八分之一是基于地理位置的单播地址。人们希望地址的分配可以根据网络服务供应商或者用户所在网络的物理位置进行。基于供应商的集聚，正如它最初的名字一样，要求网络从提供Internet接入的供应商那里得到可集聚的IP地址。但是，这种方法对于具有距离较远的分支机构的大型机构来说并不是一种完美的解决办法，因为其中许多分支机构可能会使用不同的供应商。基于供应商的集聚将为这些大单位带来更多的IP地址管理问题。
Steve Deering提议把基于地理位置的地址分配方法作为SIP( SIPP的前身，在第4章中有介绍)中的一种办法。这些地址与基于供应商的地址不同，以一种非常类似IPv4的方法分配地址。这些地址与地理位置有关，且供应商将不得不保留额外的路由器来支持IPv6地址空间中可集聚部分外的这些网络。
ISP实际上并不赞同这个解决方案，因为管理基于地理位置的寻址将大大增加复杂性(和花费)。另一方面，难以对基于供应商的地址进行配置和重配置也引起许多对基于供应商的分配方案的反对。如果没有广泛使用基于IPv4自动配置方案(如DHCP )，那么所有机构的网络将会存在巨大的管理问题。尽管IPv6对于自动配置功能有着更好的支持，但并没有将地理位置的分配方法最终融合进去。
注意，绝大部分的地址空间并没有分配，地址分配的第一部分被保留了下来。

上一篇文章发出来，得到些好评，还是很欣慰的，我们会继续努力把美国的数据做成标杆，并且尽快推动其它国家进入实施阶段。晚上正好和一个朋友兼客户说起来，他说他们业务需要正在筹建全球的 POP 点，我说也许我可以把全球数据中心的概况给大家介绍一下，所以，这篇又来让你了解一下了。
先声明一下，这个算是科普文，所以资深人士请绕行。
现在越来越多的国内互联网公司在做出海的事情，既然是互联网公司，那么海外网络规划自然是一大重点。曾经流行的段子说互联网有两个，一个是全球互联网，一个是中国互联网。无论国内国外，费心做了选择，合同签了，款也付了，服务也上架了，结果发现体验远不如预期，用户天天投诉慢慢慢，钱其实是小事，重新评估和再次迁移业务可是很麻烦麻烦的。
那么既然是网络地理知识，我们分开从两个角度说。还有一个限定，就是这里说的数据中心应该是指可以面向全球化服务的数据中心，如果是个面向本地的数据中心，估计在运营商的机房里辟块地方就够了。大可不必拿来讨论。
先说地理位置：
既然是谈数据中心，地理位置一定是个重点，那么大家都大概率的知道数据中心的选址要地理位置尽量远离地震带，温度适宜，PUE 越低越好，电费也是越便宜越好。但是因为数据中心理论上算是个数字房地产项目，所以不太可能离城市太远，不然运输和单位建造成本会很高，数据中心规模又不能太小，你都面向全球了，至少几千个机架起吧。交通方面也需要尽量便利，你运台服务器过去，国内都要两个礼拜，大家就都跪哭了。还有就是方便接入到足够多的运营商网络，尽力覆盖全国包括跨境流量，所以海边的城市会有便宜可占。最后一项，数据中心需要足够能力的人来运营，你弄个山沟沟，谁愿意去呢？
还是先说结论，一般来说，国家的首都和第二大城市，其次包括人口密集的城市比如区域的中心城市，都会是建设数据中心的首选位置。
我们假设我们是一个全球化的大型互联网公司，要建设自己的 CDN 网络，不差钱（但还没有钱到自己建设数据中心），只想提供最好的网络体验给用户，那么我们会在哪里选择数据中心呢？我们总结了国内外的各种 CDN 厂商的数据中心位置情况，大体总结如下。
先看看中国内地的情况：
运营商的三大网络出口城市，北京、上海、广州，应该是首选。
几亿人的规模，估计要做省级覆盖。那么每个省的省会是首选，是否有其它城市可选择会随着本地用户数量以及网络发达程度密切相关，还有一个特殊情况。比如山东青岛、江苏无锡，广东特殊一点，至少东莞、深圳都可以入选。西部就会比较弱，一般就只剩省会了。
当然，国内有个比较现实的问题，因为 CDN 在国内早已经进入红海阶段，所以各大 CDN 公司的数据中心选址都在从大城市往二线甚至更低的城市数据中心迁移，因为带宽成本便宜，这会导致省内网络流量不均衡，但是其实从体验上讲不如放在省会城市更好的，不过价格战胜了一切。
可能有人会说中卫，中卫应该说是没有更好选择下的最好选择了。也许很多公司会把灾备和数据存储放在那里，但未必是主力机房。而且中卫不是为全球准备的，是为中国准备的。包括苹果的国内数据中心也是如此。这个话题以后有机会再说。
那么看看去掉中国内地的亚太地区的选择：
香港、新加坡是亚洲核心，如果我只能选择两个，我会选择他们。
日本：东京和大阪，双轮驱动。
韩国：首尔。
印度：最好是德里/新德里、孟买、金奈、班加罗尔等几个城市一起上。
台湾：首选台北市，用户足够多再来一个高雄市。
印度尼西亚：雅加达
越南：胡志明市、河内
泰国：曼谷
马来西亚：吉隆坡
菲律宾：马尼拉
以上基本按照各自国家拥有的 IP 数量排序。
澳大利亚：五大护法，悉尼、墨尔本、布里斯班、阿德莱德和珀斯。
新西兰：奥克兰。
中东部分选择比较少，首选阿联酋的迪拜和以色列的特拉维夫。
说说北美地区：
美国的选择很多，但是通常来说是分为几个区域：
西部：加利福尼亚州的洛杉矶、圣地亚哥、湾区（旧金山到圣何塞之间）和华盛顿州西雅图和俄勒冈州波特兰，内华达州拉斯维加斯。犹他州的盐湖城、科罗拉多州的丹佛。
中部：德克萨斯州的达拉斯、休斯顿、奥斯汀、圣安东尼奥，堪萨斯州和密苏里州各有一个堪萨斯城。
北部地区：伊利诺伊州的芝加哥、明尼苏达州的明尼阿波利斯、密歇根州的底特律、印第安纳州的印第安纳波利斯。
南部地区：乔治亚州亚特兰大，佛罗里达州的迈阿密，北卡罗来纳州的夏洛特。
东部地区：宾夕法尼亚州的费城，华盛顿特区，弗吉尼亚州的阿什本/赫恩登/雷斯顿等贴近华盛顿特区的地区，纽约州纽约市，新泽西州的皮斯卡特维、纽瓦克、锡考克斯等贴近纽约市的地区，马萨诸塞州的波士顿。
其中数据中心最密集的区域是洛杉矶、湾区、西雅图、达拉斯、芝加哥、亚特兰大、迈阿密、贴近华盛顿特区的弗吉尼亚州的阿什本/赫恩登/雷斯顿地区。
加拿大反而简单，一般来说，西部的温哥华、东部的多伦多、蒙特利尔，再加上中部的温尼伯就足够覆盖加拿大了。最多再加一个卡尔加里。
墨西哥，简单，墨西哥城。
南美地区的选择比较少，巴西是互联网最发达的国家，一般是圣保罗和里约热内卢，首选。
阿根廷：布宜诺斯艾利斯。
哥伦比亚：波哥大和麦德林。
秘鲁：利马。
智利：圣地亚哥，附近还有一个瓦尔帕莱索。
厄瓜多尔：基多。
换到欧洲：
首选：荷兰阿姆斯特丹、德国法兰克福、英国伦敦、俄罗斯莫斯科。
德国：除了法兰克福，还有汉堡、柏林、慕尼黑可选。还有科隆、杜塞尔多夫备选。
英国：除了伦敦地区，还有曼彻斯特可选。
法国：巴黎，里昂和马赛。
意大利：米兰和罗马。
俄罗斯：除了莫斯科以外，还可以选择圣彼得堡。
西班牙：马德里、巴塞罗那。
瑞典：除了首都斯德哥尔摩以外，马尔默也是一个网络集散地。因为他的对面是哥本哈根。还有哥德堡备选。
波兰：华沙。
瑞士：苏黎世。
土耳其：伊斯坦布尔。
挪威：奥斯陆。
芬兰：赫尔辛基。
比利时：布鲁塞尔。
丹麦：哥本哈根
爱尔兰：都柏林。
乌克兰：基辅、哈尔科夫。
奥地利：维也纳。
捷克：布拉格。
罗马尼亚：布加勒斯特。
葡萄牙：里斯本。
希腊：雅典。
匈牙利：布达佩斯。
保加利亚：索非亚。
立陶宛：维尔纽斯。
拉脱维亚：里加。
爱沙尼亚：塔林。
塞尔维亚：贝尔格莱德。
以上基本按照各自国家拥有的 IP 数量排序。
最后说非洲，非洲的情况和南美差不多：
首选南非的开普敦和约翰内斯堡。
埃及：开罗。
肯尼亚：蒙巴萨。
没了。
还有一些小国家没列，但是请看下一句话。
如果你对地理知识比较熟悉的话，你会发现我提到的城市名字是比较符合“一般来说，国家的首都和第二大城市，其次包括人口密集的城市比如区域的中心城市，都会是建设数据中心的首选位置。”这句话的。
另外基于国土面积，越大的越会有多个区域性中心城市存在，比如中国、美国、加拿大、印度、澳大利亚。
再说网络：
先说一个概念，Internet Exchange，简称 IX，互联网流量交换中心。
在国外，如果两个运营商之间没有互联互通，那么绕路访问几乎是必然的，甚至在欧洲是要跨国家了。为了解决本地流量本地消化的这个问题，所以诞生了很多营利的非营利的机构和公司提供流量交换服务，有第三方，也有一些运营商自己提供此项服务。一般来说，接入的 IX 越多，可选路径越多，绕路的情况就会越少。
在中国，IX 几乎是官办的，而且运营商强势，收费方式跟国外也是巨大的差别，第三方出口这个中国特色也跟这个有很大关系，所以基本上大家都不了解这个事情。但是国外自己的网络只要有点规模就可以考虑接入 IX，差别很大。
IX 里规模比较大的有主要业务在荷兰阿姆斯特丹的 ams-ixnet，主要业务在德国的 de-cixnet，亚太这边有香港的 hkixnet。欢迎大家去了解一下。
所以考察一个数据中心的网络情况，首先要了解他们基本接入哪些运营商，哪些 IX，再看他可以选择接入哪些运营商和 IX。
这个情况跟国内也有区别，国内基本上方案上没得选，两线三线还是几线是定死的。但是在国外，有钱你就可以选择性接入，但是前提是人家方案最好是现成即用即接的。不过这种情况下，就很难选择某运营商自己的机房了，往往是第三方中立机房。
还有一个问题，就是既然是出海业务，除了面向区域用户，从国内或者 SOC/NOC 访问各地 POP 进行运维管理的方便性考察也是必须的，无论是公网还是专线。国内互联网公司用的比较简单的方案是在洛杉矶或者圣何塞建点，专门用于维护。而且这两个地方的网络非常丰富，无论是机房还是网络接入的选择余地大，而且到任何一个洲的延迟相对比较均匀。更何况三大运营商在这里都有 POP 点，回国应该是最快最稳定的选择了。
还有一个基于业务类型的带宽储备和机房的能力支持，也是必然要考虑的问题，有些机房能做高防，有些不能，真被攻击也很麻烦，而且前面说了，有 BGP 能力做流量调度为基础才能更好的对抗攻击，国内是运营商说了算，大部分只能靠带宽和硬件硬抗，但在国外是可以自己做很多种方案的，好不好看你自己了。
因为国外的运营商数量真的很多，所以基于你的用户在运营商的分布情况，去做网络规划和运营，还要做到成本尽量低，是个必备能力，也是个考验。
当然你说你用 AWS 就够了，当我什么都没说。
注意事项：
1、国内运营商的限制，导致 ANYCAST 很难做到，都是 DNS 调度居多。而国外基本上自己搭建 BGP 能力是基础，IP 申请、公告与维护也是基础工作，这个是国内公司的网络运维人员要补课的地方。你如果不知道 RADB 是啥，建议赶紧去搜索。
2、地面上的地理位置近不等于网络位置近，实际上要看网络地理的情况才更合适。比如在非洲地区和南美地区，运营商之间的互联互通比较差，如果一个巴西圣保罗运营商的网内用户想要访问另外一个巴西圣保罗运营商网内的网站，很有可能会绕路到迈阿密或者纽约，再绕回来。有一个比较有名的 CDN 厂商，是这么做的，根据网络互连情况，把本地有互联的用户访问导入到本地的 CDN 节点，剩下没有互联或者不好确认的，宁可让他们回到迈阿密或者纽约的节点，这样做用户访问平均延迟反而更低。还有一个例子就是非洲旁边有几个法属的领地，马约特、留尼汪岛这些，我们看到的情况都是从法国马赛的海缆接入网络的，反而没从最近的非洲网络接入，所以如何考虑网络上的区域覆盖，是个非常认真细致的事情，需要了解的知识点非常多。虽然可能和我们的关系没那么大，但是了解了认为可以忽略总比不知道实际情况想当然要好。
3、适当规划，先大区域部署，再根据实际情况慢慢推进网络规划。
你需要先知道目前的用户地理分布情况以及运营商情况，再基于这个做地理位置和网络接入的规划。
而且要明确一点，IX 接入和 TRANSIT 接入的角度不同，费用不同，接入情况也不同，你要根据运营商情况进行选择。
我看到的情况是大型运营商通常为收入考量，一般不太会主动接入 IX，有也可能是 Selective 或者 Private 的方式，你可能得单独 Transit 接入，但是中型、区域以及小型运营商，尤其是 IDC、CDN 厂商，是比较愿意主动接入 IX 的，所以你要明确知道你的网络使用情况，才好去选择网络接入的方式。
假设说你在国外，有自建 POP 点也使用 AKAMAI / CLOUDFLARE 等网络服务的话，那你就最好是和他们都接入 IX，这样也就不用担心回源质量问题了，一举两得。
好在 IX 官网一般都会有成员以及接入方式列表，PEERINGDB 也应该会有更新。如果有必要，也可以单独联系确认情况。
总之记住一个最高原则，无论在哪里，能做到运营商网内服务，都是最佳选择。
如果上面说的巴西的情况，跨运营商提供服务，跨国绕路都是很有可能的。
对了，想从 IP 和 ASN/BGP 角度查看用户的地理位置和运营商情况，IPIP 都可以帮助你。
4、对于一个数据中心的网站，我觉得除了详细介绍数据中心的硬件条件以外，我觉得也要明确地理位置和网络接入的情况，也是必须有的。如果能够提供 looking glass，那就最好了。
目前常见的情况是数据中心会标注在 NYC 和 WDC，其实很大程度上真实位置是在附近的新泽西州和弗吉尼亚州，这个算是行业惯例了吧。个人觉得还是明确为好。
即使从强迫症角度说，我对那些没有明确写明数据中心具体地理位置的公司，没有好感。：D
5、假设你在海外的用户不是很多，但是确实有一些，那么我建议在洛杉矶设个点覆盖一下海外用户就好。
对此有兴趣延伸话题讨论的，可以留言给我，一起交流。
延伸阅读：
1、Internet Exchange Map: >