Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Avamander]

If we keep in mind the fact that developer time is limited, the decision
should boil down to if there are better places to spend the time on. If
there are more important measurements, then that time should be spent there
instead. That was my point.

On Tue, Feb 16, 2021 at 6:41 PM Bengt Gördén  wrote:

> On 2021-02-16 15:55, Avamander wrote:
> > some may find it controversial, but I don't think any effort should be
> spent
> > at extending the life of IPv4. In this case, by extending the address
> space.
>
> I don't agree. This is a measurement tool. Whatever people think about
> extending
> or not extending the lifetime of ipv4 is irrelevant. It shouldn't hinder
> measurements of said networks. If there's networks out there that pass 0/8
> and
> 240/4 it's VERY relevant to measure it. Just because you can't see it it
> doesn't
> mean it's not there.
>
>
> --
> /bengan
>
>

Re: [atlas] [E] Re: [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Marcel Flores]

To echo some of the above sentiments, it seems to me if it represents a way
in which (at least some) folks might try and use the Internet it makes
sense to have a mechanism for measuring it.

-Marcel

On Tue, Feb 16, 2021 at 12:43 PM Peter Eckel  wrote:

> Hi Robert,
>
> my 2c: I don't think that any effort should be spent trying to ride a dead
> horse. The sooner IPv4 finally becomes obsolete, the better.
>
> Best regards,
>
>   Peter.
>
>
>

-- 
*Marcel Flores, PhD* | Sr. Research Scientist
research.verizondigitalmedia.com | AS15133

e: marcel.flo...@verizondigitalmedia.com
13031 W Jefferson Blvd. Building 900, Los Angeles, CA 90094

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Peter Eckel]

Hi Robert, 

my 2c: I don't think that any effort should be spent trying to ride a dead 
horse. The sooner IPv4 finally becomes obsolete, the better.

Best regards, 

  Peter.

> On 16. Feb 2021, at 15:51, Robert Kisteleki  wrote:
> 
> Dear All,
> 
> A little bit of poking since there were no reactions to this question on the 
> MAT mailing list.
> 
> Before embarking on evaluating what it takes for RIPE Atlas to contribute to 
> this, I'd like to ask for some input from the community; is this something we 
> should spend energy on? More specifically, would it be worthwhile for us to 
> spend time on evaluating the cost of / implementing such measurements in RIPE 
> Atlas?
> 
> Regards,
> Robert Kisteleki
> 
> 
> 
> On 2021-01-26 08:28, Seth David Schoen wrote:
>> Hi mat-wg,
>> I'm Seth, formerly a staff technologist at EFF and one of the
>> co-developers of Let's Encrypt and Certbot.
>> Recently, I've been working with John Gilmore on the IPv4 Unicast
>> Extensions Project, which aims to make some of the IPv4 address blocks
>> that were reserved in the 1980s and 1990s (and that continue to be unused,
>> or nearly so) available for addressing and routing on the Internet.
>> This project involves many different kinds of work, including writing
>> software patches to make various OSes and devices willing to generate
>> and accept packets to reserved addresses, writing Internet-Drafts to
>> describe addressing policy changes with IETF, testing devices to see how
>> they actually treat such packets, talking to various constituencies
>> about these proposals, and working with the Internet measurement
>> community to understand how the Internet as a whole treats packets to or
>> from currently-reserved address ranges, and how that treatment evolves
>> over time.
>> Two prominent examples that are already supported by Linux hosts are the
>> netblocks 0/8 ("this network") and 240/4 ("experimental"/"future use").
>> According to Internet standards created in the 1980s and still in
>> effect, these address ranges cannot be allocated and should not be
>> assigned to hosts or used on the public Internet.  However, several key
>> implementations started allowing 240/4 addresses about 11 years ago
>> during an earlier IETF attempt to open up that netblock, including
>> Linux, Android, macOS, iOS, and Solaris.  In 2019, Linux kernel version
>> 5.3 allowed ordinary unicast use of 0/8.  Today, there are rumors that
>> various organizations are currently using such reserved addresses as
>> unofficial RFC 1918-like private address space, without formal policy
>> coordination with anyone.  (There is even some public documentation from
>> Google suggesting making private use of 240/4.)
>> I participated in the Atlas probe deployathon in November and
>> successfully got a probe up and running.  I have also been talking to
>> a few RIPE people about our interests and managed to confirm that
>> (regardless of their underlying OS or network treatment) the Atlas
>> software probes will reject probing any reserved address space, while
>> the backend infrastructure will refuse to ask probes to connect to it.
>> So, I'm here to introduce our project and ask the community's view about
>> removing these restrictions so that such addresses can actually be
>> probed and measured.  We understand and hope that the majority of such
>> tests would currently result in errors.  Even the errors themselves
>> could be interesting: for example, we would like to know how often
>> routing to reserved address ranges fails on a probe host, versus on the
>> probe host's first-hop router, versus inside of ISP infrastructure.  We
>> would also like to see how this changes over time as a result of OS
>> software changes that roll out into the field.  We would also like to
>> see whether we can detect unofficial use of particular reserved address
>> ranges as private address space.  Our medium-term goal is to advertise
>> global routes to portions of these reserved address spaces, and use the
>> probes to assess how well those routes propagate through the Internet,
>> and find where blockages occur.  Clearly, we can't do this until both
>> the probe firmware, and the central dispatcher, allow tests to these
>> addresses.  Our long-term goal is to have these addresses treated as
>> ordinary unicast addresses by all nodes, including Atlas probes, so the
>> Atlas changes to remove the restrictions would be useful permanent
>> changes.
> 

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[JORDI PALET MARTINEZ]

+1

 

This time is much better invested in deploying IPv6.

 

 

El 16/2/21 15:59, "ripe-atlas en nombre de Avamander" 
 escribió:

 

Hi,

 

some may find it controversial, but I don't think any effort should be spent at 
extending the life of IPv4. In this case, by extending the address space.

 

On Tue, Feb 16, 2021 at 4:52 PM Robert Kisteleki  wrote:

Dear All,

A little bit of poking since there were no reactions to this question on 
the MAT mailing list.

Before embarking on evaluating what it takes for RIPE Atlas to 
contribute to this, I'd like to ask for some input from the community; 
is this something we should spend energy on? More specifically, would it 
be worthwhile for us to spend time on evaluating the cost of / 
implementing such measurements in RIPE Atlas?

Regards,
Robert Kisteleki



On 2021-01-26 08:28, Seth David Schoen wrote:
> Hi mat-wg,
> 
> I'm Seth, formerly a staff technologist at EFF and one of the
> co-developers of Let's Encrypt and Certbot.
> 
> Recently, I've been working with John Gilmore on the IPv4 Unicast
> Extensions Project, which aims to make some of the IPv4 address blocks
> that were reserved in the 1980s and 1990s (and that continue to be unused,
> or nearly so) available for addressing and routing on the Internet.
> 
> This project involves many different kinds of work, including writing
> software patches to make various OSes and devices willing to generate
> and accept packets to reserved addresses, writing Internet-Drafts to
> describe addressing policy changes with IETF, testing devices to see how
> they actually treat such packets, talking to various constituencies
> about these proposals, and working with the Internet measurement
> community to understand how the Internet as a whole treats packets to or
> from currently-reserved address ranges, and how that treatment evolves
> over time.
> 
> Two prominent examples that are already supported by Linux hosts are the
> netblocks 0/8 ("this network") and 240/4 ("experimental"/"future use").
> According to Internet standards created in the 1980s and still in
> effect, these address ranges cannot be allocated and should not be
> assigned to hosts or used on the public Internet.  However, several key
> implementations started allowing 240/4 addresses about 11 years ago
> during an earlier IETF attempt to open up that netblock, including
> Linux, Android, macOS, iOS, and Solaris.  In 2019, Linux kernel version
> 5.3 allowed ordinary unicast use of 0/8.  Today, there are rumors that
> various organizations are currently using such reserved addresses as
> unofficial RFC 1918-like private address space, without formal policy
> coordination with anyone.  (There is even some public documentation from
> Google suggesting making private use of 240/4.)
> 
> I participated in the Atlas probe deployathon in November and
> successfully got a probe up and running.  I have also been talking to
> a few RIPE people about our interests and managed to confirm that
> (regardless of their underlying OS or network treatment) the Atlas
> software probes will reject probing any reserved address space, while
> the backend infrastructure will refuse to ask probes to connect to it.
> 
> So, I'm here to introduce our project and ask the community's view about
> removing these restrictions so that such addresses can actually be
> probed and measured.  We understand and hope that the majority of such
> tests would currently result in errors.  Even the errors themselves
> could be interesting: for example, we would like to know how often
> routing to reserved address ranges fails on a probe host, versus on the
> probe host's first-hop router, versus inside of ISP infrastructure.  We
> would also like to see how this changes over time as a result of OS
> software changes that roll out into the field.  We would also like to
> see whether we can detect unofficial use of particular reserved address
> ranges as private address space.  Our medium-term goal is to advertise
> global routes to portions of these reserved address spaces, and use the
> probes to assess how well those routes propagate through the Internet,
> and find where blockages occur.  Clearly, we can't do this until both
> the probe firmware, and the central dispatcher, allow tests to these
> addresses.  Our long-term goal is to have these addresses treated as
> ordinary unicast addresses by all nodes, including Atlas probes, so the
> Atlas changes to remove the restrictions would be useful permanent
> changes.
> 
> 



**
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, 

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Randy Bush]

> I think the answer very much depends on who you ask.

with my researcher hat on, i am curious yellow.  with a minor concern
for how much of the lab's resources it would consume.

with my operator hat on, kinda meh.  the long tail of recalcitrant
devices is likely to be far too operationally painful.  but truth is,
i do not know the size or length of that tail.  which tweaks my
researcher hat.

so i would be interested in learning the details of an experimental
design to tease out where the problems would be.  seems like the kind of
engineering an rir should be doing.

> Those that have beein doing IPv6 since ages would claim that any time
> spent on "making formerly-reserved IPv4 addresses usable world-wide"
> is energy lost on making IPv4 go away instead... so, "no".

a, religion.  robert and crew, can we do zealotry measurements with
atlas probes? :)

> have you enabled IPv6 on something today...?

not for years.

randy

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Chriztoffer Hansen]

On Tue, 16 Feb 2021 at 17:40, Bengt Gördén  wrote:
> I don't agree. This is a measurement tool. Whatever people think about 
> extending
> or not extending the lifetime of ipv4 is irrelevant. It shouldn't hinder
> measurements of said networks. If there's networks out there that pass 0/8 and
> 240/4 it's VERY relevant to measure it. Just because you can't see it it 
> doesn't
> mean it's not there.

I support this notion, too - Avoinding the part about if it's stupid
or "brilliant" to expand the public v4 space - Focusing on the RIPE
Atlas part.

Knowing the current extent to which e.g. 240/4 is deployed in the wild
from a measurement perspective I find an interesting object to read
"research results" on.

Putting this in as a future [feature request] for the software
development of the RIPE Atlas probe software (for the developer team
to evaluate) I do not see an issue with it at all.

Thou, all feature requests (regarding the RIPE Atlas software) should
of course be objectively analyzed. How "expensive" the feature request
will be factually implemented in the end. I.e. the "usual" impact
analysis.

-- 
Chriztoffer

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Carsten Schiefner]

+1 - what Bengt says.

Best,

-C.

On 16.02.2021 17:40, Bengt Gördén wrote:

On 2021-02-16 15:55, Avamander wrote:
some may find it controversial, but I don't think any effort should be 
spent at extending the life of IPv4. In this case, by extending the 
address space.


I don't agree. This is a measurement tool. Whatever people think about 
extending or not extending the lifetime of ipv4 is irrelevant. It 
shouldn't hinder measurements of said networks. If there's networks out 
there that pass 0/8 and 240/4 it's VERY relevant to measure it. Just 
because you can't see it it doesn't mean it's not there.



--
/bengan

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Bengt Gördén]

On 2021-02-16 15:55, Avamander wrote:
some may find it controversial, but I don't think any effort should be spent 
at extending the life of IPv4. In this case, by extending the address space.


I don't agree. This is a measurement tool. Whatever people think about extending 
or not extending the lifetime of ipv4 is irrelevant. It shouldn't hinder 
measurements of said networks. If there's networks out there that pass 0/8 and 
240/4 it's VERY relevant to measure it. Just because you can't see it it doesn't 
mean it's not there.



--
/bengan

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Avamander]

Hi,

some may find it controversial, but I don't think any effort should be
spent at extending the life of IPv4. In this case, by extending the address
space.

On Tue, Feb 16, 2021 at 4:52 PM Robert Kisteleki  wrote:

> Dear All,
>
> A little bit of poking since there were no reactions to this question on
> the MAT mailing list.
>
> Before embarking on evaluating what it takes for RIPE Atlas to
> contribute to this, I'd like to ask for some input from the community;
> is this something we should spend energy on? More specifically, would it
> be worthwhile for us to spend time on evaluating the cost of /
> implementing such measurements in RIPE Atlas?
>
> Regards,
> Robert Kisteleki
>
>
>
> On 2021-01-26 08:28, Seth David Schoen wrote:
> > Hi mat-wg,
> >
> > I'm Seth, formerly a staff technologist at EFF and one of the
> > co-developers of Let's Encrypt and Certbot.
> >
> > Recently, I've been working with John Gilmore on the IPv4 Unicast
> > Extensions Project, which aims to make some of the IPv4 address blocks
> > that were reserved in the 1980s and 1990s (and that continue to be
> unused,
> > or nearly so) available for addressing and routing on the Internet.
> >
> > This project involves many different kinds of work, including writing
> > software patches to make various OSes and devices willing to generate
> > and accept packets to reserved addresses, writing Internet-Drafts to
> > describe addressing policy changes with IETF, testing devices to see how
> > they actually treat such packets, talking to various constituencies
> > about these proposals, and working with the Internet measurement
> > community to understand how the Internet as a whole treats packets to or
> > from currently-reserved address ranges, and how that treatment evolves
> > over time.
> >
> > Two prominent examples that are already supported by Linux hosts are the
> > netblocks 0/8 ("this network") and 240/4 ("experimental"/"future use").
> > According to Internet standards created in the 1980s and still in
> > effect, these address ranges cannot be allocated and should not be
> > assigned to hosts or used on the public Internet.  However, several key
> > implementations started allowing 240/4 addresses about 11 years ago
> > during an earlier IETF attempt to open up that netblock, including
> > Linux, Android, macOS, iOS, and Solaris.  In 2019, Linux kernel version
> > 5.3 allowed ordinary unicast use of 0/8.  Today, there are rumors that
> > various organizations are currently using such reserved addresses as
> > unofficial RFC 1918-like private address space, without formal policy
> > coordination with anyone.  (There is even some public documentation from
> > Google suggesting making private use of 240/4.)
> >
> > I participated in the Atlas probe deployathon in November and
> > successfully got a probe up and running.  I have also been talking to
> > a few RIPE people about our interests and managed to confirm that
> > (regardless of their underlying OS or network treatment) the Atlas
> > software probes will reject probing any reserved address space, while
> > the backend infrastructure will refuse to ask probes to connect to it.
> >
> > So, I'm here to introduce our project and ask the community's view about
> > removing these restrictions so that such addresses can actually be
> > probed and measured.  We understand and hope that the majority of such
> > tests would currently result in errors.  Even the errors themselves
> > could be interesting: for example, we would like to know how often
> > routing to reserved address ranges fails on a probe host, versus on the
> > probe host's first-hop router, versus inside of ISP infrastructure.  We
> > would also like to see how this changes over time as a result of OS
> > software changes that roll out into the field.  We would also like to
> > see whether we can detect unofficial use of particular reserved address
> > ranges as private address space.  Our medium-term goal is to advertise
> > global routes to portions of these reserved address spaces, and use the
> > probes to assess how well those routes propagate through the Internet,
> > and find where blockages occur.  Clearly, we can't do this until both
> > the probe firmware, and the central dispatcher, allow tests to these
> > addresses.  Our long-term goal is to have these addresses treated as
> > ordinary unicast addresses by all nodes, including Atlas probes, so the
> > Atlas changes to remove the restrictions would be useful permanent
> > changes.
> >
> >
>
>

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Gert Doering]

Hi,

On Tue, Feb 16, 2021 at 03:51:57PM +0100, Robert Kisteleki wrote:
> Before embarking on evaluating what it takes for RIPE Atlas to 
> contribute to this, I'd like to ask for some input from the community; 
> is this something we should spend energy on? More specifically, would it 
> be worthwhile for us to spend time on evaluating the cost of / 
> implementing such measurements in RIPE Atlas?

I think the answer very much depends on who you ask.

Those that have beein doing IPv6 since ages would claim that any time
spent on "making formerly-reserved IPv4 addresses usable world-wide" is
energy lost on making IPv4 go away instead... so, "no".

Those that want to avoid deploying IPv6 will, of course, support anything,
no matter how expensive, which gives them the illusion that this is a viable
strategy :-)

I think my response might be a bit biased.

But actually it might be interesting to know...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Robert Kisteleki]

Dear All,

A little bit of poking since there were no reactions to this question on 
the MAT mailing list.


Before embarking on evaluating what it takes for RIPE Atlas to 
contribute to this, I'd like to ask for some input from the community; 
is this something we should spend energy on? More specifically, would it 
be worthwhile for us to spend time on evaluating the cost of / 
implementing such measurements in RIPE Atlas?


Regards,
Robert Kisteleki



On 2021-01-26 08:28, Seth David Schoen wrote:

Hi mat-wg,

I'm Seth, formerly a staff technologist at EFF and one of the
co-developers of Let's Encrypt and Certbot.

Recently, I've been working with John Gilmore on the IPv4 Unicast
Extensions Project, which aims to make some of the IPv4 address blocks
that were reserved in the 1980s and 1990s (and that continue to be unused,
or nearly so) available for addressing and routing on the Internet.

This project involves many different kinds of work, including writing
software patches to make various OSes and devices willing to generate
and accept packets to reserved addresses, writing Internet-Drafts to
describe addressing policy changes with IETF, testing devices to see how
they actually treat such packets, talking to various constituencies
about these proposals, and working with the Internet measurement
community to understand how the Internet as a whole treats packets to or
from currently-reserved address ranges, and how that treatment evolves
over time.

Two prominent examples that are already supported by Linux hosts are the
netblocks 0/8 ("this network") and 240/4 ("experimental"/"future use").
According to Internet standards created in the 1980s and still in
effect, these address ranges cannot be allocated and should not be
assigned to hosts or used on the public Internet.  However, several key
implementations started allowing 240/4 addresses about 11 years ago
during an earlier IETF attempt to open up that netblock, including
Linux, Android, macOS, iOS, and Solaris.  In 2019, Linux kernel version
5.3 allowed ordinary unicast use of 0/8.  Today, there are rumors that
various organizations are currently using such reserved addresses as
unofficial RFC 1918-like private address space, without formal policy
coordination with anyone.  (There is even some public documentation from
Google suggesting making private use of 240/4.)

I participated in the Atlas probe deployathon in November and
successfully got a probe up and running.  I have also been talking to
a few RIPE people about our interests and managed to confirm that
(regardless of their underlying OS or network treatment) the Atlas
software probes will reject probing any reserved address space, while
the backend infrastructure will refuse to ask probes to connect to it.

So, I'm here to introduce our project and ask the community's view about
removing these restrictions so that such addresses can actually be
probed and measured.  We understand and hope that the majority of such
tests would currently result in errors.  Even the errors themselves
could be interesting: for example, we would like to know how often
routing to reserved address ranges fails on a probe host, versus on the
probe host's first-hop router, versus inside of ISP infrastructure.  We
would also like to see how this changes over time as a result of OS
software changes that roll out into the field.  We would also like to
see whether we can detect unofficial use of particular reserved address
ranges as private address space.  Our medium-term goal is to advertise
global routes to portions of these reserved address spaces, and use the
probes to assess how well those routes propagate through the Internet,
and find where blockages occur.  Clearly, we can't do this until both
the probe firmware, and the central dispatcher, allow tests to these
addresses.  Our long-term goal is to have these addresses treated as
ordinary unicast addresses by all nodes, including Atlas probes, so the
Atlas changes to remove the restrictions would be useful permanent
changes.