sendmailtest123

有一定概率是城域 /省网路由配糊了，毕竟连自家 CMI 的地址都不能通，算得上是移动网维基本操作了。测: 2402:4f00:100::66d

临省移动，光猫线路模板没有绑下行限速（默认 1G ），同市账号能互用（可能全省都行）。上网速率控制是 RADIUS 认证回复报文添加扩展字节传带宽参数，BRAS 动态限速实现。相关产品文档 -> https://support.huawei.com/enterprise/en/doc/EDOC1100270076/9abf158/

@AlphaTauriHonda 封网期骨干业务调整 /割接理论是不批也不做的，11 月放开以后看看吧。不过介于北京出口已经验证了一套数据样板，上广到年底兴许会有戏。

浙江移动的所谓"精品宽带"理应是个能光明正大装到商业地址下的（动态公网）家宽才对，不然实际报价和对等 PON 专线相差这么多功能却一样，用户反而没理由去签约后者了。例：基于 OP 提供的目录价+抹零后实际报价，有提供双栈固定地址的情况下 500/250 精品宽带线路收费 2000 ，而 200/200 专线线路收费 7200 。。。

关于双栈公网，一朋友在同省邻市有报装移动对等 PON 专线（就一年 7200 的那个版本），竣工初期也只有 v4 单栈，和相关负责人沟通后确实额外取得了 v6 前缀：兴许这是两种业务有报价区别的原因之一？但价位也不应该相差这么多吧。。。不过介于设备标签显示业务是"PON 专线"，说不定是客户经理业务不熟工单下错了（血赚！）

标准 PPPoE 当然不会交互这些所谓“隐私”信息 -- 相较于 IP 地址、MTU 等参数，主机名或软件版本又不是链路 /网络层需要关注的信息，再加上 PPPoE 有 ID 区分会话，在控制报文写入上述无关紧要的内容已经是累赘了，要是保活报文里再添上岂不有点离谱。

当然要不要这部分可选字段纯看运营商喜好，毕竟它们可以通过此类参数来牵制客户选择第三方网关型号的能力（现在可能比较少见了。参考部分路由器自带的“特殊拨号模式”）。

今天 58807 往外宣告的路由多了不少，新增部分主要隶属先前一直没有出现的长三角、珠三角地区分公司。粗略做了一下追踪，实际路由仍绕北京，不过也许上广出口已经准备得差不多了。

几个测试 IP
183.194.134.1 上海 24400 （上海居然这么快就有吃 CMIN2 螃蟹的外企了: 思爱普 /SAP 中国，AS135577 ，157.133.197.235 ）
112.53.180.1 浙江 56041
36.158.32.1 湖南 56047
183.206.224.1 江苏 56046
120.236.114.1 广东 56040

@acbot 用三层交换机的内置功能算是现成方案，兴许 BRAS 上的类似功能厂商也是复用自己的交换产品线代码实现的，但“纯软件”实现也不是不可以：比如#21 和我都提到能自己扩展 DHCP 服务器（不管是改代码还是调用钩子,api,脚本）做到和 netfilter 之类的联动。无非就是没有现成的开包即用项目罢了 -- 目前来讲，花心思深入调试一下几个模块化的 DHCP 服务器，你想要的效果可以直接实现。

@acbot 假设我的说法和运营商、大厂的实际实现相匹配，那扩展一个开源 DHCP 服务器使其能够识别挑战应答 Option 并针对性处理、决定需不需要返回 DHCP Offer 就可以了。。当然你也可以选择不处理扩展字段无脑返回 DHCP Offer ，随便一种 DHCP 服务器都可以实现这个功能。

说到底目前部署 IPoE 地区认证全脱胎于 DHCP ，DHCP 是完全不需要交换机硬件或某种特定协议支持的（这里先不考虑 BRAS 的用户上线控制，后续讨论见下）。另外，上面多层回复均提出非标准 IPoE 认证方式没有统一、且 CTC 的那套挑战应答（大概）还没被逆向出来、加上考虑到 IPoE 尚未完全铺开（或许以后每个省采用的认证标准都要额外加点料称作创新呢），通用实现会比较难做。说到这我其实好奇你想自主实现接入认证后作何种用途。。。

若要实现类似于 BRAS 上的状态机来阻止转发未认证用户流量，纯自主实现就需要 DHCP 服务器和路由网关能够联动了。例：自己写或合理运用开源 DHCP 服务器（例如 ISC Kea ）的钩子接口，在 DHCP 发放地址同时执行外部代码放通用户接口的转发能力（默认阻塞）。若采用大厂设备（~三层交换机）则好办：它们一般提供诸如 IPSG 、DAI 、DHCP Snooping 等端口安全功能。关闭接口 ARP 学习能力后，设备内部 IP-MAC/ARP 对应表将完全通过监听 DHCP 报文维护，那不属于 DHCP 分配的地址（自配 IP ）的报文会直接被丢弃，体验上和先前提到的 BRAS 用户上线控制技术类似。

IPoE 既然是承载在以太网帧（~二层）上的 IP 报文（~三层），在当今标准以太接入大环境下只是个普通 IP 数据包。。。因此规范的认证方式只有基于 MAC/IP/VLAN 判断接入用户或 /和地点而已，也就是思科 /华为默认支持的认证方式。同时，两家的配置文档均有提到 “订户接口 Subscriber Interface” 这一概念：一种虚拟接口，用 VLAN 对应某客户的某一业务，且维护一个状态机（~会话）来指导报文转发。常见例子就是 PON 接入专线大抵采用基于 IP 认证的 IPoE：用户填入专线的静态地址，BRAS 分析用户设备与自身的交互报文（可以是 ARP ，ICMP 这类的） IP 头段是否为该用户订阅地址，只有符合才将会话上线使能报文转发（好比配置该订户接口防火墙策略在状态机 down 时为丢弃、online 时才为转发。不过这点是我猜的，但底层实现上应该类似）。需要避免用户随意盗用不属于自己的 IP 地址？当收到源 IP 不属于该订户的入向报文，直接将状态机置 down 中止后续报文转发。总的来说，标准 IPoE 只要在用户侧三层接口在填入合适的 IP/MAC/VLAN 参数后即可上网，从而印证常见路由固件并不需要额外模块来适配这一协议，因为它们早就支持了。

那么动态分配 IPv4 场景下 BRAS 要如何验证报文 IP 头部是否匹配，控制用户的会话状态机呢：问 DHCP 。不管是用 DHCP Snooping 这种安全技术，还是用特定的组网方式，运营商只要能确保 BRAS 自身或带外服务器间 DHCP 交互是可信的，就可以参照这些交互报文来控制客户状态机的上下线。比如，只有上游 DHCP 服务器返回 Offer 且客户端接受了，才让会话上线。后续则可以持续监控客户侧 IP 是否匹配 DHCP 下发的地址，遇不匹配就让客户状态机下线等。像电信的 CTC 协议就在 DHCP Option 字段做文章（/t/875362 ），设备需要与 DHCP 服务器互相挑战应答用户名密码（业务是否欠费等先决条件大概是在这里得到验证）才能获取到 DHCP Offer 回应。

至于 IPv6 单栈（/t/875742 ，/t/875467 ）场景，目前的方案看起来是 DHCPv6 绑定光猫上行口 MAC 下发固定前缀，且在订户接口上配置静态 v6 认证。