Le 08/10/2014 14:15, Pierre Pfister a écrit :
Le 8 oct. 2014 à 13:58, Alexandru Petrescu
<alexandru.petre...@gmail.com> 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
<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.
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 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
