（以下内容根据清华大学信息化技术中心马云龙老师在首期北京高校信息化技术沙龙中的主题演讲整理而成）
我演讲的主题是在用户侧IPv4和IPv6双栈的场景下，校园网络架构的设计、建设以及运维的经验和体会。强调IPv4、IPv6双栈，是因为新增IPv6地址会给运维带来诸多的挑战和难点，相信在座NOC的同事，特别是做网络运维和建设的同事们都有深刻的体会。
清华大学校园网拓扑结构
王振华老师之前提到北京邮电大学的在线设备数量是6万多个，这实际上是IP地址的数量，并不是真正设备数。清华大学统计设备数用的是MAC地址，即接入的终端数量。我们可以看到，在清华校园网内，月活设备数有25万以上。这是个非常大的数字，为我们的网络运行和承载能力带来巨大的挑战。
下图所示为清华大学校园网的拓扑结构。实际上我们在考虑网络架构时，不用过于关注接入，因为接入并不会对拓扑结构有实质性的影响。我们大家的工作，更多还是集中在整体架构的运维上面。
我们的主干网采用了6对BRAS，并使用IRF进行站点异地备份，和王振华老师分享的北邮拓扑在出口只需要两个BRAS不同。具体需要几个BRAS，除了考虑资金的问题，还需考虑承载能力和分区域控制的需要，避免单点故障导致整个校园网瘫痪。因此，逃生链路的设置也是我们需要注意的技术细节。
我想让大家都思考一个问题：为什么我们要用BRAS？想要回答这个问题，首先需要思考用户侧双栈的时候，我们应该怎么做统一认证。
在传统的网关弹Portal认证的模式下，校园网出口计费网关不支持双栈联动，这会导致在弹Portal认证时无法识别不同协议栈的IPv4或IPv6地址。因此，在实现IPv6的实名认证时，需要使用BRAS进行统一认证。BRAS可以根据会话来识别不同协议栈的地址，将这些地址与用户信息进行绑定，并在认证时将认证结果反馈至AAA，从而实现一次认证双栈都打通的目标。此外，BRAS还可以实现基于应用程序的路由控制，以确保网络的稳定性和安全性。因此，在校园网网络规划和建设中，使用BRAS是必不可少的。这才是我们在2018年选用IPoE和BRAS最主要的原因，而不是考虑承载能力。
其实我们原来用的MX960，但是，MX960设备在用于IPoE认证时存在一个致命的Bug性问题，主要出现在设备的DBE引擎上。当这个Bug被触发后，设备就会处于死机状态，必须现场进行电源重启，才能让设备恢复正常运行。这个问题对我们网络的稳定性和安全性有非常大的影响。清华大学当时购买了多台MX960设备，但实在无法解决这个致命的问题，只得寻找其他替代品牌的设备。总之，BRAS产品是解决双栈认证问题的重要手段，而且未来双栈实名制认证的需求肯定会加强。
以下是基于IPoE的双栈准入认证流程。用户终端接入校园网，首先发起DHCP Discovery报文，报文到达BRAS设备后并不是直接转发至DHCP服务器，而是生成一条Session并将这条Session转发至AAA服务器，该Session包含用户终端MAC地址，DHCP Option选项以及系统预置的NAS账号和口令，AAA服务器收到本次请求，根据BRAS递交的账号可以向BRAS下发不同的策略，例如下发该条Session上行带宽4Mbps，下行带宽10Mbps等不同的策略。
为了可以精细化控制不同协议栈的用户终端接入网络，BRAS通过不同协议栈接口的配置模板来向AAA服务器递交不同的控制策略账号。例如根据IPv4或IPv6接口配置不同，递交不同的预策略账号，请求AAA服务器下发不同的控制策略给用户终端，也可以根据不同的业务模板下发不同的策略，例如静态地址区域配置不同的控制策略账号。通过这一多策略的配置，实现多种应用场景的用户终端接入控制。
BRAS收到AAA服务器返回的预策略值和认证成功消息后会将用户终端的DHCP Discovery报文转发至DHCP 服务器，DHCP服务器根据标准的DHCP过程为该终端分配IP地址，BRAS将DHCP服务器的ACK报文包含的IP地址、该终端MAC地址、收到的AAA服务器返回的预策略信息以及接口信息生成一条Radius报文递交给AAA服务器。AAA服务器收到BRAS递交的Radius认证报文，会在服务端生成一条DHCP在线表。
用户终端获得IP地址后，除了BRAS设备配置的白名单地址之外，不允许访问任何其他地址。用户必须发起web请求来完成用户身份认证。当用户使用浏览器访问任意HTTP页面时，BRAS收到来自该用户终端的80端口的请求报文后将报文直接重定向至AAA服务器的webportal服务端，服务端向用户返回身份认证页面，用户递交正确的用户身份，由AAA服务器的鉴权模块返回鉴权成功后，AAA服务端向BRAS下发CoA报文，包含Session_ID和用户的组策略信息，BRAS收到CoA消息后根据CoA中的策略信息更改该条Session的预策略，放行用户的访问限制。根据以上IPoE的webportal认证流程，可以封装客户端软件模拟用户的webportal认证请求，实现客户端认证，满足用户的使用需求。
当然，购买BRAS设备也需要考虑它的承载能力、Mac地址的表项、ARP/ND表项和限速情况等等。
接下来和大家聊聊IPv6 MAC（DUID）地址的生成方式和其在双栈联动中的作用。在BRAS侧或者是主机的终端侧，IPv6地址与MAC地址之间存在着一一对应的关系。DUID实际上是由时间戳和MAC地址组成的一个串，用于唯一确认一个终端设备。在实现双栈联动时，需要使用DUID去查找相应设备的MAC地址，并进而查找其对应的IPv4地址，以确保IPv6与IPv4之间的充分利用和互通性。所以DUID在双栈联动过程中有着重要的作用，它是维护IPv6和MAC地址之间映射关系的重要依据。
关于弹Portal频率的问题，我们在2018年实施IPoE的过程中，开实验局时有三台主机狂发HTTP报文，其中一个紫光输入法每秒发出超过1000次的HTTP报文。由于MX960按照80端口每遇到一个出包就弹一次Portal，从而导致在线用户数从5000涨到15000，给负载均衡设备带来了巨大的压力，影响到了网络学堂等的正常访问。我们只好开启白名单限制访问，只允许白名单内的地址弹Portal，从而规避了弹Portal频率控制的问题。这也说明弹Portal的控制需要基于每个原地址的频率进行控制，而不是以全局的方式进行控制，否则会将一些正常的地址也误判为攻击地址而被抛弃。
HTTPS也可以弹Portal，需要使用SSL拦截技术来获取用户的请求数据，再进行认证和控制。
下面给大家讲讲哑终端上线的问题。王振华老师刚才也提到了物联网上线，例如打印机、门禁和摄像头等，这些设备都需要使用以太网联网，并且没有操作系统、没有认证、没有浏览器，对我们来说，它们就是哑终端。哑终端触发上线的方法，除了使用IP报文，还可以收集ARP报文来获取MAC地址，并建立DHCP在线表。
当DHCP服务器上存在哑终端的在线表时，就可以使用脚本定时向哑终端发送上线请求。由于我们没有子接口信息，无法确定哑终端从哪个端口上线，因此该请求会以广播的方式发送到多个BRAS，以便哑终端能够正常连接至少一个BRAS。此时，可以下发CoA (Change of Authorization) 指令，在BRAS进行重新认证。
关于子注册无感知的问题，刚才王振华老师说，当设备连接到无线网Portal或BRAS Portal时，可以基于MAC地址进行认证操作。
然而，这种认证方式存在很大的安全风险。因为MAC地址可以轻易被伪造，而一旦修改了MAC地址，就相当于修改了设备的用户身份，这在清华这样的学校尤其危险。如果有人发现了这样的漏洞，很快就会在社交媒体上传开，形成舆情，指责我们的校园网存在重大的安全隐患。因为MAC地址与用户身份信息绑定在一起，如果有人用伪造的MAC地址在网络上发帖，这个帖子就会被认为是原用户的行为，从而给这名学生或老师带来严重的不良影响。
所以，仅仅基于MAC地址进行认证显然不可行。如果我们想增加额外的DHCP option选项，也会增加实际实施的难度。因此，除了绑定MAC地址之外，还可以绑定其他信息，例如操作系统和主机名等，增加伪造的难度。我们在其中还增加了fingerprint（指纹信息）的选项，这样可以更有效地防止不合法设备或用户接入网络，确保入网设备的安全性。我们清华大学实施IPoE，其中一个原因也是为了实现准入统一认证制度，这是在教育部下发的通知中明确要求的。
