Mailing List Archive

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

james


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

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

STOP FUCKING EMAILING ME

UNSUBSCRIBE

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

STOP FUCKING EMAILING ME

UNSUBSCRIBE

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

Hi,

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

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

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

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

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

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

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



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



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



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



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

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





Regards,

Jordi

@jordipalet







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



STOP FUCKING EMAILING ME



UNSUBSCRIBE



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



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



james





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

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

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

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

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

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

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

> Yes, thanks, IETF. Well done.

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

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

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

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

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

Stay well,
Brian Carpenter







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

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

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

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

I've taken care of that.


Best regards,
Daniel

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

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

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

Regards,
Jordi
@jordipalet



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

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

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

I've taken care of that.


Best regards,
Daniel

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




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

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

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

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

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

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

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

Regards,
Jordi
@jordipalet



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

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

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

I've taken care of that.


Best regards,
Daniel

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




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

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







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

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

* JORDI PALET MARTINEZ

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

Which GDPR article requires that, exactly?

Tore

Hi Tore,

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

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

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

https://gdpr-info.eu/

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

Regards,
Jordi
@jordipalet



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

* JORDI PALET MARTINEZ

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

Which GDPR article requires that, exactly?

Tore




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

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

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

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


This list has this in the header:

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


This is obviously more than sufficient.

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


Bjørn

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

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

Regards,
Jordi
@jordipalet



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

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

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


This list has this in the header:

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


This is obviously more than sufficient.

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


Bjørn




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

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

* JORDI PALET MARTINEZ

> I don't know it by memory

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

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

Not true.

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

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

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

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

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

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

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

Tore

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

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

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

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

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

Thanks! Knowing history is important when trying to understand.

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

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

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

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

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

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



Bjørn

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

* JORDI PALET MARTINEZ

> I don't know it by memory

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

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

Not true.

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

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

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

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

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


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


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

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

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

Tore




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

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

Hi,

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

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

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

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

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

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

But I don't. :)

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

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

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


Best regards,
Daniel

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

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

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

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

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

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

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


Best regards,
Daniel

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

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

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

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

Regards,
Jordi
@jordipalet



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

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

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

But I don't. :)

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

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

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


Best regards,
Daniel

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

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




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

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

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

Thanks...

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

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

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

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

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

There are several reasons that people shout about DHCPv6:

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

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

- politics: probably the most contentious area. One well-known example
is how ipv6 on cellular impacts carrier vs handset control politics.
3GPP specifies that the ppp context for tethering must support SLAAC and
therefore it provides a /64 for LAN connectivity. This means that the
handset applications have as much address space as they need. The
argument goes that if DHCPv6 were a viable option for this, then the
mobile operators would effectively wrestle control of the applications
running on the handset (and ultimately control of the handset
capabilities itself away from the handset software vendors) by handing
control of the number of available IPv6 addresses to the cellular
operator. This is, at least, the reason cited by the Android authors
for the point-blank refusal to implement DHCPv6 in android (bug ID
32621). This argument has been carried into the IETF on the basis that
any attempt to make dhcpv6 a standalone protocol should be resisted in
all cases because this will hand too much control over to the operator -
never mind the fact that it is arguably only relevant on cellular
connections, which are defined by 3GPP rather than the IETF.

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

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

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

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

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

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

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

Nick

> There are several reasons that people shout about DHCPv6:
...
> - politics: probably the most contentious area. One well-known example
> - is how ipv6 on cellular impacts carrier vs handset control
> - politics. 3GPP specifies that the ppp context for tethering must
> - support SLAAC and therefore it provides a /64 for LAN
> - connectivity. This means that the handset applications have as much
> - address space as they need. The argument goes that if DHCPv6 were a
> - viable option for this, then the mobile operators would effectively
> - wrestle control of the applications running on the handset (and
> - ultimately control of the handset capabilities itself away from the
> - handset software vendors) by handing control of the number of
> - available IPv6 addresses to the cellular operator. This is, at least,
> - the reason cited by the Android authors for the point-blank refusal to
> - implement DHCPv6 in android (bug ID 32621).

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

Steinar Haug, AS2116

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

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

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

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

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

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

> - politics: probably the most contentious area. One well-known example
> is how ipv6 on cellular impacts carrier vs handset control politics.
> 3GPP specifies that the ppp context for tethering must support SLAAC and
> therefore it provides a /64 for LAN connectivity. This means that the
> handset applications have as much address space as they need. The
> argument goes that if DHCPv6 were a viable option for this, then the
> mobile operators would effectively wrestle control of the applications
> running on the handset (and ultimately control of the handset
> capabilities itself away from the handset software vendors) by handing
> control of the number of available IPv6 addresses to the cellular
> operator. This is, at least, the reason cited by the Android authors
> for the point-blank refusal to implement DHCPv6 in android (bug ID
> 32621). This argument has been carried into the IETF on the basis that
> any attempt to make dhcpv6 a standalone protocol should be resisted in
> all cases because this will hand too much control over to the operator -
> never mind the fact that it is arguably only relevant on cellular
> connections, which are defined by 3GPP rather than the IETF.
>

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