Subject: Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-03.txt

From: Ray Hunter <[email-masked]>
Date: Thu, 12 Mar 2015 17:44:47 +0100

I have read this draft. It looks very good.

I have the following questions:

1. What are the interoperability considerations if the node also 
contains (historical) configuration for acting as an RFC7084 router?

Especially with respect to requirement L2 and L8.

I came across this whilst testing the openwrt hnet package, where some 
interfaces where configured with 'proto hnet', whilst other interfaces 
still had vanilla openwrt config "option ip6assign '64'".

SHOULD nodes when performing draft-ietf-homenet-prefix-assignment-03 
take historical RFC7084 assignments into account as being statically 
configured with a certain priority?

Also

2. may/should/must a Homenet router that participates in the 
draft-ietf-homenet-prefix-assignment-03.txt also act as a proxy for an 
old RFC7084 router connected to one interface?

[ref: RFC 7368 3.9]

Some of the hardest problems in developing solutions for home
    networking IPv6 architectures include discovering the right borders
    where the 'home' domain ends and the service provider domain begins,
    deciding whether some of the necessary discovery mechanism extensions
    should affect only the network infrastructure or also hosts, and the
    ability to turn on routing, prefix delegation, and other functions in
    a backwards-compatible manner.

I could imagine the homenet router grabbing a bunch of prefixes on 
behalf of the 7084 router, when it detects an inbound DHCP PD request on 
one of its interfaces, and then issuing a DHCP PD reply to the 7084 
router based on these prefixes, and also advertising a local route to 
the downstream router.

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Home Networking Working Group of the IETF.
>
>          Title           : Distributed Prefix Assignment Algorithm
>          Authors         : Pierre Pfister
>                            Benjamin Paterson
>                            Jari Arkko
> 	Filename        : draft-ietf-homenet-prefix-assignment-03.txt
> 	Pages           : 18
> 	Date            : 2015-02-08
>
> Abstract:
>     This document specifies a distributed algorithm for automatic prefix
>     assignment.  Given a set of delegated prefixes, it ensures that at
>     most one prefix is assigned from each delegated prefix to each link.
>     Nodes may assign available prefixes to the links they are directly
>     connected to, or for other private purposes.  The algorithm
>     eventually converges and ensures that all assigned prefixes do not
>     overlap.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-prefix-assignment-03
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>

-- 
Regards,
RayH

---

From: Steven Barth <[email-masked]>
Date: Thu, 12 Mar 2015 18:11:24 +0100

> I have read this draft. It looks very good.
I agree (having reviewed probably all the various iterations of that 
document).

> Especially with respect to requirement L2 and L8.
I think that is more of an implementation matter not so much 
draft-relevant. I mean sure if you design your OS from the ground up 
with that in mind that would be easy. However in the reference 
implementation we deliberately do not do that as that would require 
emulating a lot of OS-specific behavior.

You can however replicate this configuration by defining the interface 
as hnet with mode=leaf (i.e. always internal, not connected to routers = 
doesn't speak RP nor HNCP on it) and you can give hnet a hint on what 
size and or id of the prefix you want to have assigned.

As for L8 (running DHCPv6) hncp-04 has similar requirements, DHCPv6 
behavior was at some point actually in the PA draft but it was moved to 
hncp I suppose for clarity reasons though Pierre could probably talk 
about this in more detail.

> old RFC7084 router connected to one interface?
This - as well - is defined in hncp-04 instead and we do this in the 
reference implementation. Internally the delegating router announces the 
DP on behalf of the legacy router using HNCP and inserts a local route.

Cheers,

Steven

---

From: Ray Hunter <[email-masked]>
Date: Fri, 13 Mar 2015 16:48:00 +0100

> Steven Barth <mailto:[email-masked]>
> 12 March 2015 18:11
>
> as hnet with mode=leaf (i.e. always internal, not connected to routers 
> = doesn't speak RP nor HNCP on it) and you can give hnet a hint on 
> what size and or id of the prefix you want to have assigned.
>
> behavior was at some point actually in the PA draft but it was moved 
> to hncp I suppose for clarity reasons though Pierre could probably 
> talk about this in more detail.
>
>
>>
>> draft-ietf-homenet-prefix-assignment-03.txt also act as a proxy for 
>> an old RFC7084 router connected to one interface?
> reference implementation. Internally the delegating router announces 
> the DP on behalf of the legacy router using HNCP and inserts a local 
> route.
>
>
>
> Cheers,
>
> Steven

I've just been testing this feature, which is why I asked ;)

/56 was requested by hnet router to ISP router.

/62 was (correctly) allocated to the 7084 router by the hnet router.
route to /62was (correctly) advertised by the hnet router into Homenet.

Is it not worth adding a couple of sentences to this draft?

At the end of Section 6:

Proxy:   A proxy node is capable of acting on behalf of one or more 
non-participating device(s) (e.g. a downstream RFC7084 compliant router) 
in order to assign new prefixes, adopting, existing ones, making 
overriding assignments and destroying existing ones on behalf of the 
non-participating device(s). The exact mechanism to be deployed is 
outside the scope of this draft. The proxy node SHOULD ensure that any 
underlying topology discovery mechanism is stable and complete, before 
acting as a proxy node, to avoid causing any race conditions. The proxy 
node SHOULD also check that the network topology beyond the proxy node 
is single attached to the set of participating nodes.

-- 
Regards,
RayH

---

From: Pierre Pfister <[email-masked]>
Date: Sat, 14 Mar 2015 09:10:20 +0100

Hello Ray,

Thanks for the review.

> Proxy:   A proxy node is capable of acting on behalf of one or more non-participating device(s) (e.g. a downstream RFC7084 compliant router) in order to assign new prefixes, adopting, existing ones, making overriding assignments and destroying existing ones on behalf of the non-participating device(s). The exact mechanism to be deployed is outside the scope of this draft. The proxy node SHOULD ensure that any underlying topology discovery mechanism is stable and complete, before acting as a proxy node, to avoid causing any race conditions. The proxy node SHOULD also check that the network topology beyond the proxy node is single attached to the set of participating nodes.

Their actually is something about that already. Sub-delegation is one of the purposes of the so called « Private Links »

Private Link:   A Private Link is an abstract concept defined for the
      sake of this document.  It allows nodes to make assignments for
      their private use or delegation.  For instance, every DHCPv6-PD
      [RFC3633] client MAY be considered as a different Private Link.

Another node, by some mean such as DHCPv6-PD, asks for prefixes. In order to provide a prefix, the algorithm may be executed on a Private Link representing that client node. It is true that the proxy needs to be careful when it provides prefixes this way. Which is why the « Apply Timer » exists.

Applied (Assigned Prefix):   When an Assigned Prefix is applied, it
      MAY be used (e.g., for host configuration, routing protocol
      configuration, prefix delegation).  When not applied, it MUST NOT
      be used for any other purposes than the prefix assignment
      algorithm. […]

In order to help moving forward with specifications, the PA draft was purged from any purely Homenet specific considerations (Prefix Length considerations, Prefix Lifetimes, ULA generation, …). These considerations now belong to the hncp document (draft-ietf-homenet-hncp-04). Particularly, Recursive Prefix Delegation is described in Section 6.2.6 of the HNCP document.

Thanks,

- Pierre

---

From: Ray Hunter <[email-masked]>
Date: Tue, 17 Mar 2015 18:51:02 +0100

> Pierre Pfister <mailto:[email-masked]>
> 14 March 2015 09:10
> Hello Ray,
>
> Thanks for the review.
>
>
> Their actually is something about that already. Sub-delegation is one 
> of the purposes of the so called « Private Links »
>
> [RFC3633 <https://tools.ietf.org/html/rfc3633>] client MAY be 
> considered as a different Private Link.
>
> Another node, by some mean such as DHCPv6-PD, asks for prefixes. In 
> order to provide a prefix, the algorithm may be executed on a Private 
> Link representing that client node. It is true that the proxy needs to 
> be careful when it provides prefixes this way. Which is why the 
> « Apply Timer » exists.
>
> In order to help moving forward with specifications, the PA draft was 
> purged from any purely Homenet specific considerations (Prefix Length 
> considerations, Prefix Lifetimes, ULA generation, …). These 
> considerations now belong to the hncp document 
> (draft-ietf-homenet-hncp-04). Particularly, Recursive Prefix 
> Delegation is described in Section 6.2.6 of the HNCP document.
>
>
> Thanks,
>
> - Pierre
>
>
> ------------------------------------------------------------------------
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?

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?

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?

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?

e.g. Multiple address pools obtained from a single source SHOULD NOT be 
concatenated, but treated as a potential make before break renumbering 
event.

-- 
Regards,
RayH

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 18 Mar 2015 07:46:55 +0100

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.
> 

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.

> 
> i.e. I am delegating a /60 but I have 9 interfaces (with 4 common) = 6 prefixes to assign in Homenet.
> 

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.

> 
> 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.

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.

> 
> 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.
> 

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.

It would be technically possible to do what you are saying. But in practice, ISP’s should/must provide /56. I believe that in some situations, it might not be that simple. 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.

Regards,

- Pierre

---

From: Ray Hunter <[email-masked]>
Date: Wed, 18 Mar 2015 13:48:54 +0100

Thanks for the reply. See inline.
> 18 March 2015 07:46
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?
> 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.
> 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.
> 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*,…
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,
RayH

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 18 Mar 2015 15:13:35 +0100

Ray,

> 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.

> 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').

> 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.

> 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