[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new version of the CPE Rtr draft is ready for review
See my comments below:
As a general comment, in my opinion there is lot of overlap with existing
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
| Broadband |
| network |
| | | |
In this model PE device is issuing RA, and CPE router is receiving on WAN
interface and proxy towards LAN and WLAN interfaces.
- No need to operate DHCP relay/client/server on CPE router
- No need to operate DHCP server/relay on PE device
- 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.
- CPE router might not be capable of filtering at packet level - ND proxy
is very similar to bridging
Further comments about the text:
WLAN interface - Do we have to consider ad-hoc nodes - if one uses access
points then it is not an ad-hoc wireless network
IPv6 multicast - In my opinion this term is ambiguous - It would be more
appropriate to call it "IPv6 multicast behaviour".
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.
I don't see the strong host model to be defined anywhere in the document
The after "IPV6CP negotiates...." until the end of the section is clearly
leftover from the previous section. - Should be removed.
"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:
Stateful DHCPv6 server support in CPE router is out of scope in this document.
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
The section should refer to RFC 4980 - ICMPv6 filtering recommmendations -
or should be refered in draft-ietf-v6ops-cpe-simple-security-03
I would add:
"CPE may implement full MLD multicast processing."
"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."
I think stateful or stateless packet filtering is implies some default
- 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
"... 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)
I would put the 2nd paragraph into a subsection 8.5.1: "Generating IPv6
address on WAN interfaces"
From the text "The CPE Router may also include DNS64..."
Either put into a different subsection or into a separate draft.
not necessary - does not give anything to the draft
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....
Network Engineer, Research Associate, Head of Network Planning and Projects
Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
On Thu, 30 Oct 2008, Hemant Singh (shemant) wrote:
Hemant & Wes