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

Pierre Pfister <pierre.pfister@darou.fr> Wed, 08 October 2014 12:15 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 D9C9D1A0310 for <homenet@ietfa.amsl.com>; Wed, 8 Oct 2014 05:15:50 -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 6zFI52hRsilu for <homenet@ietfa.amsl.com>; Wed, 8 Oct 2014 05:15:48 -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 591391A0307 for <homenet@ietf.org>; Wed, 8 Oct 2014 05:15:48 -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 335C7140000B3; Wed, 8 Oct 2014 14:15:46 +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: <543526D9.2020107@gmail.com>
Date: Wed, 08 Oct 2014 14:15:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <FD386567-2DFE-4484-8F5A-794CF9C438F0@darou.fr>
References: <A0C73AEC-6D0F-498B-9BDD-D6AF91202CCB@darou.fr> <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@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 14:15:46 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/uI6ValjebN7NCp_pSIPKd6s-4Og
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 12:15:51 -0000

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

> Hi Pierre,
> 
> Le 08/10/2014 13:28, Pierre Pfister a écrit :
>> 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.
> 
> Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.

SLAAC relies on ‘interface identifier’. Ethernet uses the EUI-64.
I have no knowledge of other methods of generating an interface identifier.

The why64 draft is interesting (and sad) on that front.

> 
>> 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.
> 
> Ok.
> 
>> But again, that should be avoided whenever possible. And ISPs MUST
>> provided enough prefixes (IMO).
> 
> I agree with you.
> 
> Last time I checked Free ISP seems to provide 8 /64 prefixes to my homenet:
> 2001:db8:0:ce10::/64
> 2001:db8:0:ce11::/64
> ...
> 2001:db8:0:ce17::/64
> I dont think these could be aggregated into a single shorter prefix, or my math is missing.

That is 2001:db8:0:ce10::/61

> 
> Second, their (Free's) web interface asks me to put a next hop for each of these prefixes.
> 
I’m not sure what that means. Is that in the freebox ?
I guess it doesn’t support DHCPv6-PD (yet). Could you check that ?

If you put a homenet router below your freebox, you will have to provide a prefix to the homenet router manually (which is supposed to be done by DHCPv6-PD).

> Do you think HNCP implementation may help fill in these fields automatically somehow?
> 
> 
>>> 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.
> 
> I wonder about the implementability of this statement, but yes it may be possible to write one.

I’ll reply to your other mail concerning that.

> 
>> This is how collisions are detected.
> 
> Ok.
> 
> Alex
> 
>> 
>> 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
>> 
>> 
>> 
> 
>