Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Brian E Carpenter]

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, otr...@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?

[Philip Homburg]

>> Independent of the prefix distribution mechanism, it may be worth revisit=
>ing
>> having a single /48 for an organisation of 4 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 4 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?

[otroan]

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

[otroan]

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

[Bjørn Mork]

Gert Doering  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 

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Lorenzo Colitti]

On Thu, Apr 2, 2020 at 5:52 PM Gert Doering  wrote:

> > Independent of the prefix distribution mechanism, it may be worth
> revisiting
> > having a single /48 for an organisation of 4 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 .

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Gert Doering]

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 4 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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Philip Homburg]

>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 4 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?

[Gert Doering]

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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Ivan Pepelnjak]

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?

[Fernando Gont]

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: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Gert Doering]

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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[sthaug]

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