Twelve Steps to Enable IPv6 in Government and Enterprise Networks
In the first part of this two-part series, I shared a recent IPv6 deployment case study I worked on for a government network in the LACNIC region, concentrating on the hereditary peculiarities in the network that we had to overcome, many of which are common among government and organisational netwo…
“Hi, Jordi: 0) There is still time. 1) Please have a look at the following discussion thread on the "state of IPv6", http://www.circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/ 2) Then, you may like to have a look at the feasibility demonstration report below about our proposal for expanding IPv4 address pool, etc.: https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf 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.
Very informative. Thanks a lot! I love the "legacy IPv4" bit :--)
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!
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!
“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: https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03 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.
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.
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!
Showing 21 comment(s)