Keyboard Shortcuts
Thread View
j
: Next unread messagek
: Previous unread messagej a
: Jump to all threadsj l
: Jump to MailingList overview


Hi Mr Srinath
If you recall IPv6 discussion back in INNOG5 - I think the reality is simple - There's financial incentive to keep IPv4 going for cloud providers. Give crappy IPv6, results in non-networking folks not wanting to waste their time on it, fallback to IPv4, charge for NAT etc.I mean this speaks for itself:On Sat, Nov 05, 2022 01:42 PM, Srinath Beldona <beldona.srinath@gmail.com> wrote:--Hello Everyone,Interesting thread on IPv6 deployment.I was speaking to a Systems software developer working for a company that develops for a big cloud provider. He said IPv6 development was never a priority for the big cloud provider.This is unfortunate. I think if the IPv6 deployment trend shifts to retail ISPs deploying this may catch on with Content and Cloud Providers.Good comments Darryl.With warm regards,Srinath BeldonaOn Fri, Nov 4, 2022 at 1:45 PM Ramesh.R.Chandra--- via INNOG <innog@innog.net> wrote:_______________________________________________That is right Danny. IPv6 adoption is must but not enough due to slow adoption of IPv6 by content/ASPs. Unfortunately, there is no motivation or priority for content providers to adopt IPv6. As a result, big operator need more IPv4 to access contents on IPv4.
Would appreciate if there is active forum of ASPs to raise and speedup IPv6 adoption by content providers.
...ramesh
From: Pinto, Danny <Danny.Pinto@colt.net>
Sent: 03 November 2022 18:57
To: Daryll Swer <contact@daryllswer.com>; Shubham Agarwal <shubham8agar@gmail.com>; innog@innog.net
Cc: gaurav.kansal@nic.in
Subject: [External][INNOG] Re: Thank you note
Caution: The e-mail below is from an external source. Please do not open attachments or click links unless this email comes from a known sender and you know the content is safe.
+1
Tweaking IPv4 allocation policies would not help. IPv6 should be directional way forward.
“easy choices, hard life.. hard choices, easy life sooner “…
Regards,
Danny
From: Daryll Swer via INNOG <innog@innog.net>
Sent: Thursday, November 3, 2022 5:37 PM
To: Shubham Agarwal <shubham8agar@gmail.com>
Cc: gaurav.kansal@nic.in; innog@innog.net
Subject: [INNOG] Re: Thank you note
EXTERNAL EMAIL*
@Shubham Agarwal
IPv4 is a legacy protocol and with that it is exhausted in every sense of the word.
I don't see any reason to keep on wasting efforts and resources on IPv4. We should focus on the current protocol i.e. IPv6. Network engineers and operators should make both organisational and individual efforts to learn how to operate and configure the various translation mechanisms and techniques such as migrating to an IPv6-only backbone combined with BGP unnumbered, learn to use DS-Lite/NAT64/464xlat etc.
- The moment end-user has access to native and stable IPv6 – Around 70-80% of traffic moves to IPv6. There's no issue if IPv4 is then subjected to translation mechanisms as port exhaustion would naturally be a non-issue for the remaining 20-30% of traffic. Of course, the primary reason for such high stats is content traffic, but that's perfectly valid and fine as the point stands for v4's port exhaustion being a non-issue
- In my extensive testing with one relatively large operator in India, we observed that a /30 per 200 users was perfectly fine and did not result in port exhaustion if configured correctly using netmap instead of src nat or some weird deterministic nat configuration on their CGNAT device
- Adding a web portal (using port control protocol) for end user to map the ports based on availability and time based method will help you improve IPv4 further with limited resources. Reference example: https://danosproject.atlassian.net/wiki/spaces/DAN/pages/421101573/CGNAT+and+PCP#Introduction
However, IPv6 itself has the challenges whereby operators decide to:
- Build their IPv6 subnetting and architecture using IPv4 mindset
- Strange attitude towards BCOP 690 compliance whereby they invented this mathematical formula that a /64 per customer is sufficient even though:
- Limits only to single VLAN
- No justification for it as IPv6 is large enough to last us for 480 years even if we give every human dead and alive a /48
- Strange idea that dynamic PD will give user “privacy” even though big tech analytics tools rely largely on browser fingerprinting, system fingerprinting, supercookies etc and couldn't care less about IP changing (example Wi-Fi to mobile network and so on)
- This strange idea also breaks SLAAC
- Strange idea that anything smaller than /56 is justified for both residential and enterprise networks
Let's not forget that IPv6 even for enterprise/SMEs has the issue with PA space vs PIA space vs DFZ table size further leading to operational issues with ULAs in dual-stacked networks:
https://blog.apnic.net/2022/05/16/ula-is-broken-in-dual-stack-networks/
From a policy standpoint, I hope someone will propose to APNIC and other RIRs to make sure that every organization or ASN gets at least a /32 delegation. I ran into this policy issue when I asked for a /32 from APNIC. In some weird way, I feel it's easier to get IPv4 than to get IPv6 delegation justification and this goes against the whole “last us for 480 years” fact.
I am currently in the process of writing a comprehensive IPv6 subnetting and architecture guide for both Telcos/ISPs and enterprises using real-life production examples that I have deployed hands-on in real-time instead of just theory-based examples. However, it is not due for publication until at least next year. Hopefully when it's out, I hope it helps those operators/engineers who have passion and curiosity for network engineering beyond just profit making and trading.
And we should not ignore the ethical/human side related issues if one is employed by Indian network operators – Ranging from poor salary issues, to poor revenue/profit margins to broadband plans that are too cheap for sustainability to various other factors that can be elaborated further and better by the other folks in this mailing list who runs ISP/Telco in their daily lives :)
All of these eventually add up and the end result is a non-RFC compliant network deployment model.
In my limited experience so far, I have never seen a standardised network (meaning largely or fully RFC, BCP, BCOP compliant).
But anyway I've ranted long enough, and I hope for change to occur and for the operators to wake up and ensure they follow the best practices.
On Thu, 3 Nov 2022 at 16:06, Shubham Agarwal <shubham8agar@gmail.com> wrote:
Hii Gaurav
It is great to have on board fresh faces with new ideas and energy, leading the community and sharing their expertise to enrich the collective knowledge of the community as a whole. I would like to bring your attention to an issue being faced by APNIC members containing near minimum IPv4 resources and would love to work on a solution in this regard.
As per APNIC resource policy, the current minimum delegation size for IPv4 is a /24 (256 addresses), while the maximum delegation size for IPv4 is a /23 (512 addresses). The non-103/8 resource waiting list is also abolished, and only new APNIC account holders are eligible to receive IPv4 delegation from the remaining IPv4 pool. In this scenario, the big network operators, which have abundant amounts of allocated IPv4 resources (for example, /8 or /16), are not facing many issues. More importantly, the APNIC Inter-RIR transfer of unused IPv4 addresses and/or AS numbers is available for network operators with high financial resources to directly fulfil their requirements on their own.
However, APNIC Members containing near minimum IPv4 resources (e.g., fewer than 2,048 IPv4s) and looking for expansion or a surge-in-demand are facing a crunch of IPv4 resources, especially in developing countries.
Therefore, it can be proposed to enable all APNIC members that have a total number of assigned IPv4 resources less than /21 (i.e., below 2,048 IPs) exposure to an additional /23 IPv4 address block.
It would be very great to have views from all community members on this proposal and evaluate pros and cons against the same considering present issues being faced by community members which have lesser resources but serving at the edge of internet geographies and ensuring safe internet to end users especially in developing countries.
Regards:
Shubham Agarwal
On Thu, Nov 3, 2022 at 11:03 AM Shubham Agarwal <shubham8agar@gmail.com> wrote:
Good Morning from India..
My heartfelt congratulations to Mr. Gaurav Kansal on election victory in APNIC 54 SIG and NRO NC elections.
Wishing you all the best for your noble future endeavors.
Best Regards
Shubham Agarwal
_______________________________________________
Go to the INNOG mailing list on Orbit -- orbit.apnic.net/mailing-list/innog@innog.net
Explore orbit.apnic.net, where the APNIC community connect, discuss and share information related to Internet addressing and networking.
To unsubscribe send an email to innog-leave@innog.net_______________________________________________
Go to the INNOG mailing list on Orbit -- orbit.apnic.net/mailing-list/innog@innog.net
Explore orbit.apnic.net, where the APNIC community connect, discuss and share information related to Internet addressing and networking.
To unsubscribe send an email to innog-leave@innog.net* WARNING - EXTERNAL: This email originated from outside of Colt. Do not click any links or open any attachments unless you trust the sender and know that the content is safe.
[Colt Disclaimer] This email is from an entity of the Colt group of companies. Colt Group Holdings Limited, Colt House, 20 Great Eastern Street, London, EC2A 3EH, United Kingdom, registered in England and Wales, under company number 11530966. Corporate and contact information for our entities can be found at https://www.colt.net/legal/colt-group-of-companies/. Internet communications are not secure and Colt does not accept responsibility for the accurate transmission of this message. Content of this email or its attachments is not legally or contractually binding unless expressly previously agreed in writing by Colt
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
Go to the INNOG mailing list on Orbit -- orbit.apnic.net/mailing-list/innog@innog.net
Explore orbit.apnic.net, where the APNIC community connect, discuss and share information related to Internet addressing and networking.
To unsubscribe send an email to innog-leave@innog.net
Sent from my iPhone
Activity Summary
- 390 days inactive
- 390 days old
- innog@innog.net
- 1 participants
- 0 comments