IPv6 家庭用ルータガイドライン第 2 版と TR-124i5 の比較 第 1.0 版 2019 年 4 月 2 日 IPv4/IPv6 共存 WG IPv6 家庭用ルータ SWG
変更履歴 版改版日摘要 1.0 2019 年 4 月 2 日第 1 版
本書の構成 本文書の第 2 章以降の章, 節, 項は,TR-124i5 との比較, 参照がしやすいように TR-124i5 における第 4 章の Section の各階層に基づいて構成している. また, 文書内では,TR-124i5 における Section,Item,Requirements の項目を再掲し, ガイドラインとの差分を記載する形とした. 2
目次 1 本文書作成の背景と目的...1 2 General Device Requirements...2 2.1 IPv6 Networking Protocols...2 3 Wide Area Networking (WAN)...3 3.1 Bridging...3 3.2 EAP Re-authentication (ERP) for DHCPv6...4 3.3 IPv6 WAN Connection...5 3.4 Transitional IPv6 WAN Connection...10 3.4.1 6rd Transition Mechanism...10 3.4.2 Dual Stack Lite Transition Mechanism... 11 3.4.3 IPv6 connectivity with content-based IPv4 release control transition mechanism...13 3.4.4 MAP-E Transition Mechanism...14 3.5 PPP Client...15 3.5.1 PPP Client for establishment of IPv6 connection...18 3.6 802.1x Client...19 3.7 Denial of Service Prevention...21 3.8 Quality of Service...22 3.8.1 VLAN based QoS...29 3.8.2 Quality of Service for Tunneled Traffic...30 3.9 IPsec VPN peer to peer...31 3.10 L2tp VPN Remote Access...33 3.11 Port Control Protocol...34 4 Local Area Networking (LAN)... 36 4.1 General LAN Protocols...36 4.2 LAN IPv6 Addressing...36 4.3 DHCPv6 Server...38 4.4 Naming Services (IPv6)...40 4.5 Port Forwarding (IPv6)...42 4.6 MLD and Multicast in Routed Configurations (IPv6)...43 4.7 Firewall (Basic)...44 4.8 Firewall (Advanced)...45 4.9 Captive Portal with Web Redirection...49 i
5 Management & Diagnostics... 51 5.1 UPnP...51 5.1.1 UPnP IGD...51 5.1.2 UPnP IGD to allow Connection Request Forwarding...52 5.1.3 UPnP IGD to allow Connection Request Forwarding through the Firewall of the device...52 5.2 Remote Management (Web Browser)...53 5.3 Network Time Client...55 6 検討メンバー... 57 ii
1 本文書作成の背景と目的 1 IPv4/IPv6 共存ワーキンググループ IPv6 家庭用ルータサブワーキンググループ 2 ( 以下, 当該 SWG) では, IPv6 家庭用ルータガイドライン第 2 版 ( 以下, ガイドライン ) を 2010 年 7 月 29 日に公開している. 第 2 版の公開以降, 当該 SWG では国際的な議論 / 動向に配慮し, 外部団体による関連ドキュメントの調査活動を行っている. この活動は, 調査対象ドキュメントとガイドラインの差異を明確にするとともに, 将来的なガイドラインの改版において, 対象ドキュメントの内容をガイドラインに取り込むことを目的としており, 具体的には Internet Engineering Task Force 3 ( 以下,IETF),Broadband Forum 4 ( 以下,BBF) 等が発行したドキュメントを対象としている. 本文書は,BBF が 2016 年 7 月に発行した TR-124 Functional Requirements for Broadband Residential Gateway Devices Issue 5 5 ( 以下,TR-124i5) の内容を調査すると共に, ガイドラインと比較し, 差分をまとめたものである 6. IPv6 家庭用ルータの最低限の仕様をまとめたガイドラインとは異なり,TR-124i5 は, 装置全体の機能要件をまとめた広範囲にわたるものであるが,IPv6 に関係する部分のみを比較した. 比較の結果, いくつかの部分で両文書に大きな差異があった. この差異は, 主に対象機器の設置環境 ( 地域の違い等 ) や IPv6 機能に関する考え方の違いに起因している. 本文書において整理した両ドキュメントの違いが, 読者の理解を促進し, 家庭用ルータの実装者における仕様策定, 及びサービス提供者における IPv6 接続サービスの仕様策定の参考になれば幸いである. 1 :http://www.v6pc.jp/ 2 IPv6 家庭用ルータ SWG:http://www.v6pc.jp/jp/wg/coexistenceWG/v6hgw-swg.phtml 3 The Internet Engineering Task Force:https://www.ietf.org/ 4 Broadband Forum:https://www.broadband-forum.org/ 5 TR-124i5:https://www.broadband-forum.org/wp-content/uploads/2018/11/TR-124_Issue-5.pdf 6 TR-124 Issue 2 との比較文書については,2014 年 6 月に公開している. http://www.v6pc.jp/pdf/v6hgw_tr124i2_comparison_1.0.pdf 1
2 General Device Requirements 2.1 IPv6 Networking Protocols GEN.NETv6. 1 The RG MUST support IP Version 6, which is defined in IETF RFC 2460. GEN.NETv6. 2 The RG MUST support enabling and disabling of IPv6. 明確に記述はないが, 自明なため問題なし. ガイドラインは,IPv6 機能を利用する場合の基準について記述しているため,IPv6 機能を off にすることについては触れていない. 2
3 Wide Area Networking (WAN) 3.1 Bridging WAN.BRIDGE. 1 The RG MUST be able to bridge IPv4 over Ethernet. WAN.BRIDGE. 2 The RG MUST be a learning bridge as defined in IEEE 802.1D for all logical and physical Ethernet interfaces, supporting a minimum of 272 MAC addresses. WAN.BRIDGE. 3 If bridge mode is enabled for IPv4 on the RG by default for LAN connected devices, the RG MUST be able to support additional connections for TR-069 remote management addressability (using direct DHCPv4 or static IPv4, PPP, etc.), and connections for any locally terminated service that require IP (v4 or v6) addressability (e.g. gateway integrated voice ATA ports, etc.). Note that this special bridge mode that includes a device remote management session connection requires an additional WAN connection from the network. This requirement is considered conditional as a result of the network side dependency, but the RG must support this type of configuration. ガイドラインでは IPv4 ブリッジ機能については対象外. ガイドラインでは IP4 ブリッジ機能については対象外. TR-069 の遠隔管理が主な要件となっているため, ガイドラインでは対象外. 3
WAN.BRIDGE. 4 The RG MUST be able to bridge IPv6 over Ethernet (Ethertype 0x86DD). This includes bridging of multicast frames. WAN.BRIDGE. 5 The RG MUST be able to configure IPv6 bridging for a WAN interface, separate from IPv4 treatment. WAN.BRIDGE. 6 The RG MUST be able to configure IPv6 bridging separately for each WAN interface (if there are multiple WAN interfaces). WAN.BRIDGE. 7 When IPv6 bridging is enabled on a WAN interface, the RG MUST be configurable to act as a host on that WAN interface (doing SLAAC, etc.). It will not request IA_PD, since that is not a host function. ガイドラインではブリッジ機能については触れていない.IPv6 に関連するブリッジ機能については, 次版以降で検討予定. ガイドラインではブリッジ機能については触れていない.IPv6 に関連するブリッジ機能については, 次版以降で検討予定. ガイドラインではブリッジ機能については触れていない.IPv6 に関連するブリッジ機能については, 次版以降で検討予定. ガイドラインではブリッジ機能については触れていない.IPv6 に関連するブリッジ機能については, 次版以降で検討予定. 3.2 EAP Re-authentication (ERP) for DHCPv6 WAN.DHCPv6.ERP 1 The RG MUST support the ERP Local Domain Name (LDN) DHCPv6 Option (RFC 6440 [136]). WAN.DHCPv6.ERP 2 The RG MUST support receiving a DHCPv6 request message from a UE client, which includes an Option Request option requesting the DHCPv6 ERP Local Domain Name option (RFC 6440 [136]). The DHCPv6 request message may be Solicit, Request, or Information Request. ERP に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. ERP に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. 4
WAN.DHCPv6.ERP 3 If the RG has pre-existing knowledge of the ERP local domain name for a client (for example, from a previous AAA exchange), it SHOULD include it in an instance of the DHCPv6 ERP Local Domain Name option of the DHCPv6 message and forward it to the DHCPv6 server as a sub-option of the Relay-Supplied Options option (RFC 6422 [134]). WAN.DHCPv6.ERP 4 The RG MUST support relaying a DHCPv6 Reply Message with the DHCPv6 ERP Local Domain Name option from the DHCPv6 server to the client. WAN.DHCPv6.ERP 5 The RG MUST support configuration of the parameters for it to connect to the RADIUS or Diameter server via Web GUI or TR- 069 extension. ERP に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. ERP に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. ERP に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. 3.3 IPv6 WAN Connection WAN.IPv6. 1 The RG MUST support automated establishment of an IPv6 connection according to the flow in Annex A.2. 接続フローについて, ガイドラインに記述はないが, ガイドライン改版時に 3 章の冒頭に記述するなど参考情報として参照する. WAN.IPv6. 2 The RG MUST support a dual stack of IPv4 and IPv6 running simultaneously, as described in section 2 of RFC 4213. ガイドラインでは IPv6 機能に特化した要件を記述している為, 本要求条件は検討の範囲外とする. 5
WAN.IPv6. 3 The RG MUST allow the IPv6 stack to be enabled / disabled. WAN.IPv6. 4 The RG MUST support DHCPv6 client messages and behavior per IETF RFC 3315. See WAN.DHCPC.5 for further specifics on IAID value. WAN.IPv6. 5 The RG MUST support the role of the CPE requesting router in RFC 3633. WAN.IPv6. 6 The RG MUST support specifying in its DHCPv6 prefix delegation request an indication of the length of prefix it requires. If the RG supports multiple LANs, or has PD requests from its LAN, it MUST indicate a preferred prefix length that would at least enable the RG to assign a /64 prefix to each LAN it supports. Note that the delegated prefix may vary from the requested length. WAN.IPv6. 7 When sending DHCPv6 messages, the RG MUST identify itself in OPTION_CLIENTID (1) (client-identifier) using the same client identifier as for IPv4 (see WAN.DHCPC.3 and.4). WAN.IPv6. 8 The RG MUST support IPv6 node requirements as a host node, per IETF RFC 6434 [135]. WAN.IPv6. 9 The RG MUST support stateless address auto-configuration (SLAAC) as a host, per IETF RFC 4862. ガイドラインは,IPv6 機能を利用する場合の基準について記述しているため,IPv6 機能を off にすることについては触れていない. ガイドラインでも,WAN インタフェースで DHCPv6 を実装することは必須としている.IAID についてはガイドラインでは詳述しておらず, 次版での反映を検討する. ガイドラインでも, 同等の記述有り.( 要件 1) サービス仕様に依存する為, 次版での反映については要検討とする. RFC を超えた記述になっており, 次版での反映については要検討とする. ガイドラインでは,RFC4294 (RFC6434) そのものを参照していないが, 次版での反映については要検討とする. ガイドラインでも, 同等の記述有り.( 要件 4) 6
WAN.IPv6. 10 The RG MUST support receipt of route information per RFC 4191. If the RG only has one WAN connection, it does not need to place this information in its routing table, but it does need to save it (for possible forwarding on the LAN interface). WAN.IPv6. 11 If route information is provided (RFC 4191) and the RG has multiple WAN connections, it MUST place the route information in its routing table. WAN.IPv6. 12 If the RG does not have a globally-scoped address on its WAN interface after having been delegated a prefix, it MUST create addresses for itself from the delegated prefix. It MUST have at least one address and MAY have more. There is currently no algorithm defined for address creation. It should be assumed that different service providers will want different rules for how to create the address, how many addresses to create, and in the case of multiple addresses, how the different addresses are used. WAN.IPv6. 13 Requirement deleted; redundant with WAN.IPv6.3 ガイドラインでは,WAN 側については RFC4191 対応に関する記述はない. 次版での反映については要検討とする. ガイドラインでは,WAN 側については RFC4191 対応に関する記述はない. 次版での反映については要検討とする. ガイドライン ( 要件 6) に同様の記述があるが, 後半の複数プレフィックスを取得可能な場合の記述について備考に追記する. 項目が削除されている為, 対象外とする. 7
WAN.IPv6. 14 The RG MUST be able to request the following DHCPv6 options: IA_NA (RFC 3315), reconfigure accept (RFC 3315), IA_PD (RFC 3633), and DNS_SERVERS (RFC 3646). WAN.IPv6. 15 The RG SHOULD be able to request the following DHCPv6 options: SNTP_SERVERS (RFC 4075), domain search list (RFC 3646), and Client FQDN (RFC 4704). WAN.IPv6. 16 The RG MUST continue to use the connectivity parameters (obtained via RA or DHCP) and consider them valid until either they expire or the RG is explicitly told to use different values. WAN.IPv6. 17 The connectivity parameters (obtained via RA and DHCPv6) MUST persist across loss of WAN connection (or lack of response from WAN connection). ガイドラインには,IA_NA, IA_PD,DNS_SERVERS については, オプション名での記述がない為, 次版にて追記する. Reconfigure に関しては, 関連記述 ( 要件 36) にあるが, Reconfigure Accept の追記も含め次版での記述内容について検討する. また,ISP との情報のやりとりに関わるプロトコルおよびプロトコルオプションに関する記述について全体構成の見直しを検討する. ガイドラインには, SNTP_SERVERS, Domain Search List については, オプション名での記述がない為, 次版にて追記する.Client FQDN に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. また,ISP との情報のやりとりに関わるプロトコルおよびプロトコルオプションに関する記述について全体構成の見直しを検討する. ガイドラインには記述がないが, 次版での記述を検討する. ガイドラインに記述がないが, ネットワーク安定性が向上すると考えられる為, 次版にて追記する. 必要度については要検討. 8
WAN.IPv6. 18 The device MUST continue to use the connectivity parameters (obtained via RA or DHCP) and consider them valid until either they expire or the device is explicitly told to use different values. WAN.IPv6. 19 The RG MUST NOT advertise any address prefixes on the WAN using the IPv6 neighbor discovery protocol, or advertise itself as a default router. WAN.IPv6. 20 The RG MUST provide up to 4 instances of option-data within a single OPTION_VENDOR_OPTS (17) (RFC 3315) with IANA "ADSL Forum" Enterprise Number as the enterprise-number. Each instance will have one of the 4 sub-options from WAN.DHCPC.7 as the vendor-specific opt-code, with the corresponding value in the vendor-specific option-data. If the value of a parameter is empty for the RG, then the sub-option MUST be omitted. If there are no values to provide, the entire option MUST be omitted. WAN.IPv6. 21 The RG SHOULD be able to request the following DHCPv6 options: address selection policy (RFC 7078 [142]), route information (draft-ietf-mif-dhcpv6-route-option Error! Reference source not found.), and DNS selection policy (RFC 6731 [139]). WAN.IPv6. 22 If route information is provided (draft-ietf-mif-dhcpv6-route- option) and the RG has multiple WAN connections, it MUST place the route information in its routing table. ガイドラインに記述がないが, ネットワーク安定性が向上すると考えられる為, 次版にて追記する. 必要度については要検討. ガイドラインに記述なし.WAN 側インタフェースのディフォルト動作として禁止することを次版で記述する. BBF における個別要件と思われる為, 対象外とする. ガイドラインにて記述なし. アップリンクが複数ある場合の対応については, 今後の動向次第で次版への反映を検討する. ガイドラインにて記述なし. アップリンクが複数ある場合の対応については, 今後の動向次第で次版への反映を検討する. 9
WAN.IPv6. 23 The RG SHOULD generate address selection policy based on policies obtained from each WAN link by DHCPv6 option (draft- ietf-6man-addr-select-opt) or manually configured policy. ガイドラインにて記述なし. アップリンクが複数ある場合の対応については, 今後の動向次第で次版への反映を検討する. 3.4 Transitional IPv6 WAN Connection 3.4.1 6rd Transition Mechanism WAN.TRANS. 6rd. WAN.TRANS. 6rd. 1 The RG MUST support the 6rd transition mechanism as described in RFC 5969. This includes being able to configure the necessary parameters via TR-069 and DHCPv4, creation of the prefix, using the created prefix as a delegated prefix for purpose of including one of its /64s in RA messages, and modifying the IP header for traffic that goes between the WAN and LAN devices. 2 The RG MUST support enabling and disabling of the 6rd feature on the default routed IPv4 connection. 6rd is not applicable to bridged WAN interfaces. 2019 年 1 月時点では, 国内では IPv6 only もしくは IPv4/IPv6 Dual Stack によるネットワーク構成が主流になっており,6rd の利用は想定されない為, ガイドラインでは対応予定なし. 但し,BBF では MUST 要件となっている. 2019 年 1 月時点では, 国内では IPv6 only もしくは IPv4/IPv6 Dual Stack によるネットワーク構成が主流になっており,6rd の利用は想定されない為, ガイドラインでは対応予定なし. 但し,BBF では MUST 要件となっている. 10
WAN.TRANS. 6rd. 3 If the RG supports configuration mechanisms other than the 6rd DHCPv4 option 212 (user-entered, TR-069, etc.), the RG MUST support 6rd in "hub and spoke" mode. 6rd in "hub and spoke" mode requires all IPv6 traffic to go to the 6rd border relay. In effect, this requirement removes the "direct connect to 6rd" route defined in section 7.1.1 of RFC 5969. 2019 年 1 月時点では, 国内では IPv6 only もしくは IPv4/IPv6 Dual Stack によるネットワーク構成が主流になっており,6rd の利用は想定されない為, ガイドラインでは対応予定なし. 但し,BBF では MUST 要件となっている. 3.4.2 Dual Stack Lite Transition Mechanism WAN.TRANS. DS-LITE. WAN.TRANS. DS-LITE. WAN.TRANS. DS-LITE. WAN.TRANS. DS-LITE. 1 The RG MUST support DS-Lite (RFC 6333) with IPv4 in IPv6 encapsulation (RFC 2473). 2 This requirement replaced by requirement WAN.TRANS.DS-Lite.6. 3 The RG MUST configure a static IPv4 default route toward the DS-Lite tunnel. 4 The RG MUST deactivate the NAPT function on the DS-Lite interface. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 11
WAN.TRANS. DS-LITE. WAN.TRANS. DS-LITE. WAN.TRANS. DS-LITE. WAN.TRANS. DS-LITE. WAN.TRANS. DS-LITE. WAN.TRANS. DS-LITE. 5 The RG MUST support enabling and disabling of DS-Lite. 6 The RG MUST be able to use the DHCPv6 option to retrieve the FQDN of the AFTR element, as defined in RFC 6334. 7 Manual configuration on the RG of the FQDN or the IPv6 address of the AFTR element SHOULD be supported. 8 Remote configuration via TR-069 of the FQDN or the IPv6 address of the AFTR element SHOULD be supported. 9 The RG MUST support configurable precedence between the FQDN and the IPv6 address. 10 The RG MUST support configurable precedence between dynamic or static configuration of the IPv6 address of the AFTR element when both are available. The RG MUST use DHCPv6 by default or use an operator-specific configuration. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 12
3.4.3 IPv6 connectivity with content-based IPv4 release control transition mechanism WAN.TRANS. v4-release-control WAN.TRANS. v4-release-control WAN.TRANS. v4-release-control WAN.TRANS. v4-release-control 1 The RG MUST provide a mechanism that monitors IPv4 session/traffic. 2 The RG MUST provide a timer-based trigger for releasing an IPv4 address. 3 The RG MUST provide signaling to the BNG according to RFC 1332. 4 The RG MUST provide the (re)assignment of an IPv4 address inside a PPP session according to RFC 1332, independent of the IPv6CP status according to section 2.1/RFC 4241. 2019 年 1 月時点では, 国内では IPv4 Release Control(IPv4 アドレスをオンデマンドで利用するサービス )[TR-242 を参照のこと ] の利用は確認されていない為, ガイドラインでは対応予定なし. 但し,BBF では MUST 要件となっている. 2019 年 1 月時点では, 国内では IPv4 Release Control(IPv4 アドレスをオンデマンドで利用するサービス )[TR-242 を参照のこと ] の利用は確認されていない為, ガイドラインでは対応予定なし. 但し,BBF では MUST 要件となっている. 2019 年 1 月時点では, 国内では IPv4 Release Control(IPv4 アドレスをオンデマンドで利用するサービス )[TR-242 を参照のこと ] の利用は確認されていない為, ガイドラインでは対応予定なし. 但し,BBF では MUST 要件となっている. 2019 年 1 月時点では, 国内では IPv4 Release Control(IPv4 アドレスをオンデマンドで利用するサービス )[TR-242 を参照のこと ] の利用は確認されていない為, ガイドラインでは対応予定なし. 但し,BBF では MUST 要件となっている. 13
WAN.TRANS. v4-release-control WAN.TRANS. v4-release-control 5 The timer that triggers the release of the IPv4 address MUST be configurable. 6 The timer that triggers the release of the IPv4 address MUST be configurable via TR-069. 2019 年 1 月時点では, 国内では IPv4 Release Control(IPv4 アドレスをオンデマンドで利用するサービス )[TR-242 を参照のこと ] の利用は確認されていない為, ガイドラインでは対応予定なし. 但し,BBF では MUST 要件となっている. 2019 年 1 月時点では, 国内では IPv4 Release Control(IPv4 アドレスをオンデマンドで利用するサービス )[TR-242 を参照のこと ] の利用は確認されていない為, ガイドラインでは対応予定なし. 但し,BBF では MUST 要件となっている. 3.4.4 MAP-E Transition Mechanism WAN.TRANS. MAP-E. WAN.TRANS. MAP-E. WAN.TRANS. MAP-E. WAN.TRANS. MAP-E. 1 The RG MUST support mapping of address and port with encapsulation method (MAP-E) as specified in RFC 7597 [144]. 2 The RG MUST support the configuration for MAP-E operation by one or more methods, including TR-069, DHCPv6 with options as specified in RFC 7598 [145]. 3 The RG MUST support the MAP-E configuration for parameters with consistence as specified in RFC 7598 [145]. 4 The RG MUST support enabling and disabling of MAP-E operation. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 14
WAN.TRANS. MAP-E. WAN.TRANS. MAP-E. WAN.TRANS. MAP-E. 5 When performing NAT44 function, the RG MUST restrict the port assignment within the range per MAP-E configuration. 6 The RG MUST support MAP-E operation in hub and spoke mode by forwarding IPv4-in-IPv6 packets to the MAP-E BR for distribution. 7 The RG SHOULD be able to connect to more than one MAP-E domain. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 次版にて,IPv6 移行技術の章を追加し, 要件を追記する. 但し, サービス仕様に依存する為, 必要度については要検討. 3.5 PPP Client WAN.PPP. 1 The RG MUST support PPP and the associated protocols as defined in IETF RFCs 1332, 1334, ガイドラインでは IPv4 PPP については対象外. 1661, 1877, 1994. WAN.PPP. 2 Upon receipt of non-standard or unrecognized PPP extensions according to IETF RFCs 1570 ガイドラインでは PPP については対象外. and 2153 from the broadband network (e.g. vendor or proprietary), the RG MUST operate without fault. WAN.PPP. 3 The RG MUST support PPPoE as defined in IETF RFC 2516. ガイドラインでは PPPoE については対象外. WAN.PPP. 4 The RG MUST support IETF RFC 4638 in order to accommodate MTU/MRU values greater ガイドラインでは PPPoE については対象外. than 1492 bytes in PPPoE. WAN.PPP. 5 If the RG supports ATM, the RG SHOULD support PPP over AAL5 (PPPoA) as defined in IETF RFC 2364. ガイドラインでは PPPoA については対象外. 15
WAN.PPP. 6 The RG MUST be able to save all logins and passwords for PPP sessions originated by the RG. Passwords MUST NOT be available outside the RG (that is, they cannot be queried or displayed). WAN.PPP. 7 The RG MUST NOT immediately terminate PPPoE sessions and upper layer protocol connections when the physical connection is lost. It should defer the teardown process for two minutes. If the physical connection is restored during that time, the RG MUST first attempt to use its previous PPPoE session settings. If these are rejected, then the original PPPoE session is to be terminated and a new PPPoE session attempted. WAN.PPP. 8 The RG SHOULD incorporate a random timing delay prior to starting each IP (v4 or v6) and PPP session. This random timing delay helps to reduce connection failures when a group of users attempts to establish connections to a service provider at the same time (e.g. after power is restored to a neighborhood that had a blackout). WAN.PPP. 9 If the RG receives an authentication failure when attempting an automated PPP connection attempt, it SHOULD re-try immediately to establish the connection. After three unsuccessful attempts, the RG SHOULD wait for five minutes, then repeat the connection attempt three times. If authentication still fails, the RG SHOULD back off to thirty minute intervals between groups of three attempts. ガイドラインでは記述がないが, 実装上の要求事項として記述を次版にて追記する. 要求度は SHOULD とする. (TR-124i5 では MUST であることを追記する ) ガイドラインでは記述がないが, サービス側の PPPoE セッション飽和を避けるために実装上の要求事項として記述を次版にて追記する. 要求度は SHOULD とする.(TR-124i5 では MUST であることを追記する ) ガイドラインでは記述がないが, 網側装置の負荷軽減をはかるために実装上の要求事項として記述を次版にて追記する. ガイドラインでは記述がないが, 網側装置の負荷軽減をはかるために実装上の要求事項として記述を次版にて追記する. 16
WAN.PPP. 10 If the RG is using the PPPoE client function actively, the RG MUST be able to forward PPPoE sessions initiated from LAN devices as additional PPPoE sessions to the WAN interface (this is sometimes known as PPPoE pass-through). Specifically, these LAN initiated PPPoE sessions MUST NOT be tunneled inside the RG's primary PPPoE client session. WAN.PPP. 11 When fragmentation is required, the RG MUST fragment all PPP sessions that it originates on an access VC using MLPPP interleaving as defined in IETF RFC 1990. WAN.PPP. 12 If PPP is used, the RG MAY obtain an IPv4 subnet mask on its WAN interface using IPCP (IPv4) extensions. If this is done, the IPv4 subnet masks will be communicated with IPCP (IPv4) using the PPP IPCP (IPv4) option with option code 144, the length of the option being 6 and the mask being expressed as a 32-bit mask (e.g. 0xFFFFFF80), not as a number indicating the consecutive number of 1s in the mask (from 0 to 32). The learned network information MAY, but need not, be used to populate the LAN side embedded DHCP server for the RG. The learned network information is treated as a subnet and not as a collection of individual addresses. That is, the first and last addresses in the subnet should not be used. The IPv4 address negotiated SHOULD, but need not, be the one assigned to the RG. WAN.PPP. 13 The RG MUST make the access concentrator name used with PPPoE connections available via the Web GUI, TR-064i2 and TR-069 interfaces for diagnostic purposes. ガイドラインでは記述がないが, ユーザ環境での利便性向上の為, 記述を次版にて追記する. ガイドラインでは PPP については対象外. ガイドラインでは IPv4 PPP については対象外. BBF における個別要件と思われる為, 対象外とする. 17
WAN.PPP. 14 The RG MUST support RFC 3544, IP Header Compression over PPP". ガイドラインには記述はない が, 次版にて記述を検討す る. 3.5.1 PPP Client for establishment of IPv6 connection WAN.PPP.IPv6. 1 The RG MUST support IPv6 over PPP per IETF RFC 5072 and RFC 5172. WAN.PPP.IPv6. 2 The RG MUST support establishment of an IPv6 over PPPoE connection according to the flow in Annex A.1. WAN.PPP.IPv6. 3 The RG MUST allow any particular PPP connection to be configurable for IPv4 only, IPv6 only, or both. WAN.PPP.IPv6. 4 If the RG is configured for multiple PPPoE connections, it MUST be possible to configure it to use the same login and password for all, so that only the domain is unique per connection. WAN.PPP.IPv6. 5 The RG MUST NOT tear down a shared (IPv4 and IPv6) PPP session if error conditions prevent only one IP stack (either IPv4 or IPv6) from working. The session MUST be torn down if error conditions apply to both stacks. ガイドラインには記述はないが, 次版にて記述を追記する. ガイドラインには記述はないが, 次版にて記述を追記する. 要求度については別途検討する. ガイドラインには記述はないが, 次版にて記述を追記する. 要求度については別途検討する. ガイドラインには記述はないが, 次版にて記述を追記する. 要求度については別途検討する. ガイドラインには記述はないが, 次版にて記述を追記する. 要求度については別途検討する. 18
3.6 802.1x Client WAN.dot1x. 1 The RG MUST support IEEE 802.1X acting as a supplicant. WAN.dot1x. 2 The RG MUST be able to respond to an appropriate IEEE 802.1X request and provide certificate information using Extensible Authentication Protocol-Transport Layer Security (EAP/TLS). WAN.dot1x. 3 The RG SHOULD support EAP-MD5 username and password type authentication. WAN.dot1x. 4 The RG MUST support receiving IEEE 802.1X EAPOL frames with an individual MAC address (i.e. unicast) as well as frames with a group MAC address (i.e. multicast). WAN.dot1x. 5 The RG MUST perform mutual authentication by authenticating certificate information of the requesting authenticator. WAN.dot1x. 6 The RG MUST be able to store certificate information used to authenticate the authenticator. WAN.dot1x. 7 The RG MUST be able to update the information used to validate the authenticator by either a firmware upgrade or via updated certificates. WAN.dot1x. 8 The RG SHOULD be able to update the information used to validate the authenticator by updated certificates without a firmware upgrade. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. 19
WAN.dot1x. 9 The RG MUST be able to authenticate a minimum of eight authenticators. WAN.dot1x. 10 When used with IPv4 over Ethernet and DHCPv4, if the RG already has a connection when receiving an IEEE 802.1X request, the RG SHOULD subsequently perform a DHCPv4 lease renewal upon successful 802.1X authentication. WAN.dot1x. 11 Each RG MUST have a unique factory-installed private/public key pair and an embedded ITU-T X.509 version 3 / IETF RFC 5280 [125] certificate that has been signed by the RG vendor s certificate authority. WAN.dot1x. 12 The RG certificate MUST have a validity period greater than the operational lifetime of the RG. WAN.dot1x. 13 When used with IPv6 over Ethernet and DHCPv6, if the RG already has a connection when receiving an IEEE 802.1X request, the RG SHOULD subsequently perform a DHCPv6 CONFIRM upon successful 802.1X authentication. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. WAN 側での IEEE 802.1X 利用に関しては, 国内での利用状況を調査した上で, 次版への反映要否について検討する. 20
3.7 Denial of Service Prevention WAN.DoS. 1 The RG MUST provide denial of service (DOS) protection for itself and all LAN CPE including protection from ping of death, SYN flood, LAND and variant attacks. 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. WAN.DoS. 2 The RG MUST reject packets from the WAN with source MAC addresses of devices on the local LAN or invalid IP (v4 or v6) addresses (e.g. broadcast addresses or IP (v4 or v6) addresses matching those assigned to the LAN segment). WAN.DoS. 3 The RG MUST reject any unidentified Ethernet packets (i.e. any packet that is not associated with IP (v4 or v6) or PPPoE protocols). WAN.DoS. 4 The RG MUST perform anti-spoofing filtering for IPv6. All IPv6 traffic sent to the WAN from the LAN MUST have an IPv6 source address with a prefix assigned to the LAN by the RG, that was delegated from the WAN (through DHCPv6 or configuration). WAN.DoS. 5 Because the RG must perform anti-spoofing filtering for IPv6, until it has an IPv6 LAN prefix delegation it MUST filter all upstream IPv6 traffic from the home. ガイドラインに記述がないが, 攻撃の定義や性能要件が曖昧な為, 要件として記述することは困難と考える. 次版にて,TR-124i5 では MUST 要件であることおよび記述が困難な理由を追記する. ( ルータ性能限界と対コストとのバランスに依存する等 ) ガイドラインに記述がないが, MAC アドレスについてはリジェクトせずに通常動作することも可能であると考える為, 対応予定なし.IP アドレスについては次版にて追記するが, 不正な IP アドレスの定義について検討が必要. ガイドラインに記述がないが, unidentified の定義が曖昧な為, 要件として対応予定なし. 次版にて,TR-124i5 では MUST 要件であることおよび記述が困難な理由を追記する.( ルータ性能限界と対コストとのバランスに依存する等 ) ガイドラインには記述はないが, 次版にて追記する. 要求度については RFC7084 にて MUST から SHOULD に格下げされた経緯があり, 要検討. ガイドラインに記述はないが, 次版にて追記する. 21
3.8 Quality of Service WAN.QoS. 1 The RG MUST support classification of WAN directed LAN traffic and placement into appropriate queues (or discard) based on 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, IGMP, ) (6) source TCP/UDP port and port range, (7) destination TCP/UDP port and port range, (8) IEEE 802.1Q Ethernet priority, (9) FQDN (fully qualified domain name) of WAN session, (10) Diffserv codepoint (IETF RFC 3260), (11) Ethertype (IEEE 802.3) length/type field), (12) traffic handled by an ALG, (13) IEEE 802.1Q VLAN identification. (14) Wi-Fi SSID and, (15) LAN type (Ethernet, WiFi, etc.). WAN.QoS. 2 The RG SHOULD support classification of WAN directed LAN 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 with caution to avoid re-ordering packets), and (2) LAN-side physical port. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 22
WAN.QoS. 3 The RG MUST support the differentiated services field (DS field) in IP (v4 or v6) headers as defined in IETF RFC 2474. WAN.QoS. 4 The RG MUST by default recognize and provide appropriate treatment to packets marked with recommended Diffserv codepoints, whose values and behavior are defined in IETF RFCs 2474, 2475, 2597, 3246, and 3260. Specifically, the values shown in the DSCP column of the table below MUST be supported, except Cs0-7, which are optional. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. WAN.QoS. 5 The RG MUST be able to mark or remark the Diffserv codepoint or IEEE 802.1Q Ethernet priority of traffic identified based on any of the classifiers supported by the RG. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 23
WAN.QoS. 6 Requirement relocated to WAN.QoS.VLAN.1 QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. WAN.QoS. 7 Requirement relocated to WAN.QoS.VLAN.2 QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. WAN.QoS. 8 Requirement relocated to WAN.QoS.VLAN.3 QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. WAN.QoS. 9 The RG MUST support one best effort (BE) queue, one expedited forwarding (EF) queue and a minimum of four assured forwarding (AF) queues. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 24
WAN.QoS. 10 The RG MUST duplicate the set of queues for each access session (e.g. L2 PVC, VLAN). This can be done logically or physically. WAN.QoS. 11 The RG SHOULD support the appropriate mechanism to effectively implement Diffserv per-hop scheduling behaviors. The RG SHOULD be able to configure each queue defined in WAN.QoS.9 for strict priority or weighted round robin scheduling. SP queues are served with priority over all other queues. A strict priority scheduler is preferred for EF. WRR queues are served on the basis of configurable weights, provided with a mechanism to prevent starvation (WRR queue minimum bandwidth) WAN.QoS. 12 The RG MUST support aggregate shaping of upstream traffic across all access sessions (e.g. L2 PVC, VLAN). WAN.QoS. 13 The RG MUST support per-class shaping of upstream traffic. Classes are defined in WAN.QoS.4. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 25
WAN.QoS. 14 The RG MUST support the capability to fragment IP traffic on sessions that it originates, in order to limit the effect of large packets on traffic delay. WAN.QoS. 15 The packet size threshold before fragmenting AF and BE packets MUST be configurable. WAN.QoS. 16 The RG MUST handle all telephone service-related network traffic by a high priority queue to avoid congestion, delay, jitter, or packet loss. WAN.QoS. 17 The RG MAY handle all telephone service-related network traffic by a dedicated WAN interface to avoid congestion, delay, jitter, or packet loss. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 26
WAN.QoS. 18 The RG MUST provide counters in terms of dropped and emitted packets/bytes for each queue. Statistics SHOULD be collected from the time of last counter reset or on a configurable sample interval. WAN.QoS. 19 The RG MUST provide information about queue occupancy in terms of packets and peak percentage. Statistics SHOULD be collected from the time of last counter reset or on a configurable sample interval. WAN.QoS. 20 The RG MUST support classification of WAN-directed internally-generated traffic and placement into appropriate queues based on any one or more of the following pieces of information: (1) destination IP address(es) with subnet mask, (2) originating IP address(es) with subnet mask, (3) protocol (TCP, UDP, ICMP, ), (4) source TCP/UDP port and port range, (5) destination TCP/UDP port and port range, (6) Diffserv codepoint (IETF RFC 3260), (7) physical port, in case of voice packets. WAN.QoS. 21 The RG SHOULD support classification of WAN directed internally generated traffic and placement into appropriate queues based on any one or more of the following pieces of information: (1) packet length. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 27
WAN.QoS. 22 The RG MUST be able to learn classification keys (MAC address and IP address) through the following option of the DHCP client requests on the LAN that it serves: (1) DHCP Option 60 (Vendor Class ID), (2) DHCP Option 61 (Client Identifier), (3) DHCP Option 77 (User Class ID), and (4) DHCP Option 125 (Vendor Specific Information). WAN.QoS. 23 The RG SHOULD be able to learn classification keys (MAC address and IP address) for trusted DLNA devices as they are recognized on the LAN. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 28
3.8.1 VLAN based QoS WAN.QoS. VLAN. WAN.QoS. VLAN. WAN.QoS. VLAN. 1 The RG MUST support sending the following frame types: untagged frames, priority-tagged frames, and VLAN-tagged frames in the upstream direction. This satisfies TR-101 R-01. 2 The RG MUST support setting the priority tag and VLAN ID values. This satisfies TR-101 R-03. 3 The RG MUST support receiving untagged and VLAN-tagged Ethernet frames in the downstream direction, and MUST be able to strip the VLAN tagging from the ones received tagged. This satisfies TR-101 R-04. WAN インタフェースにおける VLAN タグの付与等は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. WAN における VLAN タグの付与等は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. WAN における VLAN タグの付与等は, 網側の機能, サービスとあわせて考える必要があり, また, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 29
3.8.2 Quality of Service for Tunneled Traffic WAN.QoS. TUNNEL. WAN.QoS. TUNNEL. WAN.QoS. TUNNEL. WAN.QoS. TUNNEL. This module only applies when the RG is an endpoint for a tunnel to the WAN. This module applies to IPv6 if it is used as either the tunneled or the tunneling protocol. 1 The RG MUST be able to mark or remark the Diffserv codepoint of traffic that will be placed over a tunnel, based on classification of that traffic (prior to placing it on the tunnel) using any of the classifiers supported by the RG. This only applies when the traffic is going from LAN to WAN. 2 The RG MUST be able to mark the Diffserv codepoint of the underlying tunnel or the IEEE 802.1Q Ethernet priority of Ethernet that is transporting the tunnel, based on classification of the tunneled traffic using any of the classifiers supported by the RG. This only applies when the traffic is going from LAN to WAN. 3 When the RG receives tunneled traffic from the WAN, it MUST be able to mark or remark the Diffserv codepoint of that traffic, based on classification of the tunneled traffic using any of the IP-layer or higher layer classifiers supported by the RG. 4 When the RG receives tunneled traffic from the WAN, it MUST be able to mark the IEEE 802.1Q Ethernet priority of the LAN Ethernet frame, based on classification of the tunneled traffic using any of the IP-layer or higher layer classifiers supported by the RG. QoS 機能は, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS 機能は, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS 機能は, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS 機能は, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 30
WAN.QoS. TUNNEL. WAN.QoS. TUNNEL. 5 When the RG receives tunneled traffic from the WAN, it MUST be able to mark or remark the Diffserv codepoint or mark the IEEE 802.1Q Ethernet priority of the LAN Ethernet frame, based on classification of the WAN Ethernet, using any of the Ethernet-layer classifiers supported by the RG. 6 When the RG receives tunneled traffic from the WAN, it SHOULD be able to mark or remark the Diffserv codepoint or mark the IEEE 802.1Q Ethernet priority of the LAN Ethernet frame, based on classification of the underlying tunnel, using any of the IP-layer classifiers supported by the RG. QoS 機能は, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. QoS 機能は, ガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 3.9 IPsec VPN peer to peer WAN.IPsecClient. 1 The RG MAY support peer to peer IPSec VPN, as defined in IETF RFCs 4301, 4303, 5996. WAN.IPsecClient. 2 If the RG supports IPSec VPN, it MUST support encapsulating security payload (ESP), as defined in IETF RFC 4303. IPsec 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. IPsec 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 31
WAN.IPsecClient. 3 If the RG supports IPSec VPN, it MUST support the IKEv2 key exchange protocol as defined in RFC 5996. WAN.IPsecClient. 4 If the RG supports IPSec VPN, it MUST support IPSec VPN in tunnel mode, which is defined in section 3.2 of RFC 4301. WAN.IPsecClient. 5 If the RG supports IPSec VPN, it MUST support dead peer detection (DPD), which is defined in RFC 5996. WAN.IPsecClient. 6 If the RG supports IPSec VPN, it must support configuring the IPSec VPN via web GUI or TR-069 extension. WAN.IPsecClient. 7 If the RG supports IPSec VPN, it MUST support that the source address in the IPSec is configured to be either an IP address or a TR-069 instance of WAN interface. IPsec 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. IPsec 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. IPsec 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. IPsec 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. IPsec 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 32
WAN.IPsecClient. 8 If the RG supports IPSec VPN, it MUST support that the destination address in the IPSec is configured to be either an IP address or a dynamic domain name. WAN.IPsecClient. 9 If the RG supports IPSec VPN, it MUST support querying the status of child security associations (SA) via TR-069 extension. IPsec 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. IPsec 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 3.10 L2tp VPN Remote Access WAN.L2tpClient. 1 The device MAY support L2TPv2 VPN, as defined in IETF RFC 2661 [73]. WAN.L2tpClient. 2 The device SHOULD support L2TPv3 VPN, as defined in IETF RFC 3931 [97]. WAN.L2tpClient. 3 If the device supports L2TP VPN, it SHOULD support L2TP Disconnect Cause Information, as defined in RFC 3145 [81]. ガイドラインには要件としての記述なし.L2TP 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. ガイドラインには要件としての記述なし.L2TP 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. ガイドラインには要件としての記述なし.L2TP 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 33
WAN.L2tpClient. 4 If the device supports L2TP VPN, it MUST support L2TP/IPSec VPN connection. WAN.L2tpClient. 5 If the device supports L2TP VPN, it MUST support LNS functions, as defined in IETF RFC 2661 [73] or IETF RFC 3931 [97]. WAN.L2tpClient. 6 If the device supports L2TP VPN, it MUST support configuring the L2TP VPN via Web GUI or TR-069 extension. ガイドラインには要件としての記述なし.L2TP 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. ガイドラインには要件としての記述なし.L2TP 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. ガイドラインには要件としての記述なし.L2TP 機能に関してはガイドラインの主旨である 最低限必要とされる機能を有するもの に該当しない機能と考えるため, 対象外とする. 3.11 Port Control Protocol WAN.PCP. 1 The RG MUST support Port Control Protocol (PCP) Client as specified in RFC 6887 [140]. ガイドラインには要件としての記述なし. ここでのユースケースは,IPv4 サービスにおいて網側の CGN のポートを PCP で操作するものである.IPv4 向けの機能については, ガイドラインの対象外とする. WAN.PCP. 2 The RG MUST support Port Control Protocol (PCP) Extension for Port Set Allocation as specified in Error! Reference source not found.. 注 : 上記リファレンスは,RFC7753 [147] である. ガイドラインには要件としての記述なし. ここでのユースケースは,IPv4 サービスにおいて網側の CGN のポートを PCP で操作するものである.IPv4 向けの機能については, ガイドラインの対象外とする. 34
WAN.PCP. 3 The RG MUST support configuring the PCP Client via web GUI or TR-069 extension. WAN.PCP. 4 The RG MUST be able to use the DHCP option to retrieve Server name(s) as defined in RFC 7291 [143]. WAN.PCP. 5 For the DS-Lite case, if PCP is enabled and no PCP server is configured, the RG MUST consider that the AFTR is the PCP server. WAN.PCP. 6 The PCP client of the RG MUST support invocations from applications on the RG, from the Web GUI or from TR-069 extensions. WAN.PCP. 7 The RG MUST embed an interworking function to ensure interworking between the UPnP IGD (Internet Gateway Device) used by CPE LAN devices in the LAN and PCP as defined in RFC 6970 [141]. WAN.PCP. 8 The RG MUST embed a PCP proxy function as defined in the IETF document Port Control Protocol (PCP) Proxy Function Error! Reference source not found.. WAN.PCP. 9 Static (i.e. configured) PCP mappings MUST be stored on the RG across reboot or power off situations. ガイドラインには要件としての記述なし. 本要件は,PCP 利用時における要件であり, ガイドラインの対象外とする. ガイドラインには要件としての記述なし. 本要件は,PCP 利用時における要件であり, ガイドラインの対象外とする. ガイドラインには要件としての記述なし. DS-Lite を含む CGN における PCP の利用は, 国内サービスにおいて例がない為, 対象外とする. ガイドラインには要件としての記述なし. 本要件は,PCP 利用時における要件であり, ガイドラインの対象外とする. ガイドラインには要件としての記述なし. 本要件は,PCP 利用時における要件であり, ガイドラインの対象外とする. ガイドラインには要件としての記述なし. 本要件は,PCP 利用時における要件であり, ガイドラインの対象外とする. ガイドラインには要件としての記述なし. 本要件は,PCP 利用時における要件であり, ガイドラインの対象外とする. 35
4 Local Area Networking (LAN) 4.1 General LAN Protocols LAN.GEN. 1 The RG MAY support SOCKS as defined in IETF RFC 1928 for non-alg access to the public address. LAN.GEN. 2 Both NetBios and zero config naming mechanisms MAY be used to populate the DNS tables. LAN.GEN. 3 The RG MAY act as a NETBIOS master browser for that name service. LAN.GEN. 4 The RG MUST support multiple subnets being used on the local LAN. ガイドラインでは IPv6 機能に特化した要件を記述している為, 検討の範囲外とする. ガイドラインでは IPv6 機能に特化した要件を記述している為, 検討の範囲外とする. ガイドラインでは IPv6 機能に特化した要件を記述している為, 検討の範囲外とする. 次版では,LAN 側の章に BBF の MUST 機能として記述されていることを記述した上で,MAY の要件度として記述する. 4.2 LAN IPv6 Addressing LAN.ADDRESSv6. 1 The RG MUST create a Link Local (LL) address for its LAN interface, and perform Duplicate Address Discovery (DAD), per RFC 4862. It MUST always use the same LL address, even after reboot or power failure. LAN.ADDRESSv6. 2 The RG SHOULD try alternate LL addresses, if DAD fails. The RG vendor can define the algorithm to be used in this case. 次版以降にて, リンクローカルアドレス付与については明記する. リンクローカルアドレスの変更については記述の是非に関して検討する. 次版以降で記述の是非を検討する. 36
LAN.ADDRESSv6. 3 The RG MUST have a ULA prefix (RFC 4193). It MUST always maintain the same prefix, even after reboot or power failure, unless this prefix is changed through configuration, in which case it MUST maintain the changed value. LAN.ADDRESSv6. 4 The RG MAY allow its ULA prefix to be changed through configuration. LAN.ADDRESSv6. 5 The RG MUST support the ability to enable or disable advertising a /64 from its ULA prefix through Router Advertisement. When enabled, this /64 will be included in RA messages, with L=1, A=1, and reasonable timer values. LAN.ADDRESSv6. 6 The RG MUST support RFC 4861 section 6.2, Router specification requirements. LAN.ADDRESSv6. 7 The RG MUST support configuration of the following elements of a Router Advertisement: M and O flags (RFC 4861), route information (RFC 4191), and default router preference (Prf) (RFC 4191). LAN.ADDRESSv6. 8 The RG SHOULD support configuration of the following elements of a router advertisement: MTU (RFC 4861). 次版では,LAN 側の章に BBF の MUST 機能として記述されていることを記述した上で, 要求度も含め, 記述内容を検討する. 次版では,LAN 側の章に BBF の MUST 機能として記述されていることを記述した上で, 要求度も含め, 記述内容を検討する. ガイドラインに同等の記述有り (3.3.4) 次版では,LAN 側の章に BBF の MUST 機能として記述されていることを記述した上で, 要求度も含め, 記述内容を検討する. ガイドランには記述なし. 次版では,LAN 側の章に記述を追加する. ガイドラインに関連する記述有り (6.1.1 と 7.2.2) 次版では,LAN 側の章に BBF の MUST 機能として記述されていることを記述した上で, RFC4191 の要求度および他のオプションの必要性も含め, 記述内容を検討する. ガイドラインに同一の記述有り (6.3.1) 37
LAN.ADDRESSv6. 9 The RG MUST advertise (in RA) a /64 prefix from all prefixes delegated via the WAN interface. This will have L=1, A=1, and lifetimes per the received (from the WAN) delegation. LAN.ADDRESSv6. 10 The RG SHOULD advertise DNS server using the RDNSS option in Router Advertisements (RFC 6106). ガイドラインに関連する記述有り (6.1.1) 次版では, 委譲された全ての Prefix から /64 を広告することの是非,L フラグを 1 とすることの是非を検討した上で, 同等の記述内容とする. 要件 7,8 との関係についても整理する. ガイドラインに同一の記述有り (6.2.1) 次版では,RFC8106 を参照した上で, オプション毎の要求度について再検討する. 4.3 DHCPv6 Server LAN.DHCPv6S. 1 The RG MUST support DHCPv6 server messages and behavior per RFC 3315. LAN.DHCPv6S. 2 The RG MUST support and be configurable to enable/disable address assignment using DHCPv6. LAN.DHCPv6S. 3 The RG MUST either have an algorithm or allow configuration (or both) as to which /64 prefix to use, from any received WAN prefixes or its own ULA prefix. ガイドラインでは,RFC3315 のメッセージ交換や振る舞いに関する記述はない. 要求度について検討した上で記述の追加を検討する.( サポートするオプションに応じて対応するメッセージや振る舞いが異なる為,SHOULD 要件とすることを検討 ) ガイドラインには, 必須機能ではないがアドレス配布が可能であることのみ記述あり (6.1.2). ガイドラインでは, アドレス配布に関連する事項として記述している (3.3.2,3.3.3, 3.3.4) 為, 本要件は包含されている. 38
LAN.DHCPv6S. 4 The RG SHOULD be configurable to support rules as to which host devices will be assigned addresses through DHCPv6. That is, it should be possible for a service provider to place its own host devices at the customer premises and have the RG only support DHCPv6 address assignment to those devices. Note that this does not require use of the RA "M" flag, as the service provider host devices can be configured to always use DHCPv6 for address assignment. The DUID may help to identify host devices. LAN.DHCPv6S. 5 The RG MUST be configurable to enable/disable prefix delegation via DHCPv6. LAN.DHCPv6S. 6 The RG MUST support delegation of any received WAN prefix and its own ULA prefix, that is shorter than /64, using mechanisms of RFC 3633. LAN.DHCPv6S. 7 The WAN / ULA prefixes that an RG is allowed to further delegate SHOULD be configurable. LAN.DHCPv6S. 8 The RG MUST support DHCPv6 Information_request messages. サービス仕様に依存するため, 対応予定なし. ガイドラインには, 設定の有効 無効に関する記述はない. 次版では,LAN.DHCPv6S.7 と併せて検討する. ガイドラインには, 必須機能ではないがプレフィックス配布が可能であることのみ記述あり (6.1.2). 次版では,LAN 側の章に BBF の MUST 機能として記述されていることを記述した上で,MAY の要件度として記述する. ガイドラインには, 必須機能ではないがプレフィックスの再配布が可能であることの記述あり ( 要件 37). 次版では, ユーザ環境での利便性向上の為, 記述を追記する. ガイドラインには, 同様の記述あり ( 要件 39). 39
LAN.DHCPv6S. 9 The RG MUST support the following DHCPv6 options: IA_NA (RFC 3315), IA_PD (RFC 3633), and DNS_SERVERS (RFC 3646). LAN.DHCPv6S. 10 The RG SHOULD support Reconfigure Accept (RFC 3315) and pass the additional set of DHCP options received from the DHCP client on its WAN interface to IPv6 hosts. LAN.DHCPv6S. 11 The options that the RG will provide via DHCPv6 MUST be configurable. LAN.DHCPv6S. 12 If address selection policy option is requested in a DHCPv6 request from hosts, the RG SHOULD advertise the generated address selection policy (see WAN.IPv6.21). ガイドラインには, 同様の記述があるが ( 要件 39, 要件 40), 必要度については検討する. ガイドラインには, 同様の記述があるが ( 要件 41), 必要度については検討する. 次版にて追記を ( 必要度についても含めて ) 検討する. 今後の動向次第で次版への反映を検討する. 4.4 Naming Services (IPv6) LAN.DNSv6. 1 The RG MUST act as a DNS server for IPv6-capable LAN devices by supporting IPv6 (AAAA) records in its DNS server (per RFC 3596) and allowing these records to be queried using either IPv4 or IPv6 transport (RFC 3901). LAN.DNSv6. 2 The RG MUST attach all known (for the host device) globally scoped IPv6 addresses to the DNS record for a particular host device (see LAN.DNS.6), as AAAA records for that device. ガイドラインには, トランスポートに関して関連する記述あり (5.1). AAAA RR は記述なし. 次版で追加を検討する. CPE ルータとしては必要ないと思われるため対応しない予定. 40