RE: new version of the CPE Rtr draft is ready for review

I like this document a lot, and really look forward to get this forward.

- 5.4. says that CPE router has failed DHCPv6 address acquisition if IA_PD option is not included in ADVERTISE/REPLY in stateful DHCPv6 case. Now considering case where a CPE router is embedded into mobile host that is attaching to different networks, some of which may mandate DHCPv6 use and some of which don't: if the mobile host always asks for IA_PD, but sometimes doesn't get it (due differencies in network policies), isn't the address acquisition process still successful for the host itself, but just not for CPE router function of the host? I mean could this section be clarified to state that in such case the address acquisition is only partially succesful? And perhaps that in such case the CPE router can configure the IPv6 address for itself and at the same time initiate other-but-less-preferred means for providing Internet connectivity to LAN side, such as fall-back to IPv4-only CPE router functionality, bridging, (NATting between ULA and global IPv6 address...), or doing ND proxying?

- Is there a reason why ND Proxy (RFC4389) is not mentioned? Because it is of experimental category?

- 5.5.2. one scenario for WAN initialization before LAN is that LAN side is not initialized at all without external host first connecting to CPE router by some technology. Again cellular use case: a mobile has always-on WAN connectivity for usual uses (VoIP/email/MMS/browsing) and a host (say PC) initiates WLAN/Bluetooth/USB/whatever connection to a mobile only much later than initial WAN connection was created. In such case the trigger for requesting IA_PD would be initialization of LAN side physical interface (e.g. triggering of Bluetooth PAN profile), as asking for IA_PD at the moment of WAN initialization would unnecessarily reserve prefixes by hosts never utilizing those.

- 5.6. IPv6 over Ethernet and PPP are not the only existing technologies and possibly more are coming, Maybe this chapter should be generalized? Examples of other technologies are:

* RFC5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks

* RFC3574 Transition Scenarios for 3GPP Networks (which is somewhat incomplete now as 3GPP has made some rather significant changes to bearer concepts since 2003)

- Could CPE router utilize RFC5006 on LAN and/or WAN interfaces?

- Is stateless DHCPv6 server or DHCPv6 relay SHOULD or MUST for CPE router to provide hosts in LAN with access to other configuration parameters available from service provider's DHCPv6 server? I.e. not just for reasons described in chapter 6.

- 8.7. could/would/should this perhaps relate/mention to this draft: http://tools.ietf.org/html/draft-bellis-dnsext-dnsproxy-00 ?

- As several transition mechanisms are being worked on, the 8.6 should perhaps mention that DS-Lite is not the only mechanisms that may cause this chapter to be updated.

If you wish, I can contribute text from cellular perspectives.