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

[<[e-mail]>]

Hi,
 
I like this document a lot, and really look forward to get this forward.
 
Few comments:
- 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
<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.
 
Best regards,
 
    Teemu
 


________________________________

	From: [e-mail] [mailto:[e-mail]]
On Behalf Of ext Hemant Singh (shemant)
	Sent: 30 October, 2008 19:29
	To: IPv6 Operations
	Subject: new version of the CPE Rtr draft is ready for review
	
	
	
http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-03.txt
	 
	Thanks.
	 
	Hemant & Wes