Re: Gmail email blocking is off the rails (again)

[Hank Nussbacher]

On 04/12/2019 05:04, Matthew Pounsett wrote:

Cute way to promote Google Groups over Mailman.  Gotta give 'em credit 
for being creative :-)


-Hank



For some reason Gmail has started blocking mailman administrative 
emails to someone who's an admin on a list I host.  Their SMTP 552 
error message points to 
, which implies the 
"problem" is the URLs in the email, but is otherwise completely unhelpful.


If anyone here has any pull with Gmail postmasters, could you please 
suggest to them that they whitelist messages that are as consistent 
and well-known as mailman's admin and moderator messages?

Re: Gmail email blocking is off the rails (again)

[Ross Tajvar]

You might have better luck emailing the mailops list.

On Tue, Dec 3, 2019, 10:06 PM Matthew Pounsett  wrote:

>
> For some reason Gmail has started blocking mailman administrative emails
> to someone who's an admin on a list I host.  Their SMTP 552 error message
> points to , which
> implies the "problem" is the URLs in the email, but is otherwise completely
> unhelpful.
>
> If anyone here has any pull with Gmail postmasters, could you please
> suggest to them that they whitelist messages that are as consistent and
> well-known as mailman's admin and moderator messages?
>
>
>

Gmail email blocking is off the rails (again)

[Matthew Pounsett]

For some reason Gmail has started blocking mailman administrative emails to
someone who's an admin on a list I host.  Their SMTP 552 error message
points to , which
implies the "problem" is the URLs in the email, but is otherwise completely
unhelpful.

If anyone here has any pull with Gmail postmasters, could you please
suggest to them that they whitelist messages that are as consistent and
well-known as mailman's admin and moderator messages?

Re: RIPE our of IPv4

[Fernando Gont]

On 3/12/19 17:47, Mark Andrews wrote:
> 
> 
>> On 4 Dec 2019, at 02:04, Fernando Gont  wrote:
>>
>> On 3/12/19 00:12, Mark Andrews wrote:
>>>
>>>
 On 3 Dec 2019, at 13:31, Valdis Klētnieks  wrote:

 On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said:

>> I believe that Dmitry's point is that we will still require IPv4 
>> addresses for new
>> organizations deploying dual-stack
>
> I think I understood what you meant, but not what you said.

> If someone is dual stack, they are IPv6-capable and IPv4-capable.

 And they're going to need v4 addresses to be v4-capable, aren't there?

 A new corporation that's trying to spin up dual-stack is going to need 2
 address allocations, a v4 and a v6.
>>>
>>> Why does a new organisation need to have any global IPv4 addresses of their 
>>> own
>>> at all?  In most cases they don’t.  It’s only inertia that is causing 
>>> people to
>>> want to have their own global IPv4 addresses.
>>>
>>> We have IPv4 as a service which gives on demand shared IPv4 addresses.  
>>> Millions
>>> of people reach the IPv4 Internet every day using IPv4AAS.
>>> CDNs are dual stack and provide the IPv4 presence on the net.  These days 
>>> these
>>> are shared addresses.
>>> VPNs run over IPv6 and they can in turn run over IPv6 in IPv4 tunnels when
>>> the remote doesn’t support native IPv6.  Its just another level on 
>>> encapsulation.
>>> Email is often out sourced so you don’t need your own IPv4 addresses for 
>>> that.
>>> Then there is in the cloud for other services, again you don’t need your 
>>> own IPv4
>>> addresses.
>>
>> Wwll, yeah.. you don't need IPv4 addresses if you are going to be using
>> somebody else's networks and services. Not that you should, though…
> 
> Why not use someone else’s IPv4 addresses?  Really.  What is wrong with using
> someone else’s IPv4 addresses if it achieves the need?  As far as I can tell
> nothing.

Security? Privacy?

It may or may not be a concern for you. But there are implications in
doing so.



> Just because enterprises that established themselves in a  IPv4-only world did
> it one way.  It doesn’t mean that enterprises establishing themselves in a 
> IPv4 /
> IPv6 world need to follow that model.

As long as you do analyze the implications and trade-offs...


-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: RIPE our of IPv4

[Brandon Martin]

On 12/3/19 10:04 AM, Fernando Gont wrote:

Wwll, yeah.. you don't need IPv4 addresses if you are going to be using
somebody else's networks and services. Not that you should, though


OTOH, many many organizations, especially outside of service providers, 
in fact DO such a thing.  I'd suspect your average mid-size business 
these days really in fact does not "need" any IPv4 addresses to conduct 
their ordinary and even many extraordinary operations.


As long as you can make IPv4 HTTP/HTTPS destinations work to handle the 
long tail of non-IPv6 web destinations out there, I bet most people 
wouldn't even notice, and the only reason the IT folks would notice 
would be during testing/troubleshooting or the fact that their machine 
suspiciously has no RFC1918 nor public IPv4 address configured on it.


Most organizations do indeed outsource most of their IT functions in one 
way or another, and it's pretty easy these days to pick outsourcing 
partners for most common business needs that are indeed natively 
IPv6-enabled.  The remainder probably run over HTTP/HTTPS, anyway, and 
are easily translatable at the service provider level.


I'd certainly not (yet) say that that's a recommended configuration, but 
I suspect it would often work.  I certainly have IPv6-only testbeds. 
There's a few groaners usually, but a surprisingly large amount of stuff 
"just works".

--
Brandon Martin

Re: RIPE our of IPv4

[Fred Baker]

> On Dec 3, 2019, at 3:22 PM, Valdis Klētnieks  wrote:
> 
> On Tue, 03 Dec 2019 14:58:59 -0800, FREDERICK BAKER said:
> 
>> I think he is saying that companies like Reliance JIO have started with a /22
>> of IPv4 and a /32 (or more) of IPv6,
> 
> As I said - you need IPv4 space to dual-stack. How does Reliance do this
> without any v4 address space?

They have a very small amount, and do CGN, the same as anyone else. If that's 
what you took away from the APNIC measurements, you missed the story, though.

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Tue, 03 Dec 2019 14:58:59 -0800, FREDERICK BAKER said:

> I think he is saying that companies like Reliance JIO have started with a /22
> of IPv4 and a /32 (or more) of IPv6,

As I said - you need IPv4 space to dual-stack. How does Reliance do this
without any v4 address space?


pgpZzt54PJqbb.pgp
Description: PGP signature

Re: Comcast & NTT packet loss today

[Job Snijders]

Hi all,

We are following up off-list!

This may be a good moment to mention that the excellent people at the NTT
NOC are always available at n...@ntt.net, or the phone numbers listed in
PeeringDB. :-)

Kind regards,

Job

On Tue, Dec 3, 2019 at 23:19 Ben Cannon  wrote:

> We’re trying to figure out wether this is an isolated or wider incident,
> looking like one of our customer’s flows is fragging between NTT and
> Comcast.
>
>  5  ae-0.a02.snjsca04.us.bb.gin.ntt.net (129.250.2.3)  5.571 ms  13.026
> ms  9.514 ms
>  6  ae-0.comcast.snjsca04.us.bb.gin.ntt.net (129.250.66.34)  119.688 ms
> 117.368 ms  111.902 ms
>  7  be-12578-cr01.9greatoaks.ca.ibone.comcast.net (68.86.88.17)  118.845
> ms  117.035 ms  114.762 ms
>  8  * be-7922-ar01.hayward.ca.sfba.comcast.net (68.86.94.154)  120.025
> ms  114.310 ms
>  9  * be-397-rar01.fairfield.ca.sfba.comcast.net (96.108.99.10)  119.178
> ms *
> 10  162.151.79.66 (162.151.79.66)  123.215 ms  121.184 ms  124.125 ms
>
> If anyone from either entity would like to contact me off list for
> troubleshooting please feel free.
>
>
> -Ben Cannon
> CEO 6x7 Networks & 6x7 Telecom, LLC
> b...@6by7.net
>
>
>
>

Re: RIPE our of IPv4

[Mark Andrews]

> On 4 Dec 2019, at 09:51, Valdis Klētnieks  wrote:
> 
> On Wed, 04 Dec 2019 07:47:25 +1100, Mark Andrews said:
> 
>> Why not use someone else’s IPv4 addresses?  Really.  What is wrong with using
>> someone else’s IPv4 addresses if it achieves the need?  As far as I can tell
>> nothing.
> 
> Other than the fact that a /24 is being advertised out of one AS and it's 
> part of
> some other AS's /14 and looks suspiciously like a hijack?  And we currently 
> don't
> deal well with identifying and preventing true hijacks and mess up false 
> positives
> a lot of the time?

I’m curious if you actually read the example of use of another’s IPv4 address 
before
starting talking about hijacking addresses?

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

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Wed, 04 Dec 2019 07:47:25 +1100, Mark Andrews said:

> Why not use someone else’s IPv4 addresses?  Really.  What is wrong with 
> using
> someone else’s IPv4 addresses if it achieves the need?  As far as I can tell
> nothing.

Other than the fact that a /24 is being advertised out of one AS and it's part 
of
some other AS's /14 and looks suspiciously like a hijack?  And we currently 
don't
deal well with identifying and preventing true hijacks and mess up false 
positives
a lot of the time?



pgpUBGTodN9bJ.pgp
Description: PGP signature

Comcast & NTT packet loss today

[Ben Cannon]

We’re trying to figure out wether this is an isolated or wider incident, 
looking like one of our customer’s flows is fragging between NTT and Comcast.

 5  ae-0.a02.snjsca04.us.bb.gin.ntt.net (129.250.2.3)  5.571 ms  13.026 ms  
9.514 ms
 6  ae-0.comcast.snjsca04.us.bb.gin.ntt.net (129.250.66.34)  119.688 ms  
117.368 ms  111.902 ms
 7  be-12578-cr01.9greatoaks.ca.ibone.comcast.net (68.86.88.17)  118.845 ms  
117.035 ms  114.762 ms
 8  * be-7922-ar01.hayward.ca.sfba.comcast.net (68.86.94.154)  120.025 ms  
114.310 ms
 9  * be-397-rar01.fairfield.ca.sfba.comcast.net (96.108.99.10)  119.178 ms *
10  162.151.79.66 (162.151.79.66)  123.215 ms  121.184 ms  124.125 ms

If anyone from either entity would like to contact me off list for 
troubleshooting please feel free.


-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC 
b...@6by7.net 

Rural Broadband Article - New Yorker

[Rod Beck]

A great article on how a very poor Appalachian community was able to bring 
fiber to the premise. Currently one gig and being upgraded to ten gigs.

https://www.newyorker.com/tech/annals-of-technology/the-one-traffic-light-town-with-some-of-the-fastest-internet-in-the-us?


Roderick Beck

VP of Business Development

United Cable Company

www.unitedcablecompany.com

New York City & Budapest

rod.b...@unitedcablecompany.com

36-70-605-5144


[1467221477350_image005.png]

Re: RIPE our of IPv4

[Mark Andrews]

> On 4 Dec 2019, at 02:04, Fernando Gont  wrote:
> 
> On 3/12/19 00:12, Mark Andrews wrote:
>> 
>> 
>>> On 3 Dec 2019, at 13:31, Valdis Klētnieks  wrote:
>>> 
>>> On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said:
>>> 
> I believe that Dmitry's point is that we will still require IPv4 
> addresses for new
> organizations deploying dual-stack
 
 I think I understood what you meant, but not what you said.
>>> 
 If someone is dual stack, they are IPv6-capable and IPv4-capable.
>>> 
>>> And they're going to need v4 addresses to be v4-capable, aren't there?
>>> 
>>> A new corporation that's trying to spin up dual-stack is going to need 2
>>> address allocations, a v4 and a v6.
>> 
>> Why does a new organisation need to have any global IPv4 addresses of their 
>> own
>> at all?  In most cases they don’t.  It’s only inertia that is causing people 
>> to
>> want to have their own global IPv4 addresses.
>> 
>> We have IPv4 as a service which gives on demand shared IPv4 addresses.  
>> Millions
>> of people reach the IPv4 Internet every day using IPv4AAS.
>> CDNs are dual stack and provide the IPv4 presence on the net.  These days 
>> these
>> are shared addresses.
>> VPNs run over IPv6 and they can in turn run over IPv6 in IPv4 tunnels when
>> the remote doesn’t support native IPv6.  Its just another level on 
>> encapsulation.
>> Email is often out sourced so you don’t need your own IPv4 addresses for 
>> that.
>> Then there is in the cloud for other services, again you don’t need your own 
>> IPv4
>> addresses.
> 
> Wwll, yeah.. you don't need IPv4 addresses if you are going to be using
> somebody else's networks and services. Not that you should, though…

Why not use someone else’s IPv4 addresses?  Really.  What is wrong with using
someone else’s IPv4 addresses if it achieves the need?  As far as I can tell
nothing.

Just because enterprises that established themselves in a  IPv4-only world did
it one way.  It doesn’t mean that enterprises establishing themselves in a IPv4 
/
IPv6 world need to follow that model.

Mark

> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

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

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Tue, 03 Dec 2019 14:12:27 +1100, Mark Andrews said:

> Email is often out sourced so you don’t need your own IPv4 addresses for 
> that.
> Then there is in the cloud for other services, again you don’t need your 
> own IPv4
> addresses.

Are you seriously trying to say "If you're a new company, there's no plausible
reason for you to need your own IPv4 addresses, because there's no reason for
you to have your own mail servers or web servers"?

Because if it *were* true that people don't need v4 addresses so they can 
dual-stack,
we wouldn't have a healthy market buying and selling v4 address space.



pgpI6UkYlltNv.pgp
Description: PGP signature

A new open source RPKI CA solution: NLnet Labs' Krill

[Job Snijders]

Dear fellow network operators,

It appears Santa brought presents early this year! I'd like to draw
attention to the below forwarded message and provide my take on it.

Some of you represent organisations that interact with multiple RIRs,
and have concluded it can be challenging to figure out the RPKI ROA
provisioning process for each individual RIR and integrate those
different processes with your internal business process.

Every RIR provides their members with what is called a 'hosted' RPKI
service. The 'hosted' RPKI service means the RIRs offer web interfaces
which operators use to create & publish RPKI ROAs. However, the devil is
in de details: concepts such as 'who holds the private keys?' or the API
specification differ from RIR to RIR. In this context the differences
aren't necessarily good or bad, they are just different.

For many operators the RIR hosted model is excellent, but ... there also
is a class of users who would perhaps benefit from something more
'unified', and this is where Krill comes in!

The use case where Krill really shines is that you can ask your RIR to
delegate your resources to your Krill instance, and then build your
tooling to interact with just Krill (instead of building RIR-specific
software)!

To me the very existence of Krill is a sign of a maturing RPKI
ecosystem. If I stare deeply into my crystal ball I can already see the
rise of third-party hosted RPKI solutions for provisioning & monitoring
RPKI objects, or integrations with IPAM systems such as 6connect. I
believe these would be positive developments for the operational
Internet community.

In short: if RPKI is on your company's roadmap, give Krill a spin! :)

get the goods: https://github.com/NLnetLabs/krill
documentation: https://rpki.readthedocs.io/en/latest/krill/

Kind regards,

Job

- Forwarded message from Alex Band  -

Date: Tue, 3 Dec 2019 12:33:51 +0100
From: Alex Band 
To: r...@nlnetlabs.nl
Subject: [RPKI] Krill 0.4.0 'The Krill Factor' released and running in
production

Dear mailing list,

We are incredibly proud to introduce Krill 0.4.0 'The Krill Factor'. This
release is the culmination of one and a half years of designing, building,
testing and documenting our RPKI Certificate Authority (CA) and
Publication Server solution.

The first three releases of Krill were meant to test the implementation.
With Krill 0.4.0 'The Krill Factor', we are confident that the software
can be used reliably with all five Regional Internet Registries (RIRs) and
its Route Origin Authorisations (ROAs) are correctly validated by all
Relying Party software implementations. As a result, NLnet Labs is now
running Krill in production under the RIPE NCC parent CA.

With Krill 0.4.0 'The Krill Factor', operators can now generate and
publish RPKI cryptographic material themselves to authorise their BGP
announcements. It supports running RPKI under all five RIRs simultaneously
and transparently, so if you have IP address space in multiple regions you
can manage it as a single pool. Krill can also delegate to child
organisations or customers who, in turn, run their own CA. The built-in
publication server lets operators publish certificates and ROAs from their
own infrastructure. Alternatively, you can use a third party which offers
RPKI publication as a service. In short, all essential functions to run
RPKI yourself using Krill are now available.

Krill can be managed using a Command Line Interface (CLI), as well as an
Application Programming Interface (API). An optional web-based user
interface is currently being developed as a separate project, named
Lagosta. With Krill 0.4.0 'The Krill Factor' data storage and the API are
now stable, allowing for seamless updates going forward. This release
serves as a starting point for further development throughout 2020 and
beyond, where we will work on features such as high availability and
support for just-in-time authorisations integrated tightly with internal
routing management.

Starting with Krill 0.4.0 and Routinator 0.6.0 we are offering commercial
support for our RPKI software solutions, in case this is a requirement for
your organisation or if you want to support the future development of the
software. The service-level agreement (SLA) contract and security policy
is on par with our DNS software NSD and Unbound. End of support for the
software will be publicly announced two years in advance. Krill is
licensed under the Mozilla Public License 2.0. Routinator and all
libraries that are built to support the RPKI toolset are licensed under
the BSD 3-Clause License.

Once again, We would like to extend our gratitude to NIC.br, the RIPE NCC
Community Projects Fund, the Dutch National Cyber Security Centre and the
Mozilla Open Source Support Fund for financially supporting the
development of Krill, as well as our Relying Party software package
Routinator. In addition, our thanks go out to DigitalOcean for offering
their cloud infrastructure for our automated test 

Re: RIPE our of IPv4

[Fernando Gont]

On 3/12/19 00:12, Mark Andrews wrote:
> 
> 
>> On 3 Dec 2019, at 13:31, Valdis Klētnieks  wrote:
>>
>> On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said:
>>
 I believe that Dmitry's point is that we will still require IPv4 addresses 
 for new
 organizations deploying dual-stack
>>>
>>> I think I understood what you meant, but not what you said.
>>
>>> If someone is dual stack, they are IPv6-capable and IPv4-capable.
>>
>> And they're going to need v4 addresses to be v4-capable, aren't there?
>>
>> A new corporation that's trying to spin up dual-stack is going to need 2
>> address allocations, a v4 and a v6.
> 
> Why does a new organisation need to have any global IPv4 addresses of their 
> own
> at all?  In most cases they don’t.  It’s only inertia that is causing people 
> to
> want to have their own global IPv4 addresses.
> 
> We have IPv4 as a service which gives on demand shared IPv4 addresses.  
> Millions
> of people reach the IPv4 Internet every day using IPv4AAS.
> CDNs are dual stack and provide the IPv4 presence on the net.  These days 
> these
> are shared addresses.
> VPNs run over IPv6 and they can in turn run over IPv6 in IPv4 tunnels when
> the remote doesn’t support native IPv6.  Its just another level on 
> encapsulation.
> Email is often out sourced so you don’t need your own IPv4 addresses for that.
> Then there is in the cloud for other services, again you don’t need your own 
> IPv4
> addresses.

Wwll, yeah.. you don't need IPv4 addresses if you are going to be using
somebody else's networks and services. Not that you should, though

-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: RIPE our of IPv4

[Randy Bush]

> Why does a new organisation need to have any global IPv4 addresses of
> their own at all?

if all folk saying such things would make their in- and out-bound mail
servers v6-only, it would reduce confusion in this area.

randy