Why used DHCPv6 when RA has RDNSS and DNSSL?

[Bjørn Mork]

Gert Doering <gert at space.net> writes:
> On Thu, Apr 02, 2020 at 12:09:34AM -0300, Fernando Gont wrote:
>> On 1/4/20 14:16, Gert Doering wrote:
>> [...]
>> > Even IETF discontinued recommending DHCPv6-PD for "inside a home network",
>> > because it doesn't work.
>> 
>> Would you mind elaborating on this one?
>
> Which of the two parts? :-)
>
> As far as I understand, the official IETF recommendation for "how to 
> run a home with multiple subnets" is "homenet / HNCP" now, which distributes
> individual /64s via HNCP, not whole prefixes via DHCPv6-PD.

You can use DHCPv6-PD for /64 prefixes.  What you claim to be a problem
is actually flexibility. A /64 is a "whole prefix" if you want it to be.

I don't think HNCP restricts the prefix length, either?  64 is only a
default IIUC.

> The reason why I state "DHCPv6 doesn't work" is "in practice".  There is
> a practical lack of interest from vendors to make it work properly (as in,
> you can properly tie the delegated prefix(es) to ACLs, for example).

Oh, please...  Do you want us to count HNCP vs DHCPv6-PD vendor support?

There is a reason HNCP depends on SLAAC, DHCP and DHCPv6 for "hosts and
non-HNCP routers".  That's the only way it can be made working for now.

> On the "why is this a bad idea to start with" side, the chunkiness of 
> subnet distribution makes it really unsuitable for anything but the most
> simple 1-level hierarchy.  
>
>
> So, ISP-to-customer, delegates a /56.  Next-level router asks for a prefix,
> and gets... what?  Third-level router asks for a prefix, and gets what?

Again, you seem to have a problem with protocol flexibilty forcing you
to make policy decisions.

The natural choice for a home CPE receiving a /56 from the upstream ISP
would be to use it as a pool of /64s.

Each next-level router/host (RFC8415 made it clear that PD is for hosts
too) would get one or more /64s.  If one is not enough, then next-level
routers and hosts can request more than one .  A next-level router
wanting to support SLAAC to its downstream users might request a /64 for
each of its interfaces for example.  Except the one facing the DHCPv6
server obviously.

The next-level router can provide more prefixes for next-next-level
routers and hosts by relaying DHCPv6 to the home CPE.  Doing complex
multi-level PD inside the home network is not necessary.

You *could* make the policy much more complicated by allowing other
intermediate prefix lengths. One of my ISPs are still stuck with 6RD and
therefore only offer a /62 to me.

But there is no need to complicate stuff with lots of different prefix
lenghts.  Managing a home network as a set of /64s is fine.

> Corporate ISP-to-customer delegates a /48, so theoretically, there are
> "enough /56s in there to do lots of PD delegation to next-level routers" -
> but in practice, a /48 is supposed to be sufficient for a good-sized
> office building with *lots* of internal structure, and as soon as you
> have lots of internal network segments, you have no liberty to just give
> out random /56s here and there anymore.

You can use the same "single pool of /64s" with a /48 too.

If there actually is a requirement for structured addressing within the
office, then you can do that with DHCPv6-PD.  But as you point out: You
need to carefully think about that design.  Using multiple delegation
levels and/or multiple prefix lengths is going to complicate stuff.

> Now, abandon the idea of "multi-level" DHCPv6-PD, and just assume "all 
> you'll ever see is mobile clients asking for a single /64" (which, as
> I heard, is thinking too small, because you can have stacks of stacks,
> but stick to the /64 for the moment).  Normally, you'd assign a /64 per
> network segment - office LAN floor 1, 2, 3, guest LAN, etc. - and have
> (effectively) an infinite number of addresses for more machines than
> you can ever connect.   If you need to set aside "as many /64s as there
> could ever machines connect", you'll end up reserving /56s (256 hosts)
> or even more *per LAN*.  Which will totally ruin your address planing,
> and all of a sudden a /48 will be *tight* for a normal company network.

This assumes structured addressing within the company network. I'd say
that's overkill if all you want is to distribute addresses over multiple
internal router hops.  Your routers are perfectly capable of handling
65000 internal routes if they have to.

The reasons for splitting into /56 prefixes would be adminstrative,
creating internal "borders" between departments. This includes
delegating address assignment policies, routing policies, reverse DNS
etc.  You *can* do this with multi-level DHCPv6-PD.  But I'm not sure
you'd want to. I'd prefer getting a prefix I could route from multiple
upstreams, and manage it as a static resource at the top level.  Each
department or whatever would then serve as a single "ISP" for their part
of the network.  Which would then look like the home network with a /56
(or even /48 if the company was assigned a shorter prefix)

> So you need to somehow build a prefix distribution mechanism, so people
> can have an arbitrary number of PD prefixes in "wherever network they 
> happen to be".  So we're back to multi-level PD, with all the challenges
> (firewall rules, ACLs, internal routing, ...). 

You don't need multi-level DHCPv6-PD in your company any more than your
ISP need to use multi-level DHCPv6-PD to be able to delegate a /48 to
you from their assigned prefix.

I definitely agree that the number of prefix lengths per delegation
level should be limited to simplify management.  One is often enough.
This not limited to DHCPv6.

> And even then, a /48 might no longer be sufficient for a company with,
> say, 500 internal network segments and 40.000 employees - where it
> would be extremely spacious otherwise.

This is a policy question.  If the segments have different policies,
then a /48 might not be enough for 500 network segments.  But then you
can justify a shorter prefix, so I don't see the problem.

If the adminstrative policy is the same for all the segments, then there
is no problem spltting the /48 for 40000 employees over as many network
segments as you like.


> Could this be made to work?  Possibly.

You made "this" into an unrelated problem. Your large company example is
not relevant for the "inside a home network" topic.

But the original question wasn't actually about home networking either.
It was about providing /64 prefixes for end hosts without SLAAC.  This
problem is independent of the size of the network (which for all
practical purposes is the Internet anyway).  Luckily we can look at each
adminstrative domain as a separate entity. We do not have to design a
complete delegation tree from IANA and down to be able to discuss the
final host delegation.

DHCPv6-PD works, and AFAIK it is implemented by every vendor wanting to
be taken seriously.

HNCP probably works too.  Time will tell, if/when it is actually
implemented at a scale making it possible to test it outside the lab.

HNCP is currently irrelevant wrt end host addressing.  It depends on
either DHCPv6 or SLAAC there.



Bjørn