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

From: <[email-masked]>
Date: Wed, 12 Nov 2008 17:24:44 +0200

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: [email-masked] [mailto:[email-masked]]
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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 12 Nov 2008 11:17:10 -0500

Teemu,
 
Thanks very much for the review.  I and Wes discussed your comments and
here are our responses back in line between <hs> </hs>.

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 12, 2008 10:25 AM
To: Hemant Singh (shemant); [email-masked]
Subject: RE: new version of the CPE Rtr draft is ready for review

Hi,

Few comments:
 
<hs>
Good catch.  This section missed the zero-LAN case.  We can modify text
in this section to say something like "the CPE Router software knows its
running in a zero-LAN hardware device and in such a case of zero-LAN
hardware, if an IA_PD is not asked for by the CPE Router, nor does a
DHCPv6 response received by the CPE Router includes the IA_PD Option,
then there is no error deemed. 
</hs>

<hs>
Partial reason.  But we have not found a need for the CPE Router to
support ND Proxy just yet.  If any deployment still thinks that the CPE
Router MUST support an ND Proxy, please contact us and we will evaluate
the deployment and the need.
</hs> 

<hs>
We can modify this section's 1st para, 2nd line to change from 
 
[After the IPv6 address configuration for WAN interface is completed,
the CPE Router configures IPv6 address for LAN interface(s).]
 
to 
 
[After the IPv6 address configuration for WAN interface is completed,
the CPE Router may configure IPv6 address(es) for any LAN interface(s).]

Further, in the 2nd paragraph, a portion of the 1st sentence of the same
section changes from 
 
[Once IPv6 address configuration of the LAN interface(s) is complete, ]
 
to
 
[When and if  IPv6 address configuration of the LAN interface(s)
completes, ]
 
</hs>

<hs>
We need to think about this one.
<.hs>

<hs>
We personally have not accepted this RFC and it's also an experimental
one.  See more below against your DHCPV6 server comments.  Again, unless
a deal-breaking need is found where this RFC MUST be supported by the
CPE Router, we will skip this RFC in our document. 
</hs>

<hs>
Yes, at least a stateless DHCPv6 server is needed to pass Service
Provider options to the LAN device(s).  We think section 5.7 can be
renamed to "DHCPv6 Server" and then we can discuss both stateless and
stateful DHCPv6 servers in the section.
<hs> 

<hs>
Wes is on top of this section.  He will read your draft pointer above
and we will reply a little later on this one.
</hs>

<hs>
We do say in this section that several proposals are out there.
However, we should probably mention more than just DS-Lite.
</hs>

<hs>
If you are coming to IETF 73, let's get together and discuss this.  We
are presenting this draft in v6ops. 
</hs> 
 
Thanks.
 
Kind Regards.
 
Hemant & Wes.

Best regards,
 
    Teemu

	
	 
	Thanks.
	 
	Hemant & Wes