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

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

Alain,

Thanks very much for the careful review. We are working closely with
Mark Townsley at Cisco who told us about your draft and Ralph's SNAT.
Mark has advised us that our CPE Router draft needs to track all
softwire new work and any IPv4 address depletion solutions like yours.
In our next version we will mention such tracking in our draft including
mention of your draft. 

I will reply to rest of your comments sometime later today or over the
weekend.

Regards.

Hemant  

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

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.