Jordi Palet Martinez

Based in Spain




Likes on articles

About the author

Jordi Palet Martínez has been working with computers, networking and technology since he was 8 years old. The last 17 years, as CEO/CTO at "The IPv6 Company", devoted most of his time to IPv6 R&D, standardization, training and consultancy, having worked already with IPv6 customers in 110 countries in the world. He has co-authored a number of RFCs and books related to IPv6 and contributed to IPv6 training and policy making in all the RIRs.

Links & Social


Published tags

• On Criteria for the Accreditation of Regional Internet Registries by Athina Fragkouli

A clear change should be the title of the ICP-2, something like "ICP-2 - Criteria for the establishment Regional Internet Registries and obligations for their continued recognition"

• Reply to Abraham Y. Chen on IPv6-only? IPv4-as-a-service? by Jordi Palet Martinez

“Hi, Jordi: 0) There is still time. 1) Please have a look at the following discussion thread on the "state of IPv6", 2) Then, you may like to have a look at the feasibility demonstration report below about our proposal for expanding IPv4 address pool, etc.: These should provide some material for furthering the dialog. Abe (2020-08-29 22:31 EDT)”

The Ericsson publicacion has a lot of wrong misconceptions as starting point and consequently, anything that starts from there, is broken. When and if IETF approves the use of 240/4, and all the vendors start having firmware updated to users to support it, then we can talk about this. Meanwhile, the only solution *BEING* deployed, is IPv6.

• On The RIPE NCC's Use of Zoom for Meetings by Kaveh Ranjbar

Very informative. Thanks a lot! I love the "legacy IPv4" bit :--)

• On How Far We've Come: In Conversation with Axel Pawlik by Ulka Athale

Hi Axel, I can't let you go without saying this: Yes please, join the mailing list. Now that you will be non-staff (I always said that staff is also community and should be able to speak openly from a personal perspective + additional knowledge), you can contribute a lot with your "internal" knowledge of so many aspects that aren't easy to see from the community side. Thanks!

• On Abuse-c Validation: Update on Progress and Some Numbers by Angela Dall'Ara

Of course, the problem of this system is that *ANY* valid email will pass the validation, even if actually is from someone else and not just a real abuse contact ... For example, a bad guy can just find the RIPE NCC contact email, and use that one. Nobody will notice, the validation will pass. We need something else. Stay tuned!

• Reply to Abraham Y. Chen on IPv6-only? IPv4-as-a-service? by Jordi Palet Martinez

“It may seem to be after the fact. However, with so many twists involved in rolling out IPv6 because it was not designed with the very basic engineering discipline of being backward compatible with IPv4, we really should look at the whole thing seriously one more time. Below is the result of a study that we accidentally ventured into. It utilizes nothing more than the original RFC791 and the long-reserved yet hardly-utilized 240/4 address block. We call it EzIP (phonetic for Easy IPv4) and submitted a draft to IETF: Basically, the EzIP approach will not only resolve IPv4 address shortage issues, but also largely mitigate the root cause to cyber security vulnerabilities, plus open up new possibilities for the Internet, all within the confines of the IPv4 domain. In fact, this scheme may be deployed "stealthily" at isolated sites where needed. These should relieve the urgency to deploy the IPv6 for an appreciable length of time. Any thought or comment would be much appreciated. Abe (2018-07-13 16:39)”

I really think is too late to consider other approaches. IPv6 is already there and artificially extending IPv4 life is a non-sense in my opinion. We just need to make sure that IPv6 continues being deployed and customers with IPv4 needs can also get that service, even if this is somehow limited.

• On IPv6-only? IPv4-as-a-service? by Jordi Palet Martinez

I just confirmed my previous response on this with Apple. If the handset gets and IPv6-only access from the operator, and requires tethering for IPv4 devices, they have a profile for enforcing one additional PDP context for the IPv4 devices, which is typically a PDP type IPv4v6 (dual-stack). However, and this is the good news, they are working in including CLAT, so we will have support for 464XLAT as in Android, so the IPv6-only (type IPv6) PDP context will make it.

• On IPv6-only? IPv4-as-a-service? by 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: 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

• Reply to Sara Solmone on Establishing Jurisdiction Online: the Problem of the Access-based Jurisdictional Principle by Sara Solmone

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

• On Establishing Jurisdiction Online: the Problem of the Access-based Jurisdictional Principle by Sara Solmone

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!

Showing 22 comment(s)

1 2 3