Re: I-D Action: draft-kaiser-nd-pd-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 23 October 2012 12:19 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D530C21F8671 for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2012 05:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.52
X-Spam-Level:
X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J59pOAn7kGWn for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2012 05:19:32 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F42721F85D5 for <ipv6@ietf.org>; Tue, 23 Oct 2012 05:19:32 -0700 (PDT)
Received: by mail-bk0-f44.google.com with SMTP id jc3so1345479bkc.31 for <ipv6@ietf.org>; Tue, 23 Oct 2012 05:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XLlxPysZvVl7znDYBom77WjuU4O2Q/FEnBg+1+7B1VY=; b=iiXiAsFeutcyze0vSDVSwUhCXh8ByK3+quPagfaTej+nSesHKISRrsUvrY3KCSR/US iTisxnNEeqmvVNHD2xoII5gEy28dghxjZgPt9IDfF6PG7J7PLIbPFqbnLr/ktLZKxj83 qsy3tc1HF88tfpM/sCyloWAuOPBu3p3Lqn0E2uwuyll50ABKEHOTGmOn2T5qb/oF45vP f4mDNXC3n0QlA3/K4VVVQjb7INwth0N5YQYB6wo0yZJjgJO/O7jGt2ss738u2Nb9bhl/ UqArY3I8WAYj3sBz8taH2YhujufRpTOnHQ4z41zcMIutFLK/Ufr3rdcYyYV5IVMvjudB EnTg==
Received: by 10.205.121.7 with SMTP id ga7mr3604239bkc.30.1350994771151; Tue, 23 Oct 2012 05:19:31 -0700 (PDT)
Received: from [192.168.1.65] (host-2-102-219-57.as13285.net. [2.102.219.57]) by mx.google.com with ESMTPS id k21sm5638046bkv.1.2012.10.23.05.19.29 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 05:19:30 -0700 (PDT)
Message-ID: <50868B52.9000105@gmail.com>
Date: Tue, 23 Oct 2012 13:19:30 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-kaiser-nd-pd-00.txt
References: <20121015135008.32010.58361.idtracker@ietfa.amsl.com>
In-Reply-To: <20121015135008.32010.58361.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: draft-kaiser-nd-pd@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2012 12:19:32 -0000

I realised while reading this draft that I just don't understand
its operating model. It refers to the "requesting" router supplying
Prefix Collection and Prefix Information to the delegating router:

>    When requesting prefixes a requesting router MUST add for each
>    requested prefix a Prefix Information in the Prefix Delegation option
>    of the RS message.  

However, by definition the requesting router doesn't know what prefix(es)
it will be given. So surely all it can ask for is N unspecified prefixes
of given lengths?

It also says:

>    PC_ID:           An unique identifier of the Prefix Collection.  The
>                     PC_ID MUST be unique among all PC_ID known by the
>                     requesting router.

How can the requesting router provide this in its REQ message? By guessing?

> 11.  Security Considerations
> 
>    TBD

OK, but since a vehicular network is open to any one of millions of
unmanaged devices, this will need to be *very* convincing, especially
in preventing DOS.

Regards
   Brian Carpenter