Le 8 oct. 2014 à 13:58, Alexandru Petrescu <[email protected]> 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 >> <[email protected]> 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 [email protected] >>>> https://www.ietf.org/mailman/listinfo/homenet >>>> >>>> >>> >>> >>> _______________________________________________ homenet mailing >>> list [email protected] >>> https://www.ietf.org/mailman/listinfo/homenet >> >> >> > > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
