Orbit

Unfortunately, Indian community (although its very strong) doesn't have much presence in APNIC and other networking forums and because of minimum presence, we don't have any say in these communities. Last time, i raise an issue of voting rights to IRINN members but unfortunately didn't get enough support from IRINN community itself.

Let's see if things will improve or not.

I am always open for suggestion and directions from the community.

Thanks.

From: contact@daryllswer.com To: "Gaurav Kansal" gaurav.kansal@nic.in Cc: innog@innog.net Sent: Tuesday, November 1, 2022 7:10:12 PM Subject: Re: [INNOG] Thank you note

I wish you all the best for your work/future—Hope you can make some positive impact in your elected position(s) :)

And I hope we see more Indians who are APNIC members making use of their voting rights in the elections going forward.

Congrats Gaurav and you truly deserve both the positions you have been elected. Industry is going through challenges in APNIC resource management and IPv4 reputation, security are areas with big opportunity to bring sort of regulation. We shall discuss separately in detail and empower you in take these forward.

….ramesh On Tue, Nov 1, 2022, 3:19 PM Gaurav Kansal <gaurav.kansal@nic.inmailto:gaurav.kansal@nic.in> wrote: Good Afternoon.

"A thank you note is the simplest form of showing gratitude". I am both humbled and honored that you have placed your confidence and support in me by electing me for the NRO NC Member and NIR SIG Co-Chair position

I sincerely thank you for casting your valuable vote in my favor and making me win the election seeing all the required capabilities as a leader in me. I feel and believe that your support will boost my confidence to discharge my duties and responsibilities in a righteous manner.

I want to extend my special and sincere thanks for the immense support, valuable time and opportunity from Sh R.S. Mani (my boss), Dr Seema Khanna, Sh Anil Jain (CEO NIXI), Mr Tarun Dua (my mentor), Mr Vivek from Hapihhost, Sh Shailesh Gupta, Mr Naveen Sharma, Mr Anurag Bhatia, Mr Daryll Swer, Mr Abhishek Mishra, APNIC team and all others who supports me directly or in-directly by encouraging me to use my temperament in the right direction to give out the best result.

I was trying from past 2 weeks to send this mail to INNOG community but unfortunately mailing list was having an issue and didn't accepting the mails.

Thanking you once again!

Regards Gaurav Kansal

[https://email.gov.in/videos/images/75.jpg]https://amritmahotsav.nic.in/

Disclaimer:

This e-mail and its attachments may contain official Indian Government information. If you are not the intended recipient, please notify the sender immediately and delete this e-mail. Any dissemination or use of this information by a person other than the intended recipient is unauthorized. The responsibility lies with the recipient to check this email and any attachment for the presence of viruses. _______________________________________________ Go to the INNOG mailing list on Orbit -- orbit.apnic.net/mailing-list/innog@innog.nethttp://orbit.apnic.net/mailing-list/innog@innog.net Explore orbit.apnic.nethttp://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.netmailto:innog-leave@innog.net "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."

Thanks for the kind words. I will posted the developments here in this INNOG mailing list.

I have an update from APNIC w.r.t. the voting rights to IRINN members and i will share that too shortly.

regards, Gaurav Kansal

From: "barkha manral12" barkha.manral12@gmail.com To: "Gaurav Kansal" gaurav.kansal@nic.in Cc: innog@innog.net Sent: Wednesday, November 2, 2022 5:19:56 PM Subject: Re: [INNOG] Thank you note

Good evening,

A very heartiest Congratulations, being selected as NRO NC member as well as SIG co-chair. We hope and looking forward the changes in the positional temperament you will bring for the Nation. I, also hereby, request you to kindly keep us updated about the changes, reformation and development happening and going to happen in future in APNIC as well as ICANN. It will be a helpful notion from your end for all us.

Best Wishes for all your future endeavours.

Regards Barkha Manral

On Tue, Nov 1, 2022, 3:19 PM Gaurav Kansal < [ mailto:gaurav.kansal@nic.in | gaurav.kansal@nic.in ] > wrote:

Good Afternoon.

"A thank you note is the simplest form of showing gratitude". I am both humbled and honored that you have placed your confidence and support in me by electing me for the NRO NC Member and NIR SIG Co-Chair position

I sincerely thank you for casting your valuable vote in my favor and making me win the election seeing all the required capabilities as a leader in me. I feel and believe that your support will boost my confidence to discharge my duties and responsibilities in a righteous manner.

I want to extend my special and sincere thanks for the immense support, valuable time and opportunity from Sh R.S. Mani (my boss), Dr Seema Khanna, Sh Anil Jain (CEO NIXI), Mr Tarun Dua (my mentor), Mr Vivek from Hapihhost, Sh Shailesh Gupta, Mr Naveen Sharma, Mr Anurag Bhatia, Mr Daryll Swer, Mr Abhishek Mishra, APNIC team and all others who supports me directly or in-directly by encouraging me to use my temperament in the right direction to give out the best result.

I was trying from past 2 weeks to send this mail to INNOG community but unfortunately mailing list was having an issue and didn't accepting the mails.

Thanking you once again!

Regards Gaurav Kansal

[ https://amritmahotsav.nic.in/ ]

Disclaimer:

This e-mail and its attachments may contain official Indian Government information. If you are not the intended recipient, please notify the sender immediately and delete this e-mail. Any dissemination or use of this information by a person other than the intended recipient is unauthorized. The responsibility lies with the recipient to check this email and any attachment for the presence of viruses. _______________________________________________ Go to the INNOG mailing list on Orbit -- [ http://orbit.apnic.net/mailing-list/innog@innog.net | orbit.apnic.net/mailing-list/innog@innog.net ] Explore [ http://orbit.apnic.net/ | orbit.apnic.net ] , where the APNIC community connect, discuss and share information related to Internet addressing and networking. To unsubscribe send an email to [ mailto:innog-leave@innog.net | innog-leave@innog.net ]

@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...

However, IPv6 itself has the challenges whereby operators decide to:

1. Build their IPv6 subnetting and architecture using IPv4 mindset - https://packetpushers.net/podcast/ipv6-buzz-102-the-problem-with-ipv4-thinki... 2. Strange attitude towards BCOP 690 https://www.ripe.net/publications/docs/ripe-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 https://www.internetsociety.org/deploy360/ipv6/faq/#:~:text=There%20is%20an%20erroneous%20perception%20that%20the%20assignment%20of%20large%20IPv6%20prefixes%20to%20end%20customers%20is%20wasteful%2C%20but%20the%20IPv6%20address%20space%20is%20so%20huge%20that%20it%20has%20been%20calculated%20(by%20Tony%20Hain)%20that%20a%20/48%20could%20be%20assigned%20to%20every%20human%20for%20the%20next%20480%20years%20before%20they%20run%20out. even if we give every human dead and alive a /48 3. 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 https://www.6connect.com/blog/is-your-isp-constantly-changing-the-delegated-ipv6-prefix-on-your-cpe-router/ 4. 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/

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 https://twitter.com/DaryllSwer/status/1553419511642357762?s=20&t=PFOm3ik3yqi3-5C8rCZA-w 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 https://www.daryllswer.com/the-human-side-of-isps/ 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.

*--* Best Regards Daryll Swer Website: daryllswer.com https://www.daryllswer.com

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

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.netmailto:innog@innog.net> Sent: Thursday, November 3, 2022 5:37 PM To: Shubham Agarwal <shubham8agar@gmail.commailto:shubham8agar@gmail.com> Cc: gaurav.kansal@nic.inmailto:gaurav.kansal@nic.in; innog@innog.netmailto: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...https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdanosproject.atlassian.net%2Fwiki%2Fspaces%2FDAN%2Fpages%2F421101573%2FCGNAT%2Band%2BPCP%23Introduction&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740263897814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MA7elP6KH0079A52pfAT9021D8IRuWlmiSHaaIUpBu8%3D&reserved=0 However, IPv6 itself has the challenges whereby operators decide to:

1. Build their IPv6 subnetting and architecture using IPv4 mindset

* https://packetpushers.net/podcast/ipv6-buzz-102-the-problem-with-ipv4-thinki...https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpacketpushers.net%2Fpodcast%2Fipv6-buzz-102-the-problem-with-ipv4-thinking%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=US3AFD1Irauz%2Bj41%2BF4Bb2M9dyr2h8Ey6c9FHli2Mno%3D&reserved=0

1. Strange attitude towards BCOP 690https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fpublications%2Fdocs%2Fripe-690&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OrZ58KCpnkcY3%2F8oLDlNUPw0agz9EOF%2Fq3DSOwtYHGw%3D&reserved=0 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 yearshttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.internetsociety.org%2Fdeploy360%2Fipv6%2Ffaq%2F%23%3A~%3Atext%3DThere%2520is%2520an%2520erroneous%2520perception%2520that%2520the%2520assignment%2520of%2520large%2520IPv6%2520prefixes%2520to%2520end%2520customers%2520is%2520wasteful%252C%2520but%2520the%2520IPv6%2520address%2520space%2520is%2520so%2520huge%2520that%2520it%2520has%2520been%2520calculated%2520(by%2520Tony%2520Hain)%2520that%2520a%2520%2F48%2520could%2520be%2520assigned%2520to%2520every%2520human%2520for%2520the%2520next%2520480%2520years%2520before%2520they%2520run%2520out.&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PqReaJpmfDQz348Uhu%2FugO5XMhA2tGM18u1yfWkjOso%3D&reserved=0 even if we give every human dead and alive a /48

1. 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 SLAAChttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.6connect.com%2Fblog%2Fis-your-isp-constantly-changing-the-delegated-ipv6-prefix-on-your-cpe-router%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2F5P5NY6slKfq7TuKBnFb6yB031iTb8BdnFPzZnieJAg%3D&reserved=0

1. 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/ https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.apnic.net%2F2022%2F05%2F16%2Fula-is-broken-in-dual-stack-networks%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AoayEM5LuAtlvb4QBgKoC4pR%2F2nVI2fOx0SUEYh%2BxyQ%3D&reserved=0

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.apnic.net%2F2022%2F05%2F16%2Fula-is-broken-in-dual-stack-networks%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AoayEM5LuAtlvb4QBgKoC4pR%2F2nVI2fOx0SUEYh%2BxyQ%3D&reserved=0 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 writinghttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FDaryllSwer%2Fstatus%2F1553419511642357762%3Fs%3D20%26t%3DPFOm3ik3yqi3-5C8rCZA-w&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RIZIFdM11cQAW8g%2F%2FeJQtvlv%2FEQWi7DwWa6ngdG59h8%3D&reserved=0 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 issueshttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.daryllswer.com%2Fthe-human-side-of-isps%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UxKrPFVDkFHz8uwxeSIb%2BgjvrDMtT7ZufnLDf6kd8EM%3D&reserved=0 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.

-- Best Regards Daryll Swer Website: daryllswer.comhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.daryllswer.com%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HQ8xFfFN6T5ejBFsAOl%2FKph5XFXDcRLYnNT38a9v5j4%3D&reserved=0

[https://mailtrack.io/trace/mail/1757eb2f284395db71267a712412ad96c3c18f60.png...] On Thu, 3 Nov 2022 at 16:06, Shubham Agarwal <shubham8agar@gmail.commailto: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.commailto: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.nethttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forbit.apnic.net%2Fmailing-list%2Finnog%40innog.net&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HI1G6j0rD1WJjCGYFJRjAL5iezV1UctjpT9GoWwGQ7c%3D&reserved=0 Explore orbit.apnic.nethttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forbit.apnic.net%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7gZLyafQw%2BK7ak6T6TWGlJ9nCwY%2BWVWnN9Y%2B3%2B355rU%3D&reserved=0, where the APNIC community connect, discuss and share information related to Internet addressing and networking. To unsubscribe send an email to innog-leave@innog.netmailto:innog-leave@innog.net _______________________________________________ Go to the INNOG mailing list on Orbit -- orbit.apnic.net/mailing-list/innog@innog.nethttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forbit.apnic.net%2Fmailing-list%2Finnog%40innog.net&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HI1G6j0rD1WJjCGYFJRjAL5iezV1UctjpT9GoWwGQ7c%3D&reserved=0 Explore orbit.apnic.nethttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forbit.apnic.net%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7gZLyafQw%2BK7ak6T6TWGlJ9nCwY%2BWVWnN9Y%2B3%2B355rU%3D&reserved=0, where the APNIC community connect, discuss and share information related to Internet addressing and networking. To unsubscribe send an email to innog-leave@innog.netmailto: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."

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 Beldona

On 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... https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdanosproject.atlassian.net%2Fwiki%2Fspaces%2FDAN%2Fpages%2F421101573%2FCGNAT%2Band%2BPCP%23Introduction&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740263897814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MA7elP6KH0079A52pfAT9021D8IRuWlmiSHaaIUpBu8%3D&reserved=0

However, IPv6 itself has the challenges whereby operators decide to:

1. Build their IPv6 subnetting and architecture using IPv4 mindset

• https://packetpushers.net/podcast/ipv6-buzz-102-the-problem-with-ipv4-thinki... https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpacketpushers.net%2Fpodcast%2Fipv6-buzz-102-the-problem-with-ipv4-thinking%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=US3AFD1Irauz%2Bj41%2BF4Bb2M9dyr2h8Ey6c9FHli2Mno%3D&reserved=0

1. Strange attitude towards BCOP 690

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fpublications%2Fdocs%2Fripe-690&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OrZ58KCpnkcY3%2F8oLDlNUPw0agz9EOF%2Fq3DSOwtYHGw%3D&reserved=0 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 https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.internetsociety.org%2Fdeploy360%2Fipv6%2Ffaq%2F%23%3A~%3Atext%3DThere%2520is%2520an%2520erroneous%2520perception%2520that%2520the%2520assignment%2520of%2520large%2520IPv6%2520prefixes%2520to%2520end%2520customers%2520is%2520wasteful%252C%2520but%2520the%2520IPv6%2520address%2520space%2520is%2520so%2520huge%2520that%2520it%2520has%2520been%2520calculated%2520(by%2520Tony%2520Hain)%2520that%2520a%2520%2F48%2520could%2520be%2520assigned%2520to%2520every%2520human%2520for%2520the%2520next%2520480%2520years%2520before%2520they%2520run%2520out.&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PqReaJpmfDQz348Uhu%2FugO5XMhA2tGM18u1yfWkjOso%3D&reserved=0 even if we give every human dead and alive a /48

1. 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 https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.6connect.com%2Fblog%2Fis-your-isp-constantly-changing-the-delegated-ipv6-prefix-on-your-cpe-router%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2F5P5NY6slKfq7TuKBnFb6yB031iTb8BdnFPzZnieJAg%3D&reserved=0

1. 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/

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.apnic.net%2F2022%2F05%2F16%2Fula-is-broken-in-dual-stack-networks%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AoayEM5LuAtlvb4QBgKoC4pR%2F2nVI2fOx0SUEYh%2BxyQ%3D&reserved=0

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.apnic.net%2F2022%2F05%2F16%2Fula-is-broken-in-dual-stack-networks%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264054052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AoayEM5LuAtlvb4QBgKoC4pR%2F2nVI2fOx0SUEYh%2BxyQ%3D&reserved=0

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 https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FDaryllSwer%2Fstatus%2F1553419511642357762%3Fs%3D20%26t%3DPFOm3ik3yqi3-5C8rCZA-w&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RIZIFdM11cQAW8g%2F%2FeJQtvlv%2FEQWi7DwWa6ngdG59h8%3D&reserved=0 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 https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.daryllswer.com%2Fthe-human-side-of-isps%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UxKrPFVDkFHz8uwxeSIb%2BgjvrDMtT7ZufnLDf6kd8EM%3D&reserved=0 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.

*--*

Best Regards

Daryll Swer

Website: daryllswer.com https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.daryllswer.com%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HQ8xFfFN6T5ejBFsAOl%2FKph5XFXDcRLYnNT38a9v5j4%3D&reserved=0

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 https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forbit.apnic.net%2Fmailing-list%2Finnog%40innog.net&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HI1G6j0rD1WJjCGYFJRjAL5iezV1UctjpT9GoWwGQ7c%3D&reserved=0 Explore orbit.apnic.net https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forbit.apnic.net%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7gZLyafQw%2BK7ak6T6TWGlJ9nCwY%2BWVWnN9Y%2B3%2B355rU%3D&reserved=0, 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 https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forbit.apnic.net%2Fmailing-list%2Finnog%40innog.net&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HI1G6j0rD1WJjCGYFJRjAL5iezV1UctjpT9GoWwGQ7c%3D&reserved=0 Explore orbit.apnic.net https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forbit.apnic.net%2F&data=05%7C01%7Cdanny.pinto%40colt.net%7Cc14cf1266bc94e95a6ae08dabd93ebb8%7Cb859cf7eff8a40bbbd0fda56e6dc0eb8%7C1%7C0%7C638030740264210329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7gZLyafQw%2BK7ak6T6TWGlJ9nCwY%2BWVWnN9Y%2B3%2B355rU%3D&reserved=0, 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