Thanks for the reply. See inline.
Pierre Pfister <mailto:[email protected]>
18 March 2015 07:46
Hello Ray,
Thanks for the comments, and for making these experimentations.
Comments inline,
OK Got it. Thanks.
Another question. I've been testing with smaller prefixes than that required to
configure the Homenet.
Is behavior defined for that situation?
In the past version of the PA draft, these considerations were part of the
draft. Since last IETF, PA and HNCP drafts were split into
3 different drafts. DNCP, HNCP, and PA. The PA one is now Homenet agnostic, and
because no behavior would be better in *all* cases where
the algorithm is used, the behavior is left as implementation/configuration
specific.
It is now HNCP’s role to have this kind of considerations.
And for now, the behavior is undefined.
How does the PA algorithm detect "available delegated prefix space is
exhausted: you need to do something else"?
Bullet point 3 of Section5, seems to me to define behavior that longer
prefixes MUST be considered when the available delegated prefix space is
in danger of being exhausted (to avoid absolute exhaustion).
It may be a corner case, but what if the delegated prefix space was
192.168.0.0/24 and there are 257 prefixes required, will the algorithm
ever terminate?
i.e. I am delegating a /60 but I have 9 interfaces (with 4 common) = 6 prefixes
to assign in Homenet.
Theoretically that should fit. And it does
Delegating router gives out a lease for 2001:6d8 :67d2 :1f0::/60
So Homenet 1 has
2001:6d8:67d2:1f9:16cc:20ff:fe8a:15c4/64(common with Homenet 2)
2001:6d8:67d2:1ff:16cc:20ff:fe8a:15c4/64
2001:6d8:1f15:62e:16cc:20ff:fe8a:15c4/64 (WAN)
Homenet 2 has
2001:6d8:67d2:1f9:16cc:20ff:fe8a:15d6/64 (common with Homenet 1)
2001:6d8:67d2:1f5:16cc:20ff:fe8a:15d6/64
2001:6d8:67d2:1f7:16cc:20ff:fe8a:15d6/64 (common with Homenet 3)
Homenet 3 has
2001:6d8 :67d2 :1f7:16cc:20ff:fe8a:154c/64 (common with Homenet 2)
2001:6d8 :67d2 :1f3:16cc:20ff:fe8a:154c/64
2001:6d8 :67d2 :1f2:16cc:20ff:fe8a:154c/64
Now if I reduce the lease to a /62 I get problems (as expected)
lease granted is 2001:6d8 :67d2 :130::/62
2001:6d8 :67d2 :131:b834::89fe/80(common with Homenet 2)
2001:6d8 :67d2 :131:2eb6::9bb2/80
2001:6d8:1f15:62e:16cc:20ff:fe8a:15c4/64 (WAN)
Homenet 2 has
2001:6d8 :67d2 :131:b834::e8a9/80 (common with Homenet 1)
2001:6d8 :67d2 :131:2e46::a68a/80
2001:6d8 :67d2 :130:16cc:20ff:fe8a:15d6/64 (common with Homenet 3)
Homenet 3 (powered on first) has
2001:6d8 :67d2 :132:16cc:20ff:fe8a:154c/64
2001:6d8 :67d2 :133:16cc:20ff:fe8a:154c/64
2001:6d8 :67d2 :130:16cc:20ff:fe8a:154c/64 (common with Homenet 2)
So this looks like a pathological case (as expected).
Is it defined what should happen in this case?
Should a prefix be split, or simply as many /64's as possible be assigned?
RFC7368 section 3.4.1 states that /64 should not be split.
The implementation (hnet) does not behave like that. The prefix is split. And
it works fine with most clients.
It is a tradeoff between having N links with no prefix at all, or N+1 links
with a /80.
Sure. I just want to make sure all implementations make the same trade
off in a mixed vendor environment.
If it were theoretically possible to discover that inter-router links were
actually point to point links, should these be assigned /127's or the /80's
instead?
That would preserve more /64's for end user systems. One mechanism could be to
check the ND cache for other link local entries, other than other Homenet
speaking routers?
In order to assign a /80, you have to brake one single /64. Giving you 2^16
smaller prefixes (You could even use a /90, it does not make difference as soon
as you go further /64).
I don’t see what using /127’s would really bring.
Agreed.
But this is HNCP consideration, not PA. PA algorithm allows you to use any
prefix length. In the latest implementation, PA code is used for both prefix
and address (/128) assignment.
OK.
I've also tried to add additional /62 prefixes to the DHCP PD server (fake ISP
router) DHCPD config, but the Homenet either doesn't request these, or the ISC
code isn't assigning them.
The homenet is thus only using a single lease, rather than concatenating
multiple small leases.
That to me would either simulate the situation where multiple small leases were
available from one ISP for utilization to number links from multiple prefixes,
or a make before break renumbering event was upcoming.
Either way I'd expect the Homenet to somehow grab these additional leases if it
had run out in the original PD assignment space, or to prepare for renumbering
by assigning dual prefixes per link.
Is there anything to define in your draft?
In Homenet model, each provided prefix is attached to an uplink. It does not
mean that one ISP has to provide a single prefix, it could provide multiple
(with prefix coloring for instance). *But*, it means that each prefix has a
different purpose, and that ultimately each link should be numbered with
prefixes from each DP.
Interesting, and this may need more work. I guess the prefixes could be
"colored" by encapsulating them in an IA_PD with multiple IA_PD Prefix
options, each containing a to be defined "IAprefix-option" mapping the
prefix to a color. I know that's outside the scope of your draft.
It would be technically possible to do what you are saying. But in practice,
ISP’s should/must provide /56.
Agreed
I believe that in some situations, it might not be that simple.
Renumbering for example.
But I also believe that those who are able to give you multiple /62s should try
harder, work on their aggregation, and provide one single bigger prefix. It’s
not like we are missing addresses.
I agree, but I think we might end up being surprised. There's not a lot
of space left in an addressing plan between /32 and /56 if you have
multiple levels of hierarchy in your network (coupled with route
aggregation). It's only 6 nibbles, or 3 octets. No better off than the
original IPv4 class A.
Regards,
- Pierre
--
Regards,
RayH
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
