Jordi Palet Martinez

I think you may be partially right in the sense that, if they really don't use the bump-in-the-api for the tethering as well, but it may be some time ago, not now, as they use bump-in-the-host in the most recent versions of the OSs, as part of the Happy Eyeball v2, which is becoming an RFC in a matter of days: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis Anyway, I think Apple folks confirmed to me (I will try to verify and come back here), that they do bump-in-the-host also for the tethering. What I don't agree is that you actually need multiple APNs. You can configure a *single* APN for multiple type of devices/configurations, with different PDP types. I've explained that in one of my slides (41) in the recent https://ripe75.ripe.net/presentations/44-ipv6-cellular_v6.pdf.

“Hi Jordi, Many thanks for your question, which is very interesting! I believe that the answer to your question lies in the national data protection laws of the countries involved in the sending and receiving of the spam emails. My understanding is that unfortunately there isn’t a universal jurisdictional rule that all the States follow to regulate the sending of spam emails. Therefore, each State decides how to regulate this subject matter and how broad the territorial scope of their national laws is. In your example, Spain and the US are the countries where the receivers of the spam emails are located. In Spain, the Act 34/2002 on Information Society Services and E-Commerce applies to the ISPs that are established in Spain, established in a Member State of the EU/the European Economic Space or that are outside the EU but target Spanish market/Spanish Internet users. This is valid irrespective of where both the company sending the spam emails and the server from where the emails were originally sent are located. The same goes for the EU General Data Protection Regulation, which will apply in May 2018. The regulation applies to the processing of personal data of Internet users established within the EU, irrespective of the location of the data controller. Therefore, the jurisdictional approach taken in the Spanish and the EU Regulation case is that of the users/market targeted by the spam email, rather than that of the country where the servers are located. Anyway, I am afraid that I am not a specialist in data protection laws, therefore please take my answer with a pinch of salt. Just my two pennies.”

Thanks a lot for your response. I think we agree on that. I know very well the Spanish LOPD, LSSI and the new GDPR, however, I still fail to see if "Internet users established within the EU" means 1) "EU citizens", or 2) "Somebody living in EU" (regardless of its citizenship), or 3) "If you are receiving that email while your are traveling within the EU (regardless of your citizenship)". My guess is that the right answer is 2, but I'm not a lawyer ;-)

Hi Sara, Thanks for the article, very interesting and in fact I'm very curious about this topic. I've a question for you, if you can provide your opinion. Let's take this example. A person or organization is sending spam from servers in country "x", to (for example) a server located in Spain. The spammed users are some of them Spanish citizens and living in Spain, others are US citizens living there. My belief is that the jurisdiction that apply here is the one where the spam is being "received" at the final destination (so Spain and US in those examples). But may be is not like that and it apply the jurisdiction of where the "destination" email server is located? Or it is the jurisdiction of the IP of the "sender" email server? Thanks in advance!

“In general, I do think the article of Jordi Palet Martinez is a useful one. I did prior, as a program manager, most of the implementation of IPv6 within a large Dutch ISP. Most of the really important topics for a successful implementation, I think, are mentioned in this article. But in regards to this, I would like to emphasise the following: - When starting an implementation, both mindset and knowledge about IPv6 are really important. Off course, together with a lot of mission work towards all layers of management concerning the necessity to implement IPv6. - Do the IPv6 implementation with a bottom-up approach. Most complexity and functionality is in the CPE. It’s a service endpoint and is a point of vulnerability from security perspective. Test IPv6 on your CPE's first in a lab environment in conjunction with the supplier/vendor. Use it for the technicians to get acquainted with IPv6 and it’s behaviour. Like always: Start on cracking the hardest nut first! For projects with a commercial justification (Business Case) like IPv6, it’s important to keep up the pace. Always avoid losing priority over other projects! - Involve the security department from the beginning and have them co-test the IPv6 product in the lab environment on all possible security vulnerabilities. The way IPv6 is designed in regards to the CPE (e.g. No NAT anymore) creates new vulnerabilities. Use this input for a proper security plan. Important here: Implementing IPv6 is actually quite simple. Implementing IPv6 with respect to subscriber’s privacy and with sufficient level of security is a different ballgame. And the last one is what this implementation is all about (At least, I hope if I was the subscriber here). Also, don’t hesitate to do one or more security audits all over the project, it provided us surprising but very useful results! - In parallel, make sure there is a solid IPv6 plan. Allocating the right amount of address space to subscribers is very important off course but besides that, there is only one chance to design the network “first time right”. We did analyse our biggest operational challenges we had in relation to IP(v4) maintenance. We found out that we had spent over the years a huge amount of effort on shuffling, renumbering and migrating subscribers over different parts of the network, based on capacity growth, adding acquired networks and constantly balancing CMTS capacity in relation to segmentation and usage. Try to learn from the past and make smart choices towards the future. IP Address Management (IPAM) is mandatory to keep control of maintenance costs on the long term, although the importance of this is hardly never acknowledged at initial stage. - Once this is all in place or in good progress, certifying and implementing IPv6 on DNS services, within the Backbone and so on is relatively straight forward. - Implementing, like also suggested in the article needs a proper pilot. In our initial implementation, we faced several serious production issues. We couldn’t have handled those if we would have activated IPv6 over the entire footprint. I consider this a “no brainer”. Good luck with implementing, please don’t hesitate to share your findings here. Also, feel free to consult me if you feel the need to.”

Thanks a lot Vincent, totally agree with your inputs!

“It might not be as hard for ISP as at first evaluation. I've gone through this. For example in the case of an ISP where most or all of their CPE routers are managed. The ISP knows what size delegated prefix the managed CPE will request. By default, if the CPE doesn't specify the assignment size requested the server will send the default size. The vast majority of CPE will be non-managed and request a non-default assignment. Only a small percentage of CPE request a larger prefix. As the CPE base does not change rapidly there is time to expand pools if required. I've got a /29. If I gave a /48 by default with the same simple pool design to all subs I'd need a /22. So there's complexity on the other side of this too as I'd have to change the pool design.”

Agree, and if you have a number of customers that means that you need a /22 in order to be able to provide a /48 to each end-site, this is very easy to justify to RIPE NCC, and there should not be an issue. I've been in situations requesting a /24, so close to that.

“Another option for the customer delegated prefix assignment size policy is to accept requests for PDs between /64 and /48 inclusive and have a default PD size for when it isn't specified in the DHCPv6 client request.”

Agree, but this is not making easy for the ISPs to make the addressing plan ... unless they reserve by default, for example /48 to each customer.

“Between the options of dynamic and static there is also the possibility of dynamic but sticky DHCPv6 PD leases. With sticky leases the DHCP server remembers the client had a lease for a configurable longer period after the expiration of the valid-lifetime that is advertised to CPE DHCP server. Normally the sticky lease will be deleted if the DHCP client sends a release message. For even greater stickiness it can be possible to ignore these releases. If the PD changes the CPE needs to follow RFC 7084 L-13 for the old prefix.”

Yeah, I've actually indicated it using a different terminology ("lease time very long").

“I knew about the survey. The reason I asked about using the RIPE Database data is that the RIPE NCC now has over 10,000 members with IPv6 (https://labs.ripe.net/Members/nathalie_nathalie/10-000-lirs-with-ipv6-resources). This is a very large number and the 368 survey responses from the RIPE NCC service region might not be representative. I don't know what proportion of LIRs use the "assignment-size:" attribute. If it is widely used, it might be possible to get an even more representative measurement than the survey.”

Now I understood what you mean and indeed I agree, that will be very interesting. The question is that it will be necessary also to discriminate among those LIRs, which of them actually are doing IPv6 services, and other issues such as if they are really "ISPs" in the sense of provide connectivity to customer end-sites (instead for example big corporations being a LIR for their own infrastructure, or data centers, etc.).