Ray,
> 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 »?
That comes for free with the set of Advertised Prefixes. You know which
prefixes are assigned, so you know which are available. And you can see when
there are no prefixes available anymore.
>
> 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).
Almost the whole section is just a MAY. Only the beginning states MUSTs. Then
you have the following text:
The rest of this section describes a more efficient approach which
MAY be applied any time a node needs to pick a prefix for a new
assignment.
So this is just a recommandation that HNCP may or may not use.
>
> 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?
Of course.
When a routine fails assigning a prefix, it won’t be run again unless some
other event happens.
For instance, if a prefix stops being applied, the interface needing the prefix
may take the prefix and use it.
I wrote a formal termination and correctness proof for the algorithm. But it
needs some ordering so it can be shared.
>>
>>> 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.
It is not required. What is left unspecified in this document does not require
coordination between participating nodes.
If there are not enough prefixes, some node may decide to not assign anything,
another node may decide to assign a smaller prefix.
In that case, the node willing to assign something will have the priority over
the one assigning nothing (There is no ’no-assignment').
>>
>>> 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.
We did it a year ago. It was implemented. I don’t think it still works thought.
>> 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.
Not my problem (Just kidding ;) ).
I think it is another story. Some people have strong opinions about that. So I
am not going to go there as it is out of the scope of PA.
- Pierre
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
