Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP

[Alexandru Petrescu <[e-mail]>]

Le 08/10/2014 14:15, Pierre Pfister a écrit :
>
> Le 8 oct. 2014 à 13:58, Alexandru Petrescu
> <[e-mail]> 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
>>> <[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.
>>
>> 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

Right, sorry, my math was missing.  So I suppose Free ISP delegates a
single /61 to me then, not several /64s.  This is a local prefix
division performed in that router.  I do not necessarily agree with it,
as I could have divided it differently, or I could have announced the 
/61 in RA in the first link of the homenet, etc.

>
>>
>> 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 ?

YEs, it is in the Freebox Server (not Player), the freebox OS 3.0, sorry 
no advertisement.

> I guess it doesn’t support DHCPv6-PD (yet). Could you check that ?

It does not support DHCPv6-PD Server on the ingress side, or otherwise 
these fields containing 'next-hop' would have not been there.

As DHCPv6-PD Client on the egress side - I dont know, no means to check 
unless I loose it.

> 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).

Yes, I agree with  you.  No DHCP-PD at this time.

But if the freebox had a daemon listening to commands to fill in these 
next-hop fields then it would work.

I am saying this because I speculate the way in which this particular 
operator may work, but I have no affiliation with it.

Alex

>> 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 [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________ homenet
>>>> mailing list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>>
>>>
>>
>>
>
>
>