RE: New (-02) version of IPv6 CPE Router draft is available for review

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

Alain,

Please see in line between <hs> and </hs>. After Wes and I have
discussed your comments, we will update folks another time.  I won't be
able to talk to Wes before Thu next week.

-----Original Message-----
From: Alain Durand [mailto:alain_durand@cable.comcast.com] 
Sent: Friday, July 18, 2008 12:26 PM
To: Hemant Singh (shemant); v6ops@ops.ietf.org
Cc: Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

I'm reading version -02. I have to first admit I have not read the -01
nor the other comments that came with it, so some of what I'm going to
say may have been said previously.

Here are my main comments on the draft:


1) Two WAN interface models.

I think this is one too many. Especially is there is a variable that the
customer has to configure to select which mode the router is on. I look
at this as a potential source of calls to the tech support.

<hs>
Even currently, a standalone Linksys like router needs to pick if DHCP
or PPPOE is used for WAN connection. At least an old version that I have
at home.  The default with Linksys is DHCP.  We can suggest one default
like DHCP, but if a DSL user uses the CPE Router, they will have to
provision the WAN port like it is done with Linksys today.  Anyhow, the
unnumbered model is something that a lot of DSL folks have asked for. We
have got to keep it. We have tried to automate as much as we can like
spawning a loopback interface with unnumbered model.  If any further
auto-detection is possible, we will suggest it to make the SP life
simpler.
<hs>

Choosing between the 2 modes, I would favor the numbered one. The reason
is that we still have customers who attach a single PC to their cable
modem.
Those device would be just as happy with a single DHCPv6 assigned
address.


2) ULA

Supporting both ULA & GUA at the same time is also a source of
complexity and confusion. The key problem I see is with external
referrals in multi-party communications where some of the hosts are
inside, and some are outside. Mixing ULA & GUA can have complex
consequences, and again generates service call.

<hs>
Sorry, I don't see the point yet.  We have clearly shown in section
5.5.1 how both ULA and GUA will coexist including very simple source
address selection (SAS) rules pointers in the section.  Other folks
haven't balked at this yet - feel free to jump in.  Renumbering is an
extra step.  If you renumber ULA to expire and shoe-horn in the GUA,
service will be disrupted for a little while. ULA's are also
automatically generated, so the operator hasn't see any of it or any
support calls.
</hs>

Also, if I read the text correctly, if the WAN interface gets configured
first, no ULA are generated. Which leads to confusing situation
depending on whether the customer turns its modem on before or after its
CPE.

<hs>
You read the text correctly. This model is used when the SP controls the
CPE Router or the CPE Router is embedded in a cable or DSL modem etc.
Irrespective of when the modem turns on wrt to its CPE, when the WAN
interface of the CPE Router get connection to the SP, the WAN interface
init will take place. There is no need for ULA here. However, there is
no reason why we cannot have the WAN init first model also follow the
same idea as the LAN interface(s) init first. However, since our
document says, the CPE Router may be embedded in a modem, we needed to
keep this ULA out of the WAN init first model to be compliant with
CableLabs (CL) eRouter CM standard. That standard mandates WAN inits
first, then the LAN inits, then the LAN interface(s) are sub-delegated
the IA_PD. If we add ULA to the WAN init first model, we won't be
compliant with CL eRouter CM standard.

If you want both WAN init first and LAN init first models to always
assign UAL to the LAN interface(s), then CL has to adopt text from our
draft to their eRouter CM standard.
</hs>

I would rather like the text to recommend to only use ULA when nothing
else is available and immediately renumber to GUA when those are
acquired.


3) Cascading routers

The text says that the CPE can either be a DHCPv6 server or a DHCPv6
relay.
This needs to be clarified. From an operation perspective, I'd rather
like that the ISP only provision the CPE, not the cascaded routers. With
that in mind, I do not think that the DHCPv6 relay mode is realistic.

<hs>
The text for this section is saying that a CPE Router vendor decides if
the vendor implements a DHCPv6 server or a relay agent in their device
to be able to support cascading of the CPE Router.  SP is not going to
provision anything here. 
</hs>

4) RIPv6

Running RIPv6 between routers within the home might be OK, although it
all depends on how the distribution of the prefixes is done, maybe a
combination of default route upstream plus a route downstream toward the
delegated router will be enough.

However, running RIPv6 between the CPE and the ISP is a whole different
ball game. We are looking at other solutions (DHCPv6 message
interception) for prefix route injection as route announcement coming
from residential customers are hard to trust.

<hs>
Preaching to the choir here. I have already said in this draft's thread
that I prefer the DHCPv6 message snooping.  We just left the door open
if anyone wanted to do anything with RIPv6.  It's optional anyway for a
vendor to support and the SP to decide to use it or not.
</hs>

5) DHCPV6 on the LAN interfaces

First:
"   The CPE Router may include a stateful DHCPv6 server to assign
   addresses to home devices connected via the LAN interface(s) of the
   CPE Router.  However, we recommend that the CPE Router use SLAAC for
   home devices."

I think this recommendation is too strong and basically says "don't run
DHCPv6 stateful on the LAN". This is in conflict with the statement to
run
DHCPv6 stateful with PD for cascading routers. I'd like this text to
adopt a more neutral tone wrt DHCPv6 stateful configuration.

<hs>
We can consider toning down the language.  For the case when the CPE
Router is embedded in a cable modem, we do not expect a cascading of
router(s) behind the eRouter CM. That is why we have an "if" in the
cascading section. It's left to the vendor to decide if they want to
support a DHCPv6 server or not.
</hs>

Another example: I found it was not spelled out if the CPE MUST
implement stateless DHCPv6 or not. It is not spelled out either if the
CPE SHOULD implement a DNS server and advertize itself as such in DHCPv6
messages or if the CPE SHOULD re-advertize the ISP DNS server address...

<hs>
Section 5.5 says clearly that the DNS server IPv6 address obtained in
DHCPv6 response messages is doled out to clients in the home. This is
the text from section 5.5: "CPE Router can pass Domain Name Server(s)
IPv6 address(es) to home devices.".

In the long-term for our draft, we do need to add support for a DNS
server on the CPE Router to advertise itself in DHCPv6 message as you
say. In our next version we can add a new section placeholder for this
item and the write the text when we get the time. 
</hs>

There is also no mention about NTP or any other similar options.

<hs>
We know about NTP but we didn't get time to do our homework on it to
make sure if it's really needed.  We do need to collect all options that
are expected to be used in the home and add them when we compile the
list.  We will add a TBD to this section say such a list is pending. 
</hs>

As such, I think this whole section need more work.

<hs>
Some work is indeed needed.  We will make sure the section has toned
down language and also complete the TBD's mentioned above.
</hs>

6) Softwire & dual-stack lite support.

We are moving the dual-stack lite work to softwire. See
draft-durand-dual-stack-lite-00.txt

If this gets adopted, I'd like to see support for it required in this
draft.
The minimum requirement is to support IPv4 over IPv6 tunneling, with
manual configuration of the tunnel endpoint.

<hs>
I already replied to this one. We will track this draft.  After I finish
reading it, I will send my feedback.
</hs>

Hemant


  - Alain.