siyanmao

深圳电信也有了。一条在南山的宽带已经割接到了 vbras 上，按照返回的名称来看，应该是华为的 VNE9000 。发送一个 PPPoE Discovery 包，会有四个 MAC 地址响应。一个快一点三个慢一点，顺序不确定。在罗湖和宝安的两条宽带看起来还没有变，依旧是 M6000 和 NE40E 。

看来大家都学会了低价中标，后续高价卖 License 和维护的套路了蛤蛤

@yulihao 同意。PON 上线前会测距的，根据距离调整发送延迟。而且上行时间片的精度很高，远不是 NTP 能达到的精度。因为 NTP 没同步导致 PON 上行时间片没对齐绝对是 SoC 的严重 bug ，根本不可能上市。感觉还是光猫里什么奇奇怪怪的应用程序影响了数据平面的转发，而不是时间片没对齐。

「坛友是运营商是什么体验」

@oblivion 在 TCP 里发大包还是有点麻烦的，要旁路掉内核的 MSS 控制和网卡的 TSO ，得魔改内核和应用层，没法过 CDN 。估计只能用在 IoT 或者推送之类的应用上。不过检测 MTU 只能检测出 L2/L3 的 VPN ，遇到 Shadowsocks 这样的 L4 代理就没办法了。

对于 ICMP 响应，看来他们的逻辑是越符合 RFC 越有问题。这倒是也有道理。运营商 CGN 、一般的 NAT 网关很可能不会响应 ICMP ，而很多 Linux 服务器不太会屏蔽掉 ICMP 。我感觉以后默认的 iptables 得屏蔽掉太大的 ICMP Echo Request 。

@bibiisme 这不就是我说的在自己的盒子里做非标行为嘛。没看到具体的协议细节，但是看之前的描述，这个绝无进 RFC 的可能。也就 CTC 之类的大运营商能在设备商和客户两边强推。

现在的 IPoE 没有用户名 /密码之类的信息，仅靠物理设备的位置进行认证。这要求整个接入网络的管理要求非常严格准确，风险很大的。哪怕是 PON ，也会出现安装的时候实际可用的资源和系统记录的资源对不上这种情况，更别说以太网入户那种了。PPPoE 在接入时有用户名密码校验，位置和系统记录不匹配会被发现，IPoE 可能就没机会了。在中国这个对“落地查人”要求很高的场合，大量出现此类问题是不可接受的。这种情况下，运营商只能在自己的盒子里做非标行为来加强控制，不仅给后期维护带来了麻烦，用户的选择权也自然受到限制。
回过头看看历史，PON 上运营商很多都选择了与物理设备无关的 LOID 认证，机卡和一的手机最终还是被淘汰了。早期的小区宽带都是 IPoE 的，最后也转向了 PPPoE 。
所以我认为，IPoE 需要提供一种标准化的，与物理设备和位置无关的，包含用户标识和保密认证信息的认证方式，要不迟早被运营商玩坏。