7月申请SoftBank 光・10ギガ宽带，时隔31天NTT才上门做工事，不得不说效率真的是低的可怕。

10G契约与1G契约不同的是10G使用フレッツ光クロス，不提供PPPoE接入；1G契约使用フレッツ光ネクスト，可以使用PPPoE接入同时也可使用IPoE接入。但无论哪种契约使用IPoE接入都需要租赁ISP专用路由器，在10G契约中是NTT由NEC代工的XG-100NE，在1G契约中是由鸿海代工的BB单元。花550日元租路由器没什么问题，不过这路由器的固件实在是有过于简陋...... 也不能改成桥接模式，无端多一层NAT很让人不爽。本篇就作为日记记录一下折腾的过程吧。

工事完成后还特意问询了前来做工事的师傅“能否用市售路由器代替NTT的HGW？” 得到了肯定的回复。但是实际上并不能，Softbank所属的VNE BBIX社使用的是名为“IPv6高速ハイブリッド”而不是JPNE的“V6プラス”，直接接入普通市售路由器只能使用纯IPv6互联网。

接上 XG-100NE 之后自动从 ISP 处下载了一些配置文件，路由器重启了一次后 PPPoE 设置被禁用，DMZ 功能消失。路由器提示使用 MAP-E 隧道接入 IPv4 网络，感觉很像国内部分地市中国移动 IPoE 的 4in6 隧道？

有一个隐藏的页面“配信済事業者ソフトウェア”（http://192.168.1.1:8888/t）可以配置端口转发，审查元素查看js源码后发现最多可以配置64条转发规则，无NAT Loopback功能，无法直接从内网使用公网IP访问开放的端口。

BBIX社持有大量IPv4地址，有前辈测试1G的契约中租用BB单元使用IPv6 IPoE radius认证+IPIP隧道来实现IPv4 over IPv6通信，已知全部端口都可开放，是独享公网IPv4。

V6プラス使用MAP-E隧道在HGW中会给出可用的端口范围。Softbank光10G契约的ISP路由器中显示MAP-E，但是并没有明确端口范围。

真的是MAP-E吗？

随机开放了几组端口用于测试，全部可通，基本可以认为全端口可用。

尝试将软路由（OpenWRT）直接与ONU连接，WAN6接口可以DHCP到一个2400:2410:xxxx:xxxx::/56的IPv6-PD，配置好IPv6各项设定后可以访问纯IPv6网站。

网上有许多前辈编写了在OpenWRT中配置V6プラス的教程。使用IPv6前缀计算MAP-E参数的网站：http://ipv4.web.fc2.com/map-e.html

很遗憾，这个网站并不支持对BBIX的2400:2410:开头的前缀进行计算，提示：未対応のプレフィックス。

不知道BBIX的隧道和配置参数是什么？想到在国内时曾对IPTV的IPoE认证过程进行抓包分析，后面尝试对HGW抓一下包看看。

2023年9月20日：补充一下测速结果，东京都内不是很理想。据说东京周边的县能跑到6Gbps以上？

2023年8月14日

抓包结果看起来是普通的IPIP隧道。验证了之前的猜想，并不是MAP-E的方式，而是IPIP。（所以为什么HGW中要显示MAP-E？）追记：后来了解到MAP-E和DS-Lite都是基于IPIP6的（笑）

以及一段RADIUS认证的数据。认证服务器是2400:2000:bb1b:8::5，User-Name是IPv6前缀，Password是什么无从得知。返回数据是IPv6 BR IP和CPE侧的IPv4地址。

无论重启多少次ISP路由器、ONU或者更换ONU，IPv4和IPv6-PD都不会发生变化。

可以认为是固定IP吗？

[removed]

2023年8月15日

想办法得到了RADIUS认证使用的secret和password。

之前抓包的时候分别抓到了两次的CHAP-Challenge和CHAP-Password的盐值。编写一个简单的脚本来验证这个Password的正确性。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import hashlib

def verify_chap_password(chap_ident, chap_password, chap_challenge, password):
    m = hashlib.md5()
    m.update(chap_ident.encode('latin-1'))
    m.update(password.encode())
    m.update(bytes.fromhex(chap_challenge))
    # 生成CHAP响应
    expected_response = m.hexdigest()
    return expected_response == chap_password

password = "<...>" # RADIUS Password

# 抓包数据
chap_ident = "\x00" # 10G: 0x00, 1G:0x01
chap_password = "73baebe2b<....>"
chap_challenge = "81d6b7777<....>"
# chap_password = "2419a3bd1<....>"
# chap_challenge = "9f2ac03c3<....>"
if verify_chap_password(chap_ident, chap_password, chap_challenge, password):
    print("PASSWORD is correct.")
else:
    print("PASSWORD is incorrect.")

运行结果：PASSWORD is correct.

感觉secret也不会有什么变化。

PS：用RADIUS客户端模拟请求了一下，确实是可以用的。

接下来只要构建RADIUS认证包发给认证服务器就可以了。

[removed]

2023年8月30日

其实与其他VNE所提供的固定IP契约的配置方法完全相同，不过需要将WAN口MAC配置成HGW的才行。因为是固定IP，不解约再重新契约的情况下IP不会发生变更，所以不再考虑RADIUS认证的问题。

总之还是设置好了10G的4in6隧道。单独写了一篇介绍配置方法。→ 参考本文

观察几天运行状况及稳定性。

2023年9月1日

碰到了新的问题，WAN6接口总是在8小时整lost connection。使用ifstatus wan6检查分配的PD前缀，发现lifetime是在4小时左右，也就是说第一次可以续订成功，第二次不知什么原因续订失败了。

从朋友得知1G契约中的lifetime大约在30天。对ISP路由器在8小时范围内进行连续抓包试试？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

Ethernet II, Src: Cisco_3d:de:8c (<secret>), Dst: NECPlatf_ (<secret>)
Internet Protocol Version 6, Src: fe80::<secret>, Dst: fe80::<secret>
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6
Message type: Advertise (2)
Transaction ID: 0x8540de
Client Identifier
Server Identifier
Reconfigure Accept
Identity Association for Prefix Delegation
Option: Identity Association for Prefix Delegation (25)
Length: 41
IAID: 00000000
T1: 7200
T2: 10800
IA Prefix
Option: IA Prefix (26)
Length: 25
Preferred lifetime: 12600
Valid lifetime: 14400
Prefix length: 56
Prefix address: 2400:2410:<secret>00::

2023年9月3日

经过整整一天的抓包后发现问题。

在第8个小时NTT服务器发送DHCPv6 Reconfigure Message后WAN6就失去了连接。

reddit上有人提到フレッツ光クロス使用OpenWRT时都会有类似的问题，使用NEC的市售路由器没有问题。看来是odhcp6c的问题了。

2023年9月12日

通过很临时的方法让odhcp6c更新IPv6租约，似乎解决了问题。目前能够持续23h以上。

2023年9月19日

WAN6连续运行一个星期没有出现问题，倒是i226V因为过热重启了一次。

odhcp6c的这个问题似乎早在3年之前就有人提出过：IPv6 network stops working after a while · Issue #61 · openwrt/odhcp6c (github.com)

openwrt官方也在摆烂没人修，只能使用临时办法暂时解决问题。

那么SoftBank光的桥接设置研究就到此为止了~