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

[Mohacsi Janos <mohacsi@niif.hu>]

Dear All,
	See my comments below:


As a general comment, in my opinion there is lot of overlap with existing 
standards:

e.g. 
section 8.8 QoS
section 7 IPv6 Data Forwarding

I think the operational model can be further simplified with ND proxy 
operations (RFC ????) with pure SLAAC.

In the ND proxy operation the IPv6 allocation and operation much more 
simplified:


   [PE device]
        |
/-------+---------\
| Broadband       |
| network         |
\--------+--------/
        |
       WAN
  [CPE device]
   |  |  |  |
   LAN     WLAN

In this model PE device is issuing RA, and CPE router is receiving on WAN 
interface and proxy towards LAN and WLAN interfaces.

Advantages:
- No need to operate DHCP relay/client/server on CPE router
- No need to operate DHCP server/relay on PE device
-

Disadvantages:
- Only one /64 could be allocated to end users - no multiple subnet possible
- The users LAN/WLAN interface "Virtually connected" to PE devices - PE 
device should be protected as it would be directly to PE interface e.g. 
MAC table
- CPE router might not be capable of filtering at packet level - ND proxy 
is very similar to bridging

Further comments about the text:
Section 2:
WLAN interface - Do we have to consider ad-hoc nodes - if one uses access 
points then it is not an ad-hoc wireless network

Section 3:

IPv6 multicast - In my opinion this term is ambiguous - It would be more 
appropriate to call it "IPv6 multicast behaviour".

Section 3.1:

The numbered element 6 has to be similar to previous 5. e.g:
enable transition if DHCPv6 fails

I would also add ND proxy enable.

Section 5.3.2:
I don't see the strong host model to be defined anywhere in the document


Section 5.6.1:

The after "IPV6CP negotiates...." until the end of the section is clearly 
leftover from the previous section. - Should be removed.

Section 5.7:

"If the CPE Router needs to
   support a stateful DHCPv6 server, then more details will be added to
   this section specifying the minimal functionality that the stateful
   DHCPv6 server needs to support.
" should be rephrased:
e.g.:
Stateful DHCPv6 server support in CPE router is out of scope in this document.


Section 7:

The data forwarding might be extended in case of ND proxy - since WAN and 
LAN/WLAN treated as single SLAAC domain.


"The routing table is
   filled by directly connected, static, and routing protocol routes.
"
should be something similar to:

"The routing table is
   filled by directly connected, static, DHCP delegated prefixes and 
routing protocol routes. "

"
 Proxy Neighbor Advertisements as described in Section 7.2.8 of
   [RFC4861] are not applicable to the CPE Router.
"

I disagree in case of ND Proxy is an accepted operation.

"As per [RFC2460], the CPE Router decrements
   the Hop Limit by 1 for any packet it forwards. 
"

This sentence has to be removed - standard behaviour - no need further 
clarification.

The section should refer to RFC 4980 - ICMPv6 filtering recommmendations - 
or should be refered in draft-ietf-v6ops-cpe-simple-security-03


Section 7.2:

I would add:
"CPE may implement full MLD multicast processing."


Section 8.1:

"Routers which may encounter a packet too large to be
   forwarded from source to destination may drop the packet and send an
   ICMPv6 Packet Too Big message to the source."

I would write the following

"
Routers which may encounter a packet too large to be forwarded from source 
to destination may drop the packet and should generate an ICMPv6 Packet 
Too Big message towards the source."


Section 8.3.1:

I think stateful or stateless packet filtering is implies some default 
behaviour:

- stateless packet filtering useful only if the default behaviour is allow 
all - selectively disable unwanted traffic
- if the default behaviour is deny all incoming packet then stateful 
filtering is a must - outgoing packet should open the firewall to the 
answers - or maintaining firewall will be a nightmare

 Section 8.5:
"... the 6to4 tunneling protocol [RFC3056] MAY be enabled automatically..."

In may opinion the following option should be presented to the end user:
- No Ipv6
- IPv6 (trying getting IPv6 on WAN interface then fall back to 6to4)
- NDproxy

I would put the 2nd paragraph into a subsection 8.5.1: "Generating IPv6 
address on WAN interfaces"

Section 8.7:

From the text "The CPE Router may also include DNS64..."
Either put into a different subsection or into a separate draft.

Section 8.8:

not necessary - does not give anything to the draft


Section 9:

Make it more precise:

"... WAN address assigned through DHCPv4 or manually configured ..."

Should be changed to:
"... WAN address assigned through DHCPv4, through PPP or manually configured..."


" A stateful firewall can enhance security by examining
   the state of each connection and only allow traffic which conforms to
   an expected packet flow."

I don't see why is this necessary here....


Best Regards,


Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Thu, 30 Oct 2008, Hemant Singh (shemant) wrote:

> http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-03.txt
>  
> Thanks.
>  
> Hemant & Wes