LAN.ADDRESS.6

The RG MUST be able to assign its own WAN IPv4 address (i.e. its public address) to a particular LAN device, concurrent with private IPv4 addressing being used for other LAN CPE.

In this situation, one device on the LAN is given the same public IPv4 address (through DHCP or manual configuration of the LAN CPE IPv4 stack). Other LAN devices utilize private IPv4 addresses. The RG can then be configured as identified in LAN.PFWD.2 so that the LAN device sharing the WAN IPv4 address receives all unidentified or unsolicited port traffic to any specific LAN device. If the RG is not configured in this manner, then only inbound traffic resulting from outbound traffic from the LAN CPE would be directed to that LAN CPE.

The gateway identified to the LAN device must be on the same subnet as that associated with the WAN IPv4 address. Note that the use of the WAN gateway address does not guarantee this since it need not meet this requirement.

LAN.ADDRESS.8

When using a WAN IPv4 address assigned to a LAN device, the RG MUST be able to be configured by the user whether this LAN device can directly communicate with other devices on the local LAN without the need to traverse the broadband connection.

This will only be done to the extent to which the RG can control isolation (e.g. routing and internal switch fabric). It does not extend to isolation external to the RG (e.g. external switch or router), which are beyond the control of the RG.

LAN.DHCPS.6

The RG MAY incorporate auto-detection of other DHCPv4 servers on the local LAN and, if configured to do so, disable the internal DHCPv4 server functionality of the RG in this situation.

In this situation, the RG would try to obtain a configuration for its LAN port through DHCPv4. If a DHCPv4 response was received, the RG would then use the information in the DHCPv4 response (e.g. IPv4 address, subnet and DNS information) and disable its internal DHCPv4 server. If implemented and a DHCPv4 response is received, this requirement takes precedence over requirement LAN.DHCPS.15.

LAN.DHCPS.10

If the RG is in a bridged configuration for LAN device traffic (i.e. NAT/NAPT is not enabled), the RG MUST support the enabling and configuration of the local RG DHCPv4 server (address range and subnet mask) remotely from a Controller. This address range may be either public or private addresses (assuming that the service provider is providing the NAT/NAPT function in the network).

Note that this assumes that a separate management IP (v4 or v6) interface has been established to the RG expressly for the purpose of CWMP or USP remote management.

LAN.DHCPS.18

The embedded DHCPv4 server functionality of the RG SHOULD provide a mechanism by which an IPv4 address can be assigned to a particular LAN device by MAC address. The user interface to establish this association may use an alternate mechanism to identify this assignment (e.g. by selecting the device using its current IPv4 address or device name) and the MAC address may be transparent to the user. These addresses may include addresses within the default subnet or addresses from additional public/private subnets that may be provisioned.

For example, the RG might have a default WAN side IPv4 address that is used for NAPT to a subset of devices and an additional set of WAN side IPv4 addresses that are bridged. The embedded DHCPv4 server might be used to assign this second set of IPv4 addresses to specific LAN CPE.

LAN.PFWD.2

The port forwarding mechanism MUST be able to be configured to direct all inbound unidentified or unsolicited port traffic originating from a user-selected public IPv4 address to any user selected LAN device.

The LAN device may be using either a private IPv4 address or the public WAN IPv4 address as identified in requirement LAN.ADDRESS.6 and LAN.ADDRESS.7.

LAN.FWD.10

The RG MUST allow for the selection of which traffic to forward over which connection (in the case of multiple PVCs, multiple PPPoE sessions, GPON Port ID, etc…) according to any one or more of the following pieces of information:

1. destination IP (v4 or v6) address(es) with subnet mask,

2. originating IP (v4 or v6) address(es) with subnet mask,

3. source MAC address,

4. destination MAC address,

5. protocol (TCP, UDP, ICMP, …)

6. source port,

7. destination port,

8. IEEE 802.1Q user priority,

9. FQDN (fully qualified domain name) of WAN session,

10. DiffServ codepoint ([82]),

11. Ethertype (IEEE 802.3 length/type field), and

12. traffic handled by an ALG.

LAN.FWD.14

The RG SHOULD be able to restrict the routing information for each WAN connection to specific LAN devices.

For example, a user might have four PCs in the home, have a WAN connection to the Internet and have a WAN connection to an employer’s network. The RG could be configured to allow all PCs access to the Internet, but only one specific PC might be allowed to send traffic over the WAN interface to the employer’s network.

LAN.IGMP.ROUTED.14

The RG MUST have a join and leave latency less than 20 ms.

This means that when the RG receives a leave, it must stop sending the stream to that device (although it is expected to continue sending to other devices that have not left) in less than 20 ms. The RG must not wait for the results of a membership query before it stops sending the stream. Rather, it must rely on its membership database to know whether there are other devices receiving that stream. When the RG receives a join, its allocation of the overall time for starting to forward that stream must not exceed 20 ms.

This latency definition handles southbound join/leave; however a definition for the northbound join/leave latency will also be useful. Also, the northbound as well as southbound latency definition involves a tradeoff between multicast system dynamics (lower latency -> higher dynamics) and bandwidth efficiency (low latency -> better bandwidth efficiency). A statistical analysis will be helpful, based on empirical TV channel switching dynamics, when available.

LAN.FW.SPI.2

The RG SHOULD provide protection for the following:

• Port scans

• Packets with same source and destination addresses

• Packets with a broadcast source address

• Downstream packets with a LAN source address

• Invalid fragmented IP (v4 or v6) packets

• Fragmented TCP packets

• Packets with invalid TCP flag settings (NULL, FIN, Xmas, etc.)

• Fragmented packet headers (TCP, UDP and ICMP)

• Inconsistent packet header lengths

• Packet flooding

• Excessive number of sessions

• Invalid ICMP requests

• Irregular sequence differences between TCP packets

The extent of this protection will be limited when the RG is configured as a bridge in which only PPPoE traffic is bridged. This protection MUST be available when the RG terminates IP (v4 or v6) or bridges IPv4.

LAN.FW.SPI.8

The RG SHOULD support specification of any of the following in a firewall rule:

• destination IP (v4 or v6) address(es) with subnet mask

• originating IP (v4 or v6) address(es) with subnet mask

• source MAC address

• destination MAC address

• protocol (0-255, or by alias: TCP, UDP, ICMP, IP, IGMP, eigrp, gre, ipinip, pim, nos, ospf, …)

• source port

• destination port

• IEEE 802.1Q user priority

• FQDN (fully qualified domain name) of WAN session

• DiffServ codepoint ([82])

• Ethertype (IEEE 802.3) length/type field)

• Traffic matching an ALG filter

• IEEE 802.1Q VLAN identification

• packet length

• TCP flags (urg, ack, psh, rst, syn, fin)

• IP option values (potentially name aliases)

• logical interface of source

• logical interface of destination

LAN.FW.SPI.10

The RG SHOULD support firewall rules that support generic pattern matching against the header or data payload of traffic. Logically this can be envisioned as:

• match(header[offset[,length|max]], condition)

• match(payload[offset[,length|max]], condition)

where condition is (relationship, data) such as:

• (=, ne, all, one, and, or) for a hex field

• (=, ne, gt, ge, lt, le) for a decimal/hex field

• (=, ne, contains) for a string field

LAN.QoS.2

The RG SHOULD support classification of LAN directed WAN traffic and placement into appropriate queues (or discard) based on any one or more of the following pieces of information:

1. packet length (note: to be used judiciously to avoid out of order packet delivery).