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.
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.
Second, their (Free's) web interface asks me to put a next hop for each
of these prefixes.
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.
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
