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

["Hemant Singh (shemant)" <shemant@cisco.com>]

Barbara,

Thanks for your input and review. Please see in line below between <hs>
and </hs>.

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Stark, Barbara
Sent: Tuesday, July 08, 2008 2:20 PM
To: v6ops@ops.ietf.org
Subject: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

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.

<hs>I don't see a problem with this PPP scenario for IPv6, especially
after we wrote our new section of 5.5.1 in the -01 draft. If we don't
find any gotchas with supporting dual-stack over the same PPP session,
we will mention the fact in the draft as a "nice thing to have" or maybe
even a must. If the DSL network supports IPv6 between the home and the
Service Provider(SP) network, then the PPP model you describe above
should work for IPv6. However, if DSL takes some time to be IPv6 ready
between home and the SP, then one model we are thinking of is for the
CPE Router to initiate a softwire to carry IPv6 over IPv4 in L2TPv2
tunnels. Thanks to Mark Townsley for clueing us in on softwires
(http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2-08).
We plan to add a softwire section to -02 draft.
</hs>

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.

<hs>
You are correct. We kept the "numbered" vs. "unnumbered" model as a
configuration option because the unnumbered model is spawning a Loopback
interface. We wanted to make sure that if unnumbered model is configured
the SP or user knows a Loopback interface is being spawned. Other than
that I agree with you that the CPE Router knows if the access network is
giving it a global IPv6 address or not.
</hs>

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

<hs>No problem. So if the SP is not doling out an IPv6 address to the
WAN interface, is the SP doling out an IA_PD option to the CPE Router?
If yes, then when global IPv6 addresses from the IA_PD get assigned to
the LAN interface(s) of the CPE Router, one can always use one more
global address to configure on the WAN interface. However, if an SP does
not like assigning of a global IPv6 address to the WAN interface, that's
is fine with he CPE Router for PPP. Further, if the SP does not dole out
an IA_PD but assigns one IPv6 global address to the LAN interface(s),
that's a model the CPE Router also does not have a problem with
supporting for PPP. However, for non-PPP cases, the CPE Router will need
a global IPv6 address on the WAN interface and the WAN prefix must be
different from the LAN prefixes because the WAN and LAN interface(s) are
two separate routing domains of the CPE Router. We have received
feedback from you (AT&T), NTT (Japan), and some folks in Europe. We will
work on the text of our document to be general enough that we satisfy
all folks.
</hs>

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.

<hs>
Loopback interfaces are also frequently used when discussing routing
protocols (not just SNMP), and have become commonplace in discussion of
router behavior.  Configuring a loopback interface on a router should
not be an onorous requirement. 
</hs>

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

<hs>
The reason is because DHCPv6 needs to ride on the link-local address of
the network interface initiating the DHCPv6. We are assigning a global
IPv6 address to the Loopback interface using DHCPv6. The WAN interface
has to remain with just a link-local address. It's funny as heck to have
the WAN interface initiate DHCPv6 using the link-local address of the
WAN interface but after DHCPv6 is completed, the IA_NA from DHCPv6 gets
assigned to the loopback interface. The draft clearly says, the Loopback
interface on the CPE Router also acquires a link-local address. 
</hs>

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.

<hs>
It's a boot mode, not a mode of operation. We had to call it something
because our document is general enough that this CPE Router can be
embedded in a cable or DSL modem or any other device. Then the "LAN
initialization before WAN initialization" is not applicable. Cable
standards have already defined a "WAN initialization before LAN
initialization" embedded router specification in a cable modem. We have
to take care of that deployment too.
</hs>

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. 

<hs>
Again, the cable standards have specified a eRouter cable modem
specification that may not support cascading of routers. We will keep
the if. 
</hs>

Thanks.

Hemant & Wes.

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