[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
Since Antonio also raised a point about IPv6 addresses assigned to the
WAN interface (and the number of WAN interface(s)), we are combining a
reply to both you and Antonio.
Barbara, when you say,
"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
could you please elaborate. Does this separate IPv6 address get assigned
to the WAN side of the CPE Router? If yes, if the WAN interface is only
assigned a link-local address, then what network interface on the WAN
side does this IPv6 address get assigned to? One choice we have is to
assign the IPv6 address to the Loopback interface facing the WAN side.
Also, when reviewers ask for another network interface on the WAN side,
or another IPv6 address on the WAN side, could reviewers please
appreciate the fact that another WAN interface can mean two things for a
router. Either we have second physical WAN interface with a new
mac-address or we still have one WAN interface and the second WAN
interface is just a logical interface bound to the physical WAN
interface such that both the physical WAN interface and the logical
interface share a mac-address between them. Antonio and Barbara, which
one of these two interfaces are you talking about? Further, if one is
spawning logical interfaces on any router, once doesn't have to stop at
one extra interface. Go ahead and spawn more if one wants.
Further, Antonio, when you say,
"Additionally, for those vendors that wish to integrate the layer 2
(DSL/cable) modem as part of the CPE router (where the "WAN"
encapsulation is not ethernet), perhaps a separately named interface
definition might be appropriate to avoid confusion with "WAN"."
In such a case, the WAN interface is a logical interface that bridges
the CPE Router to the broadband modem. We clarified the WAN interface
definition as follows with new text
WAN interface - a single physical network interface on the standalone
CPE Router that is used to connect the router to the access network of
the Service Provider. When the CPE Router is embedded in a device that
connects to the WAN, this interface is a logical network interface that
bridges the device to the CPE Router. Some devices which can have an
embedded CPE router are: a cable or DSL modem, or a cellular telephone,
When we publish our next revision of the draft, we will include new text
for the WAN interface definition.
Hemant & Wes.
From: firstname.lastname@example.org [mailto:email@example.com] On
Behalf Of Stark, Barbara
Sent: Tuesday, July 08, 2008 2:20 PM
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.
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
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 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