突发奇想，为什么非要搞个 ipv6，而不直接用 ipv4 公网+私网地址升级为新的 ip 策略呢，一切问题都可以在 ipv4 的基础上慢慢解决嘛。
pinews · 2019-01-24 21:06:57 +08:00 · 8774 次点击这是一个创建于 2112 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
pkookp8 2019-01-24 21:11:09 +08:00 via Android
设备 a 在私网 A
设备 b 在私网 B 设备 ab 都是你的设备，每个人都有这样的配置 没有公共服务器，你如何直接通过设备 a 找到设备 b |
 |
2
ysc85 2019-01-24 21:32:01 +08:00
我想到的问题是，为什么不像电话号码一样，在原来 7 位数的基础上在前面加一个数字，这样也不会导致重复。或者 IPV4 直接变为 5 节（ 192.168.1.2.3 ）或 6 节（ 192.168.1.2.3.4 ）或者每节扩展成 4 位数（ 1920.1680.0000.0000.0000 ）之类的
|
 |
4
mason961125 2019-01-24 21:44:27 +08:00
@ysc85 #2 一样是改协议，一样的成本明显 IPv6 的收益更高。
|
 |
6
ivyxjc 2019-01-24 21:56:38 +08:00 via Android  2
@ysc85 ipv4 用 4 个字节来存储 ip 地址。相关协议都是以这个为标准设计的。，没有办法再扩了。ipv6 就是增加了字节数。用 16 个字节来存。
|
 |
7
pinews OP @pkookp8 还需要升级啊，
@Archeb @mason961125 @xxq2112 不觉得 @ivyxjc 原公网 ip 默认为 x.x.x.x-1.1.1.1-1.1.1.1 如果实在没办法更新就用这个策略 |
 |
8
Seumi 2019-01-24 22:35:14 +08:00 via Android
ipv6 解决的不光是地址不够用的问题
|
 |
9
chinvo 2019-01-24 22:37:47 +08:00 via iPhone
|
|
10
chinvo 2019-01-24 22:39:48 +08:00 via iPhone
@pinews #7 你这个策略的思路是从数据包上处理吧，但是这样搞每个路由设备都要维护一个巨大的网络表和映射表，成本比扩展 IP 长度要高多了
|
|
11
pinews OP |
|
12
chinvo 2019-01-24 22:55:16 +08:00 via iPhone
|
|
14
chinvo 2019-01-24 23:13:16 +08:00
@pinews #13 那不还是增加 IP 长度么，和 IPv6 有什么区别？为什么换 IPv6 要升级设备，换你这个方案就不用？
|
 |
15
misaka19000 2019-01-24 23:28:58 +08:00
你这样路由器还是需要升级，在提升了成本的同步并没有产生应有的好处，是一种非常糟糕的设计
|
 |
16
yuikns 2019-01-24 23:38:49 +08:00
这是在说 NAT64 方案么？ http://support.huawei.com/enterprise/docinforeader!loadDocument1.action?contentId=DOC1000057170&partNo=10252#sec_eudemon_ag_nat64_0000
不过这个太烦了，需要 tunnel。内部的话，地址位就是 hard code。兼容搞不定。所以现在都是双栈，过一些年 v4 淘汰就好。 |
 |
17
yingfengi 2019-01-25 00:50:49 +08:00 via Android
ipv6 地址多的话路由表好做
|
 |
18
Aoang 2019-01-25 01:01:49 +08:00 via Android
建议去了解一下相关资料。
另外，制定 IPv4 的时候，大家都觉得应该够用了，就算你扩展 IPv4，和 IPv6 并没有什么区别，同样的需要设备兼容。 |
 |
19
1423 2019-01-25 01:05:36 +08:00 via Android
协议本来就是人定的，至于为啥这样不是那样，主要看有表决权的那帮人过眼了多少提案，并不一定这样就最好。实际结果往往是妥协出来的。
可能过几年又会觉得 IPv6 垃圾了 |
 |
20
BOYPT 2019-01-25 01:11:19 +08:00
ipv6 标准已经 20 几年来无数人努力逐步改善到现在的地步的，你想自己提一个更好的方案?
|
 |
21
Mohanson 2019-01-25 01:27:03 +08:00 via Android 1
那个， 恩，你能把 ipv4 “扩展”成 1920.1680.0000.0000 的原理说一下吗？？？
很想吐槽，建议先把谭浩强 c 语言设计学完再发帖。大声说一遍，uint8 范围是多少到多少？ |
 |
22
sdijeenx 2019-01-25 01:35:45 +08:00
ipv4 公网+私网地址不就是 ipv4+nat 嘛，搞 ipv6 是因为 IP 地址数量太少已经不够用了。
还有对于“一切问题都可以在 ipv4 的基础上慢慢解决嘛”，宽带运营商就是这么想的，改什么改躺着收钱就完事了。要不是国家强推 ipv6 运营商才懒得改呢。 |
 |
23
GeruzoniAnsasu 2019-01-25 01:58:05 +08:00 7
@ysc85
@pinews ipv9 了解一下，你们的思路跟民科很相像 以防又有路过群众说我扣民科帽子，我以为民科的特点就是在不了解不考虑甚至有意忽略事实原由的情况下仅凭想象推测结论。 首先 ip 是某种计算机网络协议， 这个协议规定地址这个字段就是 32bit4 字节二进制数。1.2.3.4 只不过是“把这 4 字节顺序按高位字节排在前面的顺序每字节用一个十进制数表示”表示的方式而已 32bit 总共也就能表示 2^32 个不同地址，这是 ip 地址不够用的本质。 怎么在这个基础上扩容？把互联网局域网凡是 IP 协议的所有流量的所有数据包中“地址”这部分全部加长，4 字节不够用，干脆*4 得了，直到宇宙尽头都够用了。大家不也都是这么想的吗 行，接下来考虑怎么“把互联网局域网凡是 IP 协议的所有流量的所有数据包中‘地址’这部分全部加长”这件事。 v4 到 v6 漫长的过渡期以及内核中两套代码几乎一样的协议栈实现就是为了达成这个目标的。 那有的人会说了，哎我能不能，不 “把互联网局域网凡是 IP 协议的所有流量的所有数据包中‘地址’这部分全部加长” 啊？ 可以啊，电话分机都熟悉吧，但问题是，你分机号也是 1001，我分机号也是 1001，哎万一我又不知道自己公司前台电话是多少，或者前台压根就没人，我怎么让你找我？分机号总共 1000 个，今天我司喜迎 1001 个员工咋办，哎没关系，给各部门先分一台分机，先转部门，部门再转接个人，简单。 简单吗？ 假设某些蠢人会说 “那别要前台嘛，要啥人工嘛，用交换机嘛” “分机号不好记，语音助手嘛，说名字就能转了” ————难到不是大家加个微信记个私人手机号就完事了？仅仅是长一点而已嘛 |
|
24
sdijeenx 2019-01-25 02:02:59 +08:00
ipv4 地址 192.168.1.2 = 192.168.001.002 = C0.A8.1.1 = 11000000.10101000.00000001.00000001 这才 32 位，不考虑地址划分的话可用地址只有 4294967296 个
ipv6 地址 2001:db8:85a3:8d3:1319:8a2e:370:7348 = 2001:0db8:85a3:08d3:1319:8a2e:0370:7348 = 0010000000000001:0000 110110111000:1000010110100011:0000100011010011:0001001100011001:1000101000101110:0000001101110000:0111001101001000 一共 128 位，不考虑地址划分可用地址有 2^128=340282366920938463463374607431768211456 个可用地址。 所以为什么要弄一个临时方案，直接用 ipv6 不好么？ |
 |
25
oovveeaarr 2019-01-25 02:17:39 +08:00 2
学而不思则罔，思而不学则殆
这句话在这个贴里面还是没错的 本质上就是一样的东西，你能从 32bit 的扩增到 48bit，为什么不选择一步到位的上 128bit，既然要改这种基础的东西，那么成本都是差不多的 PS：可以参考下，32bit/32bit PAE(36bit)/64bit 的恩恩怨怨，为啥你现在不去用 PAE 呢？ |
 |
26
tia 2019-01-25 03:41:16 +08:00 via Android 1
我想了半天，你说的这种方案不是现在正在用的？
|
 |
27
flwwater 2019-01-25 07:59:20 +08:00
万物互联
|
 |
28
wdv2ly 2019-01-25 08:18:23 +08:00
@GeruzoniAnsasu 所以说程序员还是很有必要了解些基础知识的，不然一不小心就暴露了
|
 |
29
rayhy 2019-01-25 08:29:11 +08:00 via Android
不是连包的结构也优化了？ 4 到 6 的改进不止是地址的增加吧？
|
 |
30
hundan 2019-01-25 08:32:41 +08:00 via Android
@ysc85 这个就已经是改协议了，如果你要讲，不如说多人共用一个公网 ip，由运营商划分子网，在 ipv6 没有普及的时候的确是这么做的。
|
 |
31
wly19960911 2019-01-25 08:34:07 +08:00 via Android
计算机网络重新学习下行吗…
你只要修改了 IP 的任何一个结构就等于修改了协议，现有设备不兼容 现在用的就是 nat 处理 IP 不够的情况，但是想穿透 nat 哪里这么简单，内网穿透，udp 打洞，这都需要一台服务器作为中间者帮助连接， |
 |
32
ghostheaven 2019-01-25 08:48:44 +08:00 via Android
楼主是个萌新，你们不要欺负她[手动狗头]
|
 |
33
SamsonWang 2019-01-25 08:50:42 +08:00
|
 |
34
fyibmsd 2019-01-25 08:54:33 +08:00 via iPhone
为了物联网
|
 |
35
yogogo 2019-01-25 09:04:45 +08:00
这大概就是学渣的创意吧
|
 |
36
johnniang 2019-01-25 09:21:47 +08:00 via Android
一步到位 比 临时方案 一劳永逸
|
 |
37
J2s 2019-01-25 09:59:18 +08:00
计算机网络-谢希仁 了解下
扩容有协议问题，硬件向下兼容问题，运营商的兼容损耗，emmmm.... ipv4 公网+私网地址 各大运营商都在用啊，甚至大量的端口使用来解决访问 但，服务器、物联网等需要大量的固定 IP 给终端分配，这个消耗量就上去了不够用啊 |
 |
38
fbzl 2019-01-25 10:00:09 +08:00 via iPhone
为了根服务器
|
 |
39
honjow 2019-01-25 11:06:17 +08:00
这贴充分说明了学习的重要性
|
 |
40
reus 2019-01-25 14:41:11 +08:00
基础知识都不懂……
|
 |
41
loveour 2019-01-25 14:59:19 +08:00
楼主有这个想法不奇怪呀，为什么好多人嘲笑。另外，感觉有的人把楼主的意思理解错了，我理解楼主的意思是，使用 IPV4+IPV4 这样的地址，就是 255.255.255.255+255.X.X.X 而不是 2560.X.X.X。
我理解的是，这样做省不了什么事，因为涉及到的网关设备都要换，带来的好处又不明显。因为想这么做大概是想少换设备吧？但是，想一下，怎么实施呢？结果还是要换大量设备，还是有兼容性有问题，还是有可能面临 IP 不足除非继续扩展。 |
 |
42
AstroProfundis 2019-01-25 15:44:02 +08:00
@loveour 但是 IPv6 最根本的地址长度扩展，其实就是 255.255.255.255 + (255.255.255.255)*3 然后再从“点分十进制”换成了“冒号分十六进制”（这个名字我随口现起的），关键在于这两种写法都只是为了方便人类阅读的 *表示方法*, 它们实际上就只是一串 32 位和 128 位的二进制数而已，所以你如果非要把 IPv6 按 IPv4 的点分十进制方法写成 16 段地址也没什么不行的，翻着花变换 *表示方法* 并不改变协议的本质；所以楼主说了这么大一堆只能暴露出他并不知道 IP 地址实际是什么东西，想当然地就往上“扩展”了，然而 IPv6 不仅完美符合他设想的扩展方案，还一并解决了很多别的问题
|
|
43
loveour 2019-01-25 16:27:38 +08:00
@AstroProfundis #42 我觉得你这个回复可以去 at 其他人，和我回复的内容不搭。我第一段的回复是针对有些人理解错误的，那个不是 IP 形式的问题。
理论上来说，楼主的想法是有一定道理的。其实就是分层处理的问题，公网传输只管前面一段公网 IPV4 地址，到了自己的网关再处理内部的子网，就好像电话分机，其实不是运营商的设备管理内部子机，而是企业自己的总机在管理。但是现实是协议反正要更新了，为什么不一蹴而就呢。设备本来就定期都会更新的。 |
|
45
loveour 2019-01-25 18:07:02 +08:00
@tia #44 现在直接访问一个处于 NAT 下的主机是访问不到的，如果协议地址扩展，发起访问的主机请求访问的时候可以带着 NAT 内网的信息，协议能支持，那就可以直接访问到 NAT 的主机了，这样不是公网 IP 也可以直接访问到，是这个意思。其实就是直接拨分机号还是只能打总机再转接的问题，目前的总机（也就是网关）是不支持转接的。拨号直接带分机号码也是需要网关支持的，协议还是要改，那就还不如一下子改好了。
|
 |
46
cwek 2019-01-25 20:49:03 +08:00
重新创造新的 IP 协议。快去提 RFC 吧。（笑）
|
|
47
AstroProfundis 2019-01-26 10:42:19 +08:00
@loveour 呃，我回复你实际上是因为我觉得前面说得够清楚了但你还是表示能理解楼主的想法......这种想法本身确实没什么问题，但真的是“思而不学则殆”，如果在了解过相关的技术本质的情况下再产生这样的想法，就不会问出这种问题了......
你说的“公网传输只管前面一段公网 IPV4 地址，到了自己的网关再处理内部的子网，就好像电话分机”，那数据包里面要不要包括“分机”的地址呢？显然还是要的，那既然都要放进来了，和前面的“公网部分”连着放在一起拼成一长串用一个 32 位或者 128 位数字来表示是不是实际上没有区别还省事一点呢？至于拼在一起了怎么区分两者，有个东西叫“子网掩码”的哇...网络设备在转发包的时候本来就不看“分机”地址部分的... |
 |
48
hhhsuan 2019-01-26 11:29:04 +08:00 1
ipv6 的 128bit 还是保守了，地球上可能够了，以后星际时代怎么办？应该直接上 256bit.
|
|
49
loveour 2019-01-26 11:49:00 +08:00
@AstroProfundis #47 所以我说你回复的内容不搭，我说的是“理解楼主的意思是 XX ”，指的是我觉得有的人理解错了楼主的想法，而不是“我理解并支持楼主的想法”。。你后面说的那一段难道不就是我说的网关设备还是要换，协议反正都要更新了吗
 其实我后面一个回复也打了个比方，拨打带分机的号码也是需要网关支持的。 |
|
50
AstroProfundis 2019-01-26 13:44:13 +08:00
@loveour 好吧那确实是了...不过我后面想表达的是“分机”这种思路跟现有的方案没有本质区别，只是换成了生活中相对更熟悉的表述，当前的 IPv6 方案使用基本一样的核心思想，更好地解决了问题，并且如你还有楼上很多人所说，反正都要升级设备了成本并没有什么区别当然用个更完善的协议（
|
 |
52
a22124497 2019-01-27 21:52:02 +08:00
我还以为国产 的 IPV9 又要来一次呢，结果不是呀，那我走了
|
Select Language