RFC Errata
RFC 4779, "ISP IPv6 Deployment Scenarios in Broadband Access Networks", January 2007
Source of RFC: v6ops (ops)See Also: RFC 4779 w/ inline errata
Errata ID: 958
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
(1) Section 5.2 -- bad acronym expansion Within Section 5.2, bullet B. on page 11 says: B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In | IPv4, these devices rely on Internet Group Multicast Protocol (IGMP) join messages to track membership of hosts that are part of a particular IP multicast group. [...] It should say: B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In | IPv4, these devices rely on Internet Group Management Protocol (IGMP) join messages to track membership of hosts that are part of a particular IP multicast group. [...] (2) Section 5.2.1.3 -- typo / missing article The first paragraph of Section 5.2.1.3, on top of page 14 says: [...]. In order to do that, the CM and CMTS must forward Neighbor Discovery (ND) packets | between ER and the hosts attached to the CM. ^ It should say: [...]. In order to do that, the CM and CMTS must forward Neighbor Discovery (ND) packets | between the ER and the hosts attached to the CM. ^^^^^ (3) Section 5.2.1.4 -- typo / missing article The first paragraph of Section 5.2.1.4, on mid-page 14 says: [...]. If there is a GWR present, it will also use | static default route to the ER. It should say: [...]. If there is a GWR present, it will also use | a static default route to the ER. ^^ (4) Section 5.2.2 -- typo / missing article On page 15, the text for scenario #2 says: [...] This scenario is also easy to deploy since the cable operator just | needs to add GWR at the customer site. ^ It should say: [...] This scenario is also easy to deploy since the cable operator just | needs to add a GWR at the customer site. ^^^ (5) Section 5.2.2.2.3 -- wrong article On page 18, the second paragraph of Section 5.2.2.2.3 says: The GWR will use its IPv4 address to source the tunnel to the ER. | The tunnel endpoint will be the IPv4 address of the ER. [...] ^^^ It should say: The GWR will use its IPv4 address to source the tunnel to the ER. | The tunnel endpoint will be an IPv4 address of the ER. [...] ^^ Rationale: Since IP addresses usually identify *interfaces* and routers presumably have more than one IP interface, it is improper to talk about *the* IP address of a router. (6) Section 5.2.2.3 -- improper text in figure ? On page 19, Figure 5.2.2.3 is: +-----------+ +-------------+ +-----+ +-------+ | Cable | | CMTS / Edge | |Host |--| CM |----| (HFC) |---| |=>ISP +-----+ +-------+ | Network | | Router | Network +-----------+ +-------------+ | |-------||---------------------------||---------------| | IPv4/v6 IPv4/v6 IPv4/v6 Because all parts of the network shown are dual-stack, it makes no sense to show two boundaries between similar regions. Hence, the figure should better be: +-----------+ +-------------+ +-----+ +-------+ | Cable | | CMTS / Edge | |Host |--| CM |----| (HFC) |---| |=>ISP +-----+ +-------+ | Network | | Router | Network +-----------+ +-------------+ | |-----------------------------------------------------| | IPv4/v6 (7) Section 5.2.2.5.2 The first paragraph of Section 5.2.2.5.2, at the bottom of page 22, says: Since the CM/GWR is dual stack, it can receive an IPv4 or IPv6 address using DHCP for management purposes. As the GWR functionality | is embedded in the CM, it will need an IPv6 address for forwarding data traffic. IPv6 address assignment for the CM/GWR and host can be done via DHCPv6 or DHCP-PD. Apparently, to be able to *forward* IPv6 traffic, the GWR needs at least two IPv6 addresses. Therefore, the RFC should perhaps better say: Since the CM/GWR is dual stack, it can receive an IPv4 or IPv6 address using DHCP for management purposes. As the GWR functionality | is embedded in the CM, it will need IPv6 addresses for forwarding data traffic. IPv6 address assignment for the CM/GWR and host can be done via DHCPv6 or DHCP-PD. (8) Section 5.2.3 -- missing articles The first paragraph of Section 5.2.3 says, at the top of page 24: [...]. MLDv2 is almost identical to IGMPv3 | and also supports ASM (Any-Source Multicast) and SSM (Source-Specific Multicast) service models. It should say: [...]. MLDv2 is almost identical to IGMPv3 | and also supports the ASM (Any-Source Multicast) and the SSM (Source- Specific Multicast) service models. (9) Section 6.2.1.2 -- typo On page 30, the bullet B. within Section 6.2.1.2 says: v The later option allows it to contact a remote DHCPv6 server, if needed. [...] It should say: vv | The latter option allows it to contact a remote DHCPv6 server, if needed. [...] (10) Section 6.2.2 -- typo In the last paragraph on page 31, Section 6.2.2 says: v | This solution scales better then the Point-to-Point, but since there is only one PPP session per ATM PVC, the subscriber can choose a single ISP service at a time. It should say: v | This solution scales better than the Point-to-Point, but since there is only one PPP session per ATM PVC, the subscriber can choose a single ISP service at a time. (11) Section 6.3 -- clarity The last paragraph of Section 6.3 (second paragraph on page 39) says: This facilitates the deployment of multicast services. The discussion of this section applies to all the multicast sections in | the document. ^ It should say: This facilitates the deployment of multicast services. The discussion of this section applies to all the multicast sections in | this document. ^^ (12) Section 6.3.1 -- grammar / typos The first paragraph of Section 6.3.1, on page 39, says: v | Any Source Multicast (ASM) is useful for Service Providers that intend to support the forwarding of multicast traffic of their customers. It is based on the Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol and it is more complex to manage because of the use of Rendezvous Points (RPs). With IPv6, static RP | and Bootstrap Router [BSR] can be used for RP-to-group mapping similar to IPv4. [...] It should say: v | Any-Source Multicast (ASM) is useful for Service Providers that intend to support the forwarding of multicast traffic of their customers. It is based on the Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol and it is more complex to manage because of the use of Rendezvous Points (RPs). With IPv6, static RP | and Bootstrap Routers [BSR] can be used for RP-to-group mapping similar to IPv4. [...] Alternatively, the last sentence above could be reworded to say: because of the use of Rendezvous Points (RPs). With IPv6, static RP | and the Bootstrap Router protocol [BSR] can be used for RP-to-group mapping similar to IPv4. [...] (13) Section 8.1 -- multiple flaws Near the end of the first paragraph on page 56, Section 8.1 says: [...]. The AP forwards all the packets coming to/from | host to the Edge Router. The underlying connection between the AP | and Edge Router could be based on any access layer technology such as HFC/Cable, FTTH, xDSL, etc. It should say: [...]. The AP forwards all the packets coming to/from | hosts to the Edge Router. The underlying connection between the AP | and the Edge Router could be based on any access layer technology such as HFC/Cable, FTTH, xDSL, etc. In the second paragraph on page 56, Section 8.1 says: | [...]. In most of the cases, SP assigns a limited number of public IP addresses to its customers. [...] It should say: vvvv | [...]. In most of the cases, the SP assigns a limited number of public IP addresses to its customers. [...] At the end of the section (near the bottom of page 56), the RFC says: | A. Layer 2 NAP with Layer 3 termination at NSP Edge Router | B. Layer 3 aware NAP with Layer 3 termination at Access Router It should say either: | A. Layer 2 NAP with Layer 3 termination at an NSP Edge Router | B. Layer 3 aware NAP with Layer 3 termination at an Access Router or: | A. Layer 2 NAP with Layer 3 termination at NSP Edge Routers | B. Layer 3 aware NAP with Layer 3 termination at Access Routers (14) Section 8.1.1 -- grammar The first paragraph of Section 8.1.1, at the bottom of page 56, says: When a Layer 2 switch is present between AP and Edge Router, the AP | and Layer 2 switch continues to work as a bridge, forwarding IPv4 and IPv6 packets from WLAN Host/Router to Edge Router and vice versa. It should say: When a Layer 2 switch is present between AP and Edge Router, the AP | and Layer 2 switch continue to work as a bridge, forwarding IPv4 and IPv6 packets from WLAN Host/Router to Edge Router and vice versa. (15) Section 8.1.2 On page 59, the second paragraph of Section 8.1.2 says: When the WLAN Host initiates the connection, the AAA authentication | and association process with WLAN AP will be similar, as explained in Section 8.1.1. ^ ^ It should say: When the WLAN Host initiates the connection, the AAA authentication | and association process with the WLAN AP will be similar as explained in Section 8.1.1. ^^^^^ ^ (16) Section 8.1.2.2 -- clarification needed On page 60, bullet C. of Section 8.1.2.2 says: vv vv | C. It can use its link-local address to communicate with the ER. It can also dynamically acquire through stateless auto-configuration the address for the link between itself and the ER. [...] The double "it" is unclear and inprecise. (The immediately preceding sentences refer to three different entities, the DHCP server, the Access Router, and the Edge Router -- which one is "it" ?) Presumably, it was intended to refer to the Access Router, and not to the AAA Server, but -- according to Figure 8.1.2 -- only the latter potentially has a common link with the ER and hence can use link-local addresses, whereas the AR is connected to the ER via the Access Provider Network that might comprise multiple IP hops on the route from AR to ER. It should say (text provided by Adeel): The Access Router can dynamically acquire through stateless address auto-configuration the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a +prefix shorter than /64 that in turn is divided in /64s and assigned to its interfaces connecting the hosts on the customer site. (17) Section 8.1.2.3 -- missing article The last paragraph of Section 8.1.2.3, on mid-page 61, says: If the Access Router is owned by the SP, then the Access Router will | also run IPv6 IGP, and will be part of the SP IPv6 routing domain (OSPFv3 or IS-IS). [...] It should say: If the Access Router is owned by the SP, then the Access Router will | also run an IPv6 IGP, and will be part of the SP IPv6 routing domain (OSPFv3 or IS-IS). [...] (18) Section 8.1.3 -- missing articles Section 8.1.3, near the bottom of page 61, says: PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA) models, as discussed in Sections 6.2.2 and 6.2.3, respectively, can also be deployed in IPv6 WLAN environment. It should say: | The PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA) models, as discussed in Sections 6.2.2 and 6.2.3, respectively, | can also be deployed in an IPv6 WLAN environment. (19) Section 8.1.3.1 -- missing articles At the bottom of page 61, the first paragraph Section 8.1.3.1 says: v | While deploying the PTA model in IPv6 WLAN environment, the Access Router is Layer 3 aware and it has to be upgraded to support IPv6. It should say: vvvv | While deploying the PTA model in an IPv6 WLAN environment, the Access Router is Layer 3 aware and it has to be upgraded to support IPv6. The bottom line on page 61, v | Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment. should say: vvvv | Figure 8.1.3.1 describes the PTA Model in an IPv6 WLAN environment. Alternatively, "the" could be inserted in place of "an", in both cases. (20) Section 8.1.3.2 On page 62, the literally same changes as presented in item (19) should be applied as well. (21) Section 8.2 -- multiple grammar issues The first paragraph on top of page 64 says: vvvvv | It is important to note that in the shared wireless environments, multicast can have a significant bandwidth impact. [...] It should say: v | It is important to note that in shared wireless environments, multicast can have a significant bandwidth impact. [...] The second paragraph on page 64 says: vvvvvv | The IPv6 WLAN Hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. [...] It should say: v | The IPv6 WLAN Hosts can join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. [...] (Rationale: "also" lacks similar context in preceding that might be resumed here.) The third paragraph on page 64 says: vvvvv | [...]. The Edge Router has also needs to be enabled | for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/ Access Router (if present), and send joins towards the SP core. It should say: v | [...]. The Edge Router also needs to be enabled for | PIM-SSM in order to receive joins from IPv6 WLAN Hosts or the WLAN/ Access Router (if present), and send joins towards the SP core. The sixth paragraph on page 64 says: vvvvv | This problem is inherited by WLAN that can impact both IPv4 and IPv6 multicast packets; it is not specific to IPv6 multicast. It should say: vvvvv | This problem is inherited by WLANs and can impact both IPv4 and IPv6 multicast packets; it is not specific to IPv6 multicast. Finally, the last paragraph on page 64 says: v | While deploying WLAN (IPv4 or IPv6), one should adjust their broadcast/multicast settings if they are in danger of dropping application dependent frames. [...] It should say: vv | While deploying WLANs (IPv4 or IPv6), one should adjust their broadcast/multicast settings if they are in danger of dropping application dependent frames. [...] (22) Section 8.3 -- improper article The third paragraph of Section 8.3, on mid-page 65 says: [...] The same IPv4 QoS concepts and methodologies should be | applied for the IPv6 as well. ^^^^^ It should say: [...] The same IPv4 QoS concepts and methodologies should be | applied for IPv6 as well. ^ (23) Section 8.4 -- word twister The first paragraph of Section 8.4, near the bottom of page 65, says: vvvvvvvvvvvvvvvvv | There are limited changes that have to be done for WLAN the Host/ Router in order to enhance security. [...] It should say: vvvvvvvvvvvvvvvvv | There are limited changes that have to be done for the WLAN Host/ Router in order to enhance security. [...] (24) Section 10 The last sub-item of item (21) above recurs in Section 10. At the end of bullet E. , near the bottom of page 72, the RFC says: vvvvv [...]. This problem is | inherited by WLAN that can impact both IPv4 and IPv6 multicast packets; it is not specific to IPv6 multicast. It should say: vvvvv [...]. This problem is | inherited by WLANs and can impact both IPv4 and IPv6 multicast packets; it is not specific to IPv6 multicast.
It should say:
[see above]
Notes:
Authors verified changes. Did not split into multiple items.
from pending.