Mailing List Archive

1 2 3  View All
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
On Wed, Apr 1, 2020 at 9:12 PM <sthaug@nethelp.no> wrote:

> We are already 90% of the way here: Make IA_PD work for hosts, not
> just for routers. That way Android handsets can have as many addresses
> as they want.
>

DHCPv6 PD is one of the means suggested by RFC 7934, yes. I'm not sure that
the folks asking for IA_NA would be happy with IA_PD though. The reason
most often cited for wanting DHCPv6 is that it fits well with tracking
practices and systems that are built to support on-request addressing and
networks assigning individual IP address(es) to devices. DHCPv6 PD provides
request-based addressing, but it wouldn't do much to interoperate with
those tracking systems because they deal with addresses, not subnets. From
that perspective, ND snooping might be more likely to interoperate well.
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
>> We are already 90% of the way here: Make IA_PD work for hosts, not
>> just for routers. That way Android handsets can have as many addresses
>> as they want.
>
> DHCPv6 PD is one of the means suggested by RFC 7934, yes. I'm not sure that
> the folks asking for IA_NA would be happy with IA_PD though. The reason
> most often cited for wanting DHCPv6 is that it fits well with tracking
> practices and systems that are built to support on-request addressing and
> networks assigning individual IP address(es) to devices. DHCPv6 PD provides
> request-based addressing, but it wouldn't do much to interoperate with
> those tracking systems because they deal with addresses, not subnets. From
> that perspective, ND snooping might be more likely to interoperate well.

Well, I work for one othe ISPs who would *love* to use DHCPv6 PD. Yes,
we'd have to make some modest changes to systems to handle prefixes
instead of individual addresses. But we'd be happy to just track IPv6
prefixes and *not* have to track individual addresses.

Our estimates is that the work to incorporate such a change (handling
IPv6 prefixes) would be significantly less than doing ND snooping and
similar in all relevant boxes and systems. YMMV.

Steinar Haug, AS2116
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
Lorenzo Colitti <lorenzo@google.com> writes:

> I'm not sure that the folks asking for IA_NA would be happy with IA_PD
> though.

Why don't you just try and see? You have nothing to lose AFAICT.


Bjørn
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
Hi,

On Wed, Apr 01, 2020 at 05:53:02PM +0200, Bj?rn Mork wrote:
> Lorenzo Colitti <lorenzo@google.com> writes:
>
> > I'm not sure that the folks asking for IA_NA would be happy with IA_PD
> > though.
>
> Why don't you just try and see? You have nothing to lose AFAICT.

I've said it on IETF discussions and will happily say it again - this
is a particular corner-case that might benefit developers running stacks
of VMs in VMs on their laptops, but I fail to see a real world argument
why this would be beneficial.

OTOH the cost to implement this on the network-side is significant.

Think "enterprise networks". You have LANs, and members of those
networks. Not "distribution machinery for arbitrary prefixes to be
doled out in places where you have no idea how many subnets of which
size you might need".

DHCPv6-PD has it's place in "connecting a client *network* to an
internet provider (wired/wireless/LTE/whatever)" but I totally fail
to see a positive benefit/cost analysis for anything else.

Even IETF discontinued recommending DHCPv6-PD for "inside a home network",
because it doesn't work.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
On 4/1/20 7:16 PM, Gert Doering wrote:

> Hi,
>
> On Wed, Apr 01, 2020 at 05:53:02PM +0200, Bjørn Mork wrote:
>> Lorenzo Colitti <lorenzo@google.com> writes:
>>
>>> I'm not sure that the folks asking for IA_NA would be happy with IA_PD
>>> though.
>> Why don't you just try and see? You have nothing to lose AFAICT.
> I've said it on IETF discussions and will happily say it again - this
> is a particular corner-case that might benefit developers running stacks
> of VMs in VMs on their laptops, but I fail to see a real world argument
> why this would be beneficial.


I really dont see this as "corner cases".  Maybe a few years ago, but in
todays world, more and more apps are distributed as contianers and my
guess is that we will see even more stuff like that in the future.

IF we could easily get prefixes assigned to "workstations" (or whatever
we call them) I can also imagine that it will quickly be used by various
kinds of sensors, "IoT"-devices etc. to build "personal area networks". 
Think stuff like your wireless headset, local file sharing between
devices, personal ip-cameras and so on.  Lots of devices that either use
USB or Bluetoth or other similar connections today could easily connect
to one of your local PD-prefixes and benefit from a simpler and more
robust connection over IP.

I also fail to see why the cost of implementing PD in a network would be
significantly higher than doing all the ND snoping and logging you would
need to track individual addresses - _especially_ in an enterprise network.


/Ola (T)
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
Hi,

On Wed, Apr 01, 2020 at 08:05:04PM +0200, Ola Thoresen wrote:
> I also fail to see why the cost of implementing PD in a network would be
> significantly higher than doing all the ND snoping and logging you would
> need to track individual addresses - _especially_ in an enterprise network.

Try build it.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
On 1/4/20 09:12, sthaug@nethelp.no wrote:
>> There are several reasons that people shout about DHCPv6:
> ...
>> - politics: probably the most contentious area. One well-known example
>> - is how ipv6 on cellular impacts carrier vs handset control
>> - politics. 3GPP specifies that the ppp context for tethering must
>> - support SLAAC and therefore it provides a /64 for LAN
>> - connectivity. This means that the handset applications have as much
>> - address space as they need. The argument goes that if DHCPv6 were a
>> - viable option for this, then the mobile operators would effectively
>> - wrestle control of the applications running on the handset (and
>> - ultimately control of the handset capabilities itself away from the
>> - handset software vendors) by handing control of the number of
>> - available IPv6 addresses to the cellular operator. This is, at least,
>> - the reason cited by the Android authors for the point-blank refusal to
>> - implement DHCPv6 in android (bug ID 32621).
>
> We are already 90% of the way here: Make IA_PD work for hosts, not
> just for routers. That way Android handsets can have as many addresses
> as they want.

You mean e.g. support IA_PD at CPEs on the LAN side?

Thanks!

Cheers,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
On 1/4/20 14:16, Gert Doering wrote:
> Hi,
>
[...]
>
> Even IETF discontinued recommending DHCPv6-PD for "inside a home network",
> because it doesn't work.

Would you mind elaborating on this one?

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
Hi,

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.

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

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?

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.

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.

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


Could this be made to work? Possibly.

Is anyone interested to *pay* for this work? Doubtful.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
>> We are already 90% of the way here: Make IA_PD work for hosts, not
>> just for routers. That way Android handsets can have as many addresses
>> as they want.
>
> You mean e.g. support IA_PD at CPEs on the LAN side?

I'd like IA_PD to work both CPEs on the LAN side, and I'd like it to
work for hosts.

Steinar Haug, AS2116
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
On 2/4/20 03:19, Gert Doering wrote:
> Hi,
>
> 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.

I haven't been following homenet, to be honest. Is it widely implemented?



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

I guess a % of what was originally leased?

In any case, I'm not sure one would do much more than 2 or three
hierarchies of DHCPv6-PD.

And when it comes to the home, if the CPE could do PD on the LAN side,
most current needs would be covered.

Clearly, without a requirements of how many levels you want to support,
it's impossible to tell how you might want to partition your address space.

And the desire to delegate prefixes is also a bit at odds with the
strict definition of /64 subnets which end up using a huge address space
with a very low host density.



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

But, in that case, I'm not sure you'd want *dynamic* leases.



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

Just curious: what would be the use case of /64 per host (besides trying
to limit number of entries in the NC, etc.)?

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
Just curious: what would be the use case of /64 per host (besides trying
to limit number of entries in the NC, etc.)?

A gazillion containers running on the host, each one with its own IPv6
address instead of NAT spaghetti.

Whichever way you look, we’re slowly turning IPv6 back into CLNP ;))

Ivan
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
Hi,

On Thu, Apr 02, 2020 at 05:24:34AM -0300, Fernando Gont wrote:
> > 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.
> I haven't been following homenet, to be honest. Is it widely implemented?

Not at all. IETF killed it nicely, by entering a quabbeling contest
at the crucial "it should be hit vendor implementations *now*" phase -
so after the standards were finally done, all plastic box vendors had
IPv6 implementations in their CPEs and nobody cared about homenet anymore.

(Also, one of the nicest aspects of homenet is "dual ISP multihoming", which
surprisingly ISPs seem to have no interesting in paying their CPE vendors
to implement... also, still not as nice as one might think due to source
address selection / source address *failover*)


Picking on just a few bits of your reply (because I am not disagreeing
with most)

[..]
> And the desire to delegate prefixes is also a bit at odds with the
> strict definition of /64 subnets which end up using a huge address space
> with a very low host density.

Yes. If we do away with /64s, and permit hosts to request a, like, /96,
via DHCP-PD, setting this all up would be much much easier - routers
could have a /64 on the LAN, and a second /64 for "as many /96s as you
could possible sustain" - or even "carved out of the /64" (if DHCPv6-IA_NA
is used and the router knows what is free).

Of course this would break *inside* the machine now, when you setup
a "virtual network segment" with said /96, and your android VM refuses
to do DHCPv6-IA_NA on it (and SLAAC doesn't work due to "not /64").


> > 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.
>
> But, in that case, I'm not sure you'd want *dynamic* leases.

Well, as for classic DHCPv6, "it depends". Most folks are totally happy
with a dynamic endpoint, because they do not need to sustain sessions
across a "change network" event.

Some will want static leases, that follow them around in the building.

But what when they roam to LTE in between?


[..]
> Just curious: what would be the use case of /64 per host (besides trying
> to limit number of entries in the NC, etc.)?

I let the proponents of DHCPv6-PD-to-the-host answer that - so far I haven't
heard "smaller than /64" proposed anywhere.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
>So you need to somehow build a prefix distribution mechanism, so people
>can have an arbitrary number of PD prefixes in "wherever network they=20
>happen to be". So we're back to multi-level PD, with all the challenges
>(firewall rules, ACLs, internal routing, ...). 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=20
>spacious otherwise.

Independent of the prefix distribution mechanism, it may be worth revisiting
having a single /48 for an organisation of 40000 employees.

There needs to be way to shield network complexity within a host from the
rest of the network. If we don't then limits on what routers can track (ND)
can become a limit in what we can do on a host. Even now people are already
worried about the number of 'privacy addresses'.

So having an address policy that would support a /64 per host makes sense to
me.

If we assume that hosts have no further structure (i.e., this just requests
one or a few /64s) then managing prefixes allocated to hosts is very similar
to managing individual addresses. So there is no reason why PD would not work
for that.

Of course, in a network of routers, PD makes less sense. However in this case,
when the network is actually managed, routers get prefixes from some
addressing plan, not from an automated mechanism.

That leaves homenet as the most complex dynamic case: potentially multiple
layers of routers that should configure automatically. However, in the homenet
case, the network is typically small enough that keeping track of individual
/64s is possible. So PD where each request is a /64 could very well work.
(I'm not trying to express an opinion on HNCP here)
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
Hi,

On Thu, Apr 02, 2020 at 10:44:04AM +0200, Philip Homburg wrote:
> >So you need to somehow build a prefix distribution mechanism, so people
> >can have an arbitrary number of PD prefixes in "wherever network they=20
> >happen to be". So we're back to multi-level PD, with all the challenges
> >(firewall rules, ACLs, internal routing, ...). 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=20
> >spacious otherwise.
>
> Independent of the prefix distribution mechanism, it may be worth revisiting
> having a single /48 for an organisation of 40000 employees.

Sure, but if we start handing out /40s like there's enough of them,
eventually there won't be.

> There needs to be way to shield network complexity within a host from the
> rest of the network. If we don't then limits on what routers can track (ND)
> can become a limit in what we can do on a host. Even now people are already
> worried about the number of 'privacy addresses'.
>
> So having an address policy that would support a /64 per host makes sense to
> me.

This is, interestingly enough, too big and too small at the same time.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
On Thu, Apr 2, 2020 at 2:16 AM Gert Doering <gert@space.net> wrote:

> Think "enterprise networks". You have LANs, and members of those
> networks. Not "distribution machinery for arbitrary prefixes to be
> doled out in places where you have no idea how many subnets of which
> size you might need".
>

It doesn't need to be arbitrary-size or hierarchical. The only thing that
is needed is to assign a /64 IPv6 prefix in every case where the network
assigns a /32 IPv4 address via DHCPv4 (or would assign a /128 IPv6 address
via IA_NA).
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
On Thu, Apr 2, 2020 at 5:52 PM Gert Doering <gert@space.net> wrote:

> > Independent of the prefix distribution mechanism, it may be worth
> revisiting
> > having a single /48 for an organisation of 40000 employees.
>
> Sure, but if we start handing out /40s like there's enough of them,
> eventually there won't be.
>

You don't need to hand a /40 to every enterprise that asks for it. The
address space necessary can be roughly extrapolated from how much private
IPv4 space is in use. There are some numbers to this effect in RFC 7934
section 9.2 <https://tools.ietf.org/html/rfc7934#section-9.2>.
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
Gert Doering <gert@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
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
> DHCPv6 took itself out of the running when it failed to provide the
> default gateway to its clients.

I just posted an updated version of what was the "Universal RA option" draft.
It is now the "Universal IPv6 Configuration Option", which includes support for default gateway in DHCPv6.

https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/?include_text=1

Best regards,
Ole
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
> 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.

As one of the authors of DHCPv6 PD, I might be biased.
But PD was analysed in detail for the homenet use case and was found wanting.

It does not support multiple sources of information (think multihoming).
Hierarchical PD does not deal with arbitrary topologies. Think having to implement a spanning tree with PD.
HNCP is the IETF's answer to this.

Considering how poorly hosts deal with multiple addresses, I'm not sure we have operational experience justifying pushing even more addresses to hosts (ref /64).

If we want to discuss how to deal with multiple links, I always thought the idea of multilink subnet routing, with the same /64 crossing multiple links showed promise. Regardless I think experience has shown that the "anarchy" that SLAAC brings with it has operational issues. Forcing the use of DHCP for address assignment. Or requiring modifications to SLAAC, e.g. introduction of something like the ARO option.

Cheers,
Ole
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
>> Independent of the prefix distribution mechanism, it may be worth revisit=
>ing
>> having a single /48 for an organisation of 40000 employees.
>
>Sure, but if we start handing out /40s like there's enough of them,
>eventually there won't be.

I find it weird that the IEEE manages to allocate a unique 48 bit MAC address
to each ethernet / wifi interface and that the RIRs would be unable to
allocate 40 bit unique numbers to companies with 40000 employes.

>> So having an address policy that would support a /64 per host makes sense=
> to
>> me.=20
>
>This is, interestingly enough, too big and too small at the same time.

Can you eleborate on the too small part.

Of course, we are talking about averages. There may be some big VM hosts
that may need more. Some simple devices may not need any /64.
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
At the risk of repeating myself, if ops people like this approach
then they need to engage in constructive discussion of it in the IETF.

No need for a travel budget, especially now.
https://www.ietf.org/mailman/listinfo/ipv6

Regards
Brian

On 02-Apr-20 23:10, otroan@employees.org wrote:
>> DHCPv6 took itself out of the running when it failed to provide the
>> default gateway to its clients.
>
> I just posted an updated version of what was the "Universal RA option" draft.
> It is now the "Universal IPv6 Configuration Option", which includes support for default gateway in DHCPv6.
>
> https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/?include_text=1
>
> Best regards,
> Ole.
>
Re: Why used DHCPv6 when RA has RDNSS and DNSSL? [ In reply to ]
Hi Ole,

> Op 2 apr. 2020, om 12:10 heeft otroan@employees.org het volgende geschreven:
>
>> DHCPv6 took itself out of the running when it failed to provide the
>> default gateway to its clients.
>
> I just posted an updated version of what was the "Universal RA option" draft.
> It is now the "Universal IPv6 Configuration Option", which includes support for default gateway in DHCPv6.
>
> https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/?include_text=1

Ha! You finally accepted my idea from years ago :) One set of options with two distribution protocols (one push and one pull model)

Cheers,
SAnder

1 2 3  View All