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

[Pierre Pfister <[e-mail]>]

Hi Ole,

I remember we were supposed to discuss that at last IETF. Well, let’s discuss it here now I guess.

First, that’s why the use of 64 long prefixes is recommended. And I think it could be a fairly good consensus.
draft-ietf-6man-why64 is a very interesting document. An informational one. Correct me if I’m wrong but I’m not sure it’s possible to ‘comply’ to an informational document.

In general, my opinion about this whole debate is that it’s not because it happens that some implementations are broken that we should make specifications brake on purpose as well.
On a user perspective, IPv6 is barely deployed. Don’t you think IPv6 implementations will get fixed if IETF stop telling them they are perfectly right to be broken ?

Our current implementation (http://www.homewrt.org) supports this backup scenario. And it works. And hosts obtain addresses using DHCPv6. And they receive RAs with prefix length which is not 64. And my Mac is fine, and linux laptops are fine too. I’d rather have a /80 than no connectivity at all.

Why should we mandate homenet implementations to *brake* in situations where they could work fine ? Why should we voluntarily prevent a link from being configured if we actually can configure it ?

If MUSTs are the solution, then I would rather see a ‘ISP MUST provide a /56 to customers’ than ‘Homenet MUST brake when the provided prefix is not big enough’.

Also, this scarcity avoidance mechanism is optional. If the vendor considers it as too complex. He can drop it. And brake.

Cheers,

- Pierre

Le 8 oct. 2014 à 14:38, Ole Troan <[e-mail]> a écrit :

> Pierre, Alex,
> 
> please make sure this document does comply with http://datatracker.ietf.org/doc/draft-ietf-6man-why64/
> while I think the algorithm and data formats should support any prefix lengths, I don't think the sections dealing with "what if we've run out of prefixes" should be included in this document.
> 
> cheers,
> Ole
> 
> 
>> On 08 Oct 2014, at 13:28 , Pierre Pfister <[e-mail]> wrote:
>> 
>> Hi Alex,
>> 
>> Reply is inlined,
>> 
>> Le 8 oct. 2014 à 12:09, Alexandru Petrescu <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> homenet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/homenet
>> 
>> _______________________________________________
>> homenet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/homenet
>