Arun, before I write up a few comments I'd like to remark that I don't like the idea of delegating prefixes using ICMPv6 because I don't see how this offers different/better/more versatile features compared to DHCPv6-PD. Especially since you need a state machinery or cache for this mechanism to maintain tables of allocated and free prefixes. You basically try to provide functionality with ICMPv6 that is already provided by DHCPv6-PD.
> Do let us know your comments and suggestions on the draft .. Here are my initial comments after the first pass of reading the document: Para 2.1: - Here you say that RRs make requests to the CPE. Later paragraphs (e.g. 3.1) suggest that the RR and the CPE are the same entity (which makes sense). You should clarify this. Same goes for the PE and the DR -- they appear to be the same in later paragraphs but it's not clear. Para 4.1: - Assuming that RRs and DRs aren't necessarily connected via P-t-P connection (if they were you could try and use some link-scoped multicast address), how is the "Destination Address" of the DR determined by the RR? Does it have to be specified manually? I don't recall that you specify this in the document. Would the default router's address be the "Destination Address"? Para 5.1: - The "Free Prefix Cache" section is too unspecific in my eyes. You should clarify what you actually mean by "list of available prefixes". Let's say that you have 2001:638:500::/48 in that cache. Does this mean that RRs may request several /64 prefixes from the /48? Or does it mean that you can only request the whole /48? (The latter obviously makes more sense but it should be made clear in this paragraph what is possible and what isn't.) - What do you mean by "details of acceptable IP addresses for this prefix"? Is this a list of IPv6 addresses of RRs that may request this prefix? Is this mandatory? In what form can you specify these IP addresses (e.g. also as prefixes)? - It is not clear from looking at the "Free Prefix Cache" if or if not prefixes are actually pre-assigned. Maybe a "Reserved" state that is practically the same as the "Free" state in Para 5.2 would clarify this with the addition that it may only be assigned to an RR with a specific Identifier. Para 9.: - A very important security issue I see is that the ICMPv6 messages are not limited to a link. I don't see why it wouldn't be possible for any host with a global IPv6 address to act as an RR and contact a DR with to request a prefix. This can only be countered with filtering the ICMPv6 messages on the appropriate routers. The I-D does not specifically limit the Prefix Delegation exchanges to a P-t-P link -- e.g. Figure 2 in Para 2.1 doesn't suggest it does. - Since prefixes can be freely requested by RRs in some scenarios, routing adjustments have to be made automatically by PEs based on the prefix delegations. This potentially makes the mechanism vulnerable to denial of service attacks. Especially since the administrational realm of the ISP does not include the CPEs. Again, I think that we shouldn't try to use ICMPv6 for providing a functionality that is already provided by DHCPv6-PD. Additionally, the issue of pre-assigned prefixes for CPEs is not that clear to me in your document, even though this will most likely be the most common scenario for prefix delegation in my eyes. Can you clarify how pre-assignment is done specifically? Do you use a pre-shared Identifier that has to be put on RR and DR? Cheers, Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
