摘要

  • RFC 2516 将无会话状态的发现阶段与点到点 PPP 会话分开；只有会话建立后，主机和接入集中器才分配虚拟接口资源。
  • 可选 AC-Cookie 让集中器检查发给某个源地址的值能否随 PADR 返回；Host-Uniq 与 Relay-Session-Id 则分别服务于主机和中继各自的关联需求。
  • 这些不透明标签只携带有限的报文上下文。它们都不能认证某个人，也不能证明后续 PPP 配置、流量或商业服务已经发生。

广播发现不先建会话表

1999 年 2 月发布的 RFC 2516，描述了 PPP 如何穿过一个供多台主机和接入集中器共同使用的以太网。主机广播 PADI；能够提供响应的集中器可以返回 PADO。主机选定一个报价，再向该集中器单播 PADR；PADS 随后确认接受的服务并给出会话标识符。规范把这两个阶段明确命名为 Discovery 与 PPP Session：在 PPP 会话建立之前，发现过程保持无会话状态；建立之后，主机与集中器都必须为 PPP 虚拟接口分配资源。

这道边界让共享网络上的每次广播不必自动成为持久的会话资源承诺。“无状态”并不表示处理报文无需任何计算，而是规定了何时创建属于特定 PPP 会话的较持久状态。

发出去的值必须回来

接入集中器可以在 PADO 中放入可选的 AC-Cookie。主机收到后，必须在 PADR 中原样带回；主机不解释这些字节。RFC 建议集中器能够依据 PADR 的源地址重新生成该值。这样，集中器可以检查收到报价的地址是否能沿返回方向送回该值，并据此限制该地址的并发会话数。

RFC 举例说明可以用集中器独有密钥，对主机 MAC 地址计算 HMAC；它没有规定必须采用这一算法，也没有承诺普遍防护。文本明确指出 Cookie 无法抵御所有拒绝服务攻击。它所支持的是延后分配会话资源的策略，不是证明地址背后的人是谁。

其他标签的归属不同。主机选择的 Host-Uniq 用来把收到的 PADO 或 PADS 对应到自己的请求；集中器必须原样反射，也不得解释其值。Relay-Session-Id 可由中间中继加入，对主机和集中器均不透明，两端都须在响应中原样带回。它们是各自发起方的关联标记，不是通用身份。

PADS 才改变资源状态

接受服务的 PADS 带有非零 SESSION_ID 和被接受的服务名；服务被拒时，错误标签与零会话标识符一起返回。完整 PPPoE 会话由源 MAC、目的 MAC 和 SESSION_ID 共同界定，不能仅凭 16 位编号把不同上下文合并。

PADS 使通信进入 PPP Session 阶段，但并不代替 RFC 1661 规定的 LCP 协商、可选认证和网络控制协议配置。本文不再讨论相邻 RFC 4638 已覆盖的负载尺寸与 1492 字节问题；焦点是资源承诺时点和三类标签的不同范围，而不是后续服务是否交付。

RFC 2516 记录的是一种资源保护设计及其自述限制；它没有量化节省的内存，不能证明当代部署，更不证明某次会话通过了认证或承载了流量。

来源： RFC 2516；RFC 1661；RFC 2104；RFC 4638（仅作相邻负载尺寸主题的边界说明）。