Re: Frontier Tampa issues

[David Hubbard]

Yes, exactly same issue for us, and it has happened in the past a few years ago 
fortunately.  Any chance the route takes a Level 3 (3356) path?  I’m just 
theorizing here, but my belief is they have some kind of link aggregation in 
the path from TB to 3356 (or maybe just internal near some edge) and some 
traffic is getting hashed onto a problematic link/interface/linecard, etc. 
where IPSec gets dropped.  One of our locations lost IPSec ability to some 
normal VPN endpoints but not others.  And here’s why I think this is the 
issue….  if you change the source and/or destination IP address by one, you may 
find some or all of your sessions magically work again.

In our case, one of our office locations has a static assignment of 
(fortunately) five IP’s.  We only have one external exposed, four site to site 
VPN’s.  Two began failing Saturday morning.  I moved the office firewall’s 
external IP minus 1 and that fixed both, but broke one that had been fine.  On 
the remote end fortunately I have equipment that’s able to override the local 
IP for VPN traffic, so without impacting other things it talks to, I was able 
to add a new IP one off from the previous, and use that for traffic just to 
this office location; that fixed the remaining issue.

If I’d not seen this previously several years ago, and wasted who knows how 
many hours trying to figure it out, it would have once again taken forever to 
resolve.  Trying to get through their support layer to someone who can really 
help is impossible.  The support is really complete garbage at this point after 
the Verizon dump; I was going to say service, but that’s been stable outside of 
these random weird issues that are impossible to resolve with support.

I tried to be a nice guy and raise this through the support channels, but could 
not make it past the layer where they want me to take our office down to have 
someone plug a laptop in with our normal WAN IP and “prove” ipsec isn’t working 
with different equipment.  I was like dude I just told you what I did to get it 
working again, offered packet captures, just escalate it, but ultimately gave 
up and hung up.

David

From: NANOG  on behalf 
of Nick Olsen 
Date: Sunday, January 24, 2021 at 8:42 PM
To: "nanog@nanog.org" 
Subject: Frontier Tampa issues

Anyone else seeing weird things on Tampa/Bradenton FIOS connections?

I've got three unrelated customers that cant establishes IPsec back to me.

And a third that can't process credit cards out to their third party merchant.

Customers are in 47.196.0.0/14.

In All instances, I see the traffic leave the CPE behind the FIOS circuit. The 
IPSEC traffic never makes it to my DC. And no clue on the credit card traffic. 
But it goes un-ack'd

And just now a fifth has appeared that can't query DNS against 8.8.8.8. 
Responses go out and never come back.

The first four all started around noon today.

Frontier Tampa issues

[Nick Olsen]

Anyone else seeing weird things on Tampa/Bradenton FIOS connections?

I've got three unrelated customers that cant establishes IPsec back to me.

And a third that can't process credit cards out to their third party
merchant.

Customers are in 47.196.0.0/14.

In All instances, I see the traffic leave the CPE behind the FIOS circuit.
The IPSEC traffic never makes it to my DC. And no clue on the credit card
traffic. But it goes un-ack'd

And just now a fifth has appeared that can't query DNS against 8.8.8.8.
Responses go out and never come back.

The first four all started around noon today.

Re: Past policies versus present and future uses

[JORDI PALET MARTINEZ via NANOG]

Hi Matthew,

 

I’m not sure I’ve succeded to explain it in previous emails.

The requirement for the LACNIC policies about majority of usage *in the region* 
of the resources provided has been there for many years. I’m almost sure than 
since day 1, but will need to dig into older versions of the policy manual to 
check that.

The *text* was only using the work “mayoría”, but the interpretation when 
ensuring policy compliance, was following that definition of “mayoria”, which 
is more than 50%. My policy proposal, was “cleaning” and “clarifiying” text 
here and there. For example, there were some text that clearly apply to IPv4 
and IPv6, and was only in the IPv4 section, etc. The policy proposal also did a 
lot of major changes for the recovery of uncompliant addressing space by 
ensuring that LACNIC setup periodic and automatic policy compliance checks.

So: the “>50%” was not a “change”, was just making explicit the actual 
practice, and during the discussion of the proposal, we made sure in the 
mailing list that everybody agree with that clarification of the *existing* 
interpretation. Nobody, absolutely nobody, objected or said “I don’t read it 
that way”. In fact, I asked if the people prefers to use some “other %”, or 
completely delete it or whatever.

I don’t have the exact details of the case that Ron discovered in Belize, 
because, of course, most of the details are under NDA between the resourse 
holder and LACNIC, private documents, etc., etc. So I’m not sure if “initially” 
the resource holder was really having the “majority” of the resources operated 
in Belize or some other place in the region and then they “forgot” that they 
need to follow the policy (as said, the policy has not changed in that sense). 
My guess is that they provided false information to LACNIC “yes we have the 
majority of the operation in the region”, and the RIR trusted the provided 
documents, but is only my guess.

I fully see your point, however *every ISP/LIR needs to follow the policies in 
every RIR where they have resources*. Policy changes may require changes in 
their operation, and if they don’t agree, *this is the reason* they MUST 
participate in policy discussions, to be able to defend their position.

This is *nothing new*! Is part of the job of the ISPs/LIRs, to ensure that they 
follow the policy discussions, the same way as citizens follow law development 
because changes in law (new taxes, etc.), can change their compliance with law. 
Is not about retroactivity, is about every one of us developing the “laws” and 
justify why something can’t be changed.

The solution to those that don’t want to follow (even if is part of their 
“job”) the policy development, is to have warnings when there is a policy 
change that affects them. In fact I’ve included that in a policy proposal in 
AFRINIC 
(https://www.afrinic.net/policy/proposals/2020-gen-001-d1?lang=en-GB#proposal), 
by means of a dash-board. This could be done also by other RIRs as part of 
their “operational” terms in the customers accounts (such in “mylacnic” in the 
case of LACNIC), etc., and in fact it was the main intent of my policy proposal.

As said, remember that this has been not changed, just added a clarification 
based on the existing understanding of the previuos text. LACNIC will not have 
provided to this resource-holder in 2013 the resources if they didn’t had 
indicated that the majority (over 50%) of those resrouces aren’t being operated 
in the region.

I found and older archived version of the policy manual from 2013 (in Spanish):

https://www.lacnic.net/innovaportal/file/543/1/manual-politicas-sp-2.0.pdf

In section 1.11, has exactly the same text:

“Los recursos de numeración de Internet bajo la custodia de LACNIC se deben 
distribuir a organizaciones legalmente establecidas en su región de servicio 
[COBERTURA] y para atender mayoritariamente redes y servicios que operan en 
dicha región.”

 

 

 

El 25/1/21 0:15, "Matthew Petach"  escribió:

 

 

 

On Sun, Jan 24, 2021 at 4:22 AM JORDI PALET MARTINEZ via NANOG 
 wrote:

[...] 

So, you end up with 2-3 RIRs allocations, not 5. And the real situation is that 
3 out of 5 RIRs communities, decided to be more relaxed on that requirement, so 
you don’t need actually more than 1 or may be 2 allocations. Of course, we are 
talking “in the past” because if we are referring to IPv4 addresses, you 
actually have a different problem trying to get them from the RIRs.

 

Hi Jordi,

 

I've adjusted the subject line to reflect the real thrust of this discussion.

 

You're right--if we're trying to get "new" allocations of IPv4 addresses, we've 
got bigger problems to solve.

 

But when it comes to IPv6 address blocks and ASNs, these questions are still 
very relevant.

 

And, going back to the original article that spawned the parent thread, the 
problem wasn't about companies requesting *new* blocks, it was about the usage 
of old, already granted blocks that were now being reclai

Re: DoD IP Space

[Mark Andrews]

There's no error code. Customer only sees the message "DRM license resquest 
failed" on LG TV WebOS 3.8 or above.

Translation “I use a broken GEOIP database that doesn’t handle IPv6 correctly.  
If you turn off IPv6 then the request will use IPv4 and it may work.”.

Mark

> On 25 Jan 2021, at 01:03, Travis Garrison  wrote:
> 
> I have personally seen the issue with streaming from a Samsung cell phone and 
> the Disney+ app to a Google chrome cast and a regular not-smart TV. 
> 
> Travis
> 
> -Original Message-
> From: NANOG  On Behalf Of 
> Doug Barton
> Sent: Friday, January 22, 2021 5:30 PM
> To: nanog@nanog.org
> Subject: Re: DoD IP Space
> 
> The KB indicates that the problem is with the "LG TV WebOS 3.8 or above."
> 
> Doug
> 
> (not speaking for any employers, current or former)
> 
> 
> On 1/22/21 12:42 PM, Mark Andrews wrote:
>> Disney should hire some proper developers and QA team.
>> 
>> RFC 1123 instructed developers to make sure your products handled 
>> multi-homed servers properly and dealing with one of the addresses being 
>> unreachable is part of that.  It’s not like the app can’t attempt to a 
>> stream from the IPv6 address and if there is no response in 200ms start a 
>> parallel attempt from the IPv4 address.  If the IPv6 stream succeeds drop 
>> the IPv4 stream  Happy Eyeballs is just a specific case of multi-homed 
>> servers.
>> 
>> QA should have test scenarios where the app has a dual stack network and the 
>> servers are silently untraceable over one then the other transport.  It 
>> isn’t hard to do.  Dealing with broken networks is something every 
>> application should do.
>> 

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

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

If you want services from LACNIC (as well as any other RIR), you need to sign 
the contracts (legal part) and know the policies.

In that case you will reach *that* text in both pages.

Google doesn't necessarily is right when doing translations, specially, 
because, as said several times, the formal text is the Spanish one.
 

El 24/1/21 23:13, "Masataka Ohta"  escribió:

JORDI PALET MARTINEZ wrote:
>> In the case of LACNIC it is spanish, it is clearly indicated in
>> the web site,
> 
> I can't see it clearly indicated in LACNIC web site, at all.
> 
> Where is it? How does it stated?
> 
> [Jordi] There may be some problem with your browser or Internet
> connectivity that is missing some parts of the web site, as I can see
> it in many places, and especially those more relevant (bylaws and
> policy manual):
> 
> https://www.lacnic.net/76/2/lacnic/bylaws
> 
> https://www.lacnic.net/680/2/lacnic/policy-manual-[v214---24_07_2020]

That it is stated some random pages deep within LACNIC website
does not mean "clearly indicated in LACNIC web site".

As such, LACNIC can't expect English-using people see the pages,
which means it is fault of LACNIC if they believe policy
in English is a formal one.

> Could you explain why google translation says "mayoria" in English 
> means (sorted by frequency) "most", "majority", "many", "bulk" and 
> "plurality"?
> 
> [Jordi] I'm not native English speaker, so I'm not the best one to
> explain that.

I'm afraid you are saying you have no say on the meaning of "mainly".

 > As I said, several times, the official documents are the Spanish
 > version, and in the Spanish version the right word being used is
 > "mayoría", which I believe, in *this context* it is better
 > translated to "majority".

which is not compatible with translation by google.

Masataka Ohta




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Past policies versus present and future uses

[John Sage]

On 1/24/21 3:15 PM, Matthew Petach wrote:






Hi Jordi,

I've adjusted the subject line to reflect the real thrust of this 
discussion.




[edits Message Filters to include string "Past policies versus present 
and future uses" in Subject]


[selects folder "NANOG" in Thunderbird: All Folders]

[selects Tools --> Run Filters on Folder]

Bring it. My Trash ain't half full.

The question about moderators still holds.


And yes, for those wondering, I *have* unsubscribed about three or four 
times over -- what? -- a good fifteen years or more...



- John
--

Past policies versus present and future uses

[Matthew Petach]

On Sun, Jan 24, 2021 at 4:22 AM JORDI PALET MARTINEZ via NANOG <
nanog@nanog.org> wrote:
[...]

> So, you end up with 2-3 RIRs allocations, not 5. And the real situation is
> that 3 out of 5 RIRs communities, decided to be more relaxed on that
> requirement, so you don’t need actually more than 1 or may be 2
> allocations. Of course, we are talking “in the past” because if we are
> referring to IPv4 addresses, you actually have a different problem trying
> to get them from the RIRs.
>

Hi Jordi,

I've adjusted the subject line to reflect the real thrust of this
discussion.

You're right--if we're trying to get "new" allocations of IPv4 addresses,
we've got bigger problems to solve.

But when it comes to IPv6 address blocks and ASNs, these questions are
still very relevant.

And, going back to the original article that spawned the parent thread, the
problem wasn't about companies requesting *new* blocks, it was about the
usage of old, already granted blocks that were now being reclaimed.

Historically, ISPs have focused on ensuring their usage of IP space
reflected the then-current requirements at the time the blocks were
requested.  This action by Ron, well-intentioned as it is, raises a new
challenge for ISPs:  network numbering decisions that were made in the
past, which may have been done perfectly according to the guidelines in
place at the time the blocks were assigned, may later on violate *newly
added* requirements put in place by RIRs.  How many global networks
allocate manpower and time cycles to potentially renumbering portions of
their network each time a new policy is put in place at an RIR that makes
previously-conforming addressing topologies no longer conforming?
Historically, once addresses were granted by an RIR, and the exercise of
ensuring all the requirements were met, and the addresses were in place,
that was it; nobody went back every time a new policy was put in place and
re-audited the network to ensure it was still in compliance, and did the
work to bring it back into compliance if the new policy created violations,
because the RIRs generally didn't go back to see if new policies had been
retroactively applied to all member networks.

Ron's actions have now put every network on notice; it wasn't good enough
to be in compliance at the time you obtained your address space, you MUST
re-audit your network any time new policies are put into force by the RIR
in a region in which you do business, or your address space may be revoked
due to retroactive application of the new policy against addresses you have
already put into use.

This is a bigger deal that I think many people on the list are first
grasping.

We grow up accustomed to the notion that laws can't be applied
retroactively.  If you smoked pot last year, before it was criminalized,
they can't arrest you this year after a new law was passed for smoking it
before the law was passed.

In the DDoS-guard case, the address blocks in question seem to have been
granted by LACNIC nearly a decade ago back in 2013, under whatever policies
were in force at the time.  But they're being revoked and reclaimed based
on the policies that are in place *now*, nearly a decade later.

It sends a very clear message--it's not enough to be in compliance with
policies at the time the addresses are granted.  New policies can and will
be applied retroactively, so decisions you made in the past that were valid
and legal, may now be invalid, and subject you to revocation.  It's bad
enough when it's your own infrastructure that you have some control over
that you may need to re-number; woe to you if you assign address blocks to
*customers* in a manner that was valid under previous policy, but is no
longer valid under new policies--you get to go back to your customers, and
explain that *they* now have to redo their network addressing so that it is
in compliance, in order for *you* to be in compliance with the new
policies.  Otherwise, you can *all* end up losing your IP address blocks.

So--while I think Ron's actions were done with the best of intentions, I
think the fallout from those actions should be sending a chill down the
spine of every network operator who obtained address blocks under policies
in place a decade ago that hasn't gone back and re-audited their network
for compliance after ever subsequent policy decision.

What if one of *your* customers falls into Ron's spotlight; is the rest of
your network still in compliance with every RIR policy passed in the years
or decades since the addresses were allocated?  Are you at risk of having
chunks of your IP space revoked?

I know this sets a precedent *I* find frightening.  If it isn't scaring
you, either you don't run a network, or I suspect you haven't thought all
the way through how it could impact your business at some unforeseen point
in the future, when a future policy is passed.  :/

Thanks!

Matt

Re: Nice work Ron

[John Sage]

On 1/24/21 2:18 PM, Masataka Ohta wrote:

JORDI PALET MARTINEZ via NANOG wrote:


If you don't like it, stop complaining, and send a policy proposal,


It is wast of time to complain or to modify practically
obsoleted policy.

     Masataka Ohta


[selects folder "NANOG" in Thunderbird: All Folders]

[selects Tools --> Run Filters on Folder]

**BOOM**

Where'd "Ron" go?

Oh. Ron's up in the Trash. Again.

Also, are there no moderators on this list at all?


- John
--

Re: Nice work Ron

[Masataka Ohta]

JORDI PALET MARTINEZ via NANOG wrote:


If you don't like it, stop complaining, and send a policy proposal,


It is wast of time to complain or to modify practically
obsoleted policy.

Masataka Ohta

Re: Nice work Ron

[Masataka Ohta]

JORDI PALET MARTINEZ wrote:

In the case of LACNIC it is spanish, it is clearly indicated in
the web site,


I can't see it clearly indicated in LACNIC web site, at all.

Where is it? How does it stated?

[Jordi] There may be some problem with your browser or Internet
connectivity that is missing some parts of the web site, as I can see
it in many places, and especially those more relevant (bylaws and
policy manual):

https://www.lacnic.net/76/2/lacnic/bylaws

https://www.lacnic.net/680/2/lacnic/policy-manual-[v214---24_07_2020]


That it is stated some random pages deep within LACNIC website
does not mean "clearly indicated in LACNIC web site".

As such, LACNIC can't expect English-using people see the pages,
which means it is fault of LACNIC if they believe policy
in English is a formal one.

Could you explain why google translation says "mayoria" in English 
means (sorted by frequency) "most", "majority", "many", "bulk" and 
"plurality"?


[Jordi] I'm not native English speaker, so I'm not the best one to
explain that.


I'm afraid you are saying you have no say on the meaning of "mainly".

> As I said, several times, the official documents are the Spanish
> version, and in the Spanish version the right word being used is
> "mayoría", which I believe, in *this context* it is better
> translated to "majority".

which is not compatible with translation by google.

Masataka Ohta

Re: Nice work Ron

[J. Hellenthal via NANOG]

Cool nice work Ron! Maybe a new subject for what this is really about  ...

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 24, 2021, at 13:36, JORDI PALET MARTINEZ via NANOG  
> wrote:
> 
> Again, I'm not saying is the best way, is what the community *decided* 
> before I added a clarification. The 50% was not a change, just to make it 
> explicit, what was the actual interpretation.
> 
> If you don't like it, stop complaining, and send a policy proposal, I could 
> even support it, but I'm not convinced it will reach consensus.
> 
> 
> 
> El 24/1/21 15:34, "NANOG en nombre de Masataka Ohta" 
>  mo...@necom830.hpcl.titech.ac.jp> escribió:
> 
>JORDI PALET MARTINEZ via NANOG wrote:
> 
>> I fully understand what you mean, however, I don’t think this is a
>> problem even if all the RIRs ask for “%50 or even 100%” of usage in
>> the region.
> 
>So, you don't know how most, if not all, ISPs are operating
>their network.
> 
>> That will make your life more complex, as you will need to obtain
> 
>It makes ISP's operations a lot more complex and a lot less
>profitable to be ignored by almost all, if not all, ISPs.
> 
>Your theory that ISPs could have behaved otherwise is not
>helpful in the real world of business and not practically
>acceptable by RIRs mostly consisting of ISPs.
> 
>Masataka Ohta
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
> 
> 
> 

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

Again, I'm not saying is the best way, is what the community *decided* before I 
added a clarification. The 50% was not a change, just to make it explicit, what 
was the actual interpretation.

If you don't like it, stop complaining, and send a policy proposal, I could 
even support it, but I'm not convinced it will reach consensus.

 

El 24/1/21 15:34, "NANOG en nombre de Masataka Ohta" 
 escribió:

JORDI PALET MARTINEZ via NANOG wrote:

> I fully understand what you mean, however, I don’t think this is a
> problem even if all the RIRs ask for “%50 or even 100%” of usage in
> the region.

So, you don't know how most, if not all, ISPs are operating
their network.

 > That will make your life more complex, as you will need to obtain

It makes ISP's operations a lot more complex and a lot less
profitable to be ignored by almost all, if not all, ISPs.

Your theory that ISPs could have behaved otherwise is not
helpful in the real world of business and not practically
acceptable by RIRs mostly consisting of ISPs.

Masataka Ohta



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

El 24/1/21 15:25, "NANOG en nombre de Masataka Ohta" 
 escribió:

JORDI PALET MARTINEZ via NANOG wrote:

> To summarize several responses:

You don't.

> In the case of LACNIC it is spanish, it is clearly indicated in the
> web site,

I can't see it clearly indicated in LACNIC web site, at all.

Where is it? How does it stated?

[Jordi] There may be some problem with your browser or Internet connectivity 
that is missing some parts of the web site, as I can see it in many places, and 
especially those more relevant (bylaws and policy manual):

https://www.lacnic.net/76/2/lacnic/bylaws

https://www.lacnic.net/680/2/lacnic/policy-manual-[v214---24_07_2020]



 > I've already informed LACNIC that "mainly", in my opinion, is a wrong
 > translation for "mayoria", and should be majority, but in any case,
 > the spanish version is the relevant one.

Could you explain why google translation says "mayoria" in English
means (sorted by frequency) "most", "majority", "many", "bulk" and
"plurality"?

[Jordi] I'm not native English speaker, so I'm not the best one to explain 
that. As I said, several times, the official documents are the Spanish version, 
and in the Spanish version the right word being used is "mayoría", which I 
believe, in *this context* it is better translated to "majority".





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[Masataka Ohta]

JORDI PALET MARTINEZ via NANOG wrote:


I fully understand what you mean, however, I don’t think this is a
problem even if all the RIRs ask for “%50 or even 100%” of usage in
the region.


So, you don't know how most, if not all, ISPs are operating
their network.

> That will make your life more complex, as you will need to obtain

It makes ISP's operations a lot more complex and a lot less
profitable to be ignored by almost all, if not all, ISPs.

Your theory that ISPs could have behaved otherwise is not
helpful in the real world of business and not practically
acceptable by RIRs mostly consisting of ISPs.

Masataka Ohta

Re: Nice work Ron

[Masataka Ohta]

JORDI PALET MARTINEZ via NANOG wrote:


To summarize several responses:


You don't.


In the case of LACNIC it is spanish, it is clearly indicated in the
web site,


I can't see it clearly indicated in LACNIC web site, at all.

Where is it? How does it stated?

> I've already informed LACNIC that "mainly", in my opinion, is a wrong
> translation for "mayoria", and should be majority, but in any case,
> the spanish version is the relevant one.

Could you explain why google translation says "mayoria" in English
means (sorted by frequency) "most", "majority", "many", "bulk" and
"plurality"?

Masataka Ohta

RE: DoD IP Space

[Travis Garrison]

I have personally seen the issue with streaming from a Samsung cell phone and 
the Disney+ app to a Google chrome cast and a regular not-smart TV. 

Travis

-Original Message-
From: NANOG  On Behalf Of Doug 
Barton
Sent: Friday, January 22, 2021 5:30 PM
To: nanog@nanog.org
Subject: Re: DoD IP Space

The KB indicates that the problem is with the "LG TV WebOS 3.8 or above."

Doug

(not speaking for any employers, current or former)


On 1/22/21 12:42 PM, Mark Andrews wrote:
> Disney should hire some proper developers and QA team.
> 
> RFC 1123 instructed developers to make sure your products handled multi-homed 
> servers properly and dealing with one of the addresses being unreachable is 
> part of that.  It’s not like the app can’t attempt to a stream from the IPv6 
> address and if there is no response in 200ms start a parallel attempt from 
> the IPv4 address.  If the IPv6 stream succeeds drop the IPv4 stream  Happy 
> Eyeballs is just a specific case of multi-homed servers.
> 
> QA should have test scenarios where the app has a dual stack network and the 
> servers are silently untraceable over one then the other transport.  It isn’t 
> hard to do.  Dealing with broken networks is something every application 
> should do.
> 

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

I fully understand what you mean, however, I don’t think this is a problem even 
if all the RIRs ask for “%50 or even 100%” of usage in the region.

 

That will make your life more complex, as you will need to obtain addresses 
from each RIR. In the worst case, if all them ask for the same:

If you need 2.000 addresses in LACNIC, 4.000 in ARIN, 3.000 in RIPE, 5.000 in 
APNIC and 1.000 in AFRINIC (just an example). This makes in total a global need 
for your network of 15.000 addresses. You will sign 5 contracts, and you will 
get a block from each RIR, that is a bit higher than your actual needs in that 
region. This means that you have more than 50% of the usage in that region and 
in the case of LACNIC, it means that you need to ensure that 1.000 addresses 
are used there. Probably you will not actually need to get addresses from every 
RIR, for example, the 1.000 addresses that you need for AFRINIC, are the excess 
of addresses from LACNIC, etc.

 

So, you end up with 2-3 RIRs allocations, not 5. And the real situation is that 
3 out of 5 RIRs communities, decided to be more relaxed on that requirement, so 
you don’t need actually more than 1 or may be 2 allocations. Of course, we are 
talking “in the past” because if we are referring to IPv4 addresses, you 
actually have a different problem trying to get them from the RIRs.

 

It is the decision of the community if they don’t like this complexity and they 
don’t care if you get all the addresses from LANIC (for whatever reason you 
have that preference, or the corporation is sitting them, etc.), and actually 
only 20% of the addresses are being used in the region (for example) and the 
community can change that at any time.

 

For that, you *don’t need to convince me*, you need to go to the LACNIC policy 
list and convince the community there.

 

My policy proposal *didn’t change that*. The word “majority” was already there. 
It was already being interpreted “literally” as “you need to operate more than 
the half of the IPs *that you get from LACNIC* in the LACNIC region”. I just 
added a footnote (as part of a mayor set of policy changes), to make sure that 
everybody is clearly reading the same with >50% instead of coming to the list 
or to the staff to ask for clarity every other day.

 

Note that you are interpreting the % from your “complete network”. LACNIC 
community that did the original policy and adopted the recent change, may have 
a more “regional” perspective, culture, or whatever you call it (may be because 
the lack of IPv4 addresses, the lack of business cases – in general – for 
organizations that are from that region but operate globally, etc., etc.).

 

As I already mention, note that there is a similar case in AFRINIC policy. They 
require that *all* the resources you get, are used in the region.

 

 

 

 

El 24/1/21 12:30, "Matthew Petach"  escribió:

 

 

 

On Sat, Jan 23, 2021 at 1:11 AM JORDI PALET MARTINEZ via NANOG 
 wrote:

When you sign a contract with a RIR (whatever RIR), is always 2 parties, so 
majority of resources operated in the region (so to have the complete context) 
clearly means that you are using in the region >50% of the provided IPs.

 

No.

 

If you operate a global backbone on six continents, 

and obtain a block of addresses to use for building 

that backbone, you can easily end up in a situation 

where there is no continent with >50% utilization of 

resources; it can easily end up with the space being

split 10%, 10%, 20%, 25%, 35%.  Every time I have 

gone to an RIR for resources, and have described the 

need, explaining that the largest percentage of the 

addresses will be used within the primary region 

has been sufficient.  No RIR has stated that a global 

backbone buildout can only be built in a region if > 50% 

of the addresses used on that backbone reside within 

their region.  Otherwise, you end up at a stalemate 

with no RIR able to allocate addresses for your backbone 

in good faith, because no region holds more than 50% of 

the planet's regions.

 

"Mainly" has been interpreted to be "the largest percentage"

every time I have requested space.

 

If RIRs start to put a >50% requirement in place, you're 

going to see global backbone providers put into the awkward 

position of having to lie about their buildout plans--so they're

going to consistently vote against language that explicitly says

">50%" just so that nobody is put into the position of having to

knowingly lie on an attestation.

 

I understand where you're coming from; but as someone who

has built global infrastructure in the past, I think it would be 

good to consider the view from the other side of the table,

and realize why the language is kept a bit more loose, to 

allow for the creation of infrastructure that spans multiple 

regions.

 

Thanks!

 

Matt

 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv