Additional IWF for IPoE based Access in N:1 VLANs

A typical DHCP Relay Agent sets the giaddr of client requests in order to provide an indication to a DHCP server about the subnet on which a client is located and therefore the address that the server should provision.

The AN is well positioned to add the circuit-id and remote-id sub-options that a typical relay agent adds, but it does not have an IP interface on the subnet or VLAN where the client resides in order to properly set the giaddr field as an indication of the client subnet.

RFC 3046 identifies the possibility that a bridge positioned between the full DHCP relay agent and the client may add the relay agent information option, but not set the giaddr field. This approach is used in this architecture, where the AN that has the information for constructing circuit-id and remote-id is a Layer 2 element with no need for a Layer 3 interface on each client subnet or VLAN. Since RFC 3046 gives no name to a network element performing this function, it is called a Layer 2 DHCP Relay Agent in this Technical Report.

The use of a Layer 2 DHCP relay agent does not affect the need for a full DHCP relay agent upstream. Such an agent is still needed to set the giaddr in client requests and to manage multicast to unicast behavior. It does not need to add circuit-id and remote-id, but it does need to be able to discern trusted from untrusted interfaces and only honor those fields when they come from trusted interfaces.

3.8.1.1

Basic Operation

A core principal in RFC 3046 is the difference between trusted and untrusted circuits. This guides the operation of both the Layer 2 DHCP relay agent and the full DHCP relay agent. In the absence of a Layer 2 relay agent, the access network is untrusted, and the DHCP relay agent will discard packets arriving on this untrusted interface that already contain option-82. When a Layer 2 relay agent is present, the full DHCP relay agent must be configured to (and, in fact, be able to) trust the access network between them, and expect DHCP packets to arrive containing appropriate option-82 data. In this case, the access network downstream from the DHCP relay agent is trusted, and the access network downstream from the Layer 2 relay agent is untrusted.

It is possible that the Layer 2 relay agent may trust some access interfaces, or perhaps specific VLANs of those interfaces, if they are trunking, because of the presence of another Layer 2 relay agent downstream. For such an interface, option-82 addition, removal, and regulation will reflect the trusted nature of that interface, and the Layer 2 DHCP relay requirements apply to the downstream agent.

3.8.2 DHCP Processing

These requirements describe the DHCP processing on Access Nodes. This is part of the IPoE IWF.

R-120 The Access Node MUST be able to function as a Layer 2 DHCP Relay Agent on selected untrusted ports of a given VLAN.

R-121 The Access Node MUST be able to disable the Layer 2 DHCP Relay Agent on selected user- facing ports of a given VLAN.

R-122 The Access Node, when performing the function of a Layer 2 DHCP Relay Agent, MUST support configuration of downstream trusted interfaces from which it does not discard packets arriving with option-82 already present, and does not add or replace option-82 in these packets.

R-123 The Access Node, when performing the function of a Layer 2 DHCP Relay Agent, MUST NOT remove option-82 from response packets that are destined for downstream trusted interfaces.

R-124 The Access Node, when performing the function of a Layer 2 DHCP Relay Agent, MUST add option-82 with the „circuit-id’ and/or ‘remote-id’ sub-options to all DHCP messages sent by the client before forwarding to the Broadband Network Gateway.

Note: see more details about the use of such sub-options in Section 3.9 Access Loop Identification and Characterization.

R-125 The Access Node, when performing the function of a Layer 2 DHCP Relay Agent, MUST remove option-82 information from all DHCP reply messages received from the Broadband Network Gateway before forwarding to untrusted interfaces.

R-126 A server-originated broadcast DHCP packet containing option 82 MUST NOT be bridged to untrusted user-facing ports by an Access Node.

R-127 An Access Node, when performing the function of a Layer 2 DHCP Relay Agent, MUST examine option-82 and/or the chaddr field, and only transmit these packets (after removal of option-82) to the untrusted interface for which it is intended.

R-128 The Access Node, when performing the function of a Layer 2 DHCP relay agent, MUST NOT convert the DHCP request from the client from a broadcast to a unicast packet at layer 2 or layer 3.

R-129 The Access Node, when performing the function of a Layer 2 DHCP relay agent, MUST NOT set the giaddr on the DHCP request from the client.

R-130 The Access Node, when performing the function of a Layer 2 DHCP relay agent, MUST be configurable per port to snoop all DHCP traffic and filter out those DISCOVER and REQUEST packets from the access loop that have nonzero giaddr, and unicast request packets with a zero

ciaddr.

R-131 The Access Node, when performing the function of a Layer 2 DHCP relay agent, MUST discard any DHCP request packet containing option-82 or giaddr and received from an untrusted port.

R-132 The Access Node, when performing the function of a Layer 2 DHCP relay agent, MUST only forward DHCP requests to the upstream designated port(s) to prevent flooding or spoofing.

R-133 The Access Node, when performing the function of a Layer 2 DHCP relay agent, MUST be able to transparently forward any DHCP option information other than for option 82.

3.8.3 ARP Processing and IP Spoofing Prevention

R-134 The Access Node SHOULD inspect upstream and downstream DHCP packets, discover mapping of IP address to MAC address and access ports and populate its ARP table accordingly.

R-135 The Access Node SHOULD ensure that downstream broadcast ARP requests are not sent on access ports that do not have the associated requested IP address.

The above requirement is not made redundant by R-224 since it addresses the case of a second BNG (i.e. multiple BNG aggregation) that is not acting as a DHCP relay and is thus required to send ARP requests. A malicious user might try using another user IP address (i.e. spoofing) in order to deny/disturb the other user or a network service or to gain unauthorized access to resources. The Access Node can be aware of the mapping between IP address, MAC address and port using the process described in R-134.

R-136 The Access Node SHOULD provide a mechanism to prevent user IP address spoofing.

R-137 The Access Node SHOULD be configurable with a list of IP addresses associated with user port and VLAN for users having static IP configuration.