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

[Alain Durand <alain_durand@cable.comcast.com>]

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.

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.

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.

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.


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.


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.

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

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

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


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.


  - Alain.