Re: ARIN fee structure (was: re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT)

[Owen DeLong via NANOG]

> On Apr 6, 2022, at 04:48 , John Curran  wrote:
> 
> On 5 Apr 2022, at 11:57 PM, William Herrin  > wrote:
>> 
>> On 5 Apr 2022, at 8:38 PM, Dan Mahoney (Gushi) > > wrote:
>>> But say they sign an LRSA: Those $0 fees would go up to 150, this year, 175 
>>> next year, 200 the following...250 in year five... to be able to simply add 
>>> DNSSEC, RPKI, and Validated IRR.
>> 
>> Hi Dan,
>> 
>> Speaking for myself, I'd be happy to pay the normal block size fee
>> just to get DNSSEC, RPKI and a validated IRR. I pay $80/month just for
>> my residential Internet service and another $80 or so for my off-site
>> virtual machines. A couple hundred bucks a _year_ for the niceties
>> which come with ARIN registration is no imposition at all.
> 
> Bill - 
> 
> Good to hear - one hopes that the value is sufficient (but we should still 
> look for opportunities for further improvements on both services and fees.) 
> 
>> My objection lies in having ARIN's RSA adhere to my address block
>> overall. I may feel differently about ARIN next year than I do this
>> year but once I've signed that RSA, well, that's just too bad. I now
>> have obligations to ARIN, some of them on shifting sand, and if I
>> don't fulfill them the addresses are gone.
> 
> 
> That’s an Interesting perspective - thank you for sending.   It is true that 
> both you and ARIN have obligations once you sign an RSA, but that’s true of 
> any standardized agreement that you enter – standard agreements are found 
> everywhere in life and are enforceable if applied uniformly with reasonable 
> terms. 

Most standard agreements don’t include “And if you terminate the agreement, we 
take away your toys.”

> The part of your statement I don’t understand is that some of your 
> obligations to ARIN are "on shifting sand"… If anything, you’ve got more 
> protections in place regarding your ARIN RSA agreement than likely in most 
> other standard agreement contexts (although it is true that we at ARIN don’t 
> exactly emphasize these aspects as often as we might…) 

For example, the ARIN community can at any time change policy or the board can 
enact changes in the fee structure and there is no ability to opt out of these 
changes and preserve the original terms of the agreement.

> Unlike many other standard agreements that you might find yourself in:
> 
> ARIN is an actual membership organization and governed accordingly.  Every 
> customer with IPv4 or IPv6 resources under agreement is an ARIN member and 
> has the option to participate in the ARIN election for Trustees and ARIN AC 
> members.  >(I 
> know of many not-for-profits that have “members” but not actual membership 
> organizations, and the difference is substantial regarding one’s legal rights 
> and enforceability of same.) 
> While ARIN previously did have the ability to revise your registration 
> services agreement (RSA) at will, we’ve achieved sufficient stability that it 
> was possible to end that flexibility – now ARIN may only modify the terms of 
> the RSA agreement if necessary due to a specific change in relevant statute 
> or caselaw, or upon recommendation of the Board _and_ ratification vote by 
> the ARIN members. 

Yes, but changing the effective terms of the agreement doesn’t require 
modifying the agreement any more, either. (See above)

> If ARIN fails to live up to its obligations under the agreement and our 
> performance is found to have provided valid cause for termination, the 
> agreement ends – and you keep your legacy number resources with them 
> returning to their status before agreement. 

Yes, but if you don’t have a contract with ARIN, ARIN’s ability to revoke your 
resources because the community decided it might be fun is significantly less 
certain for ARIN at best and highly unlikely at worst.

> It is true that our number resource policies are subject to change by the 
> community through the open policy development process, and therefore your 
> obligations under them might be the “shifting sand” to which you refer.  If 
> that’s the case then I understand the reference, but as you’re aware that’s 
> an inevitable consequence of having community-driven number resource policy – 
> ARIN’s number resource policy instantiates community consensus regarding such 
> obligations, which is not much different than obligations/expectation that 
> networks face in other aspects of Internet operation, aside from actually 
> being clearly written down in one place when it comes to the registry 
> obligations. 

I think it’s more about the consequences if one no longer wishes to abide the 
agreement. The fact that one cannot terminate the agreement voluntarily and 
return to the previous status is, I believe, the sticking point.

Owen

Re: [nanog] 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40

[Owen DeLong via NANOG]

> On Apr 5, 2022, at 15:04 , John Curran  wrote:
> 
> 
>> On 5 Apr 2022, at 5:31 PM, Owen DeLong > > wrote:
>>> On Apr 4, 2022, at 17:40 , John Curran >> > wrote:
>>> ...
>> 
>>> Interesting – as ARIN’s fee schedule was designed specifically so that 
>>> every IPv4 customer can get a corresponding-sized IPv6 block without any 
>>> change in annual registry fees.
>>> (i.e. I’d be interested in hearing more; on- or off- list as you prefer)   
>>> If you mean that you’d need to pay the same amount of fees of everyone else 
>>> whose received similar sized IPv6 blocks, then yes, I am afraid this is the 
>>> case. 
>> 
>> Not exactly true… Any IPv4 customer with an LRSA does not have this option 
>> because you can’t put your v6 resources on your LRSA and if you have two 
>> accounts (whether you created a second account or whether ARIN
>> split your accounts without some much as asking you if that was desired), 
>> they get charged each and no possibility for the fee calculation you 
>> describe exists.
> 
> Correct - ARIN caps the total registry maintenance fees for legacy resource 
> of those who do enter an RSA with ARIN to $150/yr (the cap increasing 
> $25/year) – the legacy cap only covers the fees for registration services for 
> IPv4 number resources, so it must be billed separately and not part of a 
> registration services plan that includes both IPv4 and IPv6 resources. 
> 
> You can consolidate to one relationship if you wish - and end up paying the 
> very same registry fees as everyone else – but then the legacy fee cap 
> doesn’t apply because you’ve got IPv4 and IPv6 resources under the same 
> service plan.
> 
> This is a case where no good deed goes unpunished - by providing a registry 
> fee cap specifically for legacy resource holders, it can sometimes lead to a 
> financial disincentive for legacy holders to get IPv6 resources since they 
> would then end up paying the exact same fees as everyone else. 

Well, I’m not as convinced as you clearly are that there are good deeds 
involved here.

I proposed a number of ways in which ARIN could have preserved the fee cap for 
v4 and allowed LRSA recipients to pay MAX(v4Legacy,V6) vs. the current 
situation where they pay SUM(v4Legacy,V6).

It really wouldn’t be all that difficult to do and, in fact, doesn’t differ 
significantly from previous ARIN billing structures (dating back pre-LRSA).

Fortunately, the problem is solved for me. I now have my legacy v4 resources 
registered in RIPE-NCC with no fees and no contract and my ARIN v6 is, indeed, 
charged separately, but at least I’m no longer being double-billed.

I highly recommend this avenue to other LRSA signatories.

>> As such, your claim here, especially in the context of a discussion of 
>> legacy resources is a bit disingenuous and we’ve discussed it enough times 
>> that you cannot claim to be unaware of this fact.
> 
> 
>   No, Owen, it was not disingenuous, but rather speaking the truth 
> about ARIN’s fee schedule and its properties, and as I clearly noted in 
> earlier message "If you mean that you’d need to pay the same amount of fees 
> of everyone else whose received similar sized IPv6 blocks, then yes, I am 
> afraid this is the case.”   The legacy fee cap that ARIN provides (for those 
> bringing legacy resources under a RSA) is appreciated by many, but the side 
> effect can be seeing a net increase when you obtain IPv6 resources and return 
> to the normal fee schedule used by everyone else. 

Spin it however you wish, the claim of “exactly the same” is NOT true if you 
continue to hold your LRSA. In a lot of cases, the amount of v4 held puts one 
in a higher fee tier then a basic v6 assignment or allocation, even with fairly 
minimal (0.75 /22s, for example) IPv4 holdings.

Yes, it is true if you give up your LRSA fee cap and merge your IPv4 resources 
into an RSA, but, as I mentioned, that often involves a substantial increase in 
annual fees, in many cases in excess of the double-billed amount that results 
from keeping two contracts.

Owen

> 
> Thanks,
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 

Puerto Rico (island-wide) power outage

[Sean Donelan]

The island-wide electrical grid has failed on Puerto Rico.


From the utility company:


Fault in the output breaker of Unit #5 of Costa Sur at 230kv caused the 
output of units 5 and 6 of the Central. The electrical system protection 
system took the rest of the units that were generating out of service.

Re: IP Multicast Persistent Duplicate Packet Issue

[Roman Islam]

Thanks Jared. Yes it is SSM. I will try to flip PIM priority and align HSRP
active.

My initial thought was keeping everything as it is. Can I simply flip PIM
assert winner to PE1. Same way we can manually select STP root. Looks like
this is probably not an option. Didn't find relevant doc on how to
manipulate PIM assert winner in Cisco boxes though. Highest IP is the
winner if IGP costs are the same to the source.

R


On Thu, Apr 7, 2022 at 3:02 AM Jared Mauch  wrote:

> If this is ASM, what device is the RP?  You may want to configure MSDP
> between PE1/PE2 to help if that’s the case, or is this SSM or something
> else you may want to just flip the PIM priority to make it pick what you
> want and see if you can tie it to your HSRP (Cisco, might I suggest VRRP so
> you could do dual-vendor later?) state, perhaps with EEM script to keep the
> config in sync if required.
>
> - Jared
>
> > On Apr 6, 2022, at 3:25 AM, Roman Islam  wrote:
> >
> > Hi Everyone,
> >
> > Has anyone experienced a TETRA Radio application issue if underlying IP
> multicast transport sends persistent duplicate packets?
> >
> > Here is my scenario as below:
> >
> > PIM is running on the MPLS L3 VPN environment. C multicast is running on
> a single VRF (TETRA) only. Source is running behind a dual home PE. HSRP,
> PIM DR path is via PE1 to the source. Anycast RP is configured with PE1 &
> PE2.
> >
> > On the receiver side there is a single PE. When I check (S,G) route on
> the receiver side PE default MDT is working as expected. After the
> threshold exceeds it switches to the data MDT. PIM Assert mechanism winner
> is PE2 though (Since PE 2 has the highest IP and source is behind dual home
> PE with equal cost I guess).
> >
> > Can this be a reason for persistent duplicate multicast packets at the
> receiver side; since the assert winner is PE2 but HSRP, PIM DR path is via
> PE1 to the source?
> >
> > If this is the case is there any way to manually configure the assert
> winner to PE1?
> >
> > Roman
>
>

Re: IP Multicast Persistent Duplicate Packet Issue

[Jared Mauch]

You can likely set "ip pim dr-priority" to get what you want

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti/command/imc-cr-book/imc_i3.html#wp1384657000

- Jared

On Thu, Apr 07, 2022 at 09:07:34AM +1000, Roman Islam wrote:
> Thanks Jared. Yes it is SSM. I will try to flip PIM priority and align HSRP
> active.
> 
> My initial thought was keeping everything as it is. Can I simply flip PIM
> assert winner to PE1. Same way we can manually select STP root. Looks like
> this is probably not an option. Didn't find relevant doc on how to
> manipulate PIM assert winner in Cisco boxes though. Highest IP is the
> winner if IGP costs are the same to the source.
> 
> R
> 
> 
> On Thu, Apr 7, 2022 at 3:02 AM Jared Mauch  wrote:
> 
> > If this is ASM, what device is the RP?  You may want to configure MSDP
> > between PE1/PE2 to help if that’s the case, or is this SSM or something
> > else you may want to just flip the PIM priority to make it pick what you
> > want and see if you can tie it to your HSRP (Cisco, might I suggest VRRP so
> > you could do dual-vendor later?) state, perhaps with EEM script to keep the
> > config in sync if required.
> >
> > - Jared
> >
> > > On Apr 6, 2022, at 3:25 AM, Roman Islam  wrote:
> > >
> > > Hi Everyone,
> > >
> > > Has anyone experienced a TETRA Radio application issue if underlying IP
> > multicast transport sends persistent duplicate packets?
> > >
> > > Here is my scenario as below:
> > >
> > > PIM is running on the MPLS L3 VPN environment. C multicast is running on
> > a single VRF (TETRA) only. Source is running behind a dual home PE. HSRP,
> > PIM DR path is via PE1 to the source. Anycast RP is configured with PE1 &
> > PE2.
> > >
> > > On the receiver side there is a single PE. When I check (S,G) route on
> > the receiver side PE default MDT is working as expected. After the
> > threshold exceeds it switches to the data MDT. PIM Assert mechanism winner
> > is PE2 though (Since PE 2 has the highest IP and source is behind dual home
> > PE with equal cost I guess).
> > >
> > > Can this be a reason for persistent duplicate multicast packets at the
> > receiver side; since the assert winner is PE2 but HSRP, PIM DR path is via
> > PE1 to the source?
> > >
> > > If this is the case is there any way to manually configure the assert
> > winner to PE1?
> > >
> > > Roman
> >
> >

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: V6 still not supported

[Mark Andrews]

There is also Customer contacts ACCC in Australia and complains that Sony is 
not supplying a working product and Sony gets fined and instructed to change 
their rules about customers behind CGNATs.

> On 7 Apr 2022, at 03:24, Jared Brown  wrote:
> 
> Owen DeLong via NANOG wrote:
>>> I would expect the trend to become that ISP's refuse to accommodate 3rd 
>>> party vendors shenanigans to the point where it hampers their operations or 
>>> to the point where it cost them more to do so.
>> 
>> $ISP_1 refuses to accommodate Sony’s shenanigans…
>>  Three possible outcomes:
>  The three possible outcomes assume status quo is maintained.
> 
>  However, if ISP A makes a business decision to not accommodate 3rd party 
> shenanigans and modifies policies accordingly, then we have a new equilibrium.
> 
>  Outcome 1 is maintained: Customer churns off ISP A. Everybody wins.
> 
>  Outcome 2 is no longer a single outcome, but rather several:
>   a. Customer is upsold to gaming package which includes a static IP. 
>   b. Customer returns Playstation and buys Xbox instead.
>   c. Customer declines gaming package, but continues to bother customer 
> service. Customer is directed to 3rd party customer support. Further customer 
> contact is handled via self service portals and other low cost customer 
> service channels.
>   d. Customer terminates contract and goes offline.
> 
>  Outcome 3 is resolved by ISP A telling returning customers that service at 
> that address is only available if ordered together with the gaming package.
> 
>> All of this, of course, becomes an effective non-issue if both $ISP and Sony 
>> deploy IPv6 and get rid of the stupid NAT tricks.
>  Well yes...
> 
>  ... but why would Sony do that when they have so conveniently externalized 
> all costs?
> 
> 
> - Jared

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Enhance CG-NAT Re: V6 still not supported

[Abraham Y. Chen]

Hi, Bill:

0)    Thanks for bringing up the NANOG posting guideline. We now have 
something tangible to discuss.


1)    Section 6. looks most relevant. So, I copy and paste it below for 
our discussion:


    A.    6.1.1. "... > relevant excerpt 1   response to excerpt 1 ... 
   ":    This seems to be what I have been doing, except maybe how to 
interpret the keyword "excerpt". Perhaps you are expecting me to cite 
more text from the message that I am responding to, such as a complete 
paragraph, instead of only a short phrase or two? If so, I certainly 
will be glad to do so.


    B.    On the other hand, the leading sentence "When posting to the 
NANOG list please avoid: Top-posting, i.e., putting your reply right on 
top of the message you're responding to,  ...   " seems to discourage 
threading the messages (keeping a long tail of the earlier texts)?


    Perhaps there is some kind of optimal trade-off between how much 
each of these two should be included in a message?


2)    The two URLs are kind of odd:

    A.    The first URL led me to a blank webpage.

    B.    The second URL led me to a list of Q's that seem to be more 
humorous than instructive.


***
*6. Posting Conventions*

1. *Format*
   When posting to the NANOG list please avoid:
1. Top-posting, i.e., putting your reply right on top of the
   message you're responding to, rather than quoting and responding
   as follows: > relevant excerpt 1
   response to excerpt
> relevant excerpt 2
   response to excerpt
> relevant excerpt 3
   response to excerpt
2. Using non-standard methods of quoting prior text;
3. Failing to quote, or to snip, as appropriate;
4. Sending in HTML or other non-standard attachment formats;
5. Starting or participating in flame wars.
   The linux-kernel mailing list FAQ provides detailed instructions
   for* quoting prior text*:

   http://www.tux.org/lkml/#s3-9


   "Dear Emily Postnews" at
   http://www.templetons.com/brad/emily.html makes lots of good
   suggestions about *signatures* and other items of interest.

***

Please review and advise.

Regards,


Abe (2022-04-06 17:31)




On 2022-04-06 11:33, William Nelson wrote:



I am still learning the proper eMail etiquette on NANOG. Could you please echo 
back some of my writings as you received? So that I can see what they got 
transformed to.



There is no transforming of your formatting after you send it.  It's 
frustrating in the format you typed it in.

https://archive.nanog.org/list/faq#posting

-bn.



Confidentiality Notice:

This email message, any attachment, and the information therein is 
confidential, intended only for the named recipient(s), and may contain 
material that is proprietary, privileged, or otherwise private under applicable 
law. If you have received this message in error, or are not a named recipient:
  
(1) You are advised that any disclosure, copying, distribution or use of this email, or the information in its content, is strictly prohibited;


(2) We ask you immediately to notify the sender by return email or contact 
Third Federal at 1-800-THIRD-FED (1-800-844-7333);

(3) We instruct you to delete this email message and any attachment from your 
computer.

Thank you.





--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: ARIN fee structure (was: re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT)

[John Curran]

On 6 Apr 2022, at 1:32 PM, William Herrin  wrote:
> 
> On Wed, Apr 6, 2022 at 4:48 AM John Curran  wrote:
>> On 5 Apr 2022, at 11:57 PM, William Herrin  wrote:
>>> My objection lies in having ARIN's RSA adhere to my address block
>>> overall. I may feel differently about ARIN next year than I do this
>>> year but once I've signed that RSA, well, that's just too bad. I now
>>> have obligations to ARIN, some of them on shifting sand, and if I
>>> don't fulfill them the addresses are gone.
>> 
>> That’s an Interesting perspective - thank you for sending.   It is true that 
>> both you and ARIN have obligations once you sign an RSA, but that’s true of 
>> any standardized agreement that you enter – standard agreements are found 
>> everywhere in life and are enforceable if applied uniformly with reasonable 
>> terms.
> 
> Hi John,
> 
> Why should I need an agreement with ARIN on the disposition of
> addresses which are already mine? 

Bill - 

You don’t need an agreement in such a case (since ARIN’s already maintaining 
your address blocks in the registry without any fee or contract.) 

> Offer me an agreement confined to
> the things I don't have, like RPKI, and you'll empower me to do my
> part in making BGP a safer place without demanding I take on new risk.

Interesting philosophy - historically ARIN customers have asked for simplicity 
in the relationship; i.e. a single fee that encompasses all of the services - 
in this way, an organization can utilize something without having to “get new 
approval” and there’s no financial or service disincentive for deployment of 
IPv6, IRR, RPKI, etc.

Feel free to propose an alternative structure if you think it makes sense - the 
suggestion process would be a good step (but feel free to run for the ARIN 
Board of Trustees if you want to really advocate for a different approach.)

>> The part of your statement I don’t understand is that some of your 
>> obligations to ARIN are "on shifting sand"… If anything, you’ve got more 
>> protections in place regarding your ARIN RSA agreement than likely in most 
>> other standard agreement contexts (although it is true that we at ARIN don’t 
>> exactly emphasize these aspects as often as we might…)
> 
> Compliance with ARIN public policy is incorporated by reference. ARIN
> policy shifts. ARIN business practices such as the fee structure are
> incorporated by reference. The business practices shift. Indeed, the
> fee structure was rearranged last year in a way that undermined one of
> the central tenets of the LRSA. To the consternation of some of the
> folks who had signed the LRSA.
> 
> The RSA requires the registrant to comply not just with the conditions
> at the time of signing but also with the ones which develop later. And
> tough luck if the registrant doesn't like them.
> 
> I'm on the same shifting sands with nearly every company I do business
> with. But in each of their cases, it's a trivial matter to switch to a
> competitor if I don't like next year's deal. I have no such risk
> mitigation in my interactions with ARIN. Perhaps if I was a
> multinational company doing business in multiple regions but alas I am
> not.

Indeed - you only emphasize why it is important for organizations to get 
involved in ARIN’s governance…  It is not intended that your sole interaction 
with ARIN be via contractual mechanisms, but rather that network operators 
actually participate as members of the organization.

Thanks, 
/John

John Curran
President and CEO
American Registry for Internet Numbers

Looking for an Amazon Cloudfront contact

[Eric Kuhnke]

It looks like I may have a range of recently put into use residential
symmetric gigabit last mile IP space that's being filtered/blocked at the
application level.

Please contact me off-list.

Re: ARIN fee structure (was: re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT)

[William Herrin]

On Wed, Apr 6, 2022 at 4:48 AM John Curran  wrote:
> On 5 Apr 2022, at 11:57 PM, William Herrin  wrote:
>> My objection lies in having ARIN's RSA adhere to my address block
>> overall. I may feel differently about ARIN next year than I do this
>> year but once I've signed that RSA, well, that's just too bad. I now
>> have obligations to ARIN, some of them on shifting sand, and if I
>> don't fulfill them the addresses are gone.
>
> That’s an Interesting perspective - thank you for sending.   It is true that 
> both you and ARIN have obligations once you sign an RSA, but that’s true of 
> any standardized agreement that you enter – standard agreements are found 
> everywhere in life and are enforceable if applied uniformly with reasonable 
> terms.

Hi John,

Why should I need an agreement with ARIN on the disposition of
addresses which are already mine? Offer me an agreement confined to
the things I don't have, like RPKI, and you'll empower me to do my
part in making BGP a safer place without demanding I take on new risk.


> The part of your statement I don’t understand is that some of your 
> obligations to ARIN are "on shifting sand"… If anything, you’ve got more 
> protections in place regarding your ARIN RSA agreement than likely in most 
> other standard agreement contexts (although it is true that we at ARIN don’t 
> exactly emphasize these aspects as often as we might…)

Compliance with ARIN public policy is incorporated by reference. ARIN
policy shifts. ARIN business practices such as the fee structure are
incorporated by reference. The business practices shift. Indeed, the
fee structure was rearranged last year in a way that undermined one of
the central tenets of the LRSA. To the consternation of some of the
folks who had signed the LRSA.

The RSA requires the registrant to comply not just with the conditions
at the time of signing but also with the ones which develop later. And
tough luck if the registrant doesn't like them.

I'm on the same shifting sands with nearly every company I do business
with. But in each of their cases, it's a trivial matter to switch to a
competitor if I don't like next year's deal. I have no such risk
mitigation in my interactions with ARIN. Perhaps if I was a
multinational company doing business in multiple regions but alas I am
not.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: V6 still not supported

[Jared Brown]

Owen DeLong via NANOG wrote:
>> I would expect the trend to become that ISP's refuse to accommodate 3rd 
>> party vendors shenanigans to the point where it hampers their operations or 
>> to the point where it cost them more to do so.
>
> $ISP_1 refuses to accommodate Sony’s shenanigans…
>   Three possible outcomes:
  The three possible outcomes assume status quo is maintained.

  However, if ISP A makes a business decision to not accommodate 3rd party 
shenanigans and modifies policies accordingly, then we have a new equilibrium.

  Outcome 1 is maintained: Customer churns off ISP A. Everybody wins.

  Outcome 2 is no longer a single outcome, but rather several:
   a. Customer is upsold to gaming package which includes a static IP. 
   b. Customer returns Playstation and buys Xbox instead.
   c. Customer declines gaming package, but continues to bother customer 
service. Customer is directed to 3rd party customer support. Further customer 
contact is handled via self service portals and other low cost customer service 
channels.
   d. Customer terminates contract and goes offline.

  Outcome 3 is resolved by ISP A telling returning customers that service at 
that address is only available if ordered together with the gaming package.

> All of this, of course, becomes an effective non-issue if both $ISP and Sony 
> deploy IPv6 and get rid of the stupid NAT tricks.
  Well yes...

  ... but why would Sony do that when they have so conveniently externalized 
all costs?


- Jared

Re: IP Multicast Persistent Duplicate Packet Issue

[Jared Mauch]

If this is ASM, what device is the RP?  You may want to configure MSDP between 
PE1/PE2 to help if that’s the case, or is this SSM or something else you may 
want to just flip the PIM priority to make it pick what you want and see if you 
can tie it to your HSRP (Cisco, might I suggest VRRP so you could do 
dual-vendor later?) state, perhaps with EEM script to keep the config in sync 
if required.

- Jared

> On Apr 6, 2022, at 3:25 AM, Roman Islam  wrote:
> 
> Hi Everyone,
> 
> Has anyone experienced a TETRA Radio application issue if underlying IP 
> multicast transport sends persistent duplicate packets?
> 
> Here is my scenario as below:
> 
> PIM is running on the MPLS L3 VPN environment. C multicast is running on a 
> single VRF (TETRA) only. Source is running behind a dual home PE. HSRP, PIM 
> DR path is via PE1 to the source. Anycast RP is configured with PE1 & PE2. 
> 
> On the receiver side there is a single PE. When I check (S,G) route on the 
> receiver side PE default MDT is working as expected. After the threshold 
> exceeds it switches to the data MDT. PIM Assert mechanism winner is PE2 
> though (Since PE 2 has the highest IP and source is behind dual home PE with 
> equal cost I guess).
> 
> Can this be a reason for persistent duplicate multicast packets at the 
> receiver side; since the assert winner is PE2 but HSRP, PIM DR path is via 
> PE1 to the source? 
> 
> If this is the case is there any way to manually configure the assert winner 
> to PE1? 
> 
> Roman

Now open - 2022 ARIN Community Grants for Internet infrastructure development/research projects

[John Curran]

NANOGers -

The ARIN Community Grant program has opened its 2022 "call for applications”.   
If you are aware of a non-commercial development or research project that could 
enhance Internet operations and might benefit from additional funding, please 
bring this opportunity to their attention.   More information attached below.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

===
From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] Apply Now for an ARIN Community Grant
Date: 6 April 2022 at 11:11:35 AM EDT
To: "arin-annou...@arin.net" 
mailto:arin-annou...@arin.net>>

Do you have a project that needs funding, is non-commercial in nature, and 
benefits the Internet community with the ARIN service region? Apply now for a 
2022 ARIN Community Grant.

The ARIN Community Grant Program provides financial grants in support of 
operational and research projects that improve the overall Internet industry 
and Internet user environment that advance ARIN’s mission and broadly benefit 
the Internet community within the ARIN region. Projects must fit into one or 
more of these four broad categories:

• Internet technical improvements that promote and facilitate the expansion, 
development, and growth of the infrastructure of the Internet consistent with 
the public interest
• Registry processes and technology improvements that help maintain a globally 
consistent and highly usable Internet Number Registry system
• Informational outreach that advances the Internet on topics such as, but not 
limited to: IPv6 deployment, Internet research, and Internet governance
• Research related to ARIN’s mission and operations

For 2022, the ARIN Board of Trustees has approved a total expenditure of up to 
$60,000 (USD) for grants of varying amounts, starting at $1,000 to $20,000 
(USD) and based on project need. We invite you to learn more about ARIN’s 
Community Grant Program and to find the link to the application form at: 
https://www.arin.net/grants

The call for applications is open now through 1 June 2022. We encourage all 
applicants to clearly demonstrate how projects meet eligibility guidelines and 
selection criteria through the application form to improve chances of selection.

ARIN looks forward to funding important projects through the ARIN Community 
Grant Program in 2022.

Regards,

American Registry for Internet Numbers (ARIN)
===

Re: Enhance CG-NAT Re: V6 still not supported

[Abraham Y. Chen]

Hi, Ant:

1)    As I Cc:'ed you, I attempted to contact the author of the IPv4+ 
draft a few days ago to offer my reading of his work. I have not heard 
any response. In short, I believe that IPv4+ is paraphrasing the scheme 
of the unsuccessful RFC1385 that EzIP Draft cited as Informative 
Reference [12]. -- meaning that EzIP has avoided the trap of such approach.


2)    I went back to earlier versions of the IPv4+ drafts and discovered 
a surprising trend. That is, through all eight revisions, there has been 
hardly any actual write-up text changes! It appears that the author is 
just keeping the six-months-timer ticking.


3)    Since you indicated that IPv4+ was reported to NANOG, maybe you 
could retrieve that thread and check with the author about what is the 
status?


4)    "Have you approached any vendors about the feasibility of IP 
Options being used for switching at line rate in silicon?    ":    No. 
For the first phase of implementing EzIP, the configuration is called 
RAN (Regional Area Network). It is essentially a numbering plan 
enhancement to CG-NAT. There is no change to the basic IPv4 Header. The 
only engineering effort is "disabling the program code that has been 
disabling the use of the 240/4 netblock", followed by retiring the NAT 
function. So that CG-NAT can operate as simple routers, by having the 
look-up state-tables capability as backup.


5)    In the long run, yes, processing of the Option Word needs be 
considered and ideally be implemented in silicon to achieve the line 
rate switching. Many claim, however, such end-to-end connectivity is not 
needed according to the current trend, which is primarily Server / 
Client model by CDN business. So, EzIP is actually a forward looking two 
stage scheme. We can focus on the first phase for now to relieve the 
underlying issues. There will be plenty of lead time to upgrade the 
silicon when the demand for end-to-end connectivity begins to build up.


6)    " ...   but your replies are practically illegible because of 
formatting.   ... ":    I am still learning the proper eMail etiquette 
on NANOG. Could you please echo back some of my writings as you 
received? So that I can see what they got transformed to.


Thanks,


Abe (2022-04-06 11:25)


On 2022-04-03 16:14, Anthony Newman wrote:

You should check 
outhttps://datatracker.ietf.org/doc/html/draft-tang-ipv4plus-08  which is still 
dragging on
after receiving similar treatment here to EzIP (although less patented by its 
author) and equally unlikely
to be possible to implement in the real world in a timely fashion.

Have you approached any vendors about the feasibility of IP Options being used 
for switching at line rate in silicon?
Software IP stacks are the absolute least of your problem when proposing 
alterations to routing behaviour based on
packet contents. Apologies if this has been covered, but your replies are 
practically illegible because of formatting.





--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

[Jeff Behrns via NANOG]

Lumen / Level3 filtergen is trimming these routes now.  Don't bother trying
to query filtergen.level3.net currently; server is full.  Small AS cone does
not equal small societal footprint & impact.  While I appreciate the
intention upthread of proxy registering at ATLDB, it really just distracted
from finding the root issue.

IP Multicast Persistent Duplicate Packet Issue

[Roman Islam]

Hi Everyone,

Has anyone experienced a TETRA Radio application issue if underlying IP
multicast transport sends persistent duplicate packets?

Here is my scenario as below:

PIM is running on the MPLS L3 VPN environment. C multicast is running on a
single VRF (TETRA) only. Source is running behind a dual home PE. HSRP, PIM
DR path is via PE1 to the source. Anycast RP is configured with PE1 & PE2.

On the receiver side there is a single PE. When I check (S,G) route on the
receiver side PE default MDT is working as expected. After the threshold
exceeds it switches to the data MDT. PIM Assert mechanism winner is PE2
though (Since PE 2 has the highest IP and source is behind dual home PE
with equal cost I guess).

Can this be a reason for persistent duplicate multicast packets at the
receiver side; since the assert winner is PE2 but HSRP, PIM DR path is via
PE1 to the source?

If this is the case is there any way to manually configure the assert
winner to PE1?

Roman

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

[Wes George]

On 4/4/2022 7:08 PM, Tom Beecher wrote:


I am an ARIN admin and tech POC for one of the affected ASNs/sets of
prefixes across 2 OrgIDs. I looked back at the messages I've received
that mention NONAUTH or Non-Authenticated. The only thing I've
gotten is
the message originally sent via ARIN-Announce that John forwarded,
plus
similar reminders.


I'm extremely grateful to Job and Kenneth for stepping in to address
ARIN's failure here before it ruined a lot of people's weeks.


ARIN clearly stated they were attempting to reach people with records 
for the last year. If the contact info you had was correct and they 
still didn't get to you, perhaps it better to speak with them to 
figure out why before just branding it a 'failure'.



In the interest of fairness and accuracy, there's an important 
clarifying detail. ARIN *did* notify the POCs associated with the actual 
NONAUTH IRR records. But those are wholly separate from the POCs for the 
actual address or ASN resources, which is what I was referencing above, 
and thus it resulted in a bad assumption on my part. That said, if the 
email addresses associated with what are likely 
stale/crufty/unmaintained records in the NONAUTH IRR were dead, no one 
got notified. Reasonable people can disagree on whether that was enough 
of an attempt. In this case, I didn't know these existed, and thus 
didn't know that the contact info for them was similarly out of date. I 
suspect I'm not the only one in this situation.


My calling this a failure was too strong, and for that I apologize, but 
I disagree with their choice to not notify the current resource holder 
POCs when they were unable to successfully notify the POCs for the 
corresponding objects. That said, it's not an easy problem, and there 
are things that multiple parties (including me) could or should have 
done to address this, so the blame is not solely ARIN's.


Wes George

FuboTV Geolocation

[Nicholas Warren]

Is anyone on the list from FuboTV that can assist or point me in the right 
direction for a geolocation issue?

Thank you,
Nich Warren
AS395658

Re: ARIN fee structure (was: re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT)

[John Curran]

On 5 Apr 2022, at 11:57 PM, William Herrin 
mailto:b...@herrin.us>> wrote:

On 5 Apr 2022, at 8:38 PM, Dan Mahoney (Gushi) 
mailto:d...@prime.gushi.org>> wrote:
But say they sign an LRSA: Those $0 fees would go up to 150, this year, 175 
next year, 200 the following...250 in year five... to be able to simply add 
DNSSEC, RPKI, and Validated IRR.

Hi Dan,

Speaking for myself, I'd be happy to pay the normal block size fee
just to get DNSSEC, RPKI and a validated IRR. I pay $80/month just for
my residential Internet service and another $80 or so for my off-site
virtual machines. A couple hundred bucks a _year_ for the niceties
which come with ARIN registration is no imposition at all.

Bill -

Good to hear - one hopes that the value is sufficient (but we should still look 
for opportunities for further improvements on both services and fees.)

My objection lies in having ARIN's RSA adhere to my address block
overall. I may feel differently about ARIN next year than I do this
year but once I've signed that RSA, well, that's just too bad. I now
have obligations to ARIN, some of them on shifting sand, and if I
don't fulfill them the addresses are gone.

That’s an Interesting perspective - thank you for sending.   It is true that 
both you and ARIN have obligations once you sign an RSA, but that’s true of any 
standardized agreement that you enter – standard agreements are found 
everywhere in life and are enforceable if applied uniformly with reasonable 
terms.

The part of your statement I don’t understand is that some of your obligations 
to ARIN are "on shifting sand"… If anything, you’ve got more protections in 
place regarding your ARIN RSA agreement than likely in most other standard 
agreement contexts (although it is true that we at ARIN don’t exactly emphasize 
these aspects as often as we might…)

Unlike many other standard agreements that you might find yourself in:


  1.  ARIN is an actual membership organization and governed accordingly.  
Every customer with IPv4 or IPv6 resources under agreement is an ARIN member 
and has the option to participate in the ARIN election for Trustees and ARIN AC 
members. 
(I know of many not-for-profits that have “members” but not actual membership 
organizations, and the difference is substantial regarding one’s legal rights 
and enforceability of same.)
  2.  While ARIN previously did have the ability to revise your registration 
services agreement (RSA) at will, we’ve achieved sufficient stability that it 
was possible to end that flexibility – now ARIN may only modify the terms of 
the RSA agreement if necessary due to a specific change in relevant statute or 
caselaw, or upon recommendation of the Board _and_ ratification vote by the 
ARIN members.
  3.  If ARIN fails to live up to its obligations under the agreement and our 
performance is found to have provided valid cause for termination, the 
agreement ends – and you keep your legacy number resources with them returning 
to their status before agreement.

It is true that our number resource policies are subject to change by the 
community through the open policy development process, and therefore your 
obligations under them might be the “shifting sand” to which you refer.  If 
that’s the case then I understand the reference, but as you’re aware that’s an 
inevitable consequence of having community-driven number resource policy – 
ARIN’s number resource policy instantiates community consensus regarding such 
obligations, which is not much different than obligations/expectation that 
networks face in other aspects of Internet operation, aside from actually being 
clearly written down in one place when it comes to the registry obligations.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers