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 <pierre.pfis...@darou.fr> wrote: > > Hi Alex, > > Reply is inlined, > > Le 8 oct. 2014 à 12:09, Alexandru Petrescu <alexandru.petre...@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 > > _______________________________________________ > 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
