Subject: RFC 4779 errata

From: Alfred Hönes <[email-masked]>
Date: Mon, 14 May 2007 21:53:27 +0200 (MESZ)

Hello,
after studying the recently published RFC 4779 (IPv6 BB Deployment
Scenarios) authored by you, I would like to submit a few comments,
pointing out many of the issues I found with the RFC text, and
supplying material for an appropriate RFC Errata Note.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(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.

Please supply replacement text matching the scenario as explained
in Section 8.1.2.

(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.

Please comment.

At least item (1) should urgently be addressed by an Errata Note.
IMHO, item (16) should also be resolved on this way.
I leave it to your decision what else should be included there.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+