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

[Sander Steffann]

Hi Ole,

> Op 2 apr. 2020, om 12:10 heeft otr...@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



signature.asc
Description: Message signed with OpenPGP

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

[Brian E Carpenter]

At the risk of repeating myself, if ops people like this approach
then they need to engage in constructive discussion of it in the IETF.

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

Regards
   Brian

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

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

[Philip Homburg]

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

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

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

Can you eleborate on the too small part.

Of course, we are talking about averages. There may be some big VM hosts
that may need more. Some simple devices may not need any /64.

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

[otroan]

> DHCPv6-PD works, and AFAIK it is implemented by every vendor wanting to
> be taken seriously.
> 
> HNCP probably works too.  Time will tell, if/when it is actually
> implemented at a scale making it possible to test it outside the lab.
> 
> HNCP is currently irrelevant wrt end host addressing.  It depends on
> either DHCPv6 or SLAAC there.

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

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

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

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

Cheers,
Ole

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

[otroan]

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

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

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

Best regards,
Ole

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

[Bjørn Mork]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> So 

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

[Lorenzo Colitti]

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

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

You don't need to hand a /40 to every enterprise that asks for it. The
address space necessary can be roughly extrapolated from how much private
IPv4 space is in use. There are some numbers to this effect in RFC 7934
section 9.2 .

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

[Gert Doering]

Hi,

On Thu, Apr 02, 2020 at 10:44:04AM +0200, Philip Homburg wrote:
> >So you need to somehow build a prefix distribution mechanism, so people
> >can have an arbitrary number of PD prefixes in "wherever network they=20
> >happen to be".  So we're back to multi-level PD, with all the challenges
> >(firewall rules, ACLs, internal routing, ...).  And even then, a /48
> >might no longer be sufficient for a company with, say, 500 internal
> >network segments and 40.000 employees - where it would be extremely=20
> >spacious otherwise.
> 
> Independent of the prefix distribution mechanism, it may be worth revisiting
> having a single /48 for an organisation of 4 employees.

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

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

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

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

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

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

[Philip Homburg]

>So you need to somehow build a prefix distribution mechanism, so people
>can have an arbitrary number of PD prefixes in "wherever network they=20
>happen to be".  So we're back to multi-level PD, with all the challenges
>(firewall rules, ACLs, internal routing, ...).  And even then, a /48
>might no longer be sufficient for a company with, say, 500 internal
>network segments and 40.000 employees - where it would be extremely=20
>spacious otherwise.

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

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

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

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

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

That leaves homenet as the most complex dynamic case: potentially multiple
layers of routers that should configure automatically. However, in the homenet
case, the network is typically small enough that keeping track of individual
/64s is possible. So PD where each request is a /64 could very well work.
(I'm not trying to express an opinion on HNCP here)

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

[Gert Doering]

Hi,

On Thu, Apr 02, 2020 at 05:24:34AM -0300, Fernando Gont wrote:
> > As far as I understand, the official IETF recommendation for "how to
> > run a home with multiple subnets" is "homenet / HNCP" now, which distributes
> > individual /64s via HNCP, not whole prefixes via DHCPv6-PD.
> I haven't been following homenet, to be honest. Is it widely implemented?

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

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


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

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

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

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


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

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

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

But what when they roam to LTE in between?


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

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

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

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

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

[Ivan Pepelnjak]

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

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

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

Ivan

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

[Fernando Gont]

On 2/4/20 03:19, Gert Doering wrote:

Hi,

On Thu, Apr 02, 2020 at 12:09:34AM -0300, Fernando Gont wrote:

On 1/4/20 14:16, Gert Doering wrote:
[...]

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


Would you mind elaborating on this one?


Which of the two parts? :-)

As far as I understand, the official IETF recommendation for "how to
run a home with multiple subnets" is "homenet / HNCP" now, which distributes
individual /64s via HNCP, not whole prefixes via DHCPv6-PD.


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




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

On the "why is this a bad idea to start with" side, the chunkiness of
subnet distribution makes it really unsuitable for anything but the most
simple 1-level hierarchy.


So, ISP-to-customer, delegates a /56.  Next-level router asks for a prefix,
and gets... what?  Third-level router asks for a prefix, and gets what?


I guess a % of what was originally leased?

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


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


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


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





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


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




Now, abandon the idea of "multi-level" DHCPv6-PD, and just assume "all
you'll ever see is mobile clients asking for a single /64" (which, as
I heard, is thinking too small, because you can have stacks of stacks,
but stick to the /64 for the moment).  Normally, you'd assign a /64 per
network segment - office LAN floor 1, 2, 3, guest LAN, etc. - and have
(effectively) an infinite number of addresses for more machines than
you can ever connect. 


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


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

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

[Gert Doering]

Hi,

On Thu, Apr 02, 2020 at 12:09:34AM -0300, Fernando Gont wrote:
> On 1/4/20 14:16, Gert Doering wrote:
> [...]
> > Even IETF discontinued recommending DHCPv6-PD for "inside a home network",
> > because it doesn't work.
> 
> Would you mind elaborating on this one?

Which of the two parts? :-)

As far as I understand, the official IETF recommendation for "how to 
run a home with multiple subnets" is "homenet / HNCP" now, which distributes
individual /64s via HNCP, not whole prefixes via DHCPv6-PD.

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

On the "why is this a bad idea to start with" side, the chunkiness of 
subnet distribution makes it really unsuitable for anything but the most
simple 1-level hierarchy.  


So, ISP-to-customer, delegates a /56.  Next-level router asks for a prefix,
and gets... what?  Third-level router asks for a prefix, and gets what?

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

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

So you need to somehow build a prefix distribution mechanism, so people
can have an arbitrary number of PD prefixes in "wherever network they 
happen to be".  So we're back to multi-level PD, with all the challenges
(firewall rules, ACLs, internal routing, ...).  And even then, a /48
might no longer be sufficient for a company with, say, 500 internal
network segments and 40.000 employees - where it would be extremely 
spacious otherwise.


Could this be made to work?  Possibly.

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

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

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

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

[sthaug]

>> We are already 90% of the way here: Make IA_PD work for hosts, not
>> just for routers. That way Android handsets can have as many addresses
>> as they want.
> 
> You mean e.g. support IA_PD at CPEs on the LAN side?

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

Steinar Haug, AS2116

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

[Fernando Gont]

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

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

[Fernando Gont]

On 1/4/20 09:12, sth...@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: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

[Gert Doering]

Hi,

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

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

[Ola Thoresen]

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


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

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

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



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


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


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



/Ola (T)

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

[Gert Doering]

Hi,

On Wed, Apr 01, 2020 at 05:53:02PM +0200, Bjørn Mork wrote:
> Lorenzo Colitti  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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

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

[Bjørn Mork]

Lorenzo Colitti  writes:

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

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


Bjørn

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

[sthaug]

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

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

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

Steinar Haug, AS2116

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

[Lorenzo Colitti]

On Wed, Apr 1, 2020 at 9:12 PM  wrote:

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

DHCPv6 PD is one of the means suggested by RFC 7934, yes. I'm not sure that
the folks asking for IA_NA would be happy with IA_PD though. The reason
most often cited for wanting DHCPv6 is that it fits well with tracking
practices and systems that are built to support on-request addressing and
networks assigning individual IP address(es) to devices. DHCPv6 PD provides
request-based addressing, but it wouldn't do much to interoperate with
those tracking systems because they deal with addresses, not subnets. From
that perspective, ND snooping might be more likely to interoperate well.

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

[Philip Homburg]

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

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

[sthaug]

> 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

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

[JORDI PALET MARTINEZ]

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" 
 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: d...@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.

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

[Robert Webb]

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@lists.cluenet.de  bounces+rwebb=ropeguru@lists.cluenet.de> On Behalf Of JORDI PALET
> MARTINEZ
> Sent: Wednesday, April 1, 2020 7:08 AM
> To: Daniel Roesen ; 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"  bounces+jordi.palet=consulintel...@lists.cluenet.de en nombre de
> d...@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: d...@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.
> 
> 

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

[Daniel Roesen]

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: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

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

[Webmaster]

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" 
 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" 
 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: d...@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.

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

[Daniel Roesen]

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: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Re: GDPR issues of mailing lists ? - Was: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Mohácsi János]

Sorry. RFC8058 and/or RFC 2369

On 2020. 04. 01. 10:50, Janos Mohacsi wrote:

Hi Jordi,

In  my opinion to adhere the GDPR regulations each mailing list (maybe 
mailing list operator) should have a data management policy and implement some 
simple rules. The data management policy  should be made available during the 
subscription. If anything changes in the regulation or in the policy all 
subscribed users should be notified and allow them to unsubscribe. 
Unsubscription can be done with any mail receiving from the particular mailing 
list  since the modern mailing list managers follow the RFC 8058 


Regards,
Janos Mohacsi

On 2020. 04. 01. 10:33, JORDI PALET MARTINEZ wrote:

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" 

 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.





--
János Mohácsi
International R Officer
GÉANT activity coordinator in Hungary, EOSC GB member

T: +36 30 555 7599
mohacsi.ja...@kifu.gov.hu

Kormányzati Informatikai Fejlesztési Ügynökség

--
János Mohácsi
International R Officer
GÉANT activity coordinator in Hungary, EOSC GB member

T: +36 30 555 7599
mohacsi.ja...@kifu.gov.hu

Kormányzati Informatikai Fejlesztési Ügynökség



Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a 
nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az általa 
meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy kérjük, 
hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és törölje 
az üzenetet, valamint annak összes csatolt mellékletét a rendszeréből. Ha Ön 
nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely 
csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel 
közölnie vagy azzal visszaélnie.

This message and any attachment are confidential and are legally privileged. It 
is intended solely for the use of the individual or entity to whom it is 
addressed and others authorised to receive it. If you are not the intended 
recipient, please telephone or email the sender and delete this message and any 
attachment from your system. Please note that any dissemination, distribution, 
copying or use of or reliance upon the information contained in and transmitted 
with this e-mail by or to anyone other than the recipient designated above by 
the sender is unauthorised and strictly prohibited.

GDPR issues of mailing lists ? - Was: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Mohácsi János]

Hi Jordi,

In  my opinion to adhere the GDPR regulations each mailing list (maybe 
mailing list operator) should have a data management policy and implement some 
simple rules. The data management policy  should be made available during the 
subscription. If anything changes in the regulation or in the policy all 
subscribed users should be notified and allow them to unsubscribe. 
Unsubscription can be done with any mail receiving from the particular mailing 
list  since the modern mailing list managers follow the RFC 8058 


Regards,
Janos Mohacsi

On 2020. 04. 01. 10:33, JORDI PALET MARTINEZ wrote:

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" 

 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.





--
János Mohácsi
International R Officer
GÉANT activity coordinator in Hungary, EOSC GB member

T: +36 30 555 7599
mohacsi.ja...@kifu.gov.hu

Kormányzati Informatikai Fejlesztési Ügynökség



Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a 
nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az általa 
meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy kérjük, 
hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és törölje 
az üzenetet, valamint annak összes csatolt mellékletét a rendszeréből. Ha Ön 
nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely 
csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel 
közölnie vagy azzal visszaélnie.

This message and any attachment are confidential and are legally privileged. It 
is intended solely for the use of the individual or entity to whom it is 
addressed and others authorised to receive it. If you are not the intended 
recipient, please telephone or email the sender and delete this message and any 
attachment from your system. Please note that any dissemination, distribution, 
copying or use of or reliance upon the information contained in and transmitted 
with this e-mail by or to anyone other than the recipient designated above by 
the sender is unauthorised and strictly prohibited.

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

[JORDI PALET MARTINEZ]

El 1/4/20 10:55, "Tore Anderson" 
 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.

Re: GDPR issues of mailing lists ? - Was: Why used DHCPv6 when RA has RDNSS and DNSSL?

[JORDI PALET MARTINEZ]

Exactly, and I don’t think this data management policy, and GDPR compliance has 
been published in the list, and is available in the list web site when you 
register, etc.

 

The RFC is good, but GDPR is “agnostic” of RFCs … The DPA can say, even if you 
are RFC-folks, the list is open for any other folks to subscribe, and they 
don’t need to know that the list unsubscribe info is in the header, they may 
not even know how to see the header …

 

Believe me, I got similar resposes from the DPAs around the EU. 

 

Regards,

Jordi

@jordipalet

 

 

 

El 1/4/20 10:50, "Mohácsi János"  escribió:

 

Hi Jordi, 

In  my opinion to adhere the GDPR regulations each mailing list (maybe 
mailing list operator) should have a data management policy and implement some 
simple rules. The data management policy  should be made available during the 
subscription. If anything changes in the regulation or in the policy all 
subscribed users should be notified and allow them to unsubscribe. 
Unsubscription can be done with any mail receiving from the particular mailing 
list  since the modern mailing list managers follow the RFC 8058 

Regards, 

Janos Mohacsi 

 

On 2020. 04. 01. 10:33, JORDI PALET MARTINEZ wrote:
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" 
 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.
 
 
 
-- 
János Mohácsi
International R Officer
GÉANT activity coordinator in Hungary, EOSC GB member   
 
T: +36 30 555 7599
mohacsi.ja...@kifu.gov.hu
 
Kormányzati Informatikai Fejlesztési Ügynökség
 


Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a 
nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az általa 
meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy kérjük, 
hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és törölje 
az üzenetet, valamint annak összes csatolt mellékletét a rendszeréből. Ha Ön 
nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely 
csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel 
közölnie vagy azzal visszaélnie.

This message and any attachment are confidential and are legally privileged. It 
is intended solely for the use of the individual or entity to whom it is 
addressed and others authorised to receive it. If you are not the intended 
recipient, please telephone or email the sender and delete this message and any 
attachment from your system. Please note that any dissemination, distribution, 
copying or use of or reliance upon the information contained in and transmitted 
with this e-mail by or to anyone other than the recipient designated above by 
the sender is unauthorised and strictly prohibited.




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

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

[JORDI PALET MARTINEZ]

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" 
 escribió:

JORDI PALET MARTINEZ  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 
List-Unsubscribe: ,

List-Archive: 
List-Post: 
List-Help: 
List-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.

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

[Gert Doering]

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

Re: GDPR issues of mailing lists ? - Was: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Gert Doering]

Hi,

On Wed, Apr 01, 2020 at 10:56:09AM +0200, JORDI PALET MARTINEZ wrote:
> The RFC is good, but GDPR is ???agnostic??? of RFCs ??? The DPA can say, even 
> if you are RFC-folks, the list is open for any other folks to subscribe, and 
> they don???t need to know that the list unsubscribe info is in the header, 
> they may not even know how to see the header ???

This domain is called "cluenet.de", it implies "can quote, and understands
e-mail".  No?

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

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

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

[Bjørn Mork]

Brian E Carpenter  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

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

[Jens Link]

Bjørn Mork  writes:

> This list has this in the header:
>
> List-Id: IPv6 operators forum 
> List-Unsubscribe: ,
>   
> List-Archive: 
> List-Post: 
> List-Help: 
> List-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: jensl...@quux.de| ---  | 

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

[Tore Anderson]

* 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

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

[JORDI PALET MARTINEZ]

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

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

[Bjørn Mork]

JORDI PALET MARTINEZ  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 
List-Unsubscribe: ,

List-Archive: 
List-Post: 
List-Help: 
List-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

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

[JORDI PALET MARTINEZ]

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" 
 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: d...@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.

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

[Tore Anderson]

* 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

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

[Daniel Roesen]

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: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

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

[JORDI PALET MARTINEZ]

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

    

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 1/4/20 6:08, "Sunita Badiga" 
 escribió:

 

STOP FUCKING EMAILING ME 

 

UNSUBSCRIBE



On Mar 31, 2020, at 8:35 PM, james machado  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  
wrote:

On 31-Mar-20 23:17, Mark Tinka wrote:
> 
> 
> On 31/Mar/20 12:09, sth...@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.

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

[Gert Doering]

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


signature.asc
Description: PGP signature

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

[james machado]

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.carpen...@gmail.com> wrote:

> On 31-Mar-20 23:17, Mark Tinka wrote:
> >
> >
> > On 31/Mar/20 12:09, sth...@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
>
>
>
>

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

[Lorenzo Colitti]

On Wed, Apr 1, 2020 at 4:03 AM Gert Doering  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

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.

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

[indrules]

Unsubscribe 

> On Mar 31, 2020, at 5:34 PM, Brian E Carpenter  
> wrote:
> 
> On 31-Mar-20 23:17, Mark Tinka wrote:
>> 
>> 
>>> On 31/Mar/20 12:09, sth...@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
> 
> 
> 

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

[Brian E Carpenter]

On 31-Mar-20 23:17, Mark Tinka wrote:
> 
> 
> On 31/Mar/20 12:09, sth...@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

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

[Fernando Gont]

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

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

[Gert Doering]

Hi,

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


signature.asc
Description: PGP signature

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

[Fernando Gont]

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

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

[Fernando Gont]

On 31/3/20 07:09, sth...@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: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

[James R Cutler]

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.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net



> On Mar 31, 2020, at 12:01 PM, Gert Doering  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 14Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

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

[Gert Doering]

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

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

[ignatios]

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

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

[Roger Wiklund]

Thanks for all the feedback

I also run dual stack with SLAAC for IPv6 assignment and my IPv4 DNS
servers resolve the  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  wrote:

>
>
> On 31/Mar/20 12:09, sth...@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.
>

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

[Mark Tinka]

On 31/Mar/20 12:09, sth...@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.

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

[Mark Tinka]

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.

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

[Tim Chown]

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 
mailto:brian.e.carpen...@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:: 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!

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

[Fernando Gont]

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

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

[Brian E Carpenter]

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

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

[Enno Rey]

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

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

[James R Cutler]

> On Mar 30, 2020, at 8:30 PM, 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:: 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
 

 (nota bene: I have not checked this on my Catalina systems due to time 
constraints.)


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

Why used DHCPv6 when RA has RDNSS and DNSSL?

[Roger Wiklund]

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