Mailing List Archive

> On Mar 30, 2020, at 8:30 PM, Roger Wiklund <roger.wiklund@gmail.com> wrote:
>
> Hi
>
> I played around with IPv6 on my Mac today (Mac OS Catalina) and I noticed that besides the IP from DHCPv6 (dynamic) it's also generating two other addresses.
>
> ether aa:bb:cc:dd:ee:ff
> inet6 fe80::1cad:944f:df4a:d123%en0 prefixlen 64 secured scopeid 0x7
> inet6 2001:123:44:55:1a:f346:1bef:b88a prefixlen 64 autoconf secured
> inet6 2001:123:44:55:20ac:49d2:68c5:595b prefixlen 64 autoconf temporary
> inet6 2001:123:44:55::101 prefixlen 64 dynamic
>
> I don't really know that the "secured" address is used for TBH (both autoconf are randomized and not based on the MAC)
> The temporary address is used for outgoing connections and is changed every so often.
> The dynamic address if from my DHPv6 server.
>
> I think Windows has the same behaivour.
>
> This got me thinking, if the temporary address is used as the outgoing source address, this gives me even less incentive to use DHCPv6. Especially since my Juniper SRX supports RDNSS via RA: https://tools.ietf.org/html/rfc8106 <https://tools.ietf.org/html/rfc8106>
>
> set protocols router-advertisement interface ge-0/0/0.20 dns-server-address 2001:4860:4860::8888 lifetime 3600
> set protocols router-advertisement interface ge-0/0/0.20 dns-server-address 2001:4860:4860::8844 lifetime 3600
> set protocols router-advertisement interface ge-0/0/0.20 prefix 2001:123:44:55::/64
>
> When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't see the need to allocate a dynamic address if the autogenerated are used. For client's you dont really have any inbound connections unless it's a support case.
>
> What's your view on this?
>
> Thanks!

I don’t understand why this is a disincentive of any consequence to preparing for the future by adopting IPv6.

See also: https://apple.stackexchange.com/questions/315232/disable-temporary-autoconf-inet6-address <https://apple.stackexchange.com/questions/315232/disable-temporary-autoconf-inet6-address> (nota bene: I have not checked this on my Catalina systems due to time constraints.)


James R. Cutler
James.cutler@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Hi,

On Tue, Mar 31, 2020 at 02:30:46AM +0200, Roger Wiklund wrote:
> Hi
>
> I played around with IPv6 on my Mac today (Mac OS Catalina) and I noticed
> that besides the IP from DHCPv6 (dynamic) it's also generating two other
> addresses.
>
> When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't
> see the need to allocate a dynamic address if the autogenerated are used.
> For client's you dont really have any inbound connections unless it's a
> support case.
>
> What's your view on this?
>
> Thanks!

I for one think that, very broadly speaking, DHCPv6 should & can be avoided in many environments.
See also 'Does One Need DHCP(v6)?' https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/

cheers

Enno



--
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator

It seems that the router must be setting both the A bit (use SLAAC) and the M bit (use DHCPv6). So the host is obeying both. There's no real harm in it, in most circumstances.

Fixing the ambiguity about what hosts should do about this has often been discussed in the IETF but there's never really been evidence that it's worth doing.

Regards
Brian Carpenter

On 31-Mar-20 13:30, Roger Wiklund wrote:
> Hi
>
> I played around with IPv6 on my Mac today (Mac OS Catalina) and I noticed that besides the IP from DHCPv6 (dynamic) it's also generating two other addresses.
>
> ether aa:bb:cc:dd:ee:ff
> inet6 fe80::1cad:944f:df4a:d123%en0 prefixlen 64 secured scopeid 0x7
> inet6 2001:123:44:55:1a:f346:1bef:b88a prefixlen 64 autoconf secured
> inet6 2001:123:44:55:20ac:49d2:68c5:595b prefixlen 64 autoconf temporary
> inet6 2001:123:44:55::101 prefixlen 64 dynamic
>
> I don't really know that the "secured" address is used for TBH (both autoconf are randomized and not based on the MAC)
> The temporary address is used for outgoing connections and is changed every so often.
> The dynamic address if from my DHPv6 server.
>
> I think Windows has the same behaivour.
>
> This got me thinking, if the temporary address is used as the outgoing source address, this gives me even less incentive to use DHCPv6. Especially since my Juniper SRX supports RDNSS via RA: https://tools.ietf.org/html/rfc8106
>
> set protocols router-advertisement interface ge-0/0/0.20 dns-server-address 2001:4860:4860::8888 lifetime 3600
> set protocols router-advertisement interface ge-0/0/0.20 dns-server-address 2001:4860:4860::8844 lifetime 3600
> set protocols router-advertisement interface ge-0/0/0.20 prefix 2001:123:44:55::/64
>
> When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't see the need to allocate a dynamic address if the autogenerated are used. For client's you dont really have any inbound connections unless it's a support case.
>
> What's your view on this?
>
> Thanks!

Hi, Brian,

On 31/3/20 00:29, Brian E Carpenter wrote:
> It seems that the router must be setting both the A bit (use SLAAC) and the M bit (use DHCPv6).

FWIW, my Sagemcom router provided by my ISP does the same (set both A
in PIOs, and M (and O :-) ) in the RA). UBuntu reacts as descirbed by
the OP.


> So the host is obeying both. There's no real harm in it, in most circumstances.

Not sure I would clasify it as "harm", but:
my ubuntu box does rfc7217+rfc4941. But since the M bit is set, it
configures a DHCPv6-leased address... with a predictable IID. (
apparently the CPE has a poool that starts at ::1000, and leases
addresses incrementally).

Certainly, that's not nice.

Besides, if folks are concerned about the number of addresses in use (as
some did in recent 6man discussions), one would say this is a
low-hanging fruit: an address that is configured, and will *never* be used.



> Fixing the ambiguity about what hosts should do about this has often been discussed in the IETF but there's never really been evidence that it's worth doing.

FWIW, me, even if it was just for the sake "clarity", that would be
worth doing.

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

There are also devices that will try DHCPv6 regardless of the M/O bits. My HP printer was one.

Tim

On 31 Mar 2020, at 04:29, Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:

It seems that the router must be setting both the A bit (use SLAAC) and the M bit (use DHCPv6). So the host is obeying both. There's no real harm in it, in most circumstances.

Fixing the ambiguity about what hosts should do about this has often been discussed in the IETF but there's never really been evidence that it's worth doing.

Regards
Brian Carpenter

On 31-Mar-20 13:30, Roger Wiklund wrote:
Hi

I played around with IPv6 on my Mac today (Mac OS Catalina) and I noticed that besides the IP from DHCPv6 (dynamic) it's also generating two other addresses.

ether aa:bb:cc:dd:ee:ff
inet6 fe80::1cad:944f:df4a:d123%en0 prefixlen 64 secured scopeid 0x7
inet6 2001:123:44:55:1a:f346:1bef:b88a prefixlen 64 autoconf secured
inet6 2001:123:44:55:20ac:49d2:68c5:595b prefixlen 64 autoconf temporary
inet6 2001:123:44:55::101 prefixlen 64 dynamic

I don't really know that the "secured" address is used for TBH (both autoconf are randomized and not based on the MAC)
The temporary address is used for outgoing connections and is changed every so often.
The dynamic address if from my DHPv6 server.

I think Windows has the same behaivour.

This got me thinking, if the temporary address is used as the outgoing source address, this gives me even less incentive to use DHCPv6. Especially since my Juniper SRX supports RDNSS via RA: https://tools.ietf.org/html/rfc8106

set protocols router-advertisement interface ge-0/0/0.20 dns-server-address 2001:4860:4860::8888 lifetime 3600
set protocols router-advertisement interface ge-0/0/0.20 dns-server-address 2001:4860:4860::8844 lifetime 3600
set protocols router-advertisement interface ge-0/0/0.20 prefix 2001:123:44:55::/64

When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't see the need to allocate a dynamic address if the autogenerated are used. For client's you dont really have any inbound connections unless it's a support case.

What's your view on this?

Thanks!

On 31/Mar/20 02:30, Roger Wiklund wrote:

>
>
> When I read DHCPv6 vs SLAAC it often boils down to "control" but I
> don't see the need to allocate a dynamic address if the autogenerated
> are used. For client's you dont really have any inbound connections
> unless it's a support case.
>
> What's your view on this?

We only use DHCPv6 to assign IPv6 DNS addresses to devices.

Otherwise, we rely on SLAAC.

DHCPv6 took itself out of the running when it failed to provide the
default gateway to its clients.

Mark.

>> When I read DHCPv6 vs SLAAC it often boils down to "control" but I
>> don't see the need to allocate a dynamic address if the autogenerated
>> are used. For client's you dont really have any inbound connections
>> unless it's a support case.
>>
>> What's your view on this?
>
> We only use DHCPv6 to assign IPv6 DNS addresses to devices.
>
> Otherwise, we rely on SLAAC.
>
> DHCPv6 took itself out of the running when it failed to provide the
> default gateway to its clients.

Note that there have been multiple requests for DHCPv6 to do this but
every attempt has been shot down.

Steinar Haug, AS2116

On 31/Mar/20 12:09, sthaug@nethelp.no wrote:

> Note that there have been multiple requests for DHCPv6 to do this but
> every attempt has been shot down.

Yep - thankfully, we have an option.

Operating two address assignment protocols is just silly.

At my house, I don't even bother with DHCPv6 for DNS. I just use the
IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
done with the purist madness around this.

Mark.

Thanks for all the feedback

I also run dual stack with SLAAC for IPv6 assignment and my IPv4 DNS
servers resolve the AAAA records.

After skimming through rfc7217 + rfc4941 with the "autoconf temporary"
being used for outbound and "autoconf secured" being static and can thus be
used for reliable incoming connections I _really_ don't see the use for
allocating a 3rd dynamic IP via DHCPv6 that may never be used.

For me the use case for DHCPv6 boils down to if you need:

PXE boot
Provide NTP servers (typically OS handles this even without DHCP)
Provide DNS servers (If you don't run dual stack and can't provide DNS
servers via Router Advertisement)
You need other DHCP options for IP-Phones etc.
Dynamic DNS

Disclaimer: It's been a decade+ since I did any sort of Enterprise IP
management so I'm happy to be corrected if I've missed/misunderstood
something.

/Roger

On Tue, Mar 31, 2020 at 12:18 PM Mark Tinka <mark.tinka@seacom.mu> wrote:

>
>
> On 31/Mar/20 12:09, sthaug@nethelp.no wrote:
>
> > Note that there have been multiple requests for DHCPv6 to do this but
> > every attempt has been shot down.
>
> Yep - thankfully, we have an option.
>
> Operating two address assignment protocols is just silly.
>
> At my house, I don't even bother with DHCPv6 for DNS. I just use the
> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
> done with the purist madness around this.
>
> Mark.
>

On Tue, Mar 31, 2020 at 02:30:46AM +0200, Roger Wiklund wrote:
> Hi
> I played around with IPv6 on my Mac today (Mac OS Catalina) and I noticed
> that besides the IP from DHCPv6 (dynamic) it's also generating two other
> addresses.
[...]
> I don't?really know that the "secured" address is used for TBH (both
> autoconf are randomized and not based on the MAC)
> The temporary address is used for outgoing connections and is changed
> every so often.

> When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't
> see the need to allocate a dynamic address if the autogenerated are used.
> For client's you dont really have any inbound connections unless it's a
> support case.

Ha! Yes, you're arguing from a client perspective. When I am in a bigger
environemnt, a lot of machines need to be addressable (be it for services
outside their local link, be it to secure access to special infrastructure
to a limited set of clients, be it for pulled backups, to name a few.

@work I use lots of dhcpv6 in these cases. We specifically don't
use it on the WLAN where personal devices live; those use the
autoconf'd tmp addresses, and pooled natted DHCP addresses for V4.

Regards,
-is

Hi,

On Tue, Mar 31, 2020 at 02:30:46AM +0200, Roger Wiklund wrote:
> When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't
> see the need to allocate a dynamic address if the autogenerated are used.

"control" in the sense of "the management station can see which client
is reachable under which IPv6 address"... and possibly "and put in proper
forward and reverse DNS entries".

So, managed networks tend to like DHCPv6 (DNS!), and wonder how they
should cope with Android.

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

Hi,

On Tue, Mar 31, 2020 at 12:17:44PM +0200, Mark Tinka wrote:
> At my house, I don't even bother with DHCPv6 for DNS. I just use the
> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
> done with the purist madness around this.

"In da house", mDNS usually does the trick nicely for "I want to ssh
to my wife's laptop to fix her time machine backup".

As soon as you have a larger routed network, mDNS falls short, and
(unless you have a windows domain) there are no existing mechanisms
to put a SLAAC v6 address into DNS...

Yes, thanks, IETF. Well done.

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

On 31/3/20 07:09, sthaug@nethelp.no wrote:
>>> When I read DHCPv6 vs SLAAC it often boils down to "control" but I
>>> don't see the need to allocate a dynamic address if the autogenerated
>>> are used. For client's you dont really have any inbound connections
>>> unless it's a support case.
>>>
>>> What's your view on this?
>>
>> We only use DHCPv6 to assign IPv6 DNS addresses to devices.
>>
>> Otherwise, we rely on SLAAC.
>>
>> DHCPv6 took itself out of the running when it failed to provide the
>> default gateway to its clients.
>
> Note that there have been multiple requests for DHCPv6 to do this but
> every attempt has been shot down.

Yes. That has been very unfortunate.


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On 31/3/20 12:59, Gert Doering wrote:
> Hi,
>
> On Tue, Mar 31, 2020 at 02:30:46AM +0200, Roger Wiklund wrote:
>> When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't
>> see the need to allocate a dynamic address if the autogenerated are used.
>
> "control" in the sense of "the management station can see which client
> is reachable under which IPv6 address"... and possibly "and put in proper
> forward and reverse DNS entries".
>
> So, managed networks tend to like DHCPv6 (DNS!), and wonder how they
> should cope with Android.

Probably they don't.


FWIW, it's quite interesting to see the same folks ditching DHCPv6 to
then complain if SLAAC-based hosts use more addresses than they would like.

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Golly whiz, I have always considered DHCPv6 and RA/SLAAC as configuration tools for end systems. In addition, I have always considered the configuration of end systems to be the (implicit)) responsibility of the end system owner, not the network provider. I would love to find someone who could eloquently articulate why the end system owner (especially in managed environments) can not choose how to configure end systems.

Why must the availability of these two particular configuration tools become such a partisan/religious debate. Does it make a significant difference in the cost of providing network services? Does it make a significant difference in the cost of end systems? I can find no evidence of this in the debate.

It seems obvious that (non-superuser) home systems have configuration requirements different from those in managed offices. Getting these satisfied to meet business requirements requires thought at a higher protocol level (such as Business Operations) and division of labor/control is often useful. Forcing end system configuration management into router configurations conflicts with end system change control. In many situations SLAAC, an obviously router-centric function, meets basic addressing requirements without burdening router operations with end system details. It many, often overlapping, situations DHCPv6 offers an orthogonal management point for items such as NTP, DNS, Printers, and more without interfering with managing the routing network.

Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking?

Could we then work on larger problems, such as implementing secure route distribution?

Show me my error and I will repent.

James R. Cutler
James.cutler@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net



> On Mar 31, 2020, at 12:01 PM, Gert Doering <gert@space.net> wrote:
>
> Hi,
>
> On Tue, Mar 31, 2020 at 12:17:44PM +0200, Mark Tinka wrote:
>> At my house, I don't even bother with DHCPv6 for DNS. I just use the
>> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
>> done with the purist madness around this.
>
> "In da house", mDNS usually does the trick nicely for "I want to ssh
> to my wife's laptop to fix her time machine backup".
>
> As soon as you have a larger routed network, mDNS falls short, and
> (unless you have a windows domain) there are no existing mechanisms
> to put a SLAAC v6 address into DNS...
>
> Yes, thanks, IETF. Well done.
>
> 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

Unsubscribe

> On Mar 31, 2020, at 1:21 PM, James R Cutler <james.cutler@consultant.com> wrote:
>
> ?Golly whiz, I have always considered DHCPv6 and RA/SLAAC as configuration tools for end systems. In addition, I have always considered the configuration of end systems to be the (implicit)) responsibility of the end system owner, not the network provider. I would love to find someone who could eloquently articulate why the end system owner (especially in managed environments) can not choose how to configure end systems.
>
> Why must the availability of these two particular configuration tools become such a partisan/religious debate. Does it make a significant difference in the cost of providing network services? Does it make a significant difference in the cost of end systems? I can find no evidence of this in the debate.
>
> It seems obvious that (non-superuser) home systems have configuration requirements different from those in managed offices. Getting these satisfied to meet business requirements requires thought at a higher protocol level (such as Business Operations) and division of labor/control is often useful. Forcing end system configuration management into router configurations conflicts with end system change control. In many situations SLAAC, an obviously router-centric function, meets basic addressing requirements without burdening router operations with end system details. It many, often overlapping, situations DHCPv6 offers an orthogonal management point for items such as NTP, DNS, Printers, and more without interfering with managing the routing network.
>
> Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking?
>
> Could we then work on larger problems, such as implementing secure route distribution?
>
> Show me my error and I will repent.
>
> James R. Cutler
> James.cutler@consultant.com
> GPG keys: hkps://hkps.pool.sks-keyservers.net
>
>
>
>> On Mar 31, 2020, at 12:01 PM, Gert Doering <gert@space.net> wrote:
>>
>> Hi,
>>
>>> On Tue, Mar 31, 2020 at 12:17:44PM +0200, Mark Tinka wrote:
>>> At my house, I don't even bother with DHCPv6 for DNS. I just use the
>>> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
>>> done with the purist madness around this.
>>
>> "In da house", mDNS usually does the trick nicely for "I want to ssh
>> to my wife's laptop to fix her time machine backup".
>>
>> As soon as you have a larger routed network, mDNS falls short, and
>> (unless you have a windows domain) there are no existing mechanisms
>> to put a SLAAC v6 address into DNS...
>>
>> Yes, thanks, IETF. Well done.
>>
>> 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
>

Unsubscribe

> On Mar 31, 2020, at 1:21 PM, James R Cutler <james.cutler@consultant.com> wrote:
>
> ?Golly whiz, I have always considered DHCPv6 and RA/SLAAC as configuration tools for end systems. In addition, I have always considered the configuration of end systems to be the (implicit)) responsibility of the end system owner, not the network provider. I would love to find someone who could eloquently articulate why the end system owner (especially in managed environments) can not choose how to configure end systems.
>
> Why must the availability of these two particular configuration tools become such a partisan/religious debate. Does it make a significant difference in the cost of providing network services? Does it make a significant difference in the cost of end systems? I can find no evidence of this in the debate.
>
> It seems obvious that (non-superuser) home systems have configuration requirements different from those in managed offices. Getting these satisfied to meet business requirements requires thought at a higher protocol level (such as Business Operations) and division of labor/control is often useful. Forcing end system configuration management into router configurations conflicts with end system change control. In many situations SLAAC, an obviously router-centric function, meets basic addressing requirements without burdening router operations with end system details. It many, often overlapping, situations DHCPv6 offers an orthogonal management point for items such as NTP, DNS, Printers, and more without interfering with managing the routing network.
>
> Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking?
>
> Could we then work on larger problems, such as implementing secure route distribution?
>
> Show me my error and I will repent.
>
> James R. Cutler
> James.cutler@consultant.com
> GPG keys: hkps://hkps.pool.sks-keyservers.net
>
>
>
>> On Mar 31, 2020, at 12:01 PM, Gert Doering <gert@space.net> wrote:
>>
>> Hi,
>>
>>> On Tue, Mar 31, 2020 at 12:17:44PM +0200, Mark Tinka wrote:
>>> At my house, I don't even bother with DHCPv6 for DNS. I just use the
>>> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
>>> done with the purist madness around this.
>>
>> "In da house", mDNS usually does the trick nicely for "I want to ssh
>> to my wife's laptop to fix her time machine backup".
>>
>> As soon as you have a larger routed network, mDNS falls short, and
>> (unless you have a windows domain) there are no existing mechanisms
>> to put a SLAAC v6 address into DNS...
>>
>> Yes, thanks, IETF. Well done.
>>
>> 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
>

Hi,

On Tue, Mar 31, 2020 at 03:10:50PM -0300, Fernando Gont wrote:
> > So, managed networks tend to like DHCPv6 (DNS!), and wonder how they
> > should cope with Android.
> Probably they don't.

I'm working with one enterprise right now, and one of the options on
the table is "have a separate wifi segment for android with SLAAC,
and use the NAC software in place to bump android devices to that
subnet".

Which is a major PITA...

(What they *want* is "IPAM shows what IPv6 address is in use on which
device in the network", which DHCPv6 would do nicely, including
static assignments via DHCP reservations - while everything else
relies on "IPv6/MAC ND logging on the router" or other disintegrated
fumbling...)

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

On 31/3/20 15:21, James R Cutler wrote:
> Golly whiz, I have always considered DHCPv6 and RA/SLAAC as
> configuration tools for end systems. In addition, I have always
> considered the configuration of end systems to be the (implicit))
> responsibility of the end system owner, not the network provider. I
> would love to find someone who could eloquently articulate why the end
> system owner (especially in managed environments) can not choose how to
> configure end systems.

Because the network admin can always choose to drop his/her packets if
he/she does not behave as expected. Whether you like it or not, the
network admin rules.


> Why must the availability of these two particular configuration tools
> become such a partisan/religious debate.

Because there are folks that believe they know better than the folk
running the network.



> Does it make a significant
> difference in the cost of providing network services? Does it make a
> significant difference in the cost of end systems? I can find no
> evidence of this in the debate.

There is not. It's a religious debate.



> It seems obvious that (non-superuser) home systems have configuration
> requirements different from those in managed offices. Getting these
> satisfied to meet business requirements requires thought at a higher
> protocol level (such as Business Operations) and division of
> labor/control is often useful. Forcing end system configuration
> management into router configurations conflicts with end system change
> control. In many situations SLAAC, an obviously router-centric function,
> meets basic addressing requirements without burdening router operations
> with end system details. It many, often overlapping, situations DHCPv6
> offers an orthogonal management point for items such as NTP, DNS,
> Printers, and more without interfering with managing the routing network.
>
> Wouldn’t it be more cost effect in the long term to simply make SLAAC
> and DHCPv6 cooperative and complementary attributes of end-to-end
> networking?

They should have enough features such that net admin can pick whatever
of these two they please.

SLAAC has incorporated RDNSS/DNSSL. So the only thing left if DHCPV6
being able to configure a default route. (And Android to support it, you
might say).

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On 31/3/20 16:03, Gert Doering wrote:
> Hi,
>
> On Tue, Mar 31, 2020 at 03:10:50PM -0300, Fernando Gont wrote:
>>> So, managed networks tend to like DHCPv6 (DNS!), and wonder how they
>>> should cope with Android.
>> Probably they don't.
>
> I'm working with one enterprise right now, and one of the options on
> the table is "have a separate wifi segment for android with SLAAC,
> and use the NAC software in place to bump android devices to that
> subnet".
>
> Which is a major PITA...
>
> (What they *want* is "IPAM shows what IPv6 address is in use on which
> device in the network", which DHCPv6 would do nicely, including
> static assignments via DHCP reservations - while everything else
> relies on "IPv6/MAC ND logging on the router" or other disintegrated
> fumbling...)

IMO, the work of folks doing standardization should be to provide the
tools such that folks running networks can pick whatever they feel fits
best.

IPv6 automatic configuration is kind of a mess (an artifact of history
and religious battle). That's what folks like myself respond when asked
what's the rationale for what we have.

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On 31-Mar-20 23:17, Mark Tinka wrote:
>
>
> On 31/Mar/20 12:09, sthaug@nethelp.no wrote:
>
>> Note that there have been multiple requests for DHCPv6 to do this but
>> every attempt has been shot down.
>
> Yep - thankfully, we have an option.
>
> Operating two address assignment protocols is just silly.
>
> At my house, I don't even bother with DHCPv6 for DNS. I just use the
> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
> done with the purist madness around this.

There's purism (which I don't understand) and there's also historical
baggage that is incredibly hard to get rid of. As I have reminded from
time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
became a proven technology for IPv4 (i.e. many of us were still running
around manually assigning IPv4 addresses to newly installed Suns and
NCDs and the like). DHCPv6 was an afterthought.

Unfortunately, the purism has made it impossible to have a rational
discussion about engineering our way out of this historical duplication.

On 01-Apr-20 05:01, Gert Doering wrote:

...
> As soon as you have a larger routed network, mDNS falls short, and
> (unless you have a windows domain) there are no existing mechanisms
> to put a SLAAC v6 address into DNS...

I think there's no *deployed* mechanism. DynDNS is said to work in the
lab. There's also some hope that DNS-SD will alleviate this problem,
but only if it gets deployed.

> Yes, thanks, IETF. Well done.

It's not because nobody has tried. But the bridge between theory and
operations seems to be hard to cross.

On 01-Apr-20 07:21, James R Cutler wrote:

...
> Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking?

Well, duh. What we need is more people with real operational smarts
able to spend a lot of time and patience in the IETF. Yes, I know
why that is hard. (I had operation smarts once; no longer.) But that
is the only way we we can get a pragmatic approach into RFC text.

Don't worry about the travel budget, because the IETF is going to
have to do much more of its work remotely for the next couple of years
anyway. But the time and patience investment is substantial.

Stay well,
Brian Carpenter

Unsubscribe

> On Mar 31, 2020, at 5:34 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> ?On 31-Mar-20 23:17, Mark Tinka wrote:
>>
>>
>>> On 31/Mar/20 12:09, sthaug@nethelp.no wrote:
>>>
>>> Note that there have been multiple requests for DHCPv6 to do this but
>>> every attempt has been shot down.
>>
>> Yep - thankfully, we have an option.
>>
>> Operating two address assignment protocols is just silly.
>>
>> At my house, I don't even bother with DHCPv6 for DNS. I just use the
>> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
>> done with the purist madness around this.
>
> There's purism (which I don't understand) and there's also historical
> baggage that is incredibly hard to get rid of. As I have reminded from
> time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
> became a proven technology for IPv4 (i.e. many of us were still running
> around manually assigning IPv4 addresses to newly installed Suns and
> NCDs and the like). DHCPv6 was an afterthought.
>
> Unfortunately, the purism has made it impossible to have a rational
> discussion about engineering our way out of this historical duplication.
>
> On 01-Apr-20 05:01, Gert Doering wrote:
>
> ...
>> As soon as you have a larger routed network, mDNS falls short, and
>> (unless you have a windows domain) there are no existing mechanisms
>> to put a SLAAC v6 address into DNS...
>
> I think there's no *deployed* mechanism. DynDNS is said to work in the
> lab. There's also some hope that DNS-SD will alleviate this problem,
> but only if it gets deployed.
>
>> Yes, thanks, IETF. Well done.
>
> It's not because nobody has tried. But the bridge between theory and
> operations seems to be hard to cross.
>
> On 01-Apr-20 07:21, James R Cutler wrote:
>
> ...
>> Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking?
>
> Well, duh. What we need is more people with real operational smarts
> able to spend a lot of time and patience in the IETF. Yes, I know
> why that is hard. (I had operation smarts once; no longer.) But that
> is the only way we we can get a pragmatic approach into RFC text.
>
> Don't worry about the travel budget, because the IETF is going to
> have to do much more of its work remotely for the next couple of years
> anyway. But the time and patience investment is substantial.
>
> Stay well,
> Brian Carpenter
>
>
>

Unsubscribe

> On Mar 31, 2020, at 5:34 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> ?On 31-Mar-20 23:17, Mark Tinka wrote:
>>
>>
>>> On 31/Mar/20 12:09, sthaug@nethelp.no wrote:
>>>
>>> Note that there have been multiple requests for DHCPv6 to do this but
>>> every attempt has been shot down.
>>
>> Yep - thankfully, we have an option.
>>
>> Operating two address assignment protocols is just silly.
>>
>> At my house, I don't even bother with DHCPv6 for DNS. I just use the
>> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
>> done with the purist madness around this.
>
> There's purism (which I don't understand) and there's also historical
> baggage that is incredibly hard to get rid of. As I have reminded from
> time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
> became a proven technology for IPv4 (i.e. many of us were still running
> around manually assigning IPv4 addresses to newly installed Suns and
> NCDs and the like). DHCPv6 was an afterthought.
>
> Unfortunately, the purism has made it impossible to have a rational
> discussion about engineering our way out of this historical duplication.
>
> On 01-Apr-20 05:01, Gert Doering wrote:
>
> ...
>> As soon as you have a larger routed network, mDNS falls short, and
>> (unless you have a windows domain) there are no existing mechanisms
>> to put a SLAAC v6 address into DNS...
>
> I think there's no *deployed* mechanism. DynDNS is said to work in the
> lab. There's also some hope that DNS-SD will alleviate this problem,
> but only if it gets deployed.
>
>> Yes, thanks, IETF. Well done.
>
> It's not because nobody has tried. But the bridge between theory and
> operations seems to be hard to cross.
>
> On 01-Apr-20 07:21, James R Cutler wrote:
>
> ...
>> Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking?
>
> Well, duh. What we need is more people with real operational smarts
> able to spend a lot of time and patience in the IETF. Yes, I know
> why that is hard. (I had operation smarts once; no longer.) But that
> is the only way we we can get a pragmatic approach into RFC text.
>
> Don't worry about the travel budget, because the IETF is going to
> have to do much more of its work remotely for the next couple of years
> anyway. But the time and patience investment is substantial.
>
> Stay well,
> Brian Carpenter
>
>
>

On Wed, Apr 1, 2020 at 4:03 AM Gert Doering <gert@space.net> wrote:

> (What they *want* is "IPAM shows what IPv6 address is in use on which
> device in the network", which DHCPv6 would do nicely, including
> static assignments via DHCP reservations - while everything else
> relies on "IPv6/MAC ND logging on the router" or other disintegrated
> fumbling...)
>

Gert, have you asked why the solutions listed in Enno's blog post
<https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/>
earlier in this thread don't work for them? Specifically, the router-based
IP snooping and NDP monitoring features in switch platforms? Is it just
that support for these features is patchy, and existing IPAMs do not
support them? Or is there some deeper problem? What can we do to make this
better? Yes, using IA_NA would address this particular need, but it has
disadvantages compared to SLAAC as well.

The real problem is there are distinct use cases for both SLAAC and DHCPv6
and the people in charge of DHCPv6 keep screwing up. It should be possible
to run either SLAAC/RA or DHCPv6 and have each offering provide the
required information without having to run additional services just to get
basic feature parity to IPv4. This is slowing implementation in enterprise
networks.

james


On Tue, Mar 31, 2020 at 3:24 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 31-Mar-20 23:17, Mark Tinka wrote:
> >
> >
> > On 31/Mar/20 12:09, sthaug@nethelp.no wrote:
> >
> >> Note that there have been multiple requests for DHCPv6 to do this but
> >> every attempt has been shot down.
> >
> > Yep - thankfully, we have an option.
> >
> > Operating two address assignment protocols is just silly.
> >
> > At my house, I don't even bother with DHCPv6 for DNS. I just use the
> > IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
> > done with the purist madness around this.
>
> There's purism (which I don't understand) and there's also historical
> baggage that is incredibly hard to get rid of. As I have reminded from
> time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
> became a proven technology for IPv4 (i.e. many of us were still running
> around manually assigning IPv4 addresses to newly installed Suns and
> NCDs and the like). DHCPv6 was an afterthought.
>
> Unfortunately, the purism has made it impossible to have a rational
> discussion about engineering our way out of this historical duplication.
>
> On 01-Apr-20 05:01, Gert Doering wrote:
>
> ...
> > As soon as you have a larger routed network, mDNS falls short, and
> > (unless you have a windows domain) there are no existing mechanisms
> > to put a SLAAC v6 address into DNS...
>
> I think there's no *deployed* mechanism. DynDNS is said to work in the
> lab. There's also some hope that DNS-SD will alleviate this problem,
> but only if it gets deployed.
>
> > Yes, thanks, IETF. Well done.
>
> It's not because nobody has tried. But the bridge between theory and
> operations seems to be hard to cross.
>
> On 01-Apr-20 07:21, James R Cutler wrote:
>
> ...
> > Wouldn’t it be more cost effect in the long term to simply make SLAAC
> and DHCPv6 cooperative and complementary attributes of end-to-end
> networking?
>
> Well, duh. What we need is more people with real operational smarts
> able to spend a lot of time and patience in the IETF. Yes, I know
> why that is hard. (I had operation smarts once; no longer.) But that
> is the only way we we can get a pragmatic approach into RFC text.
>
> Don't worry about the travel budget, because the IETF is going to
> have to do much more of its work remotely for the next couple of years
> anyway. But the time and patience investment is substantial.
>
> Stay well,
> Brian Carpenter
>
>
>
>

STOP FUCKING EMAILING ME

UNSUBSCRIBE

> On Mar 31, 2020, at 8:35 PM, james machado <hvgeekwtrvl@gmail.com> wrote:
>
> The real problem is there are distinct use cases for both SLAAC and DHCPv6 and the people in charge of DHCPv6 keep screwing up. It should be possible to run either SLAAC/RA or DHCPv6 and have each offering provide the required information without having to run additional services just to get basic feature parity to IPv4. This is slowing implementation in enterprise networks.
>
> james
>
>
> On Tue, Mar 31, 2020 at 3:24 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> On 31-Mar-20 23:17, Mark Tinka wrote:
> >
> >
> > On 31/Mar/20 12:09, sthaug@nethelp.no <mailto:sthaug@nethelp.no> wrote:
> >
> >> Note that there have been multiple requests for DHCPv6 to do this but
> >> every attempt has been shot down.
> >
> > Yep - thankfully, we have an option.
> >
> > Operating two address assignment protocols is just silly.
> >
> > At my house, I don't even bother with DHCPv6 for DNS. I just use the
> > IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
> > done with the purist madness around this.
>
> There's purism (which I don't understand) and there's also historical
> baggage that is incredibly hard to get rid of. As I have reminded from
> time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
> became a proven technology for IPv4 (i.e. many of us were still running
> around manually assigning IPv4 addresses to newly installed Suns and
> NCDs and the like). DHCPv6 was an afterthought.
>
> Unfortunately, the purism has made it impossible to have a rational
> discussion about engineering our way out of this historical duplication.
>
> On 01-Apr-20 05:01, Gert Doering wrote:
>
> ...
> > As soon as you have a larger routed network, mDNS falls short, and
> > (unless you have a windows domain) there are no existing mechanisms
> > to put a SLAAC v6 address into DNS...
>
> I think there's no *deployed* mechanism. DynDNS is said to work in the
> lab. There's also some hope that DNS-SD will alleviate this problem,
> but only if it gets deployed.
>
> > Yes, thanks, IETF. Well done.
>
> It's not because nobody has tried. But the bridge between theory and
> operations seems to be hard to cross.
>
> On 01-Apr-20 07:21, James R Cutler wrote:
>
> ...
> > Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking?
>
> Well, duh. What we need is more people with real operational smarts
> able to spend a lot of time and patience in the IETF. Yes, I know
> why that is hard. (I had operation smarts once; no longer.) But that
> is the only way we we can get a pragmatic approach into RFC text.
>
> Don't worry about the travel budget, because the IETF is going to
> have to do much more of its work remotely for the next couple of years
> anyway. But the time and patience investment is substantial.
>
> Stay well,
> Brian Carpenter
>
>
>

STOP FUCKING EMAILING ME

UNSUBSCRIBE

> On Mar 31, 2020, at 8:35 PM, james machado <hvgeekwtrvl@gmail.com> wrote:
>
> The real problem is there are distinct use cases for both SLAAC and DHCPv6 and the people in charge of DHCPv6 keep screwing up. It should be possible to run either SLAAC/RA or DHCPv6 and have each offering provide the required information without having to run additional services just to get basic feature parity to IPv4. This is slowing implementation in enterprise networks.
>
> james
>
>
> On Tue, Mar 31, 2020 at 3:24 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> On 31-Mar-20 23:17, Mark Tinka wrote:
> >
> >
> > On 31/Mar/20 12:09, sthaug@nethelp.no <mailto:sthaug@nethelp.no> wrote:
> >
> >> Note that there have been multiple requests for DHCPv6 to do this but
> >> every attempt has been shot down.
> >
> > Yep - thankfully, we have an option.
> >
> > Operating two address assignment protocols is just silly.
> >
> > At my house, I don't even bother with DHCPv6 for DNS. I just use the
> > IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
> > done with the purist madness around this.
>
> There's purism (which I don't understand) and there's also historical
> baggage that is incredibly hard to get rid of. As I have reminded from
> time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
> became a proven technology for IPv4 (i.e. many of us were still running
> around manually assigning IPv4 addresses to newly installed Suns and
> NCDs and the like). DHCPv6 was an afterthought.
>
> Unfortunately, the purism has made it impossible to have a rational
> discussion about engineering our way out of this historical duplication.
>
> On 01-Apr-20 05:01, Gert Doering wrote:
>
> ...
> > As soon as you have a larger routed network, mDNS falls short, and
> > (unless you have a windows domain) there are no existing mechanisms
> > to put a SLAAC v6 address into DNS...
>
> I think there's no *deployed* mechanism. DynDNS is said to work in the
> lab. There's also some hope that DNS-SD will alleviate this problem,
> but only if it gets deployed.
>
> > Yes, thanks, IETF. Well done.
>
> It's not because nobody has tried. But the bridge between theory and
> operations seems to be hard to cross.
>
> On 01-Apr-20 07:21, James R Cutler wrote:
>
> ...
> > Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking?
>
> Well, duh. What we need is more people with real operational smarts
> able to spend a lot of time and patience in the IETF. Yes, I know
> why that is hard. (I had operation smarts once; no longer.) But that
> is the only way we we can get a pragmatic approach into RFC text.
>
> Don't worry about the travel budget, because the IETF is going to
> have to do much more of its work remotely for the next couple of years
> anyway. But the time and patience investment is substantial.
>
> Stay well,
> Brian Carpenter
>
>
>

Hi,

On Wed, Apr 01, 2020 at 10:11:30AM +0900, Lorenzo Colitti wrote:
> On Wed, Apr 1, 2020 at 4:03 AM Gert Doering <gert@space.net> wrote:
>
> > (What they *want* is "IPAM shows what IPv6 address is in use on which
> > device in the network", which DHCPv6 would do nicely, including
> > static assignments via DHCP reservations - while everything else
> > relies on "IPv6/MAC ND logging on the router" or other disintegrated
> > fumbling...)
>
> Gert, have you asked why the solutions listed in Enno's blog post
> <https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/>
> earlier in this thread don't work for them? Specifically, the router-based
> IP snooping and NDP monitoring features in switch platforms? Is it just
> that support for these features is patchy, and existing IPAMs do not
> support them?

Mostly this, plus control / reservations ("this machine is supposed to
get *that* address").

> Or is there some deeper problem? What can we do to make this
> better? Yes, using IA_NA would address this particular need, but it has
> disadvantages compared to SLAAC as well.

You could just stop being the ugly kid that does not want to play with
the others.

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

If you’re receiving the messages is because YOU subscribed to the list.



If you subscribed to the list, you know how to unsubscribe.



If you don’t know it, you should be smart enough to look into the email header and you will find how to do it.



Just in case you don’t know how to do it, here is it for you:



List-Unsubscribe: <http://lists.cluenet.de/mailman/listinfo/ipv6-ops>,

            <mailto:ipv6-ops-request@lists.cluenet.de?subject=unsubscribe>





Regards,

Jordi

@jordipalet







El 1/4/20 6:08, "Sunita Badiga" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de indrules@aol.com> escribió:



STOP FUCKING EMAILING ME



UNSUBSCRIBE



On Mar 31, 2020, at 8:35 PM, james machado <hvgeekwtrvl@gmail.com> wrote:



The real problem is there are distinct use cases for both SLAAC and DHCPv6 and the people in charge of DHCPv6 keep screwing up. It should be possible to run either SLAAC/RA or DHCPv6 and have each offering provide the required information without having to run additional services just to get basic feature parity to IPv4. This is slowing implementation in enterprise networks.



james





On Tue, Mar 31, 2020 at 3:24 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On 31-Mar-20 23:17, Mark Tinka wrote:
>
>
> On 31/Mar/20 12:09, sthaug@nethelp.no wrote:
>
>> Note that there have been multiple requests for DHCPv6 to do this but
>> every attempt has been shot down.
>
> Yep - thankfully, we have an option.
>
> Operating two address assignment protocols is just silly.
>
> At my house, I don't even bother with DHCPv6 for DNS. I just use the
> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
> done with the purist madness around this.

There's purism (which I don't understand) and there's also historical
baggage that is incredibly hard to get rid of. As I have reminded from
time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
became a proven technology for IPv4 (i.e. many of us were still running
around manually assigning IPv4 addresses to newly installed Suns and
NCDs and the like). DHCPv6 was an afterthought.

Unfortunately, the purism has made it impossible to have a rational
discussion about engineering our way out of this historical duplication.

On 01-Apr-20 05:01, Gert Doering wrote:

...
> As soon as you have a larger routed network, mDNS falls short, and
> (unless you have a windows domain) there are no existing mechanisms
> to put a SLAAC v6 address into DNS...

I think there's no *deployed* mechanism. DynDNS is said to work in the
lab. There's also some hope that DNS-SD will alleviate this problem,
but only if it gets deployed.

> Yes, thanks, IETF. Well done.

It's not because nobody has tried. But the bridge between theory and
operations seems to be hard to cross.

On 01-Apr-20 07:21, James R Cutler wrote:

...
> Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking?

Well, duh. What we need is more people with real operational smarts
able to spend a lot of time and patience in the IETF. Yes, I know
why that is hard. (I had operation smarts once; no longer.) But that
is the only way we we can get a pragmatic approach into RFC text.

Don't worry about the travel budget, because the IETF is going to
have to do much more of its work remotely for the next couple of years
anyway. But the time and patience investment is substantial.

Stay well,
Brian Carpenter







**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

On Wed, Apr 01, 2020 at 09:29:45AM +0200, JORDI PALET MARTINEZ wrote:
> If you’re receiving the messages is because YOU subscribed to the list.

Not necessarily. Especially with the big freemailers, email accounts
sometimes change owners... where old owner didn't unsub from all mailing
lists, especially the low volume ones.

I've taken care of that.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Well, we can't know probably, but he must be able to unsubscribe by himself anyway ...

It is true however, that this list must follow GDPR, and this means having an explicit unsubscription link in the footer, which will also facilitate some people to unsubscribe (yes we know, even having that footer, some people is not "able" to read it).

Regards,
Jordi
@jordipalet



?El 1/4/20 9:46, "Daniel Roesen" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de dr@cluenet.de> escribió:

On Wed, Apr 01, 2020 at 09:29:45AM +0200, JORDI PALET MARTINEZ wrote:
> If you’re receiving the messages is because YOU subscribed to the list.

Not necessarily. Especially with the big freemailers, email accounts
sometimes change owners... where old owner didn't unsub from all mailing
lists, especially the low volume ones.

I've taken care of that.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

By the way ... I just realized that the list is not handling correctly DMARC users. So my own emails when they come back, go to the spam folder, which means they are going to the spam folder of many folks.

This was a problem with IETF and RIRs exploders and I believe they applied some patch or mailman/pipermail upgrade to resolve it.

?El 1/4/20 9:59, "JORDI PALET MARTINEZ" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de jordi.palet@consulintel.es> escribió:

Well, we can't know probably, but he must be able to unsubscribe by himself anyway ...

It is true however, that this list must follow GDPR, and this means having an explicit unsubscription link in the footer, which will also facilitate some people to unsubscribe (yes we know, even having that footer, some people is not "able" to read it).

Regards,
Jordi
@jordipalet



?El 1/4/20 9:46, "Daniel Roesen" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de dr@cluenet.de> escribió:

On Wed, Apr 01, 2020 at 09:29:45AM +0200, JORDI PALET MARTINEZ wrote:
> If you’re receiving the messages is because YOU subscribed to the list.

Not necessarily. Especially with the big freemailers, email accounts
sometimes change owners... where old owner didn't unsub from all mailing
lists, especially the low volume ones.

I've taken care of that.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.







**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

* JORDI PALET MARTINEZ

> It is true however, that this list must follow GDPR, and this means having an explicit unsubscription link in the footer

Which GDPR article requires that, exactly?

Tore

Hi Tore,

I've taken a quick look, because I don't know it by memory, but:

1) Before 25 May 2018, every EU citizen or resident must get a confirmation from any database holder with his personal data, to re-confirm the authorization. I'm not sure if that was done for this list. I believe this is art. 39 and some further text in the following articles.

2) Right to object. Art. 59, but also many others. It is not probably clearly said that it must be in a footer but it must be clearly available how to.

https://gdpr-info.eu/

I don't have any problem myself, but I think it is good for the host of the list to comply with GDPR, to avoid any DPA fine.

Regards,
Jordi
@jordipalet



?El 1/4/20 10:11, "Tore Anderson" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de tore@fud.no> escribió:

* JORDI PALET MARTINEZ

> It is true however, that this list must follow GDPR, and this means having an explicit unsubscription link in the footer

Which GDPR article requires that, exactly?

Tore




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> writes:

> 2) Right to object. Art. 59, but also many others. It is not probably clear=
> ly said that it must be in a footer but it must be clearly available how to=
> .
>
> https://gdpr-info.eu/
>
> I don't have any problem myself, but I think it is good for the host of the=
> list to comply with GDPR, to avoid any DPA fine.


This list has this in the header:

List-Id: IPv6 operators forum <ipv6-ops.lists.cluenet.de>
List-Unsubscribe: <http://lists.cluenet.de/mailman/listinfo/ipv6-ops>,
<mailto:ipv6-ops-request@lists.cluenet.de?subject=unsubscribe>
List-Archive: <http://lists.cluenet.de/pipermail/ipv6-ops>
List-Post: <mailto:ipv6-ops@lists.cluenet.de>
List-Help: <mailto:ipv6-ops-request@lists.cluenet.de?subject=help>
List-Subscribe: <http://lists.cluenet.de/mailman/listinfo/ipv6-ops>,
<mailto:ipv6-ops-request@lists.cluenet.de?subject=subscribe>


This is obviously more than sufficient.

There is not need to duplicate this in the footer to compensate for
buggy and user unfriendly email clients


Bjørn

I agree that it is sufficient for smart people, but I'm not sure if in case somebody is not smart and make a complain to the DPA, they will agree being sufficient.

I'm just fine either way, just making sure that the list responsible avoids troubles because non-smart (not to say stupid) people.

Regards,
Jordi
@jordipalet



?El 1/4/20 10:43, "Bjørn Mork" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de bjorn@mork.no> escribió:

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> writes:

> 2) Right to object. Art. 59, but also many others. It is not probably clear=
> ly said that it must be in a footer but it must be clearly available how to=
> .
>
> https://gdpr-info.eu/
>
> I don't have any problem myself, but I think it is good for the host of the=
> list to comply with GDPR, to avoid any DPA fine.


This list has this in the header:

List-Id: IPv6 operators forum <ipv6-ops.lists.cluenet.de>
List-Unsubscribe: <http://lists.cluenet.de/mailman/listinfo/ipv6-ops>,
<mailto:ipv6-ops-request@lists.cluenet.de?subject=unsubscribe>
List-Archive: <http://lists.cluenet.de/pipermail/ipv6-ops>
List-Post: <mailto:ipv6-ops@lists.cluenet.de>
List-Help: <mailto:ipv6-ops-request@lists.cluenet.de?subject=help>
List-Subscribe: <http://lists.cluenet.de/mailman/listinfo/ipv6-ops>,
<mailto:ipv6-ops-request@lists.cluenet.de?subject=subscribe>


This is obviously more than sufficient.

There is not need to duplicate this in the footer to compensate for
buggy and user unfriendly email clients


Bjørn




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

* JORDI PALET MARTINEZ

> I don't know it by memory

Huh. In that case, what do you base your claims about what the GDPR requires on, exactly?

> 1) Before 25 May 2018, every EU citizen or resident must get a confirmation from any database holder with his personal data, to re-confirm the authorization.

Not true.

Assuming the lawful grounds for processing is «consent» pursuant to article 6(1)(a) GDPR, and consent was given prior to 25th of May 2018 in a way that satisfies the requirements for consent pursuant to article 7 GDPR, then there is no need to ask the data subject to «re-confirm».

The process of subscribing to a mailing list does to me seem to constitute valid consent.

It would also be possible to instead the lawful grounds «necessary for the performance of a contract» pursuant to article 6(1)(b) GDPR, in which case valid consent is not required.

The lack of a privacy statement is likely a bigger problem as far as GDPR compliance is concerned.

> 2) Right to object. Art. 59, but also many others. It is not probably clearly said that it must be in a footer but it must be clearly available how to.

It is most definitively not mentioned in the article 59 GDPR because that article about annual activity reports issued by the supervisory authorities, so that one totally irrelevant here.

You are right that there is a right to object (article 21 GDPR). However that has absolutely nothing to say about mailing list footers either.

Tore

Bjørn Mork <bjorn@mork.no> writes:

> This list has this in the header:
>
> List-Id: IPv6 operators forum <ipv6-ops.lists.cluenet.de>
> List-Unsubscribe: <http://lists.cluenet.de/mailman/listinfo/ipv6-ops>,
> <mailto:ipv6-ops-request@lists.cluenet.de?subject=unsubscribe>
> List-Archive: <http://lists.cluenet.de/pipermail/ipv6-ops>
> List-Post: <mailto:ipv6-ops@lists.cluenet.de>
> List-Help: <mailto:ipv6-ops-request@lists.cluenet.de?subject=help>
> List-Subscribe: <http://lists.cluenet.de/mailman/listinfo/ipv6-ops>,
> <mailto:ipv6-ops-request@lists.cluenet.de?subject=subscribe>
>
>
> This is obviously more than sufficient.

people can't/won't read headers. Most mail clients hide them pretty
well. I guess that most people don't even konw they are there.

Jens
--
----------------------------------------------------------------------------
| Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@quux.de | --------------- |
----------------------------------------------------------------------------

Brian E Carpenter <brian.e.carpenter@gmail.com> writes:
> On 31-Mar-20 23:17, Mark Tinka wrote:
>
>> Operating two address assignment protocols is just silly.
>>
>> At my house, I don't even bother with DHCPv6 for DNS. I just use the
>> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
>> done with the purist madness around this.
>
> There's purism (which I don't understand) and there's also historical
> baggage that is incredibly hard to get rid of. As I have reminded from
> time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
> became a proven technology for IPv4 (i.e. many of us were still running
> around manually assigning IPv4 addresses to newly installed Suns and
> NCDs and the like). DHCPv6 was an afterthought.

Thanks! Knowing history is important when trying to understand.

> Unfortunately, the purism has made it impossible to have a rational
> discussion about engineering our way out of this historical duplication.

Is there a way out? Which doesn't involve time travel?

The obviously solution to the "too many protocols" problem is fewer
protocols. But we cannot really remove anything, can we? Only add.

So how do we get out of this? I vote for "accept that we have two
protocols, and stop whining".

Of course, you can do whatever you want in your home or anywhere else
where you manage both ends. And you can be arrogant and ignore one of
the protocols if you're big enough. You probably want to look up how
history has judged technical arrogance, though.

The rest of us we can live just fine with SLAAC+DHCPv6. Just remember
that it is so much better than SLAAC+DHCPv6+whatever.



Bjørn

?El 1/4/20 10:55, "Tore Anderson" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de tore@fud.no> escribió:

* JORDI PALET MARTINEZ

> I don't know it by memory

Huh. In that case, what do you base your claims about what the GDPR requires on, exactly?

> 1) Before 25 May 2018, every EU citizen or resident must get a confirmation from any database holder with his personal data, to re-confirm the authorization.

Not true.

Assuming the lawful grounds for processing is «consent» pursuant to article 6(1)(a) GDPR, and consent was given prior to 25th of May 2018 in a way that satisfies the requirements for consent pursuant to article 7 GDPR, then there is no need to ask the data subject to «re-confirm».

The process of subscribing to a mailing list does to me seem to constitute valid consent.

It would also be possible to instead the lawful grounds «necessary for the performance of a contract» pursuant to article 6(1)(b) GDPR, in which case valid consent is not required.

[Jordi] This is right *if* the list owner can demonstrate all the subscriptions. We don't know that.

The lack of a privacy statement is likely a bigger problem as far as GDPR compliance is concerned.


[Jordi] Agree, and my email intent was not to raise just if the list follows this or that GDPR article, but in general.


> 2) Right to object. Art. 59, but also many others. It is not probably clearly said that it must be in a footer but it must be clearly available how to.

It is most definitively not mentioned in the article 59 GDPR because that article about annual activity reports issued by the supervisory authorities, so that one totally irrelevant here.

You are right that there is a right to object (article 21 GDPR). However that has absolutely nothing to say about mailing list footers either.

Tore




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi,

On Wed, Apr 01, 2020 at 10:56:55AM +0200, Bj?rn Mork wrote:
> The rest of us we can live just fine with SLAAC+DHCPv6. Just remember
> that it is so much better than SLAAC+DHCPv6+whatever.

Maybe it's time for a unified SLAAC+DHCPv6 standard! Much better than
two competing standards!

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

On Wed, Apr 01, 2020 at 10:01:21AM +0200, Webmaster wrote:
> By the way ... I just realized that the list is not handling correctly
> DMARC users. So my own emails when they come back, go to the spam
> folder, which means they are going to the spam folder of many folks.

One could argue that this is the problem of the DMARC user, expecting
the world to adjust to their personal believe how to combat the
deficiencies of email.

But I don't. :)

FYI, you're the first to complain/note a DMARC issue with the lists I'm
hosting (with >10k subs), so doesn't seem to be a widespread problem
yet.

> This was a problem with IETF and RIRs exploders and I believe they
> applied some patch or mailman/pipermail upgrade to resolve it.

I'm working on upgrading Mailman in the coming weeks and will also
revisit DMARC and other stuff at that point.


Best regards,
Daniel

PS: btw, you're posting as "webmaster@" - rly?

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Wed, Apr 01, 2020 at 10:56:03AM +0200, Jens Link wrote:
> people can't/won't read headers. Most mail clients hide them pretty
> well. I guess that most people don't even konw they are there.

Correct, but appending footers is a problem with cryptographic
signatures, so a pretty much no-go too.

There is the the issue of email address ownership changing to
"non-enlightened" folks, as well as malware out there actually able to
perform double opt-in subscription to Mailman lists via email. I've seen
it happen. So there ARE unsuspecting, innocent people ending up
subscribed here who have ZERO idea how they got here, nor how they get
off the list.

I have to clue myself up how other list ops deal with that.
But I see that there is certainly no "magic bullet" that doesn't have
severe drawbacks. Email is becoming more and more unusable due to the
defensive measures being taken against spam, phishing and other
malicious use of email.

On a side note to all: I would prefer not to prolong this discussion
here so much as it's quite off-topic. At minimum open a new thread (a
new thread, not just change subject) so people have a chance to filter.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

The problem is that you only realize about the DMARC problem is you "verify" your own emails when they come back from the list and you have configured the list to also send back the emails to you ...

Otherwise it passes unadvertised, but some people don't get emails from people that uses DMARC in strict mode, use gmail or yahoo, etc.

Not a complain, just to it is not "unadvertised".

Regards,
Jordi
@jordipalet



?El 1/4/20 12:47, "Daniel Roesen" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de dr@cluenet.de> escribió:

On Wed, Apr 01, 2020 at 10:01:21AM +0200, Webmaster wrote:
> By the way ... I just realized that the list is not handling correctly
> DMARC users. So my own emails when they come back, go to the spam
> folder, which means they are going to the spam folder of many folks.

One could argue that this is the problem of the DMARC user, expecting
the world to adjust to their personal believe how to combat the
deficiencies of email.

But I don't. :)

FYI, you're the first to complain/note a DMARC issue with the lists I'm
hosting (with >10k subs), so doesn't seem to be a widespread problem
yet.

> This was a problem with IETF and RIRs exploders and I believe they
> applied some patch or mailman/pipermail upgrade to resolve it.

I'm working on upgrading Mailman in the coming weeks and will also
revisit DMARC and other stuff at that point.


Best regards,
Daniel

PS: btw, you're posting as "webmaster@" - rly?

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Since this has turned into a thread complaining about following rules, how about taking the discussion about email somewhere more appropriate, https://www.mailop.org/, and stay on topic about IPv6 on an IPv6 mail list!

Thanks...

> -----Original Message-----
> From: ipv6-ops-bounces+rwebb=ropeguru.com@lists.cluenet.de <ipv6-ops-
> bounces+rwebb=ropeguru.com@lists.cluenet.de> On Behalf Of JORDI PALET
> MARTINEZ
> Sent: Wednesday, April 1, 2020 7:08 AM
> To: Daniel Roesen <dr@cluenet.de>; ipv6-ops@lists.cluenet.de
> Subject: Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
>
> The problem is that you only realize about the DMARC problem is you
> "verify" your own emails when they come back from the list and you have
> configured the list to also send back the emails to you ...
>
> Otherwise it passes unadvertised, but some people don't get emails from
> people that uses DMARC in strict mode, use gmail or yahoo, etc.
>
> Not a complain, just to it is not "unadvertised".
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> ?El 1/4/20 12:47, "Daniel Roesen" <ipv6-ops-
> bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de
> dr@cluenet.de> escribió:
>
> On Wed, Apr 01, 2020 at 10:01:21AM +0200, Webmaster wrote:
> > By the way ... I just realized that the list is not handling correctly
> > DMARC users. So my own emails when they come back, go to the spam
> > folder, which means they are going to the spam folder of many folks.
>
> One could argue that this is the problem of the DMARC user, expecting
> the world to adjust to their personal believe how to combat the
> deficiencies of email.
>
> But I don't. :)
>
> FYI, you're the first to complain/note a DMARC issue with the lists I'm
> hosting (with >10k subs), so doesn't seem to be a widespread problem
> yet.
>
> > This was a problem with IETF and RIRs exploders and I believe they
> > applied some patch or mailman/pipermail upgrade to resolve it.
>
> I'm working on upgrading Mailman in the coming weeks and will also
> revisit DMARC and other stuff at that point.
>
>
> Best regards,
> Daniel
>
> PS: btw, you're posting as "webmaster@" - rly?
>
> --
> CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of the
> individual(s) named above and further non-explicilty authorized disclosure,
> copying, distribution or use of the contents of this information, even if
> partially, including attached files, is strictly prohibited and will be considered a
> criminal offense. If you are not the intended recipient be aware that any
> disclosure, copying, distribution or use of the contents of this information,
> even if partially, including attached files, is strictly prohibited, will be
> considered a criminal offense, so you must reply to the original sender to
> inform about this communication and delete it.
>
>

James R Cutler wrote on 31/03/2020 19:21:
> Wouldn’t it be more cost effect in the long term to simply make SLAAC
> and DHCPv6 cooperative and complementary attributes of end-to-end
> networking?

DHCPv6 lacks a tiny handful of features to make it fully independent of
SLAAC: a default route option and the network prefix would be the most
important of these, but it also lacks a prefix length option and an
option for specifying MTU. Other than the lack of these features, there
is no technical reason that DHCPv6 couldn't be fully standalone.

The prevailing sentiment expressed at the various IETF groups where this
has formally been discussed (mif, dhc, v6ops, 6man) is that there is no
requirement for DHCPv6 to have these features because they already exist
in ND, and as ND is necessary for DHCPv6 to work already, it would be
pointless and confusing to duplicate the functionality in DHCPv6.

As an aside, the concerns about duplicating functionality often do not
apply to SLAAC, RDNSS being a good example, and pref64. The ambivalence
here is surprising, particularly considering that some peoples'
arguments about whether duplicated functionality is acceptable seems to
change depending on which protocol they're advocating at the time.

There are several reasons that people shout about DHCPv6:

- protocol purity: minimalist protocols are better, so the fewer options
each protocol has, the simpler things are. That's fine as far as it
goes, but we need to overlook that that horse bolted over 20 years ago,
settled down, and had foals, a mortgage and car loan, but yet people are
still insistent that the barn door ought to be kept closed on principal.

- technical distaste: lots of reasons here; some understandable (e.g.
cannot force state changes on dhcp client devices unless the client
requests an update), and some not (it allows the operator to force their
networking policies on you, like omg, as if you're not already subject
to a network operator's policies to start with). The consequence of
this is that there is an extraordinarily long history at the IETF of
people dissing DHCP which goes right back to the earliest days of
dhcpv4. No-one claims that DHCP is perfect, but it's a reasonably good
solution for many use cases.

- 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). This argument has been carried into the IETF on the basis that
any attempt to make dhcpv6 a standalone protocol should be resisted in
all cases because this will hand too much control over to the operator -
never mind the fact that it is arguably only relevant on cellular
connections, which are defined by 3GPP rather than the IETF.

Obviously if the Android people refuse to implement DHCPv6 for reasons
which make sense to their specific use-cases, then it's in their
interests to ensure that standalone DHCPv6 does not ever become a viable
option, because that would undermine their ability to continue to refuse
to implement DHCPv6.

- "I don't need it, therefore you can't have it". Related closely to
the previous point, this is one of the most thoroughly disappointing
positions to take because it screws over other dhcpv6 deployment
scenarios with scathing regard to their technical or operational
validity. This is routinely accompanied by straw-man technical
alternatives and/or disingenuous lines of questioning, leading to claims
of lack of consensus, often by the people doing the shouting-down.

Another recurrent line of argument there is where people successfully
run SLAAC on their home / lab / local networks, and then incorrectly
extrapolate that because their requirements are fulfilled by SLAAC's
feature sets, everyone else should be fine too.

Ultimately, operators would prefer the ability to make their own choices
about how to manage their own network.

If DHCPv6 had the features above, then this whole sorry debate could
finally be put to bed and everyone could move on with their lives.
SLAAC people could use SLAAC to their heart's content, and operators who
preferred DHCP could use DHCP. However, the current state of play at
the IETF is blocking this from happening.

It's also not helped that several ietf WG chairs have made it clear that
they don't want the issue reappearing on their WGs because it causes too
much shouting.

Engineering / cost concerns play little to no part in the debate.

Nick

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

Steinar Haug, AS2116

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

IA_PD 'works' (for small values of works) for hosts today.

The upstream interface of a CPE is defined as a host instead of a router.

The big gap in IA_PD is that it doesn't specify how routing is supposed to
work. This is fine if IA_PD happens between routers and all routers have a
common routing protocol.

For IA_PD to hosts, including CPEs, there is a varity of hacks to install
the prefix in the FIB of the access router.

On Wed, Apr 1, 2020 at 9:03 PM Nick Hilliard <nick@foobar.org> wrote:

> - 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). This argument has been carried into the IETF on the basis that
> any attempt to make dhcpv6 a standalone protocol should be resisted in
> all cases because this will hand too much control over to the operator -
> never mind the fact that it is arguably only relevant on cellular
> connections, which are defined by 3GPP rather than the IETF.
>

FWIW I think you're misreading that issue. The actual arguments against
IA_NA are stated in RFC 7934. They don't have much or anything to do with
mobile networks, who have widely deployed (and, as far as I can tell, are
happy with) SLAAC.

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.

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

> 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

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

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

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