RE: Posted a new copy of CPE Rtr draft

[<teemu.savolainen@nokia.com>]

Hi,

Thank you for the revision. I read it trough and I have following comments/questions/nits:

- 5.3.1: I guess SLAAC can also be used to aquire global IPv6 address for WAN interface as said in 5.?

- After reading the document I was not completely certain what level of DHCPv6 server functionality it is envisioned to be implemented by CPE. In 5.5. it is said that CPE router can pass DNS server information to clients -> does this mean CPE router should have at least Stateless DHCPv6 server in order to serve these queries? Or alternatively, is it ok for CPE router to act as DHCPv6 relay and relay information requests to SP? Which way is preferred (MUST/SHOULD/MAY..)? I understand stateful DHCPv6 server functionality is a question mark still.

- You mention DNS64 in the document (8.6), do you envision CPE router could implement NAT64 as wall? I think NAT64 could be left out or just mentioned shortly - without going into details (so that completing this work would not pend on NAT64 work's progress), but how do you see?

- Last paragraph of 7 says "A route SHOULD be added..." and later:"... null route MAY be automatic.". Should it say "A _null_ route SHOULD be added"?  I was unclear which route should be added to prevent routing loops, or just a route.

- 7.1. In 3GPP case the /64 prefix is not only for LAN interfaces, but also for the WAN interface. Thus I'd rather say:".. across multiple LAN interfaces, possibly including WAN interfase as well, and the CPE router..". Then "..any two LAN interfaces.." -> "..any two interfaces..". And still later "..if any two disparate LAN interfaces..." -> "..if any two disparate interfaces..".

- 7.1. Says "..has more than multiple prefixes available.." should it just be:"..has multiple prefixes available.."?

- 10. introduces WAN_IP_ACQUIRE_TIMEOUT constant. I would like to see comment here that particular L2 specifications may override this constant with some other value, as this is L2 dependent. In some L2 mechanisms one can see right at the L2 setup whether it supports native IPv4/IPv6 and it can be detected quickly if the address family is available natively or not. Also in some cases where L2 is setup on-demand, there is no time to wait for this long timeouts (user may be waiting) but its better proceed quickly with tunnel setups. 

Best regards,

	Teemu





 

>-----Original Message-----
>From: owner-v6ops@ops.ietf.org 
>[mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext Hemant 
>Singh (shemant)
>Sent: 06 March, 2009 14:27
>To: IPv6 Operations
>Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
>Subject: Posted a new copy of CPE Rtr draft
>
>http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-rout
>er-04.txt
>
>Sorry, we forgot that the -00 submission for I-D's was March 
>4th, 2009 and thus did not release a 
>draft-ietf-v6ops-ipv6-cpe-router-00.txt.  As folks may know 
>this draft is a work item of the v6ops WG as of the 
>Minneapolis IETF during November 2008.  Soon as IETF opens up 
>-00 submission again during the March IETF, we will submit the 
>-00 version of this draft.  We didn't want to wait any longer 
>to release this new version so that folks could get a few 
>weeks of review before IETF 74.
>
>Gross items taken care of in this version.
>
>1. Added DS-Lite section to the draft.
>2. Added text to cater to Brian Carpenter's comment that the 
>CPE Rtr should not hard code it's data forwarding table to 
>existing 200::/3 prefix.
>3. Added more explanatory text to strong host model portion of 
>the document to address question raised by Dave Thaler at the 
>mike during IETF 73.
>4. Augmented the Abstract to cater to comments from the mike 
>during IETF
>73 as to how other task forces may use this document.
>5. Added ND Proxy section catering to comments from Teemu.
>
>Hemant & Wes
>
>