Subject: Requesting Comments & Suggestions - ID on Prefix Delegation using ICMPv6

From: Arun Thulasi <[email-masked]>
Date: Sat, 01 May 2004 20:11:09 +0530

Hello All,

We've submitted a draft that describes a mechanism for Prefix Delegation 
using ICMPv6 by satisfying the requirements mentioned in Requirements 
for IPv6 prefix delegation 
(draft-ietf-ipv6-prefix-delegation-requirement-04.txt) ..

Do let us know your comments and suggestions on the draft ..

We would also like to request the Working Group and the Chairs to consider
draft-arunt-prefix-delegation-using-icmpv6-00.txt as a Working Group item.

Thanks,
Arun T
Shankar R

[email-masked] wrote:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

    Title        : IPv6 Prefix Delegation Using ICMPv6
    Author(s)    : S. Raman, A. Thulasi
    Filename    : draft-arunt-prefix-delegation-using-icmpv6-00.txt
    Pages        : 34
    Date        : 2004-4-29
    
This document describes a Prefix Delegation Mechanism which
  delegates IPv6 prefixes to a subscriber's network (or "site") by an
  Internet Service Provider (ISP). It uses ICMPv6 messages to handle
  Prefix Delegation between the Delegating Router and the Requesting
  Router.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arunt-prefix-delegation-using-icmpv6-00.txt 

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message.  You can also visit 
https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
    "get draft-arunt-prefix-delegation-using-icmpv6-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
    [email-masked].
In the body type:
    "FILE 
/internet-drafts/draft-arunt-prefix-delegation-using-icmpv6-00.txt".
    
NOTE:    The mail server at ietf.org can return the document in
    MIME-encoded form by using the "mpack" utility.  To use this
    feature, insert the command "ENCODING mime" before the "FILE"
    command.  To decode the response(s), you will need "munpack" or
    a MIME-compliant mail reader.  Different MIME-compliant mail readers
    exhibit different behavior, especially when dealing with
    "multipart" MIME messages (i.e. documents which have been split
    up into multiple messages), so check your local documentation on
    how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Mon, 03 May 2004 14:01:14 +0200

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

---

From: Ralph Droms <[email-masked]>
Date: Fri, 14 May 2004 11:04:07 -0400

draft-arunt-prefix-delegation-using-icmpv6-00.txt is an interesting approach
to prefix delegation.  Looking at it objectively, it appears to me that this
protocol largely duplicates the prefix delegation functions in RFC 3633, at
an approximately equivalent cost in message exchanges and implementation
complexity.  Further, I believe there are several issues in prefix
delegation that are addressed in RFC 3633, but are not addressed as well or
at all in draft-arunt-prefix-delegation-using-icmpv6-00.txt:

  As I understand the protocol, there is a four message exchange between the
  RR and the DR for prefix delegation, which is equivalent to the message
  exchange in RFC 3633.  In draft-arunt-prefix-delegation-using-icmpv6-00.txt,
  the RR must be configured with the address of the DR, while RFC 3633 uses a
  multicast discovery mechanism.

  The mechanism for CPE identification seems inadequate, especially as
  compared to RFC 3633.  How is the uniqueness of the 32-bit identifier
  draft-arunt-prefix-delegation-using-icmpv6-00.txt ensured?  In RFC 3633,
  there are several ways in which a DUID for a device can be formed, with
  guarantees of uniqueness among all devices.

  Is there a way in draft-arunt-prefix-delegation-using-icmpv6-00.txt for the
  DR to communicate a preferred lifetime to the RR?

  How does draft-arunt-prefix-delegation-using-icmpv6-00.txt address the
  security issues raised in section 9?  There is also a security exposure in
  prefix revocation (section 7.2), where an attacker spoofing the identity of
  the DR can cause an RR to stop using previously delegated prefixes.

I think RFC 3633 meets the requirements from the prefix delegation
requirements document and includes the features needed for deployment
of prefix delegation service.  We have multiple implementations and have
demonstrated interoperability, and RFC 3633 prefix delegation is already
in commercial deployment, so I don't see the need at this time to
pursue an alternative prefix delegation protocol.

- Ralph

At 08:11 PM 5/1/2004 +0530, Arun Thulasi wrote:
>using ICMPv6 by satisfying the requirements mentioned in Requirements for 
>IPv6 prefix delegation