[sig-policy] Re: New version: prop-154: Resizing of IPv4 assignment for the IXPs

[Sanjeev Gupta]

I did a quick search on my router, and I see:

sanjeev@P14W11:/mnt/c/Users/sanje/Desktop$ grep -e '/2[789]' someroutes.txt
| sort | uniq
   DAb   1.6.73.96/27   103.241.63.130   20
   DAb   12.229.60.8/29 210.23.3.65  20
   DAb + 1.6.1.64/27103.241.63.130   20
   DAb + 1.6.140.80/28  103.241.63.130   20
   DAb + 1.6.148.0/28   103.241.63.130   20
   DAb + 1.6.19.224/27  103.241.63.130   20
   DAb + 1.6.195.176/28 103.241.63.130   20
   DAb + 1.6.195.96/28  103.241.63.130   20
   DAb + 1.6.2.160/27   103.241.63.130   20
   DAb + 1.6.215.144/28 103.241.63.130   20
   DAb + 1.6.215.160/28 103.241.63.130   20
   DAb + 1.6.23.224/27  103.241.63.130   20
   DAb + 1.6.4.192/27   103.241.63.130   20
   DAb + 1.6.67.160/28  103.241.63.130   20
   DAb + 1.6.70.48/28   103.241.63.130   20
   DAb + 1.6.75.128/27  103.241.63.130   20
   DAb + 1.6.75.64/27   103.241.63.130   20
   DAb + 1.6.8.16/28103.241.63.130   20
   DAb + 1.6.8.224/27   103.241.63.130   20
   DAb + 1.6.9.16/28103.241.63.130   20
   DAb + 1.7.143.160/28 103.241.63.130   20
   DAb + 1.7.177.16/28  103.241.63.130   20
   DAb + 1.7.177.32/28  103.241.63.130   20
   DAb + 1.7.179.160/28 103.241.63.130   20
   DAb + 1.7.188.160/28 103.241.63.130   20
   DAb + 1.7.193.0/27   103.241.63.130   20
   DAb + 1.7.193.160/27 103.241.63.130   20
   DAb + 1.7.196.0/27   103.241.63.130   20
   DAb + 1.7.196.224/27 103.241.63.130   20
   DAb + 1.7.197.0/27   103.241.63.130   20
   DAb + 1.7.224.64/28  103.241.63.130   20


So, as a new IX (current 20, planned 50 peers), I have 2 choices with the
new policy:

   1. I come in as a new, normal, Member.  I get a /24 (to save costs).  I
   announce the lower /25 for my looking glass, etc, and the upper /25 for my
   Peering LAN.
   2. Or, under the new policy, I get a /26 for my LAN, and apply for a /24
   (the minimum) for my public resources.

So the new policy makes it MORE expensive for me to tell APNIC I am an IX.
Plus my fear that I might start doing well, and need to renumber (or I can
tell people, sorry, the IX is full, please wait till someone leaves).

Under option 1, if I grow, I get another /24, move my LG and www, and
expand the peering LAN.  Or I save significant money, I announce the LOWER
/28 (my LG), and expand the Peering LAN to the full /24.

Under option 2, I need to renumber.

So tell me (I asked last week): when you say:

> 5. Advantages
> This proposal will ensure rapid expansion of IXPs in terms of membership
> and POP numbers for this region

what do you mean?  You specifically force pain onto me every time I wish to
expand, and you rub it in by saying you are encouraging "rapid expansion"

(This is apart from my general background opposition to special cases and
tinkering.  Please, let v4 changes die.  Let Sunny and Chimi finish handing
out what they have, to whomever applies, and let us move on)

-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane


On Wed, Sep 13, 2023 at 7:11 PM Sanjeev Gupta  wrote:

> On Wed, Sep 13, 2023 at 5:42 PM Aftab Siddiqui 
> wrote:
>
>> Hi Jahangir,
>> Peering lan should never be on the global routing table whether you
>> support this policy or not. Even the peering lan of existing IXP are not
>> advertised to global routing table.
>>
>
> Aftab, so for my new IX, I will get a /26 for the LAN (I have 10 members),
> and a /24  (or /23) (because I am a member)?  After all, I need global
> reachability for my lg, my portal, my member page  How does this help
> conserve resources?
>
> Why not give me a /24, and let me handle what I need, etc?  Despite
> repeated wisdom, /25 (with a Route Object, and IRR) is as visible as a /24
> in general.
>
> My concern remains: why are IXs a special case at all?  As Vivek
> responded, it is not like we have a separate pool for them anyway.  Why
> treat them special?
>
> Now, if you were proposing that an IX (to be encouraged) should be able to
> request a /18 (!), now that might *encourage* IXs.  But again, someone this
> large is likely to be commercial, they can afford to spend the money to buy
> (dare I say "lease" a /18).
>
>
>
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version: prop-154: Resizing of IPv4 assignment for the IXPs

[Sanjeev Gupta]

On Wed, Sep 13, 2023 at 5:42 PM Aftab Siddiqui 
wrote:

> Hi Jahangir,
> Peering lan should never be on the global routing table whether you
> support this policy or not. Even the peering lan of existing IXP are not
> advertised to global routing table.
>

Aftab, so for my new IX, I will get a /26 for the LAN (I have 10 members),
and a /24  (or /23) (because I am a member)?  After all, I need global
reachability for my lg, my portal, my member page  How does this help
conserve resources?

Why not give me a /24, and let me handle what I need, etc?  Despite
repeated wisdom, /25 (with a Route Object, and IRR) is as visible as a /24
in general.

My concern remains: why are IXs a special case at all?  As Vivek responded,
it is not like we have a separate pool for them anyway.  Why treat them
special?

Now, if you were proposing that an IX (to be encouraged) should be able to
request a /18 (!), now that might *encourage* IXs.  But again, someone this
large is likely to be commercial, they can afford to spend the money to buy
(dare I say "lease" a /18).
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version: prop-154: Resizing of IPv4 assignment for the IXPs

[Sanjeev Gupta]

Thank you, Vivek.

Aftab, so what I understand is, new IXPs will be at a disadvantage compared
to other new applicants. Others can get a /23 initial, IXPs get a /26.

You had mentioned that this proposal would encourage IXs.


On Tue, 12 Sep 2023, 13:29 Vivek Nigam,  wrote:

> Hi Sanjeev,
>
>
>
> 1. We don't have a separate pool for IXP delegations.
>
>
>
> 2. Based on recent delegation trends, APNIC and NIRs combined delegate
> about 280 /24's each month.
>
>
>
> Thanks
>
> Vivek
>
>
>
> *From: *Sanjeev Gupta 
> *Date: *Monday, 11 September 2023 at 2:35 pm
> *To: *sig-policy 
> *Cc: *Aftab Siddiqui 
> *Subject: *[sig-policy] Re: New version: prop-154: Resizing of IPv4
> assignment for the IXPs
>
> Would the APNIC Secetariat please clarify (for IPv4):
>
>
>
>1. Are IXP allocations made from a separate pool?  If so,
>
>
>1. What is the free size of the pool
>   2. What is the rate of depletion
>
>
>1. What is the rate of depletion of the general (final /8) pool?
>
> I am trying to understand what we will achieve by holding IXP allocations
> to a tighter standard (/26) than general new signups, which get a /23
> anyway.
>
>
>
>
>
>
>
>
>
> --
> Sanjeev Gupta
> +65 98551208   http://sg.linkedin.com/in/ghane
> <https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsg.linkedin.com%2Fin%2Fghane=05%7C01%7C%7C38ed677cc90a46c7215108dbb288e14b%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C638300073195866861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=WikbihZjC%2Bg0E%2BnQN51Nx2%2FscbLFAhC84yzBCZPLzf8%3D=0>
>
>
>
>
>
> On Sat, Sep 9, 2023 at 7:07 AM Shaila Sharmin <
> shaila.sharmin@gmail.com> wrote:
>
> Dear SIG members,
>
> A new version of the proposal "prop-154: Resizing of IPv4 assignment for
> the IXPs"
> has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-154
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Regards,
> Bertrand, Shaila, and Anupam
> APNIC Policy SIG Chairs
>
>
>
> ---
>
> prop-154-v002: Resizing of IPv4 assignment for the IXPs
>
> 
>
> Proposer: Simon Sohel Baroi (sba...@gmail.com)
>Aftab Siddiqui
>
>
> 1. Problem statement
> 
> According to APNIC Internet Number Resource Policies ( Ref – APNIC-127,
> Dated: 22 DEC, 2022 ), an Internet Exchange Point ( IXP ) is eligible to
> receive a maximum /23 of IPv4 and /48 of IPv6 resources. Usually APNIC
> assign one /24 to start a new IXP. But from analysis through PeeringDB,
> we found most of places the resources have been underutilized and new
> IXPs are wasting a large amount of valuable IPv4 space. On the other
> side there are large IXP, who can’t grow due to lack of IP resources,
> where /23 is not enough as the membership size is big. The size of the
> minimum and maximum range of IP delegation to new or existing IXPs is
> the main problem in the current policy.
>
> Present IXP Status in APAC region from PeeringDB [5] :
>
> +---+---++---+---+
> |  IX Names | Peers | Vs | Peers |  IX
> Names |
> +---+---+ +---+---+
> | BBIX Tokyo|  299  ||   17  |
> BBIX-Thailand |
> +---+---+ +---+---+
> | JPIX TOKYO|  257  ||   3   |
> MekongIX  |
> +---+---+ +---+---+
> | Equinix Tokyo |  131  ||   2   | Equinix
> Mumbai|
> +---+---+ +---+---+
> | JPNAP Tokyo   |  211  ||   13  | npIX
> JWL  |
> +---+---+ +---+---+
> | HKIX  |  296  ||   3   | Vanuatu Internet
> Exchange |
> +---+---+ +---+---+
> | Equinix Hong Kong |  216  ||   4   |
> MyNAP |
> +-

[sig-policy] IPv4 Guidelines

[Sanjeev Gupta]

Helpdesk,

Please see:
https://www.apnic.net/about-apnic/corporate-documents/documents/resource-guidelines/ipv4-guidelines/

The status is marked as Active.  Is this currently the case?  Or has it
been obsoleted by newer documents?

I am concerned that as we make new Policy, to address specific small
issues, we are not looking at the change is language throughout the unified
documentation, for consistency.

-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version: prop-154: Resizing of IPv4 assignment for the IXPs

[Sanjeev Gupta]

Would the APNIC Secetariat please clarify (for IPv4):


   1. Are IXP allocations made from a separate pool?  If so,
  1. What is the free size of the pool
  2. What is the rate of depletion
   2. What is the rate of depletion of the general (final /8) pool?

I am trying to understand what we will achieve by holding IXP allocations
to a tighter standard (/26) than general new signups, which get a /23
anyway.




-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane


On Sat, Sep 9, 2023 at 7:07 AM Shaila Sharmin 
wrote:

> Dear SIG members,
>
> A new version of the proposal "prop-154: Resizing of IPv4 assignment for
> the IXPs"
> has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-154
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Regards,
> Bertrand, Shaila, and Anupam
> APNIC Policy SIG Chairs
>
>
>
> ---
>
> prop-154-v002: Resizing of IPv4 assignment for the IXPs
>
> 
>
> Proposer: Simon Sohel Baroi (sba...@gmail.com)
>Aftab Siddiqui
>
>
> 1. Problem statement
> 
> According to APNIC Internet Number Resource Policies ( Ref – APNIC-127,
> Dated: 22 DEC, 2022 ), an Internet Exchange Point ( IXP ) is eligible to
> receive a maximum /23 of IPv4 and /48 of IPv6 resources. Usually APNIC
> assign one /24 to start a new IXP. But from analysis through PeeringDB,
> we found most of places the resources have been underutilized and new
> IXPs are wasting a large amount of valuable IPv4 space. On the other
> side there are large IXP, who can’t grow due to lack of IP resources,
> where /23 is not enough as the membership size is big. The size of the
> minimum and maximum range of IP delegation to new or existing IXPs is
> the main problem in the current policy.
>
> Present IXP Status in APAC region from PeeringDB [5] :
> +---+---++---+--
> -+
> |  IX Names | Peers | Vs | Peers |  IX
> Names |
> +---+---+ +---+---+
> | BBIX Tokyo|  299  ||   17  |
> BBIX-Thailand |
> +---+---+ +---+---+
> | JPIX TOKYO|  257  ||   3   |
> MekongIX  |
> +---+---+ +---+---+
> | Equinix Tokyo |  131  ||   2   | Equinix
> Mumbai|
> +---+---+ +---+---+
> | JPNAP Tokyo   |  211  ||   13  | npIX
> JWL  |
> +---+---+ +---+---+
> | HKIX  |  296  ||   3   | Vanuatu Internet
> Exchange |
> +---+---+ +---+---+
> | Equinix Hong Kong |  216  ||   4   |
> MyNAP |
> +---+---+ +---+---+
> | Equinix Singapore |  422  ||   25  | DE-CIX Kuala
> Lumpur   |
> +---+---+ +---+---+
> | IIX-Jakarta   |  449  ||   13  |
> IIX-Lampung   |
> +---+---+ +---+---+
> | DECIX-Mumbai  |  446  ||   14  | Decix
> Kolkata |
> +---+---+ +---+---+
> | MegaIX Sydney |  232  ||   46  | EdgeIX -
> Melbourne|
> +---+---++---+--
> -+
>
>
> 2. Objective of policy change
> -
> The objective of this proposal is to modify the default size of IPv4
> assignments for IXPs from up to /23 to /26, which can receive a
> replacement up to a maximum of a /22, provided the IXP returns the IPv4
> address space previously assigned to them.
>
> 3. Situation in other regions
> -
> Similar policy has been adopted by RIPE NCC ( ripe-733 :  IPv4 Address
> Allocation and Assignment Policies for the RIPE NCC Service Region ) [4]
>
>
> 4. Proposed policy solution
> ---
>
> Current Policy text :
>
> 6.2.

[sig-policy] Re: New version: prop-154: Resizing of IPv4 assignment for the IXPs

[Sanjeev Gupta]

On Mon, Sep 11, 2023 at 11:28 AM Aftab Siddiqui 
wrote:

> You receive a /26 for a new site as per this new policy, you already have
> a /24 assigned to your account which is out of the scope of this policy and
> can be globally advertised if you want to, you can't advertise anything you
> receive under this policy.
>
> First statement says, you can not announce any resource you receive under
> this policy
>
> Second statement says, any resource you have received outside this policy
> whether its directly from APNIC or through transfer then it is not
> restricted to be announced.
>
> I hope that clarifies.
>

Understood.

So the impact will be the paragraph:

*Criteria for Internet Exchange Points*


   - Internet Exchange Points (IXP) are eligible to receive a delegation
   from APNIC to be used exclusively to connect the IXP participant devices to
   the Exchange Point.
   - Global routability of the delegation is left to the discretion of the
   IXP and its participants.


at:
https://www.apnic.net/get-ip/get-ip-addresses-asn/check-your-eligibility/

Thank you.
-- 
Sanjeev
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version: prop-154: Resizing of IPv4 assignment for the IXPs

[Sanjeev Gupta]

On Sat, Sep 9, 2023 at 7:07 AM Shaila Sharmin 
wrote:



> Any resources assigned under this policy will not be announced in the
> global routing table (mistakes are exempted) and must be used for IXP
> peering only, in case otherwise the resources will be revoked by APNIC.
>
> Global routability of the delegation outside this policy is left to the
> discretion of the IXP and its participants.
>

I am unclear what the two paragraphs above mean, together.

My new IX (BEST!!!-IX) receives a /26.

The first paragraph says I MUST NOT announce this outside the IX LAN.  Or
else

The second says it is left to my discretion.

What am I missing?


> 5. Advantages / Disadvantages
> -
> Advantages:
> This proposal will ensure rapid expansion of IXPs in terms of membership
> and POP numbers for this region and smoothen allocation of IPv4.
>

How?  How will *restricting* the allocation "ensure rapid expansion"?

You also state:
> Reducing the default assignment size to /26 would stop wasting a large amount
of valuable IPv4 space

We have to decide consistently if IPv4 space is valuable or not.  If it is,
let me use this, it has value to me.  Let me use it to increas emy value
(perhaps transfer?  Allocate?  Compress?  Dare I say: Lease?)

But then I am told that IPv6 is here to stay, and IPv4 is valueless.  I
organised the Singapore IPv6 Day a dozen years ago.  Why are we tinkering
with something that is dying?  I mean, Members should be rushing to return
their IPv4 space to reduce their APNIC bills, right?

 --
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane

>
>
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable

[Sanjeev Gupta]

> If the leasing of addresses is authorized, contrary to the original
spirit of the policies and the very existence of the RIRs, the link
between connectivity and addresses disappears, which also poses security
problems, since, in the absence of connectivity, the resource holder who
has received the license to use the addresses does not have immediate
physical control to manage/filter them, which can cause damage to the
entire community.

Wait, so NIRs can no longer hand out addresses unless they provide
connectivity?  I believe they assign/allocate IR without providing
connectivity.



-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-155-v001: IPv6 PI assignment for associate members

[Sanjeev Gupta]

I am in favour of this.

-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane


On Fri, Aug 18, 2023 at 10:34 AM Bertrand Cherrier 
wrote:

> Dear SIG members,
>
> A new proposal "prop-155-v001: IPv6 PI assignment for associate members"
> has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on
> Thursday, 14 September 2023.
>
> https://conference.apnic.net/56/program/program/#/day/8/
>
> We invite you to review and comment on the proposal on the mailing list
> before the OPM.
>
> The comment period on the mailing list before the OPM is an important
> part of the Policy Development Process (PDP). We encourage you to
> express your views on the proposal:
>
>- Do you support or oppose this proposal?
>- Does this proposal solve a problem you are experiencing? If so,
>  tell the community about your situation.
>- Do you see any disadvantages in this proposal?
>- Is there anything in the proposal that is not clear?
>- What changes could be made to this proposal to make it more effective?
>
> Information about this proposal is appended below as well as available at:
>
> http://www.apnic.net/policy/proposals/prop-155
>
> Regards,
> Bertrand, Shaila, and Anupam
> APNIC Policy SIG Chairs
>
>
> ---
>
> prop-155-v001: IPv6 PI assignment for associate members
>
> 
>
> Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com)
>Simon Baroi (sba...@gmail.com)
>
>
> 1. Problem statement
> 
> The first tier of membership in APNIC is called "Associate." According
> to APNIC-121 (APNIC Membership: Tiers and Voting rights) Section 2.1 and
> 2.2, Associate members do not receive any IPv4 or IPv6 address space.
> However, APNIC Members with a delegated IPv4 address block but no IPv6
> space are instantly eligible for an appropriately sized IPv6 block
> without restrictions.
>
> If an entity requests only IPv6 assignment and has no IPv4 delegation,
> then as per APNIC-127 section 9.1.4 "Provider Independent IPv6
> assignments” they must submit a detailed usage plan for at least 12
> months following the allocation, with a minimum assignment size of /48.
> This incurs annual fees of AUD 1,180 based on the HD ratio.
>
> This policy is seen as a barrier to deploying IPv6, especially for
> personal use, as it doesn't incentivize IPv6 assignment alone. The
> proposal aims to address this issue by providing a Provider Independent
> assignment to Associate members with minimum justifiable eligibility.
> This change will remove the barrier and facilitate IPv6 deployment.
>
>
> 2. Objective of policy change
> -
> Provide an incentive to small enterprises and academia/researchers to
> receive IPv6 assignment.
>
>
> 3. Situation in other regions
> -
> RIPE NCC: IPv6 PI can be sponsored by an LIR (EUR 50/yr)
> ARIN: As an end-user IPv6 only can be requested following certain criteria
> AFRINIC: Must not be an LIR
> LACNIC: Not been an LIR or ISP, submit addressing plans for at least a year
>
>
> https://www.nro.net/wp-content/uploads/RIR-Comparative-Policy-Overview-2023-Q2.pdf
>
> Section 3.4.3 - END USERS
>
>
> 4. Proposed policy solution
> ---
> Summary of Proposed Changes:
> Allow associate members to apply for IPv6 PI resources with minimum
> justification criteria as currently specified in Section 9.1.4 of
> APNIC-114, provided that the member will use the resources in the next
> 12 months period.
>
> Update APNIC-114 "APNIC guidelines for IPv6 allocation and assignment
> requests" Section 9 as follows:
>
> Current: Organizations with a previously delegated IPv4 assignment from
> APNIC are eligible for an appropriately sized IPv6 block under Section
> 9.2.1 of the “APNIC Internet Number Resource Policies“.
>
> Proposed:
> Eligibility:
> Organizations or individuals with no previously delegated IPv4
> assignment from APNIC or any other Regional Internet Registry (RIR) are
> eligible to apply for a /48 IPv6 PI assignment.
>
> Eligible entities must meet the requirements specified in the APNIC
> policies for IPv6 PI assignments, including justification for the
> requested address space as specific in Section 9.1.4
>
> Agreement to Announce IPv6 Address Space:
> Organizations or individuals receiving a /48 IPv6 PI assignment must
> agree to use and announce the IPv6 address space within twelve (12)
> months from the assignment date.
>
> Monitori

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Sanjeev Gupta]

Shaila,

I oppose this, but not because of its details.

We (Operators) cannot have it both ways.  We have been screaming that IPv4
is over, since at least 2011.  Slicing it finer extends the pain, as well
as demonstrates to everyone that IPv4 is still a valuable, and required,
commodity.

Issue what we have. Then stop.  Let us not micromanage this.


-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane


On Tue, Aug 8, 2023 at 12:12 PM Shaila Sharmin 
wrote:

> Dear SIG members,
>
> A new proposal "prop-154-v001: Resizing of IPv4 assignment for the IXPs" has
> been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on Thursday,
> 14 September 2023.
>
>  https://conference.apnic.net/56/program/program/#/day/8/
>
> We invite you to review and comment on the proposal on the mailing list before
> the OPM.
>
> The comment period on the mailing list before the OPM is an important part
> of the Policy Development Process (PDP).
> We encourage you to express your views on the proposal:
>
>- Do you support or oppose this proposal?
>- Does this proposal solve a problem you are experiencing? If so,
>  tell the community about your situation.
>- Do you see any disadvantages in this proposal?
>- Is there anything in the proposal that is not clear?
>- What changes could be made to this proposal to make it more effective?
>
> Information about this proposal is appended below as well as available at:
>
>  http://www.apnic.net/policy/proposals/prop-154
>
> Regards,
> Bertrand, Shaila, and Anupam
> APNIC Policy SIG Chairs
>
>
> ---
>
> prop-154-v001: Resizing of IPv4 assignment for the IXPs
>
> 
>
> Proposer: Simon Sohel Baroi (sba...@gmail.com)
>Aftab Siddiqui
>
>
> 1. Problem statement
> 
> According to APNIC Internet Number Resource Policies ( Ref – APNIC-127,
> Dated: 22 DEC, 2022 ),
> an Internet Exchange Point ( IXP ) is eligible to receive a maximum /23
> of IPv4 and /48 of IPv6
> resources. Usually APNIC assign one /24 to start a new IXP. But from
> analysis through PeeringDB,
> we found most of the places the resources have been under-utilised and new
> IXPs are wasting a large
> amount of valuable IPv4 spaces. On the other side there are large IXP,
> who can’t grow due to
> lack of IP resources, where /23 is not enough as the membership number
> is big. The size of the
> minimum and maximum range of IP delegation to new or existing IXPs is
> the main problem in the
> current policy.
>
> Present IXP Status in APAC region from PeeringDB [5] :
>
> +---+---++---+--
> -+
> |  IX Names | Peers | Vs | Peers |  IX
> Names |
> +---+---+ +---+---+
> | BBIX Tokyo|  299  ||   17  |
> BBIX-Thailand |
> +---+---+ +---+---+
> | JPIX TOKYO|  257  ||   3   |
> MekongIX  |
> +---+---+ +---+---+
> | Equinix Tokyo |  131  ||   2   | Equinix
> Mumbai|
> +---+---+ +---+---+
> | JPNAP Tokyo   |  211  ||   13  | npIX
> JWL  |
> +---+---+ +---+---+
> | HKIX  |  296  ||   3   | Vanuatu Internet
> Exchange |
> +---+---+ +---+---+
> | Equinix Hong Kong |  216  ||   4   |
> MyNAP |
> +---+---+ +---+---+
> | Equinix Singapore |  422  ||   25  | DE-CIX Kuala
> Lumpur   |
> +---+---+ +---+---+
> | IIX-Jakarta   |  449  ||   13  |
> IIX-Lampung   |
> +---+---+ +---+---+
> | DECIX-Mumbai  |  446  ||   14  | Decix
> Kolkata |
> +---+---+ +---+---+
> | MegaIX Sydney |  232  ||   46  | EdgeIX -
> Melbourne|
> +---+---++---+--
> -+
>
>
> 2. Objective of policy change
> -
> The objective of this proposal is to modify the default size of IPv4
> assignm

[sig-policy] Re: Prop-152-v001: Reduce the IPv4 delegation from /23 to /24

[Sanjeev Gupta]

Wait, you can do that?

Well, I would like to request the APNIC EC for a /12 (although I am not
greedy, will take a /18 if they are a bit short this week).  Is there a
form for this?  Online? https://my.apnic/net/forms/O_PONY.html doesn't work
for me.

But seriously, I hope someone said no, and documented it, or a few years
from now AFRINIC members will be watching our proceedings.

-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane


On Mon, Jul 24, 2023 at 12:21 PM Rajesh Chharia  wrote:

> Dear Gaurav,
>
> I have requested APNIC EC to put a temporary halt on moving the resources
> from the reserve to available till this proposal outcome is determined.
>
> Regards
> Rajesh Chharia
>
> > On 24-Jul-2023, at 05:30, G  wrote:
> >
> > Returned/Reclaimed IP segments remains in 'Reserved' category for only
> one year (APNIC secretariat can correct me, if i am wrong) . Before the
> depletion of 'Available' pool, most of the current segments under
> 'Reserved' pool will already be moved to 'Available' category.
> >
> > So, whether the policy authors wants to not to move the 'Reserved' pool
> in 'Available' category or this policy will only applies on the segments
> available in 'Reserved' pool at the time of depletion of 'available' one ?
> > ___
> > SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
> > To unsubscribe send an email to sig-policy-le...@lists.apnic.net
> >
>
> ___
> SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-le...@lists.apnic.net
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]

[Sanjeev Gupta]

Hi,

I see this as more of a "do not make policy retroactively".  People who
"bought" an "asset" in good faith should not be told it is worth different
now.

I am amenable to changing the cut-off date in Prop-123 to the date it was
sent to the Policy SIG, as that might have given warning to people the
rules were changing.

APNIC Secretariat, how many transfers will be affected by Prop-123?


-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane

On Mon, Jan 29, 2018 at 4:16 AM, Henderson Mike, Mr <
michael.hender...@nzdf.mil.nz> wrote:

> Not supported
>
>
>
> The proposal should in my opinion be amended to read:
>
> ___
>
> Disadvantages:
>
>
>
> None Completely negates the purpose of prop-116-v006: Prohibit to transfer 
> IPv4 addresses in
>
> the final /8 block.
>
> ___
>
>
>
>
>
> Regards
>
>
>
>
>
> *Mike*
>
>
>
> *From:* sig-policy-boun...@lists.apnic.net [mailto:sig-policy-bounces@
> lists.apnic.net] *On Behalf Of *Bertrand Cherrier
> *Sent:* Friday, 26 January 2018 4:28 p.m.
> *To:* sig-pol...@apnic.net
> *Subject:* [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
>
>
>
> Dear SIG members,
>
> The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has
> been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 45 in
> Kathmandu, Nepal on Tuesday, 27 February 2018.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. We encourage you to
> express your views on the proposal:
>
>  - Do you support or oppose this proposal?
>  - Does this proposal solve a problem you are experiencing? If so,
>tell the community about your situation.
>  - Do you see any disadvantages in this proposal?
>  - Is there anything in the proposal that is not clear?
>  - What changes could be made to this proposal to make it more
>effective?
>
> Information about this proposal is available at:
>
>http://www.apnic.net/policy/proposals/prop-123
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
> https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt
>
> ---
>
>
>
> prop-123-v001: Modify 103/8 IPv4 transfer policy
>
>
>
> ---
>
>
>
> Proposer:Alex Yang
>
>  yang...@126.com
>
>
>
>
>
> 1. Problem statement
>
> ---
>
>
>
> Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses in
>
> the final /8 block reached consensus at the APNIC 44 AMM on 14 Sep
>
> 2017. Since that APNIC has stopped all the IPv4 transfers from 103/8
>
> block if the delegation date is less than 5 years.
>
>
>
> However, some of the 103/8 ranges were delegated before 14 Sep 2017.
>
> Those resources should not be subjected to 5 years restriction. The
>
> community was not aware of the restriction when they received those
>
> resources, some of the resources have been transferred or planning to
>
> transfer. If APNIC is not allow those transfers to be registered,
>
> there will be underground transfers. This will cause incorrect APNIC
>
> Whois data.
>
>
>
>
>
> 2. Objective of policy change
>
> ---
>
>
>
> To keep the APNIC Whois data correct.
>
>
>
>
>
> 3. Situation in other regions
>
> ---
>
>
>
> No such situation in other regions.
>
>
>
>
>
> 4. Proposed policy solution
>
> ---
>
>
>
> “Prohibit transfer IPv4 addresses under final /8 address block (103/8)
>
> which have not passed five years after its allocation/assignment”
>
> should only apply to those ranges were delegated from APNIC since 14
>
> Sep 2017.
>
>
>
>
>
> 5. Advantages / Disadvantages
>
> ---
>
>
>
> Advantages:
>
>
>
> - Allow APNIC to register those 103/8 transfers to keep the APNIC
>
>   Whois data correct.
>
>
>
>
>
> Disadvantages:
>
>
>
> None.
>
>
>
>
>
> 6. Impact on resource holders
>
> ---

Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG

[Sanjeev Gupta]

>  - Do you support or oppose the proposal?
Mild support.

>  - Do you see any disadvantages in this proposal?
No.

>  - Is there anything in the proposal that is not clear?
No.

>  - What changes could be made to this proposal to make it more effective?
An explicit requirement that the receiving party should be a current APNIC
member

Overall, I am not clear on how useful or often this will be, but I see no
disadvantages.  This will help improve the Whois database, and document
what is currently been done off-books.  It improves the paperwork.



-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane

On Wed, Aug 9, 2017 at 2:16 PM, chku <c...@twnic.net.tw> wrote:

> Dear SIG members
>
> The proposal "prop-119: Temporary transfers" was sent to the Policy SIG
> Mailing list in May 2017.
>
> It will be presented at the Open Policy Meeting at APNIC 44 which will
> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15 September
> 2017.
>
> Information about the proposal is available from:
>
> http://www.apnic.net/policy/proposals/prop-119
>
> You are encouraged to express your views on the proposal:
>
>  - Do you support or oppose the proposal?
>  - Do you see any disadvantages in this proposal?
>  - Is there anything in the proposal that is not clear?
>  - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Ching-Heng, Bertrand
> APNIC Policy SIG Chairs
>
>
> 
>
> prop-119-v001: Temporary transfers
>
> 
>
> Proposer:   David Hilario
> d.hila...@laruscloudservice.net
>
> 1. Problem statement
> 
>
> It is currently not possible for an organisation to receive a temporary
> transfer under the current policy framework. Some organisations do not
> want to have address space registered as assignments or sub-allocations,
> but would rather have the address space registered as "ALLOCATED PA".
>
>
> 2. Objective of policy change
> 
>
> Create a possibility for temporary transfers that would allow
> organisations to have resources directly registered under them while
> they are the custodians of these resources on the Internet. While also
> guaranteeing that the offering party will under the APNIC policy be able
> to recover the resources once the “lease” time has expired unless
> specifically renewed.
>
>
> 3. Situation in other regions
> 
>
> RIPE region has a concept of temporary transfers in their policies. This
> concept is not found in the other RIRs for the moment.
>
>
> 4. Proposed policy solution
> 
>
> Adding to section "8.2.1. Conditions on the space to be transferred" the
> following paragraphs: It must be specified if the transfer is a
> permanent or temporary transfer.
>
> A temporary transfer must have an end date, upon the end date the
> resources will be transferred back to the same origin account or its
> successor in the event of merger and acquisitions, unless the transfer
> is specifically prolonged and confirmed by both parties.
>
> If the source account does no longer exist and has no successor, the
> space will then be returned to the origin RIR for the space. Temporary
> transfers cannot be further transferred.
>
>
> 5. Advantages / Disadvantages
> 
>
> Advantages:
> Gives a greater flexibility in how LIRs manage and distribute their free
> pool. Enables organisation to receive address space in the way they
> intend.
>
> Disadvantages:
> These transfers would be treated and appear as regular transfers, only
> APNIC the offering and receiving party will be aware of their temporary
> nature.
>
> Organisations receiving such space, if they further assign it, must make
> be ready to renumber/revoke space from their customers and services then
> the lease expires, this is no different than a sub-allocation and
> implies the same limitations.
>
>
> 6. Impact on resource holders
> 
> none
>
>
> 7. References
> -
>
>
>
>
>
>
>
> ___
> Sig-policy-c

Re: [sig-policy] Revised prop-116-v003: Prohibit to transfer IPv4 addresses in the final /8 block

[Sanjeev Gupta]

On Sun, Jan 29, 2017 at 7:39 PM, Sumon Ahmed Sabir <su...@fiberathome.net>
wrote:

> 2) Market transfers containing 103/8 space
>
> +--+---+---+
> |  |   Total   | Number of |
> | Year | Transfers |   /24s|
> +--+---+---+
> | 2011 | 2 | 2 |
> | 2012 |21 |68 |
> | 2013 |16 |61 |
> | 2014 |25 |95 |
> | 2015 |67 |   266 |
> | 2016 |   103 |   394 |
> +--+---+---+


Would it be possible, for this and the preceding table, to have a column
with "Number of allocation made"?  This may help put the increasing trend
in context.


-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Sanjeev Gupta]

On Tue, Mar 3, 2015 at 2:04 PM, Scott Leibrand scottleibr...@gmail.com
wrote:


 See criterion #3 at https://blog.apnic.net/2014/09/02/2-byte-asn-run-out/
 for a brief explanation of why 2-byte ASNs are still preferred for IXP
 peering.


Scott, thank you.  I was looking only at the other peer, and its equipment,
supporting 4byte.  As we are not using communities (small operator, here),
I did not remember that use case.

-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Sanjeev Gupta]

On Fri, Feb 27, 2015 at 12:47 PM, Izumi Okutani iz...@nic.ad.jp wrote:

 May I clarify with APNIC hosmaster whether :

  a. It is a must for an applicant to be multihomed at the time of
 submitting the request

  b. If an applicant can demonstrate a plan to be multihomed in
 immediate future, it is not a must they are physically multihomed
 at the time of submitting a request


When I became an APNIC member in 2005, and applied for an ASN, I clearly
stated that I was _planning_ to multihome.  At that time, I did not even
have PI address space.

I had discussed with two service providers, and provided the network
diagram in my application.


-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Policy Outcomes from LACNIC 22

[Sanjeev Gupta]

On Tue, Nov 25, 2014 at 1:37 PM, Adam Gosling a...@apnic.net wrote:

 The proposal changes the ASN delegation criteria in such a way that the
 multi-homing requirement is no longer a requirement. If passed, the policy
 would require only that an network operator needs to interconnect with
 one other network ASN that has a different routing policy to its own.


With 4-byte ASNs, is there any concern that we might run out of ASNs before
we run out of IPv6 addresses?

-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

[Sanjeev Gupta]

On Tue, Sep 16, 2014 at 6:40 AM, Jay Daley j...@nzrs.net.nz wrote:



 Does anyone honestly believe that in the next say 50 years we will have
 less than 1,048,576 organisations who might have ambitions one day to have
 a /20 or less than 8,192 who think they are as big and important as the US
 DoD? (Ignoring the fact that the number of /20s will be less than that
 given the larger allocations made).


I have ambitions of having a /20 IPv6 allocation.  Ambitions are easy.  But
APNIC will ask for justification, I suppose.

If the US DoD, or Toyota, can justify a /20, sure, why not?

Frankly, given the current state of the Routing Registeries, and RPKI, etc,
having BGP announcements on hex-digit boundaries would greatly help
troubleshooting by eyeball.

I support using /28 , and then /24 , etc, rather than /29 or /27 or
whatever.  I know this is inefficient, and realise that 50 years from now,
it will be seen as stupid and wasteful.  But 50 years from now, they are
unlikely to care how APNIC handled allocations.

-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED]

[Sanjeev Gupta]

On Wed, Sep 3, 2014 at 7:07 AM, HENDERSON MICHAEL, MR 
michael.hender...@nzdf.mil.nz wrote:

 However, I understand the current situation is that the ‘legacy’ IPv6
 address allocation was for smaller allocations within blocks on /29
 boundaries, if I read the Proposition correctly.

 As a special case only, I would support the allocation of these ‘legacy
 /29’ blocks. The provisos being that firstly they do fall into this
 ‘legacy’ category, and that secondly it is not possible (owing to
 allocation to a third party) to allocate a /28 to the relevant resource
 holder


I agree.  As a small operator, who spends time helping other small
operators offer IPv6, it would greatly benefit us if allocation (and hence
our BGP announcements and filters) were on a /32 or /28.

To those who are already within a /29, and the adjacent /29 is also
allocated, a /29 is the least evil.  But new allocations should be of, or
from, a /28.


-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Returned to SIG: prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure

[Sanjeev Gupta]

On Mon, Mar 10, 2014 at 3:43 PM, Owen DeLong o...@delong.com wrote:


 Can you give me an example of what would be the scenario here?  Assuming I
 am the upstream ISP of the hosts I control, willing to subject them to
 vast quantities of traffic.  Would I announce 1.2.3.0/24 upstream, and
 point it to my customer's link?


 I'm not assuming that the upstream ISP would be the malefactor. That is,
 in fact, a rather odd assumption, is it not?


Very odd, but I was trying to think of ways to force someone to use my
servers.


 OTOH, if you are a malefactor that wants to turn your botnet into
 anycasted DNS servers to issue incorrect redirections to others, getting
 said botnet (or its upstream routers if you are able to control them
 somehow) to announce 1.2.3.0/24 really doesn't pose any problem to you as
 a result of the traffic it generates.


This is the part that I really do not understand.  Suppose I control a
significant number of Windows7 PCs, and a few Cisco Routers, in your
network, through a CC botnet.  How would I get them (the PCs) to make
announcements for 1.2.3.0/24?  I could install quagga (after porting it)
quietly on them, but who would the Windows 7 PCs peer with?  Only the
routers under my control?  In which case, what would be the point?

I could get the Ciscos to startup BGP, and start announcing 1.2.3.0/24 ,
but to whom?  Again, I can only peer if I control both sides of the link,
and if I control both sides, why do anycast anywhay?  I have control on the
RIB.

If I controlled the Routers at the edge of your network, I could redirect
traffic from your nodes to any address I wished.  This requires no new DNS,
or 1.2.3.0/24 routing.

There is one other case I can think of.  Start DNS servers on the zombie
PCs, assign them 1.2.3.4, and use them as a DNS server farm.  But who would
come to them?  If this was a home network (or any kind of leaf network),
assigning 8.8.8.8 to my interface does not make you next to me send your
DNS query to me.



 Or would I announce 1.2.3.0/24 from another ISP's origin AS?


 Not sure how that would work or help other than in an attempt to cover
 your tracks.


Thank you, so we can close that scenario I postulated as invalid.


 How would (evil me) be able to hurt hosts other than on _my_ network?


 You are assuming that you are doing this with routers you own (in the
 commercial sense of the word). I am assuming someone doing this with
 routers that they control (in the enable access sense of the word) but do
 not own (in the commercial sense of the word).

 Malefactors these days are rather well known for using other people's
 equipment to carry out their misdeeds, or are you unfamiliar with the term
 botnet?


I am aware of the concept, and some implementations.  And I appreciate your
distinction between the the own and control part, it helps bisect the
problem.

Suppose I subvert a router in your network (might be your edge router,
might be an internal).  Now what?  Where does 1.2.3.0/24 come into the
picture?


 I am not doubting that people would not want to misuse this, but how would
 this work in the case you have outlined?


 I hope I have adequately clarified.


I can understand if I am being too slow in picking up something obvious.  I
am still nt seeing a _new_ attack vector _due_ to 1.2.3.0/24 being allowed
to be used internally (and even leaking externally).


-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Returned to SIG: prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure

[Sanjeev Gupta]

On Wed, Mar 5, 2014 at 5:33 AM, Masato Yamanishi myama...@japan-telecom.com
 wrote:

 Is there anyone who want to continue this proposal?


I read the Transcript, and saw the comment made on the inadvisability of
1.2.3.4/24 being used as a DNS resolver.  I am not sure that this concern
is either new enough, or severe enough, to substantially cause the proposal
to be dropped.

To quote the Transcript:


Yoshinobu Matsuzaki (IIJ): Let me clarify

why I oppose to the prop-110, because

it's creating a new security risk.  Once

the broadband router is set with default

setting, that DNS reserve the 1.2.3.4, if

there's no DNS server maintained by ISP,

probably it's query to the DNS server in

the Internet, and sometimes it's

maintained by good guy, but sometimes it

could be maintained by bad boy.  Right?




I see two scenarios which might lead to to this objection: (Yamanishi-san,
please forward this email to mazz if he is not on this list.  I hope I am
not misunderstanding his objections.)

   1. Consumer Router manufacturers might start hardcode-ing 1.2.3.4 as the
   default DNS resolver, and this may be someone outside the ISP's network.  I
   appreciate that this may happen, and I have seen similar things happen re:
   NTP servers.  I do not, however, think this is either going to be likely,
   or widespread.  At least in S E Asia, I have not seen any Home Routers with
   even Google's PDNS hardcoded into them.  As such, I do not think D-Link or
   Linksys (as an example) is likely to ship devices with 1.2.3.4 as the
   default.  The support costs for D-Link if this does not work would be
   prohibitive.
   2. Second, the Home Device could be re-sold, with 1.2.3.4 as the DNS
   setup, and the new owner would be unknowingly be using it.  I consider this
   extremely unlikely to happen accidentally.  The new owner would (unless he
   had exactly the same ISP and setup) need to review settings, perhaps a
   factory default.  And if he had the same ISP and setup as the previous
   owner, then there would be no additional danger anyway.

As such, I am not saying that a bad network operator could not announce
1.2.3.4, and wait for people to use him.  I am saying that this is not an
additional danger, many people already use 8.8.8.8. and 4.4.2.2, for
example, or OpenDNS.

And any person deciding to announce 1.2.3.0/24 to the open network, would
have to face a massive traffic storm anyway.  prop-109 by Geoff Huston
mentions the traffic flowing to certain easily-remembered ranges.  Assuming
that 1.2.3.0/24 gets even 50Mbps of traffic if I announce it to the
Internet, that is till still an expensive pipe, and probably not worth it
on the off-chance that a random user will use it and allow evil me to
redirect him to the particular bank that he is a member of, and which I am
forging a website for.
To summarize, there is no ADDITIONAL danger, and there are some advantages
to this proposal.  I would like work on this proposal to continue, and see
if we can address the concerns raised at the APNIC Meeting.

(BTW, I see that AS15169, Google, is still advertising 1.2.3.0/24.  This
may be due to the APNIC-YouTube experiment).
-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy