Twelve Steps to Enable IPv6 in Government and Enterprise Networks
• 10 min read
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…
I feel that the main problem in this region is that we allow a "wild west" by not requiring justification of the need in transfers and we should resolve that. Same with the lack of policy regarding leasing. All this clearly goes against the community and the membership. To make it worst, address-policy WG chairs ignore proposals from community members which will facilitate the allocation of IPv6 (avoiding the need for at least some of those transfers), against the PDP, and discriminate those members by "selecting" by themselves that a later submitted policy proposal is accepted or presented in the WG instead of the 1st one already submitted much ahead, disallowing the normal community defined process, presumably even against the code of conduct. No wonder that the community just don't care and avoids investing time in discussing topics that the staff warned about and some participants submitted proposals that have been ignored, for example for the ASs. Going back to the specific topic in this posting, it will be interesting to know if the NCC is getting escalated abuse reports coming from those IPv6 blocks or any other information that can tell us how much of that space is being used for good and bad.
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"
“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 ;-)
Showing 23 comment(s)