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

["Hemant Singh (shemant)" <shemant@cisco.com>]

Janos,

Thanks very much for the detailed review.  Sorry for the delayed reply.
Please see in line below between <hs> and </hs>.  I have removed some
text from your original email to make my email reply a little shorter. 

-----Original Message-----
From: Mohacsi Janos [mailto:mohacsi@niif.hu] 
Sent: Friday, December 05, 2008 12:49 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: new version of the CPE Rtr draft is ready for review

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

<hs>Listen to audio sessions of IETF 72 where I said, the device is not
merely a router.  The device may have a bridge inside it, have switched
and routed ports, so the data forwarding for all such devices together
has to be clearly defined.  There may be overlap, but we authors are in
the business of getting such a device build ASAP and the document serves
to facilitate vendors.  See the new Abstract that mentions such facts.
As for the Qos section, it's for completeness for what features are
suggested to be in the device.  
</hs>

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

<hs>
See Wes' or my reply about ND Proxy to the mailer.
</hs>


IPv6 multicast - In my opinion this term is ambiguous - It would be more

appropriate to call it "IPv6 multicast behaviour".

<hs>
Thanks, we have accepted your comment.
</hs>

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.

<hs>
Perfect editorial comment.  Will do.
</hs>

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

<hs>
RFC 1122 is referenced in the document.  This RFC discusses both strong
and weak host models.  If you are not familiar with such models and want
a quick overview rather than sifting thru RFC 1122, please see
http://en.wikipedia.org/wiki/Host_model
</hs>

Section 5.6.1:

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

<hs>
It is intentional. Some common behavior is repeated in different
protocol sections.  Actually, one reviewer in David Miles wanted the
same text to be included in section 5.6.1 and that is why we complied.
Maybe in the new version we will make one sub-section to describe the
common text and then just point to this section in multiple protocol or
model sections.
</hs>

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.

<hs>
Good point.  We may just add a reference for RFC 3315 or if the
community decided they want a brief description of the server, we may
consider that input.
</hs>

Section 7:

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

<hs>
When we add the new ND Proxy sub-section, we will update the Data
Forwarding section too. 
</hs>

"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. "

<hs>
Good suggestion.  We will see what to incorporate in this sentence for
PD's.
</hs>

"
  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.

<hs>
You are correct.  When I added the new ND Proxy sub-section to a new
private version of the draft, this statement has been removed from the
document.
</hs>

"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.

<hs>
Yes, we will consider removing the statement.
</hs>

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

<hs>
OK, good suggestion - will do.
</hs>

Section 7.2:

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

<hs>
If MLD Proxy works to receive mcast data from the SP to the home, why do
we want to even add a "MAY support full MLD mcast processing"?  We do
point to full mcast functionality in the last paragraph of this section
for the case if the home wants to send mcast data out to the Internet.
The text of the section is fine as is unless you can show any case we
missed that would require full MLD mcast processing.
</hs>

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."

<hs>
Disagree with your recommendation that says "should generate an ICMPv6
Packet" rather than use our text that is essentially saying the error
message must be sent.  Our text is correct because RFC4443, in section
3.2 says the following:
[A Packet Too Big MUST be sent by a router in response to a packet
 that it cannot forward because the packet is larger than the MTU of
 the outgoing link.]
</hs>

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

<hs>
Let me check the cpe-simple-security draft (been a while since I read
that draft and I don't remember details from it right now) and see if
any default behavior for filters is mentioned in that document.
Otherwise, we may expand our section for any defaults.
</hs>

  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

<hs>
We already mention item two in your end user choices in the document.
How does the CPE Router know there is "No Ipv6", so is there really a
need for the first choice?  Then I don't understand what does ND Proxy
have anything to do with 6to4?
</hs>

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

<hs>
You suggestion is worth thinking about.  We'll mull over it.
</hs>

Section 8.7:

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

<hs>
Whatever DNS functionality including DNS64 the CPE router has to deal
with will be outlined in our draft.  
</hs>

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..."

<hs>
Agreed - will do.
</hs>

" 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....

<hs>
As this section says, we describe common practice out there for IPv4 CPE
Rtr.  The text above is in line with that.
</hs>

Kind Regards.

Hemant