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.