Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

Pierre Pfister <pierre.pfister@darou.fr> Wed, 08 October 2014 11:28 UTC

Return-Path: <SRS0=W1if=67=darou.fr=pierre.pfister@bounces.m4x.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A61D1A02D1 for <homenet@ietfa.amsl.com>; Wed, 8 Oct 2014 04:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_D0BRDZEJsz for <homenet@ietfa.amsl.com>; Wed, 8 Oct 2014 04:28:37 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8541A0263 for <homenet@ietf.org>; Wed, 8 Oct 2014 04:28:36 -0700 (PDT)
Received: from [192.168.0.15] (roo49-3-88-173-49-87.fbx.proxad.net [88.173.49.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id AC014140000B3; Wed, 8 Oct 2014 13:28:34 +0200 (CEST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister <pierre.pfister@darou.fr>
In-Reply-To: <54350D62.5050706@gmail.com>
Date: Wed, 08 Oct 2014 13:28:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>
References: <A0C73AEC-6D0F-498B-9BDD-D6AF91202CCB@darou.fr> <54350D62.5050706@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Oct 8 13:28:35 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/H1hL8CuDimCYl7GLMPkKMc6oqSY
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Oct 2014 11:28:40 -0000

Hi Alex,

Reply is inlined,

Le 8 oct. 2014 à 12:09, Alexandru Petrescu <alexandru.petrescu@gmail.com> a écrit :

> Hi Pierre,
> 
> Thanks for the draft update.  Now I have two questions:
> 
>> prefixes of size 64 are RECOMMENDED.
> 
> Why is this length recommended?  I think it may be because of Ethernet?

I’m not a big fan of putting 64s everywhere neither. And I strongly disagree with mandating 64 bit long prefixes. 
The prefix algorithm itself is agnostic on this side.

Nevertheless, some parts of this document are home-network specific. 
Not even talking about crappy implementations, home network links should support SLAAC whenever possible.
Which is the reason why using 64bit long prefixes is RECOMMENDED.

But smaller prefixes are better than *no prefix at all*. 
When there are not enough prefixes available (e.g. the ISP provides a single 64 while we have multiple links), smaller prefixes can be used (80 for instance). 
Which means dhcpv6 must be used.
Our implementation supports it, and it works with my laptop.

But again, that should be avoided whenever possible. And ISPs MUST provided enough prefixes (IMO).

> 
> Maybe it would be advantageous to not make any recommendation on the prefix length.  Some times this may develop into a barrier beyond which it will be hard to go.
> 
> The other question is about the assumed capability to decide non between prefixes, such as to detect collisions.  Do you think it is possible to decide equality between prefixes?  I rather think prefixes have a more refined relationship than just equal/not-equal - e.g. they are also aggregated.
> 
> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do you think a 'collision' could be detected?  I doubt we have such an algorithm somewhere.
> 

Equality is never considered alone. Actually, most of the time, you will find considerations such as:
The prefix is not included or does not include any other Assigned
       Prefix with a higher precedence.

This is how collisions are detected.

Cheers,

- Pierre


> Alex
> 
> 
> 
> Le 30/06/2014 17:18, Pierre Pfister a écrit :
>> Hello group,
>> 
>> I’d like to inform you about the changes made in the two last homenet-prefix-assignment updates.
>> 
>> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>> 
>> The changes are mostly about fixing typos, but a few technical changes have been made as well (based on the experience gained from the implementation of the Prefix Assignment Algorithm over HNCP).
>> 
>> 
>>  — Changes between 00 and 01
>> 
>> - If a Delegated Prefix is included in another Delegated Prefix, it is ignored. This is intended to improve support for non-homenet routers that provide prefix sub-delegation. That way, sub-delegated prefixes are ignored.
>> 
>> - Adding network leader definition (The router with the highest identifier).
>> 
>> - Add a section about DHCPv6 downstream prefix delegation. For downstream RFC7084 routers support.
>> 
>> - Adding Delegated Prefix deprecation procedure in order to differentiate prefix deprecation and node disconnection. When a node disconnect, the DPs advertised by this node may be kept some time (depending on the DP's lifetimes). But if a DP is actively deprecated, nodes must stop using it immediately.
>> 
>> 
>>  — Changes between 01 and 02
>> 
>> - Designated router election can make use of the information provided by the flooding protocol (i.e. when no router is designated yet, only the highest router id present on the link can become designated).
>> 
>> - New implementation guideline in appendix concerning "prefix waste avoidance". It proposes an algorithm that provides a good trade-of between randomness, pseudo-randomness and prefix selection efficiency.
>> 
>> 
>> 
>> Comments are welcome,
>> 
>> Pierre Pfister
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>> 
>> 
> 
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet