Comments on draft-wbeebee-ipv6-cpe-router-01.txt

["Stark, Barbara" <bs7652@att.com>]

Hi Hemant and Wes,
Thanks for the update of this draft. I think it could potentially be
quite useful to the industry. But, just so you understand my focus, I'm
more interested in how such a work could drive the behavior of retail
"CPE routers", than I am in how it can drive specifications for routers
that service providers (SPs) source and provide to end users. I pretty
much know what I want in a CPE router -- my biggest unknown is how to
interact with retail routers on the LAN-side of my SP CPE router,
because I'm not sure how they'll behave. I also want to try and make
sure that these retail routers can operate, with minimal or no
configuration, without a SP router between them and the SP access
network (where applicable).

With that in mind, here are a few comments.

1. Based on what I'm hearing from the access network side of my company,
I'm expecting for retail CPE routers (in the US) to continue to need to
support two different IP stacks to the WAN: IPv6/PPP/PPPoE/Ethernet and
IPv6/Ethernet. Today (in IPv4 retail routers), this is a configurable
option that defaults to IP/Ethernet. I would expect that to be the
default with IPv6, as well. If a device is configured to do IPv4 over
PPP, I would expect it to do IPv6 over PPP (preferably over the same PPP
session) when running in dual stack.

The "PPPoE" stack will use IPv6CP for WAN IP address configuration, and
DHCPv6 for other config options.

2. The document seems to suggest that "numbered" vs. "unnumbered" model
is a configuration option (section 5.3.2). I think the CPE router needs
to be able to automatically detect what the access network is giving it.
It should be pretty apparent if the access network is giving it a global
IP address or not.

3. I disagree with the behavior suggested for "unnumbered" model. I
don't think a CPE router should automatically open up a maintenance
loopback interface just because it doesn't get a global IP address. If
this is a retail CPE router, I think it really shouldn't be setting up a
maintenance loopback interface by default. Our access network is
definitely considering not giving out global addresses to the WAN
interface, but we have no requirements for any "loopback" maintenance
interfaces at all. We have considered the possibility of a separate IP
address for our TR-069 management of the CPE routers that we supply, but
would want this to be a configurable option. As a default, we believe
that the global address that the CPE router selects for its LAN
interface is sufficient for all WAN-side Internet communication,
including VoIP, TR-069, ping, traceroute, etc. [I often do ping tests
from the router when my WAN is having problems].

The option for separate IP address for maintenance would need to be
configurable whether or not the CPE router gets a global address on its
WAN interface. It's not just for the "unnumbered" model.

By the way, when I hear about IPv6 and loopback interface in the same
sentence, I usually think about ::1 (or 127.0.0.1 in IPv4). I associate
loopback network interfaces with SNMP. I've never heard that phrase used
with respect to a TR-069 interface. We do not support SNMP for
management of consumer and small business CPE routers. If you want to
have a configurable option for a maintenance interface that uses a
different IP address, I would prefer using more generic language,
instead of SNMP language. That would also prevent confusion between ::1
and loopback "network" interfaces, for people like me. I also find other
references to SNMP MIBs to be, umm, not of interest to me (e.g., section
4). But since there's no requirement to support SNMP, I don't really
care -- I just find it odd that there seems to be an underlying implicit
assumption that SNMP is used for management.

When a CPE router does not get a global IP address on its WAN, I don't
understand why it would be recommended for the CPE router to use its
maintenance interface to launch subsequent DHCPv6 messages. I would
expect the link-local address on the regular WAN interface to be
sufficient for this (especially since I want to be able to have no
global address on the WAN, and no special maintenance interface). Even
if a router is configured to have a special maintenance (TR-069)
interface, I would only want to see that set up after getting the global
prefix, and would want the general WAN interface used for all DHCPv6 and
SLAAC.

4. I find it interesting that "LAN initialization before WAN
initialization" is considered a "mode" of operation in 5.5.1. It's
simply that LAN initialization must have no dependency on the existence
of any WAN IP interface. Link-local and ULA happen no matter what. Then
if the WAN gets a global prefix, the router does what it needs to do to
get global addresses to the host devices.

5. In section 6 it says "If the CPE router supports cascading of routers
through automatic prefix sub-delegation, the CPE router must support a
DHCPv6 server or DHCPv6 relay agent." I think that all CPE routers need
to be able to operate in a cascaded network, because that's what users
are doing today and will continue to do. I would like to see all CPE
routers be able to operate in a cascaded network, be able to hand out
prefixes (if there are prefixes to hand out), and be able to operate as
a DHCPv6 relay agent if the upstream router has no prefixes to hand out
(because the upstream router only has a /64 itself). I don't think this
should be an "if" statement. 

Barbara
Barbara Stark    AT&T

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623