date:20220325


*** Resend to go through NANOG 


On 2022-03-23 11:59, Abraham Y. Chen wrote:

Dear Pascal:

0)    So glad to see your recount of the history and the analysis!

1)    We have recently formulated a proposal called EzIP (Phonetic for 
Easy IPv4) that is very much along the line of what you just described 
below, but with a few twists. I browsed through US patent 7,356,031, 
but failed to spot the key word "240. It appears to me that it was 
more a general concept than practice. Did you submit a draft on your 
work to IETF? Perhaps due to these, our (including patent examiner's) 
prior art search never came across your work. Although, your patent 
was granted in the same year as the Normative Reference [2] of our 
IETF draft. Please have a quick read of the below whitepaper. It 
provides you an overview of EzIP as well as references to US Pat. 
No.11,159,425, the current IETF draft and a feasibility demonstration 
setup.


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)    Here is a few quick comparisons between our two teams' work and 
the outline of EzIP benefits:


    A.    Your "Realm" is very much equivalent to our RAN (Regional 
Area Network). However, instead of utilizing 240.0.0/8, we propose to 
use the full 240/4 each to maximize its effectiveness. Each RAN can 
serve up to 39M population as large as Tokyo Metro, even before 
utilizing the three private netblocks.


    B.    Your "Elevator Shaft" making use of part of the 240/4 pool 
is equivalent to our single IPv4 public address to tether a RAN from 
the Internet core. Ours is a "micro" building block approach that 
provides more flexibility. For example, up to 75% of the smaller 
countries around the world need only one IPv4 each to achieve the 
"Elevator Shaft" configuration.
    C.    Your "Inter-Realm Router" is simply the current Internet 
core routers in the EzIP scheme.


    D.   Instead of proposing any modification to the IP packet 
header, EzIP can deploy within the capability of the RFC791. That is, 
when inter-RAN traffic is needed, the Option Word mechanism is 
activated to carry the 240/4 addresses within the RAN, leaving the 
basic source and destination address fields to carry the public IPv4 
addresses of the RANs at either end.


    E.    EzIP implementation is very straightforward. We have 
identified at least one case that only requires "*/disabling/* the 
program code that has been */disabling/* the use of the 240/4 
netblock". With your software expertise, you likely know other 
configurations.


    F.    EzIP essentially proposes to expand the address pool 
currently used by CG-NAT without any hardware change. In addition, the 
simplification in administrating the 240/4 addresses deterministically 
can mitigate the root cause to the cyber insecurity, thus reducing the 
OpEx.


    G.    Treating 240/4 as the fourth netblock in RFC1918 allows the 
RAN to operate pretty much independent of the Internet core. On the 
other hand, being rejected by current routers enables RANs to be 
deployed worldwide by themselves without interference in either 
direction. This forms an */overlay /*network providing Internet-like 
services while having individualized flexibility per RAN.


    H.    As more and more RANs are deployed, there will be increasing 
number of IPv4 public addresses becoming "spares". Each can support 
one RAN to serve other purposes, such as true test beds for 
experimenting new protocols.


    I.    There probably are a few more parallelisms that we can 
identify, as we discuss more.


I look forward to your thoughts and critiques.

Regards,


Abe (2022-03-23 11:59 EDT)



On 2022-03-23 05:01, Pascal Thubert (pthubert) via NANOG wrote:

I see the same thing from the other side, being a S/W developer for switching 
and routing boxes since the early 90's. The PM barrier is a high wall indeed. 
And yet some techs succeed to pass it. What I'm arguing is that we can pass 
that wall if we work together with the same objective.

I've been monitoring this list for a while, very insightful, very happy with 
what I learn in the process. But here I feel compelled to react. I read that 
IPv6 did not succeed in 25 years. But unless I miss something, complaining did 
not succeed either, did it?

My frustration is that indeed (as a dev guy) we have been trying hard to serve users our 
best. We proposed a number of things in the IPv4 evolution direction that I see being 
asked on this list. For larger IPv4 space and smooth migration, I'm personally fond of 
the IP-in-IP variation that filed in 20+ years ago as US patent 7,356,031. Basically we 
reserve a /8, say, since it is so popular at this time, 240.0.0./8, and make it the 
"elevator shaft" between IPv4 realms. Say the current IPv4 Internet is realm 1, 
that Internet would have IP address 240.0.0.1/8 in the shaft, and would continue 
operating as is, without a change in hosts and routers for traffic staying inside the 
current

Re: V6 still not supported R: 202203232156.AYC


** Resend to go through NANOG ***


On 2022-03-23 23:11, Abraham Y. Chen wrote:

Dear Pascal:

1)    "   Did you propose this work at a WG in Vienna this week?  
":    No, but I was invited to be a coauthor of a HuaWei study 
comparing addressing schemes that was presented there. See material 
attached.


2)    " I coined the term elevator shaft for the description 
below  , but the lawyer language is hard to parse for the rest of 
us so I paraphrased and exemplified. ... ":    Well, the lawyer got 
paid for his legalese. But, I doubt the essence of your patent. (See 
more thoughts below.)


3)    ".. And I just picked 240.0.0.0/8 as an example ...    ":    
This is not the way to link up with another Intellectual Property 
work. You need to present your implementation, before paraphrasing to 
others. Otherwise, it is more than misleading.


4)    " Now that you’re aware of the possible prior art ...   ":    
Not too fast! As I stated, neither myself nor the patent examiner of 
my case found your work. And, I characterize your claim as "more a 
general /*concept*/*//*than practice." So, if the examiner did pick up 
your patent, he probably decided to disregard it. What you need to 
understand is that the basic criterion for granting a patent is:


    "The */first/* party who has the */original idea/* that has been 
reduced to */practice/**//*for teaching the general public."


    I do not believe that yours could pass such a simple test, not to 
mention that the proposed header changes were so extensive compared to 
EzIP's simple no-change approach (using  only the old-fashioned RFC791).


    Note: There was a historical issue about what qualified an 
Internet related work for a patent (at least in US) around the turn of 
this century. The most famous one was the "one-click purchase" scheme 
by Amazon. Yours appear to be close to the other end of the extreme, 
because fourteen years later (the patent life of seventeen years is 
almost over) you are still paraphrasing, without a working model to 
show. I do not want to burden colleagues on this List with the 
details. If you want, I can give you a run-down offline.


5)    " I guess we need to continue that discussion on an IETF ML 
rather than here,   ": Let me know where you feel is more appropriate, 
after you have reviewed the above.


Regards,


Abe (2022-03-23 23:10 EDT)



On 2022-03-23 12:47, Pascal Thubert (pthubert) wrote:


Dear Abe:

Neat  Did you propose this work at a WG in Vienna this week?

Just a few points:

* I coined the term elevator shaft for the description below. I just 
thought that it may help visualize this story; figuring the Internet 
as a 2-D flat in a building, and the special prefix bring a 3^rd 
dimension to interconnect levels as an elevator shaft does in the 
building. The 20 year old IPR did not use that term or that example, 
it was more generic than that, but the lawyer language is hard to 
parse for the rest of us so I paraphrased and exemplified.


* And I just picked 240.0.0.0/8 as an example to show that you can 
easily build 100 parallel Internets because it was discussed in 
another thread that would provide a lot less value off it, which may 
hint that the way we use that prefix should be thought carefully.


* Now that you’re aware of the possible prior art, I believe you are 
required by law to notify the USPTO so they determine what to do with 
the reference. Sorry for the hassle.


* I guess we need to continue that discussion on an IETF ML rather 
than here, unless people in the list ask for more. I’ll read with 
interest the details of your proposal.


The bottom line for NANOG is that the dev guys are willing to help, 
whether by evolving IPv6 or proposing IPv4 ideas like the ones below. 
But we need push / support from your side to pass the PM bar.


Keep safe;

Pascal

*From:* Abraham Y. Chen 
*Sent:* mercredi 23 mars 2022 16:59
*To:* Pascal Thubert (pthubert) 
*Cc:* Michael Thomas ; nanog@nanog.org
*Subject:* Re: V6 still not supported Re: 202203231017.AYC

Dear Pascal:

0)    So glad to see your recount of the history and the analysis!

1)    We have recently formulated a proposal called EzIP (Phonetic 
for Easy IPv4) that is very much along the line of what you just 
described below, but with a few twists. I browsed through US patent 
7,356,031, but failed to spot the key word "240. It appears to me 
that it was more a general concept than practice. Did you submit a 
draft on your work to IETF? Perhaps due to these, our (including 
patent examiner's) prior art search never came across your work. 
Although, your patent was granted in the same year as the Normative 
Reference [2] of our IETF draft. Please have a quick read of the 
below whitepaper. It provides you an overview of EzIP as well as 
references to US Pat. No.11,159,425, the current IETFdraft and a 
feasibility demonstration setup.


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)    Here is a few

Re: Let's Focus on Moving Forward Re: V6 still not supported


* Resend to go through NANOG 


On 2022-03-25 12:24, Abraham Y. Chen wrote:

Dear Owen:

0)    You rapid fired a few posts in succession yesterday. Some are 
interesting and crucial views that I would like to follow-up on. I 
will start from quoting the earlier ones. I hope that I am picking up 
the correct leads.


1)    " ... 240/4 is way more effort than its proponents want to 
believe and even if it were reclassified effectively as GUA, it 
doesn’t buy all that much life for IPv4. ...   ":     Perhaps you have 
not bothered to scan through a two page whitepaper (URL below, again) 
that I submitted a week or so ago? It promises simple implementation 
and significant increase of assignable IPv4 addresses, even extendable 
to the similar size of IPv6 if we could forgo our mentality about the 
IP addresses as "Personal Properties", by switching to treat them as 
"Natural Resources".


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)    " ...  so that content providers can start turning off v4 where 
it’s costing them money to support it.    " & "... Content 
providers turning off v4 face competition from content providers that 
don’t. ...  ":    These two statements appeared to come from two 
separate posting of yours. They seemed to be contradicting each other. 
Did I misread somehow?


Now from the last post below:

3)    "  ... 240/4 is way more effort than its proponents want to 
believe and even if it were reclassified effectively as GUA, it 
doesn’t buy all that much life for IPv4   ": Please see 
information provided by Pt. 1) above.


4)    " ... I think it should be reclassified from never going to be 
used into some part of the internet might actually do something with 
it. Its important that happens now, better late then never ... Please 
feel free to use it for router IDs in BGP and/or OSPF area numbers. :p 
...    ":    I am in full agreement with you. Our proposal is the 
solution in Pt. 1) above.


5)    "  ...  if we continue to waste effort that is better spent 
deploying IPv6 on bandaids and hacks to make v4 last just a little 
longer,  ":    This is not a productive opinion. Please do not 
forget that the Internet heavily promotes personal freedom. One can 
not force others to do something that they do not believe in. Stopping 
them from doing one thing does not automatically make them to do what 
you like. A project must have its own merits that attract 
contribution. The failure of the IPv6 actually started from when a 
decision was made to the effect of "not to emphasize backward 
compatibility with IPv4" which broke one of the golden rules in system 
engineering. Not recognizing such and focusing to find a way for 
remedying it, but continuing to force others to migrate to IPv6 camp 
with various tactics does not foster progress.


6)    "  ... The problem is that we’re not talking about parallel 
experiments. ... ":    EzIP is a parallel experiment to the current 
Internet (not only IPv4, but also IPv6) operations, because its 
overlay architecture on the latter demarcates everything happening on 
it from the Internet. As long as packets exchanged between the two 
conform to the established Internet protocols, an EzIP deployment 
(called RAN - Regional Area Network) will appear as innocent as an 
ordinary private network.


Regards,


Abe (2022-03-25 12:24)



On 2022-03-24 21:25, Owen DeLong via NANOG wrote:

On Mar 24, 2022, at 15:49, Joe Maimon  wrote:



Owen DeLong wrote:

On Mar 24, 2022, at 03:36 , Joe Maimon  wrote:



In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible.

I think this isn’t so much preempting the vacuum as trying to pretend we can 
survive on an hour of air for 20 years.

240/4 is way more effort than its proponents want to believe and even if it 
were reclassified effectively as GUA, it doesn’t buy all that much life for 
IPv4.

I think it should be reclassified from never going to be used into some part of 
the internet might actually do something with it. Its important that happens 
now, better late then never. Whether its GUA or not or a mix of whatever, 
whether it buys months or years will depend greatly on how its actually used if 
it is ever used.

Please feel free to use it for router IDs in BGP and/or OSPF area numbers. :p


You may be right about not being worth it. More importantly, you may be wrong. 
IPv6 is replete with not only a plethora of wrong predictions, but the same 
ones over and over again. To be clear, the only effort asked from the unwilling 
is to support cutting the red tape frustrating the willing. A hearty round of 
knock yourself out from the right folk in the right place and time and we dont 
have to debate this particular point ever again.

Certainly, if we continue to waste effort that is better spent deploying IPv6 
on bandaids and hacks to make v4 last just a little longer, we will continue

Re: Let's Focus on Moving Forward Re: V6 still not supported


**  Resend to go through NANOG **


On 2022-03-25 12:24, Abraham Y. Chen wrote:

Dear Owen:

0)    You rapid fired a few posts in succession yesterday. Some are 
interesting and crucial views that I would like to follow-up on. I 
will start from quoting the earlier ones. I hope that I am picking up 
the correct leads.


1)    " ... 240/4 is way more effort than its proponents want to 
believe and even if it were reclassified effectively as GUA, it 
doesn’t buy all that much life for IPv4. ...   ":     Perhaps you have 
not bothered to scan through a two page whitepaper (URL below, again) 
that I submitted a week or so ago? It promises simple implementation 
and significant increase of assignable IPv4 addresses, even extendable 
to the similar size of IPv6 if we could forgo our mentality about the 
IP addresses as "Personal Properties", by switching to treat them as 
"Natural Resources".


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)    " ...  so that content providers can start turning off v4 where 
it’s costing them money to support it.    " & "... Content 
providers turning off v4 face competition from content providers that 
don’t. ...  ":    These two statements appeared to come from two 
separate posting of yours. They seemed to be contradicting each other. 
Did I misread somehow?


Now from the last post below:

3)    "  ... 240/4 is way more effort than its proponents want to 
believe and even if it were reclassified effectively as GUA, it 
doesn’t buy all that much life for IPv4   ": Please see 
information provided by Pt. 1) above.


4)    " ... I think it should be reclassified from never going to be 
used into some part of the internet might actually do something with 
it. Its important that happens now, better late then never ... Please 
feel free to use it for router IDs in BGP and/or OSPF area numbers. :p 
...    ":    I am in full agreement with you. Our proposal is the 
solution in Pt. 1) above.


5)    "  ...  if we continue to waste effort that is better spent 
deploying IPv6 on bandaids and hacks to make v4 last just a little 
longer,  ":    This is not a productive opinion. Please do not 
forget that the Internet heavily promotes personal freedom. One can 
not force others to do something that they do not believe in. Stopping 
them from doing one thing does not automatically make them to do what 
you like. A project must have its own merits that attract 
contribution. The failure of the IPv6 actually started from when a 
decision was made to the effect of "not to emphasize backward 
compatibility with IPv4" which broke one of the golden rules in system 
engineering. Not recognizing such and focusing to find a way for 
remedying it, but continuing to force others to migrate to IPv6 camp 
with various tactics does not foster progress.


6)    "  ... The problem is that we’re not talking about parallel 
experiments. ... ":    EzIP is a parallel experiment to the current 
Internet (not only IPv4, but also IPv6) operations, because its 
overlay architecture on the latter demarcates everything happening on 
it from the Internet. As long as packets exchanged between the two 
conform to the established Internet protocols, an EzIP deployment 
(called RAN - Regional Area Network) will appear as innocent as an 
ordinary private network.


Regards,


Abe (2022-03-25 12:24)



On 2022-03-24 21:25, Owen DeLong via NANOG wrote:

On Mar 24, 2022, at 15:49, Joe Maimon  wrote:



Owen DeLong wrote:

On Mar 24, 2022, at 03:36 , Joe Maimon  wrote:



In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible.

I think this isn’t so much preempting the vacuum as trying to pretend we can 
survive on an hour of air for 20 years.

240/4 is way more effort than its proponents want to believe and even if it 
were reclassified effectively as GUA, it doesn’t buy all that much life for 
IPv4.

I think it should be reclassified from never going to be used into some part of 
the internet might actually do something with it. Its important that happens 
now, better late then never. Whether its GUA or not or a mix of whatever, 
whether it buys months or years will depend greatly on how its actually used if 
it is ever used.

Please feel free to use it for router IDs in BGP and/or OSPF area numbers. :p


You may be right about not being worth it. More importantly, you may be wrong. 
IPv6 is replete with not only a plethora of wrong predictions, but the same 
ones over and over again. To be clear, the only effort asked from the unwilling 
is to support cutting the red tape frustrating the willing. A hearty round of 
knock yourself out from the right folk in the right place and time and we dont 
have to debate this particular point ever again.

Certainly, if we continue to waste effort that is better spent deploying IPv6 
on bandaids and hacks to make v4 last just a little longer, we will continue to 
fail

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

2022-03-25 Thread Amir Herzberg

Hi Matthew and NANOG,

I don't want to defend prepending 255 times, and can understand filtering
of extra-prepended-announcements, but I think Matthew may not be correct
here:

> Anyone that is prepending to do traffic engineering is
> doing *differential* prepending; that is, a longer number
> of prepends along one path, with a shorter set of prepends
> along a different path.
>
> So, dropping the inbound announcement with 255 prepends
> merely means your router will look for the advertisement with
> a shorter number of prepends on it.
>

Right. But let's consider the (typical) case where someone is prepending
for traffic engineering. Now, if you're not very near to the origin of the
prepended announcement, and still received it (and not the shorter
alternative), then it is quite likely that you received it since the
alternate path failed - and the backup path was announced, instead (by
upstreams of the origin). So your router is quite likely not to receive the
shorter announcement.

After all, if your router received both short and long announcements (from
same relationship, e.g., both from providers), then your router would
probably select the shorter path anyway, without need to filter out the
long one, right?

So, filtering announcements with many prepends may cause you to lose
connectivity to these networks. Of course, you may not mind losing
connectivity to Kazakhstan :) ...

best, Amir

>
>
> --
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
 https://sites.google.com/site/amirherzberg/applied-crypto-textbook





On Fri, Mar 25, 2022 at 8:19 PM Matthew Petach 
wrote:

>
>
> On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson 
> wrote:
>
>> Tom, how exactly does someone “ride the 0/0” train in the DFZ?
>>
>
> It's not so much "ride the 0/0 train" as much as it is
> "treat excessive prepends as network-unreachable"
>
> Think of prepends beyond say 10 prepends as a way
> to signal "infinite" distance--essentially, "unreachable"
> for that prefix along that path.
>
> Anyone that is prepending to do traffic engineering is
> doing *differential* prepending; that is, a longer number
> of prepends along one path, with a shorter set of prepends
> along a different path.
>
> So, dropping the inbound announcement with 255 prepends
> merely means your router will look for the advertisement with
> a shorter number of prepends on it.
>
> If you're only announcing one path for your prefix, and it is
> prepended 255 times, you're fundamentally not understanding
> how BGP works, and the only way to get a clue-by-four might
> be to discover you've made your prefix invisible to a significant
> portion of the internet.
>
>
>>
>>
>> I’m connected to both commercial internet and NREN, and
>> unfortunately-long paths are not uncommon in this scenario, in order to do
>> traffic steering.  If there’s another solution that affects global
>> *inbound* traffic distributions, I’d love to hear about it (and so would
>> a lot of my peers in edu).
>>
>>
>>
>> If there were a usable way to “dump” the excessively-long path only as
>> long as a better path was already known by at least one edge router, that
>> might be workable, but you’d have to keep track of it somewhere to
>> reinstall it if the primary route went away… at which point you may as well
>> have not dropped it in the first place.
>>
>>
> You dump the excessively-long path based on the assumption that
> the only reason for a long set of prepends out one path is to shift
> traffic
> away from that path to one that you're advertising out with a *shorter*
> set of prepends.
>
> The router doesn't need to 'look' for or 'keep track' of the different
> path; the human makes the decision that any sane BGP speaker
> would only prepend 255 times on a path if there was a shorter
> as-path advertisement they wanted people to use instead.
>
> So, drop the excessively long prepended path, and make use
> of the 'should be in the table somewhere' advertisement of the
> prefix with fewer prepends.
>
> Easy-peasy.
>
>
>>
>>
>> -Adam
>>
>>
>>

Re: V6 still not supported

2022-03-25 Thread Owen DeLong via NANOG

> On Mar 25, 2022, at 06:30 , Jared Brown  wrote:
> 
> Owen DeLong via NANOG wrote:
>> When your ISP starts charging $X/Month for legacy protocol support
> 
> Out of interest, how would this come about?

ISPs are facing ever growing costs to continue providing IPv4 services.

Likely they will eventually have to start passing those costs along to 
IPv4-dependent customers.

Owen

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

2022-03-25 Thread Matthew Petach

On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson 
wrote:

> Tom, how exactly does someone “ride the 0/0” train in the DFZ?
>

It's not so much "ride the 0/0 train" as much as it is
"treat excessive prepends as network-unreachable"

Think of prepends beyond say 10 prepends as a way
to signal "infinite" distance--essentially, "unreachable"
for that prefix along that path.

Anyone that is prepending to do traffic engineering is
doing *differential* prepending; that is, a longer number
of prepends along one path, with a shorter set of prepends
along a different path.

So, dropping the inbound announcement with 255 prepends
merely means your router will look for the advertisement with
a shorter number of prepends on it.

If you're only announcing one path for your prefix, and it is
prepended 255 times, you're fundamentally not understanding
how BGP works, and the only way to get a clue-by-four might
be to discover you've made your prefix invisible to a significant
portion of the internet.

>
>
> I’m connected to both commercial internet and NREN, and unfortunately-long
> paths are not uncommon in this scenario, in order to do traffic steering.
> If there’s another solution that affects global *inbound* traffic
> distributions, I’d love to hear about it (and so would a lot of my peers in
> edu).
>
>
>
> If there were a usable way to “dump” the excessively-long path only as
> long as a better path was already known by at least one edge router, that
> might be workable, but you’d have to keep track of it somewhere to
> reinstall it if the primary route went away… at which point you may as well
> have not dropped it in the first place.
>
>
You dump the excessively-long path based on the assumption that
the only reason for a long set of prepends out one path is to shift traffic
away from that path to one that you're advertising out with a *shorter*
set of prepends.

The router doesn't need to 'look' for or 'keep track' of the different
path; the human makes the decision that any sane BGP speaker
would only prepend 255 times on a path if there was a shorter
as-path advertisement they wanted people to use instead.

So, drop the excessively long prepended path, and make use
of the 'should be in the table somewhere' advertisement of the
prefix with fewer prepends.

Easy-peasy.

>
>
> -Adam
>
>
>

Re: V6 still not supported

2022-03-25 Thread Owen DeLong via NANOG



> On Mar 24, 2022, at 21:18 , James R Cutler  
> wrote:
> 
> On Mar 24, 2022, at 9:25 PM, Owen DeLong via NANOG  > wrote:
>> 
>> I think that we’re still OK on allocation policies. What I’d like to see is 
>> an end to the IPv4-think in large ISPs, such as Comcast’s continued micro 
>> allocations to their customers.
> 
> What exactly is your definition of “micro allocations”? Is a prefix/56 a 
> “micro allocation”? In over nine years of being an active forum participant 
> and customer of Comcast, I can not recall the usage of the term.

They’re issuing /60s (maximum) to residential customers.

And yes, a /56 is a micro allocation. /48 is the intended norm for IPv6 site 
assignments and is a perfectly reasonable prefix size for v6 delegation to a 
site.

Owen

TIMELY - IMPORTANT NOTICE - Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022

2022-03-25 Thread John Curran

NANOGers -

Please take note of the following event that will take place in less than 10 
days time - ARIN will shut down the ARIN-NONAUTH IRR database on Monday, 4 
April 2022 at 12:00 PM ET

Any networks relying on upon routing objects in the ARIN-NONAUTH IRR database 
should be actively working on alternative arrangements.

If you have questions about this transition or need any assistance, you can 
contact ARIN by:

• Submitting an Ask ARIN ticket or chat with us using your ARIN Online account
• emailing the Routing Security Team at 
routing.secur...@arin.net
• contacting the Registration Services Help Desk by phone Monday through 
Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660

Thank you!
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: John Curran mailto:jcur...@arin.net>>
Subject: IMPORTANT NOTICE - Retirement of ARIN Non-Authenticated IRR 
rescheduled for 4 April 2022
Date: 16 February 2022 at 4:33:24 PM EST
To: NANOG Operators' Group mailto:nanog@nanog.org>>

NANOGers -

An important reminder – On 4 April 2022, ARIN's non-authenticated Internet 
Routing Registry (IRR) will be retired.

Please review the attached notice for details, and do not hesitate to contact 
ARIN if you have any questions about this transition or need assistance.

I ask that you do not hesitate to forward this notice to any others you know 
that are potentially unaware & impacted by this important transition.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] UPDATE: Retirement of ARIN Non-Authenticated IRR 
rescheduled for 4 April 2022
Date: 28 January 2022 at 9:01:07 PM GMT+4
To: "arin-annou...@arin.net" 
mailto:arin-annou...@arin.net>>

This announcement is to inform you that the retirement of the ARIN 
non-authenticated Internet Routing Registry (IRR) has been rescheduled to 4 
April 2022 at 12:00 PM EST. After this time, users will no longer be able to 
create, update, or delete records in the ARIN-NONAUTH database, and the 
ARIN-NONAUTH data stream will no longer be available in Near Real Time 
Mirroring (NRTM) or via FTP or Whois Port 43. This date change is being made in 
order to ensure that the first day after retirement does not fall on a Friday.

The following information is from the initial announcement:

ARIN has been engaged in a multi-year project to create and deploy a new and 
improved Internet Routing Registry (IRR). As a result of these efforts, ARIN 
now provides users with the ability to create, update, and delete objects in 
ARIN’s authenticated IRR database using ARIN Online or ARIN’s RESTful API. 
Unfortunately, use of ARIN’s previous non-authenticated email-based IRR service 
actually increased after ARIN released its authenticated IRR, in opposition to 
the outcome ARIN anticipated when improving its IRR.

On 8 February 2021, ARIN held a consultation to solicit input on the retirement 
of ARIN’s non-authenticated email-based IRR service. This retirement was 
originally scheduled for 30 September 2021. Based on community input, the 
proposed date for the ARIN-NONAUTH retirement was delayed to 31 March 2022 to 
allow more transition time for users. We also notified by email Points of 
Contact (POCs) of organizations who have objects in the ARIN-NONAUTH database 
of the retirement date and offered them our assistance with the transition.

If you have questions about this transition or need assistance, you can contact 
us by:

• submitting an Ask ARIN ticket or chat with us using your ARIN Online account
• emailing the Routing Security Team at 
routing.secur...@arin.net
• contacting the Registration Services Help Desk by phone Monday through 
Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660

Regards,

Brad Gorman
Senior Product Owner, Routing Security
American Registry for Internet Numbers (ARIN)

Re: ISP data collection from home routers

2022-03-25 Thread Eric Kuhnke

yes, because otherwise the contention (it's a shared access media, after
all) and RF channel bonding/allocation wouldn't work. Configuration depends
on what the exact CMTS configuration is on your last mile coax segment.

however it's also possible to have the cable MSO push an update to
cablemodems which locks out a read-only diagnostics/info page that would
otherwise be available.

On Fri, 25 Mar 2022 at 13:47, Michael Thomas  wrote:

>
> On 3/24/22 12:53 PM, Tom Beecher wrote:
> > You don't even have to use their equipment. My provider at home is
> > Charter / Spectrum. I own my own cable modem  / router ,they have no
> > equipment in my home. Their privacy policy is pretty standard.
> > Essentially :
> > - Anything they can see that I transmit they will collect.
> > - Anything they can see when I use their apps , even if I'm not on
> > their network, they will collect.
> > - They will use that information for their technical and business
> > reasons, whatever they want.
> > - I am very limited in what I can request that they don't collect or use.
> >
> > None of this is new in the US. I think more people care about
> > this than we think, but people don't really have an option to vote
> > with their wallets.
>
> Even if you own your modem, the DOCSIS specs require that it be
> completely controlled by the MSO, right?
>
> Mike
>
>
>

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

2022-03-25 Thread Brian Knight via NANOG

Ask your upstream providers for a BGP community tag that lowers localpref below 
100 within their network. Set that community tag on any backup routes along 
with your (moderate) path prepending.

The backup upstream will then install that route only if there is no other way 
to get to your AS.

The path prepending remains so that other providers can more quickly install 
the primary route when it comes back.

Those two actions together have always made any backup route behave correctly 
for me.

-Brian

> On Mar 25, 2022, at 4:57 PM, Adam Thompson  wrote:
> 
> 
> Tom, how exactly does someone “ride the 0/0” train in the DFZ?
>  
> I’m connected to both commercial internet and NREN, and unfortunately-long 
> paths are not uncommon in this scenario, in order to do traffic steering.  If 
> there’s another solution that affects global inbound traffic distributions, 
> I’d love to hear about it (and so would a lot of my peers in edu).
>  
> If there were a usable way to “dump” the excessively-long path only as long 
> as a better path was already known by at least one edge router, that might be 
> workable, but you’d have to keep track of it somewhere to reinstall it if the 
> primary route went away… at which point you may as well have not dropped it 
> in the first place.
>  
> -Adam
>  
> Adam Thompson
> Consultant, Infrastructure Services
> 
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>  
> From: NANOG  On Behalf Of Tom 
> Beecher
> Sent: Friday, March 25, 2022 4:13 PM
> To: Paschal Masha 
> Cc: nanog 
> Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
>  
> The best practice with regards to as_path length is to have an edge filter 
> that dumps any prefix with a length longer than say 10. Depending on the 
> situation, might even be able to go smaller. 
>  
> At a certain point, keeping that route around does nothing for you, just 
> shoot it and ride the 0/0 train. 
>  
> On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha  
> wrote:
> :) probably the longest prepend in the world.
> 
> A thought though, is it breaking any standard or best practice procedures?
> 
> Regards 
> Paschal Masha | Engineering 
> Skype ID: paschal.masha
> 
> - Original Message -
> From: "Erik Sundberg" 
> To: "nanog" 
> Sent: Friday, March 25, 2022 6:43:38 AM
> Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
> 
> If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends 
> for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends 
> let's say 20. Thanks! 
> 
> This is a Kazakhstan register IP Block and ASN 
> 
> 
> 
> Network Next Hop Metric LocPrf Weight Path 
> 
> *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21 299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 i 
> 
> 
> 
> 
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
> previous e-mail messages attached to it may contain confidential information 
> that is legally privileged. If you are not the intended recipient, or a 
> person responsible for delivering it to the intended recipient, you are 
> hereby notified that any disclosure, copying, distribution or use of any of 
> the information contained in or attached to this transmission is STRICTLY 
> PROHIBITED. If you have received this transmission in error please

RE: MAP-T (was: Re: V6 still not supported)

2022-03-25 Thread Vasilenko Eduard via NANOG

The best MAP discussion (really rich in details) is from Richard Patterson.
Sky has implemented green field FBB in Italy.
He did many presentations in different places. This one should be looked from 
00:37 to 1:09 
https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-ipv6-only-networks

The absence of logs is a really big advantage.
But where to get big enough IPv4 address space for MAP?

XLAT464 would win anyway because it is the only IPv4aaS translation available 
on a smartphone.

Eduard
-Original Message-
From: Rajiv Asati (rajiva) [mailto:raj...@cisco.com] 
Sent: Saturday, March 26, 2022 12:44 AM
To: Vasilenko Eduard ; Jared Brown 
; nanog@nanog.org
Subject: Re: MAP-T (was: Re: V6 still not supported)

FWIW, MAP has been deployed by few operators (in at least 3 continents that I 
am aware of).

Charter communications is one of the public references (see NANOG preso 
https://www.youtube.com/watch?v=ZmfYHCpfr_w).

MAP (CPE function) has been supported in OpenWRT software (as well as many CPE 
vendor implementations) for few years now; MAP (BR function) has been supported 
by few vendors including Cisco (in IOS-XE and XR).

Cheers,
Rajiv 

https://openwrt.org/packages/pkgdata_owrt18_6/map-t
https://openwrt.org/docs/guide-user/network/map

 

-Original Message-
From: NANOG  on behalf of Vasilenko 
Eduard via NANOG 
Reply-To: Vasilenko Eduard 
Date: Friday, March 25, 2022 at 11:17 AM
To: Jared Brown , "nanog@nanog.org" 
Subject: RE: MAP-T (was: Re: V6 still not supported)

Hi Jared,
Theoretically, MAP is better. But 

1. Nobody has implemented it for the router.
The code for the CGNAT engine gives the same cost/performance.
No promised advantage from potentially stateless protocol.

2.MAP needs much bigger address space (not everybody has) because:
a) powered-off subscribers consume their blocks anyway
b) it is not possible to add "on the fly" additional 64 ports to the 
particular subscriber that abuse some Apple application (and go to 1k ports 
consumption) that may drive far above any reasonable limit of ports per subs.
Design should block a big enough number of UDP/TCP ports for every subs 
(even most silent/conservative).

Ed/
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Jared Brown
Sent: Friday, March 25, 2022 4:49 PM
To: nanog@nanog.org
Subject: MAP-T (was: Re: V6 still not supported)

Most IPv6 transition mechanisms involve some form of (CG)NAT. After 
watching a NANOG presentation on MAP-T, I have a question regarding this.

Why isn't MAP-T more prevalent, given that it is (almost) stateless on the 
provider side?

Is it CPE support, the headache of moving state to the CPE, vendor support, 
or something else?


NANOG 2017
Mapping of Address and Port using Translation MAP T: Deployment at Charter 
Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w


- Jared

RE: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

2022-03-25 Thread Adam Thompson

Tom, how exactly does someone “ride the 0/0” train in the DFZ?

I’m connected to both commercial internet and NREN, and unfortunately-long 
paths are not uncommon in this scenario, in order to do traffic steering.  If 
there’s another solution that affects global inbound traffic distributions, I’d 
love to hear about it (and so would a lot of my peers in edu).

If there were a usable way to “dump” the excessively-long path only as long as 
a better path was already known by at least one edge router, that might be 
workable, but you’d have to keep track of it somewhere to reinstall it if the 
primary route went away… at which point you may as well have not dropped it in 
the first place.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

From: NANOG  On Behalf Of Tom 
Beecher
Sent: Friday, March 25, 2022 4:13 PM
To: Paschal Masha 
Cc: nanog 
Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

The best practice with regards to as_path length is to have an edge filter that 
dumps any prefix with a length longer than say 10. Depending on the situation, 
might even be able to go smaller.

At a certain point, keeping that route around does nothing for you, just shoot 
it and ride the 0/0 train.

On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha 
mailto:paschal.ma...@ke.wananchi.com>> wrote:
:) probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?

Regards
Paschal Masha | Engineering
Skype ID: paschal.masha

- Original Message -
From: "Erik Sundberg" mailto:esundb...@nitelusa.com>>
To: "nanog" mailto:nanog@nanog.org>>
Sent: Friday, March 25, 2022 6:43:38 AM
Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN 
prepending 255 times

If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 
46.42.196.0/24 from 255 prepends to a more reasonable 
number of prepends let's say 20. Thanks!

This is a Kazakhstan register IP Block and ASN



Network Next Hop Metric LocPrf Weight Path

*> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 
35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21 299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 i








CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner.
Thank you.

Re: ISP data collection from home routers

" Most end users (at least in the US) don't have a choice as many jurisdictions 
have sold a franchise (monopoly) to one provider. Either they sign or they 
don't get internet." 


That's not true. 





- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "PJ Capelli via NANOG"  
To: "Christian David"  
Cc: nanog@nanog.org 
Sent: Friday, March 25, 2022 10:04:56 AM 
Subject: Re: ISP data collection from home routers 

Most end users (at least in the US) don't have a choice as many jurisdictions 
have sold a franchise (monopoly) to one provider. Either they sign or they 
don't get internet. 

Perhaps 5G will broaden the number of providers end users can choose from, and 
not be forced into this kind of contract. But why do you think any ISP would 
agree to not collect this information? 

pj capelli 
pjcape...@pm.me 

No one can build you the bridge on which you, and only you, must cross the 
river of life - Nietzsche 

Sent with ProtonMail secure email. 

--- Original Message --- 

On Thursday, March 24th, 2022 at 1:11 PM, Christian David 
 wrote: 

> I think that if the end user at signed contract agreed with this data 
> 

> collecting and also if there's a mechanism that the same user could deny 
> 

> the data collection, its look fine to me, there's compliant here in 
> 

> Brazil with LGPD (our variant from GDPR) and i think that users could 
> 

> see it as a "plus" cause the majority of ISPs don't have a service that 
> 

> inspect CPE WIFI's quality. 
> 

> Em 24/03/2022 14:00, Jay Hennigan escreveu: 
> 

> > On 3/24/22 06:26, Josh Luthman wrote: 
> > 

> > > I'm surprised we're having this discussion about an internet device 
> > > 

> > > that the customer is using to publicize all of their information on 
> > > 

> > > Facebook and Twitter. 
> > 

> > That's called informed consent. And Facebook and Twitter use TLS to 
> > 

> > protect the data in transit. 
> > 

> > > Consumers do not care enough about their privacy to the point where 
> > > 

> > > they are providing the information willingly. 
> > 

> > That's the point. The customer is providing information willingly when 
> > 

> > they post to social media. The ISP is collecting data without consent.

Re: ISP data collection from home routers

2022-03-25 Thread Tom Beecher

>
> Even if you own your modem, the DOCSIS specs require that it be
> completely controlled by the MSO, right?
>

Pretty sure that's correct, yes.


On Fri, Mar 25, 2022 at 4:47 PM Michael Thomas  wrote:

>
> On 3/24/22 12:53 PM, Tom Beecher wrote:
> > You don't even have to use their equipment. My provider at home is
> > Charter / Spectrum. I own my own cable modem  / router ,they have no
> > equipment in my home. Their privacy policy is pretty standard.
> > Essentially :
> > - Anything they can see that I transmit they will collect.
> > - Anything they can see when I use their apps , even if I'm not on
> > their network, they will collect.
> > - They will use that information for their technical and business
> > reasons, whatever they want.
> > - I am very limited in what I can request that they don't collect or use.
> >
> > None of this is new in the US. I think more people care about
> > this than we think, but people don't really have an option to vote
> > with their wallets.
>
> Even if you own your modem, the DOCSIS specs require that it be
> completely controlled by the MSO, right?
>
> Mike
>
>
>

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

2022-03-25 Thread Tom Beecher

The best practice with regards to as_path length is to have an edge filter
that dumps any prefix with a length longer than say 10. Depending on the
situation, might even be able to go smaller.

At a certain point, keeping that route around does nothing for you, just
shoot it and ride the 0/0 train.

On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha 
wrote:

> :) probably the longest prepend in the world.
>
> A thought though, is it breaking any standard or best practice procedures?
>
> Regards
> Paschal Masha | Engineering
> Skype ID: paschal.masha
>
> - Original Message -
> From: "Erik Sundberg" 
> To: "nanog" 
> Sent: Friday, March 25, 2022 6:43:38 AM
> Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
>
> If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends
> for 46.42.196.0/24 from 255 prepends to a more reasonable number of
> prepends let's say 20. Thanks!
>
> This is a Kazakhstan register IP Block and ASN
>
>
>
> Network Next Hop Metric LocPrf Weight Path
>
> *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 i
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files
> or previous e-mail messages attached to it may contain confidential
> information that is legally privileged. If you are not the intended
> recipient, or a person responsible for delivering it to the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution or use of any of the information contained in or attached to
> this transmission is STRICTLY PROHIBITED. If you have received this
> transmission in error please notify the sender immediately by replying to
> this e-mail. You must destroy the original transmission and its attachments
> without reading or saving in any manner.
> Thank you.
>
>
>
>

Re: MAP-T (was: Re: V6 still not supported)

2022-03-25 Thread JORDI PALET MARTINEZ via NANOG

The cost of deploying MAP in CPEs is a bit higher than 464XLAT, which is not an 
issue anyway. There are several open source implementations for both of them.

It is true that MAP avoids state in the network, however, it means higher 
"cost" for users in terms of restrictions of ports. It also means more IPv4 
addresses even if the ports are not used. In some countries, like India, MAP 
was not alllowed by the regulator, because the lack of proper logging, so it 
was push-back by the bigger provider (probably the bigger in the world - Jio) 
of IPv6.

At the end, if you turn on IPv6 to residential customers, typically you will 
get 70-80% IPv6 traffic, so the state in the NAT64 using 464XLAT is lower and 
lower every day.

With 464XLAT there is no restriction on the number of ports per subscriber, the 
usage of IPv4 addresses is more efficient, and of course, you can use the same 
protocol in cellular networks, with also make simpler the support of backup 
links in CPEs (for example GPON in the primary link and 4G in the backup one).

Last but not least, 464XLAT also allows enterprise networks to swich to 
IPv6-only (with IPv4aaS) providing a smooth transition to a final IPv6-only 
stage.

The fact that in terms of users 464XLAT exceeds all the other transition 
tehcnologies all together, should mean something.

There is a bunch of information at 
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/, which 
is just waiting for the final OK from the IESG to jumpt to the final stage (RFC 
Editor).

Regads,
Jordi
 
 
Saludos,
Jordi
@jordipalet
 

-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Jared Brown
Sent: Friday, March 25, 2022 4:49 PM
To: nanog@nanog.org
Subject: MAP-T (was: Re: V6 still not supported)

Most IPv6 transition mechanisms involve some form of (CG)NAT. After 
watching a NANOG presentation on MAP-T, I have a question regarding this.

Why isn't MAP-T more prevalent, given that it is (almost) stateless on the 
provider side?

Is it CPE support, the headache of moving state to the CPE, vendor support, 
or something else?


NANOG 2017
Mapping of Address and Port using Translation MAP T: Deployment at Charter 
Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w


- Jared



**
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: ISP data collection from home routers

" They can easily profile you and know when you're at home, and when you're 
gone." 


And? 



- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Giovane C. M. Moura via NANOG"  
To: "Josh Luthman" , "Lady Benjamin Cannon of 
Glencoe, ASCE"  
Cc: "North American Network Operators' Group"  
Sent: Thursday, March 24, 2022 9:04:06 AM 
Subject: Re: ISP data collection from home routers 


> Who cares about the SSID??? 

I don't remember the data model, but I remember that they retrieved data 
very often, multiple times a minute. 

(some ppl in the list may have access to this data and know it very well) 

They can easily profile you and know when you're at home, and when 
you're gone. Some people may find this interesting... 

To have a really meaningful discuss on the privacy implications, we 
would need to see the data model, and the frequency that they pool the data. 

/giovane

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

2022-03-25 Thread Baldur Norddahl

On Fri, 25 Mar 2022 at 17:32, Joe Provo  wrote:

> That said, prepending pretty much anything more than your current view
> of the Internet's diameter in ASNs is useless in practice.
>

That is one way of viewing it. But prepending can also be used for traffic
engineering. I could prepend 1 to my free peers, 2 to my paid peers, 3 to
cheap ip transit, 4 to expensive ip transit etc. The linked draft RFC does
not appear to discuss this at all. The depth of prepending used this way
only relates to how many different classes of peers you can imagine in your
setup and is not at all related to the "internet's diameter".

To someone on the other side of the planet, who are neither peers nor
customers of peers, they will just observe that I am prepending 3 or 4
times and wondering why the extra prepends? The answer is that closer to my
home there are people who are observing the same routes with 1 or 2
prepends and that it matters.

The draft RFC lists some alternatives to prepends of which none can do
anything of the sort I just described.

Regards,

Baldur

Re: ISP data collection from home routers

Sounds good to me. Solve the end-user problems, since they don't have the 
ability or care to do it themselves and doing so manually has too much latency 
and doesn't scale. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Giovane C. M. Moura via NANOG"  
To: "North American Network Operators' Group"  
Sent: Thursday, March 24, 2022 5:43:58 AM 
Subject: ISP data collection from home routers 

Hello there, 

Several years ago, a friend of mine was working for a large telco and 
his job was to detect which clients had the worst networking experience. 

To do that, the telco had this hadoop cluster, where it collected _tons_ 
of data from home users routers, and his job was to use ML to tell the 
signal from the noise. 

I remember seeing a sample csv from this data, which contained 
_thousands_ of data fields (features) from each client. 

I was _shocked_ by the amount of (meta)data they are able to pull from 
home routers. These even included your wifi network name _and_ password! 
(it's been several years since then). 

And home users are _completely_ unaware of this. 

So my question to you folks is: 

- What's the policy regulations on this? I don't remember the features 
(thousands) but I'm pretty sure you could some profiling with it. 

- Is anyone aware of any public discussion on this? I have never seen it. 

Thanks, 

Giovane Moura

Re: V6 still not supported

2022-03-25 Thread Doug McIntyre

On Fri, Mar 25, 2022 at 02:30:26PM +0100, Jared Brown wrote:
> Owen DeLong via NANOG wrote:
> > When your ISP starts charging $X/Month for legacy protocol support
> 
> Out of interest, how would this come about?

It already happens, more along the lines of "Business Class" vs. "Residential 
Class".

Ie. for Residential Class, you may get put onto CGNAT, and have no control over 
that.

While on x level of Business Class, you get to opt out of CGNAT, and 
potentially even have a
static IP address assigned to your connection.

Re: ISP data collection from home routers

2022-03-25 Thread Michael Thomas




On 3/24/22 12:53 PM, Tom Beecher wrote:
You don't even have to use their equipment. My provider at home is 
Charter / Spectrum. I own my own cable modem  / router ,they have no 
equipment in my home. Their privacy policy is pretty standard.

Essentially :
- Anything they can see that I transmit they will collect.
- Anything they can see when I use their apps , even if I'm not on 
their network, they will collect.
- They will use that information for their technical and business 
reasons, whatever they want.

- I am very limited in what I can request that they don't collect or use.

None of this is new in the US. I think more people care about 
this than we think, but people don't really have an option to vote 
with their wallets.


Even if you own your modem, the DOCSIS specs require that it be 
completely controlled by the MSO, right?


Mike

Re: V6 still not supported

2022-03-25 Thread Pascal Thubert (pthubert) via NANOG

Hello Phil

The only far ressemblance with 6to4 is the thing that was actually nice in the 
design, the automatic word in automatic tunnel. Which for the rest of us means 
stateless. Compared to CGNATs that is huge.

Beyond that the proposal is not a tunnel and more akin to a nat64 since it 
allows v6 nodes to talk to v4 nodes. The network can be pure v4 or pure v6 if 
the method is implemented as a bump in the stack at the wrong end.

Your response is also missing the capability to extend the IPv4 network a 
million times. Or drop it completely while maintaining IPv4 applications.

6to4 was meant for early v6 to interconnect islands. A solution for a problem 
that never really existed. Solutions without a problem aren’t usually popular.

Apparently here there’s a real world problem to be solved. Sophisms are of no 
help.


Regards,

Pascal

> Le 25 mars 2022 à 19:40, Philip Homburg  a écrit :
> 
> 
>> 
>> A host in the Internet that wants to talk to a host in China would require 
>> an 
>> update to parse new DNS double-A (realm, address) records to encapsulate the 
>> p
>> acket IP-in-IP, outer src= 240.0.0.1 outer dest=240.0.0.2. The router that 
>> ser
>> ves the shaft at level 1 attracts 240.0.0.0/8 within realm 1 and routes up 
>> the
>> elevator for more specific (host) routes within that prefix. The router that 
>> serves the shaft at level 2 attracts 240.0.0.2/32 inside the shaft; upon the 
>> s
>> aid packet it would swap the inner and outer destination and the packet 
>> would 
>> reach the Chinese address with classical routing within realm 2. 
>> 
>> Routers serving the shaft need an update, but then, only those do. Obviously 
>> t
>> he host in China can only reply if its stack is updated to understand the 
>> form
>> at. But all the other hosts and routers in China can be classical IPv4 as we 
>> k
>> now them long as their traffic stays in China. To migrate to IPv6 what you 
>> can
>> do is map the elevator shaft prefix in, say, 400::/3 (sadly cannot use F00/3 
>> that would map 240 neatly but is already assigned). 
>> 
>> The current internet would own 400:1::/32, China would own 400:2::/32, 
>> etc... 
>> You encode the double-A of the host in the prefix, reserve a well known 
>> suffix
>> for IPv4 mapped double-A, and you have an IPv6 address that can be mapped bot
>> h ways statelessly. When migrating to v6, each IPv4 node that owns a public 
>> IP
>> v4 address in one realm gets a full IPv6 /64 for free.
>> "
> 
> Somehow this sounds a lot like 6to4: packets get routed to special devices
> in the network and ISPs have little control over this. Not a popular
> architecture.
> 
> Or another way to look at it is the resemblance with the ill fated 
> 'Provider-Based Global Unicast Addresses' (RFC 1884, Section 2.4.7). This
> was not very popular either.
>

Re: WP: Russian military behind hack of satellite communication devices

2022-03-25 Thread Sean Donelan


On Fri, 25 Mar 2022, Eric Kuhnke wrote:

I'd be willing to bet that this was either a malicious firmware push that
was applied to the CPEs without proper authentication methods being in
place, such as CPEs being able to verify a crypto key signed firmware
signature, or a configuration file pushed to the CPEs that knocked them off
the network with incorrect RF/channel/modulation/timing parameters.


https://www.airforcemag.com/hackers-attacked-satellite-terminals-through-management-network-viasat-officials-say/

“The terminal management network … that manages the KA-SAT network, and 
manages other Eutelsat networks—that network was penetrated,” said one 
Viasat official. “And from there, the hackers were able to launch an 
attack against the terminals using the normal function of the management 
plane of the network.”


[...]

The attack compromised the management plane—the part of the network that 
controls customer terminals to ensure they can communicate with the 
satellite, the Viasat officials said. The hackers had abused that 
functionality to change the software configuration on the terminals and 
render them inoperable.


But, contrary to some early reports, the attack did not brick the 
terminals. “It did not make them permanently inoperable,” said the second 
official. “Every single terminal that was knocked off the air can be 
brought back with a software update.” Although the network is generally 
capable of updating terminals over the air, by downloading new software 
via the satellite link, many of the terminals attacked cannot be brought 
back online by the customer, and so can’t get the required update over the 
air. Those will have to be updated by tech support staff, the first 
official said.


[...]
Despite this, Viasat was now bringing “thousands of terminals back online 
per day, and will have the network completely restocked and back to full 
capacity within a few weeks,” the first official said.


[...]
Editor’s Note: This story was updated at 3:15 p.m. on March 25 to correct 
some technical issues with how the KA-SAT network and other assets were 
described

Re: A straightforward transition plan (was: Re: V6 still not supported)

2022-03-25 Thread John Curran

On 25 Mar 2022, at 2:27 PM, Philip Homburg  wrote:
> 
>> If by ?straightforward transition plan? one means a clear and rational set 
>> of 
>> options that allows networks to plan their own migration from IPv4-only to 
>> IPv
>> 6, while maintaining connectivity to IPv4-only hosts and with a level of 
>> effor
>> t reasonable comparable to just running IPv4, then I would disagree, as such 
>> a
>> n "IPng transition plan? was achievable, expected, and we collectively 
>> failed 
>> to deliver on it (as noted below) 
> 
> I'm a bit confused about the achievable part.
> 
> Obviously, the adoption of IPv6 without a clear transition plan was a process
> failure. However, it is not clear to me that waiting a few years would 
> have brought something much better. And waiting more than a decade would
> mean that today there would not be a mature IPv6.
> ...
> The big issue is 3). If we look at the current internet, there are parties
> who lack IPv4 addresses and want to switch to IPv6. Obviously, they
> want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
> On the other hand, there are parties who have enough IPv4 addresses and
> have no reason to switch to IPv6.
> 
> So we are clearly in the situation of 'migration from IPv4-only to IPv6,
> while maintaining connectivity to IPv4-only hosts'

Correct (although I will also point out that having zero IPv4 addresses isn’t 
really the problem but rather “not enough IPv4 space for their networking 
needs” – in the ARIN region, for example, organizations can obtain a small 
amount of IPv4 address space specifically for purposes of IPv6 transition 
technology use - it’s quite necessary for nearly any IPv6/IPv6 interoperability 
solution since they need to have an IPv4-facing interfaces)

> It should be clear that an IPv4-only host only speaks IPv4. This means that
> communication with an IPv4-only host has to be IPv4. So either the
> IPv6-only host or something in the network has to speak IPv4. If the
> IPv6 host speaks IPv4 then we get dual stack, which has been rejected
> as a broken solution. Technically, it is also possible to tunnel IPv4
> packets, then the host is in some sense dual stack, but most of the network
> is not. However, automatic tunnel configuration is hard, and tunnels
> tend to be fragile.
> 
> So the only option is a device in the network that translates between
> IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
> a technical point of view it is a disaster.

We actually have an abundance of technical solutions that provide some degree 
of IPv6/IPv4 interoperability, all with various tradeoffs, and which address 
various deployment scenarios such as whether the network service has 
involvement in the individual CPE, DNS resolution, ability to alter/profile 
applications, etc…  it’s a rather complex mess, and there’s far more solutions 
in use that just NAT64.  

> Looking back, we can say that the only feature of IPv6 that makes people
> invest in IPv6 is the bigger address space. So it is safe to say that
> most of the internet would have waited to invest in IPv6 until we were
> (almost) out of IPv4 addresses. So by its very nature this transation 
> between IPv6 and IPv4 would have NAT component.

 Full agreement there…  one would have expected a strong focused 
effort in making a small number of standard NAT-based interoperability 
protocols for IPng, including working through the transition scenario 
implications. 

> In my opinion, It is clear that during the time IPv6 was developed, any
> solution involving NAT would have been rejected.

Pretty much correct…  As you may be aware, there was a large focus on 
tunnel-bases solutions (so that various islands of IPv6 exploration could be 
interconnected) but actual NAT-based interoperability wasn’t in the cards.

> So I'm confused, what transition technology was achievable (also in the
> political sense) but not delivered?

Well, I think you’ve hit the nail on the head - we certainly could have 
delivered on the actual IPng technical requirements for a straightforward 
transition plan (and ended up with a short finite number of well-tested 
protocols with far more attention paid to them starting 10 years earlier in the 
process) rather than present cornucopia of last-minute solutions of various 
technical strength – alas, taking that path of actually working on NAT-based 
interoperability solutions did not align with the culture/politics of the IETF. 

> If there is a magical transition technology that allows an IPv6-only host to
> talk to an IPv4-only host, then let's deploy it.

DNS64/NAT64, DS-Lite, 6rd, 464XLAT, MAP-T, MAP-E, … pick a transition protocol 
and see what happens!
(with more coming every year...)

FYI,
/John

Re: WP: Russian military behind hack of satellite communication devices

2022-03-25 Thread Eric Kuhnke

Point to multipoint / TDMA contended access VSAT hub and CPE networks are
well known for not having much security. In many setups the remote CPE
modems, which are built from a fairly cheap BOM of hardware, implicitly
trust the hub linecard. Have seen this with 3 different vendors' platforms.

I'd be willing to bet that this was either a malicious firmware push that
was applied to the CPEs without proper authentication methods being in
place, such as CPEs being able to verify a crypto key signed firmware
signature, or a configuration file pushed to the CPEs that knocked them off
the network with incorrect RF/channel/modulation/timing parameters.

Note that the Viasat KA-SAT terminals are at the very lower end of the
market for contended access (64:1 or more) consumer/small business grade
geostationary VSAT. Which is why it sort of makes sense that a lot of them
were used for low data rate SCADA for wind farms and such.

On Thu, 24 Mar 2022 at 20:48, Sean Donelan  wrote:

>
> Not yet official, but the U.S. intelligence community seems to continue
> its rapid release of intelligence.  I think everyone was expecting it,
> especially since Viasat executives declined to say it earlier this week at
> the SATCOM 2022 conference.
>
>
>
>
> https://www.washingtonpost.com/national-security/2022/03/24/russian-military-behind-hack-satellite-communication-devices-ukraine-wars-outset-us-officials-say/
> By Ellen Nakashima
> Today at 10:25 p.m. EDT
>
> U.S. intelligence analysts have concluded that Russian military spy
> hackers were behind a cyberattack on a satellite broadband service that
> disrupted Ukraine’s military communications at the start of the war last
> month, according to U.S. officials familiar with the matter.
>
> The U.S. government, however, has not announced its conclusion publicly.
>
> [...]
>
> The modems were part of Viasat’s European satellite network, KA-SAT. The
> company uses distributors in Europe to sell Internet service, which relies
> on modems, to customers. The company is shipping new modems to the
> distributors so they can get them to affected customers, the official
> said.
>

Weekly Global IPv4 Routing Table Report

2022-03-25 Thread Routing Table Analysis Role Account

This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 26 Mar, 2022

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  894229
Prefixes after maximum aggregation (per Origin AS):  336759
Deaggregation factor:  2.66
Unique aggregates announced (without unneeded subnets):  428489
Total ASes present in the Internet Routing Table: 72908
Prefixes per ASN: 12.27
Origin-only ASes present in the Internet Routing Table:   62546
Origin ASes announcing only one prefix:   25701
Transit ASes present in the Internet Routing Table:   10362
Transit-only ASes present in the Internet Routing Table:381
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  65
Max AS path prepend of ASN (267602)  58
Prefixes from unregistered ASNs in the Routing Table:   868
Number of instances of unregistered ASNs:   874
Number of 32-bit ASNs allocated by the RIRs:  38896
Number of 32-bit ASNs visible in the Routing Table:   32344
Prefixes from 32-bit ASNs in the Routing Table:  151610
Number of bogon 32-bit ASNs visible in the Routing Table:31
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:479
Number of addresses announced to Internet:   3068372992
Equivalent to 182 /8s, 227 /16s and 168 /24s
Percentage of available address space announced:   82.9
Percentage of allocated address space announced:   82.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  303143

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   234292
Total APNIC prefixes after maximum aggregation:   66359
APNIC Deaggregation factor:3.53
Prefixes being announced from the APNIC address blocks:  229205
Unique aggregates announced from the APNIC address blocks:94106
APNIC Region origin ASes present in the Internet Routing Table:   12501
APNIC Prefixes per ASN:   18.33
APNIC Region origin ASes announcing only one prefix:   3558
APNIC Region transit ASes present in the Internet Routing Table:   1723
Average APNIC Region AS path length visible:4.7
Max APNIC Region AS path length visible: 27
Number of APNIC region 32-bit ASNs visible in the Routing Table:   7696
Number of APNIC addresses announced to Internet:  774201472
Equivalent to 46 /8s, 37 /16s and 96 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:261013
Total ARIN prefixes after maximum aggregation:   119721
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   260865
Unique aggregates announced from the ARIN address blocks:124035
ARIN Region origin ASes present in the Internet Routing Table:18992
ARIN Prefixes per ASN:

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-25 Thread Christopher Morrow

1) please join the list properly and stop replying to the digests.
(note there have been many folks asking you to do this, disconnected
message/new-threads
are super super super annoying and remove the parts of the discussion from
a coherent thread)

On Fri, Mar 25, 2022 at 12:25 PM Abraham Y. Chen  wrote:

> 1)" ... 240/4 is way more effort than its proponents want to believe
> and even if it were reclassified effectively as GUA, it doesn’t buy all
> that much life for IPv4. ...   ": Perhaps you have not bothered to scan
> through a two page whitepaper (URL below, again) that I submitted a week or
> so ago? It promises simple implementation and significant increase of
> assignable IPv4 addresses, even extendable to the similar size of IPv6 if
> we could forgo our mentality about the IP addresses as "Personal
> Properties", by switching to treat them as "Natural Resources".
>
>   https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>

This paper is super thin on any reasonable level of detail, and seems to
wholly miss the mark on ipv4 usage patterns.

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

2022-03-25 Thread Joe Provo

On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:
> :) probably the longest prepend in the world.
> 
> A thought though, is it breaking any standard or best practice procedures?

Many popular BGP implementations have historically had weaknesses 
with excessively long AS-paths. Best practice is to protect ones'
infrastructure so many networks drop paths over certain lengths
(at various times, 50 or 100 were common due to specific issues).
It is highly common for any filtering mechanism, once established,
to stay in place, so I fully expect this path to be invible to many
and fragile for the rest [see
https://blog.apnic.net/2019/07/15/excessive-bgp-as-path-prepending-is-a-self-inflicted-vulnerability/].

That said, prepending pretty much anything more than your current view
of the Internet's diameter in ASNs is useless in practice. Cascading
effects are considered in 
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
where a decent low number (5) is propsed.

Chers,

Joe

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling

Let's Focus on Moving Forward Re: V6 still not supported


Dear Owen:

0)    You rapid fired a few posts in succession yesterday. Some are 
interesting and crucial views that I would like to follow-up on. I will 
start from quoting the earlier ones. I hope that I am picking up the 
correct leads.


1)    " ... 240/4 is way more effort than its proponents want to believe 
and even if it were reclassified effectively as GUA, it doesn’t buy all 
that much life for IPv4. ...   ":     Perhaps you have not bothered to 
scan through a two page whitepaper (URL below, again) that I submitted a 
week or so ago? It promises simple implementation and significant 
increase of assignable IPv4 addresses, even extendable to the similar 
size of IPv6 if we could forgo our mentality about the IP addresses as 
"Personal Properties", by switching to treat them as "Natural Resources".


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)    " ...  so that content providers can start turning off v4 where 
it’s costing them money to support it.    " & "... Content providers 
turning off v4 face competition from content providers that don’t. ...  
":    These two statements appeared to come from two separate posting of 
yours. They seemed to be contradicting each other. Did I misread somehow?


Now from the last post below:

3)    "  ... 240/4 is way more effort than its proponents want to 
believe and even if it were reclassified effectively as GUA, it doesn’t 
buy all that much life for IPv4   ": Please see information provided 
by Pt. 1) above.


4)    " ... I think it should be reclassified from never going to be 
used into some part of the internet might actually do something with it. 
Its important that happens now, better late then never ... Please feel 
free to use it for router IDs in BGP and/or OSPF area numbers. :p ...    
":    I am in full agreement with you. Our proposal is the solution in 
Pt. 1) above.


5)    "  ...  if we continue to waste effort that is better spent 
deploying IPv6 on bandaids and hacks to make v4 last just a little 
longer,  ":    This is not a productive opinion. Please do not 
forget that the Internet heavily promotes personal freedom. One can not 
force others to do something that they do not believe in. Stopping them 
from doing one thing does not automatically make them to do what you 
like. A project must have its own merits that attract contribution. The 
failure of the IPv6 actually started from when a decision was made to 
the effect of "not to emphasize backward compatibility with IPv4" which 
broke one of the golden rules in system engineering. Not recognizing 
such and focusing to find a way for remedying it, but continuing to 
force others to migrate to IPv6 camp with various tactics does not 
foster progress.


6)    "  ... The problem is that we’re not talking about parallel 
experiments. ... ": EzIP is a parallel experiment to the current 
Internet (not only IPv4, but also IPv6) operations, because its overlay 
architecture on the latter demarcates everything happening on it from 
the Internet. As long as packets exchanged between the two conform to 
the established Internet protocols, an EzIP deployment (called RAN - 
Regional Area Network) will appear as innocent as an ordinary private 
network.


Regards,


Abe (2022-03-25 12:24)



On 2022-03-24 21:25, Owen DeLong via NANOG wrote:

On Mar 24, 2022, at 15:49, Joe Maimon  wrote:



Owen DeLong wrote:

On Mar 24, 2022, at 03:36 , Joe Maimon  wrote:



In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible.

I think this isn’t so much preempting the vacuum as trying to pretend we can 
survive on an hour of air for 20 years.

240/4 is way more effort than its proponents want to believe and even if it 
were reclassified effectively as GUA, it doesn’t buy all that much life for 
IPv4.

I think it should be reclassified from never going to be used into some part of 
the internet might actually do something with it. Its important that happens 
now, better late then never. Whether its GUA or not or a mix of whatever, 
whether it buys months or years will depend greatly on how its actually used if 
it is ever used.

Please feel free to use it for router IDs in BGP and/or OSPF area numbers. :p


You may be right about not being worth it. More importantly, you may be wrong. 
IPv6 is replete with not only a plethora of wrong predictions, but the same 
ones over and over again. To be clear, the only effort asked from the unwilling 
is to support cutting the red tape frustrating the willing. A hearty round of 
knock yourself out from the right folk in the right place and time and we dont 
have to debate this particular point ever again.

Certainly, if we continue to waste effort that is better spent deploying IPv6 
on bandaids and hacks to make v4 last just a little longer, we will continue to 
fail and further delay IPv6 reaching a level of deployment that allows us to 
start turning down

Re: IPv6 "bloat" history


On 3/23/22 2:25 AM, Masataka Ohta wrote:

William Allen Simpson wrote:



Neighbor Discovery is/was agnostic to NBMA.  Putting all the old
ARP and DHCP and other cruft into the IP-layer was my goal, so
that it would be forever link agnostic.


To make "IP uber alles", link-dependent adaptation mechanisms
between IP and links are necessary. So, "ND uber alles" is a
wrong goal.



Meant to reply to this separately.

I've implemented on the order of 35+ protocols, most of them
predating IP.

My first IP implementation was 1979 for the Perkin-Elmer 7/16.
The link layer was X.25 to talk to Merit and over Telenet
(not telnet -- Telenet was a provider in those days).

John Gilmore recently gave a good history of the ARP origin.

Note that for PPP, we also had to negotiate a link layer shim.

Some folks then grabbed that effort, instead of building their
own, resulting in such monstrosities as PPP over Ethernet.

After so many times reinventing the wheel, IP uber alles is a
better goal.  Speaking as somebody familiar with the effort.

Re: ISP data collection from home routers

2022-03-25 Thread PJ Capelli via NANOG

Not sure why they are different; most ISPs are not a pure play and can use that 
data for other aspects of their business that you may not have agreed to (e.g. 
Verizon FiOS feeding to Verizon Wireless).  Comcast/NBC, etc.

pj capelli
pjcape...@pm.me

No one can build you the bridge on which you, and only you, must cross the 
river of life - Nietzsche

Sent with ProtonMail secure email.

--- Original Message ---

On Thursday, March 24th, 2022 at 10:24 AM, Kord Martin 
 wrote:

> On 2022-03-24 10:04 a.m., Giovane C. M. Moura via NANOG wrote:
> 

> > They can easily profile you and know when you're at home, and when
> > 

> > you're gone. Some people may find this interesting...
> > 

> > To have a really meaningful discuss on the privacy implications, we
> > 

> > would need to see the data model, and the frequency that they pool the
> > 

> > data.
> 

> Is your concern that ISPs have access to this information, or that it's
> 

> something they could possibly be selling to a third party? Those are two
> 

> completely different discussions.
> 

> K

signature.asc
Description: OpenPGP digital signature

Re: ISP data collection from home routers

2022-03-25 Thread PJ Capelli via NANOG

Most end users (at least in the US) don't have a choice as many jurisdictions 
have sold a franchise (monopoly) to one provider.  Either they sign or they 
don't get internet.

Perhaps 5G will broaden the number of providers end users can choose from, and 
not be forced into this kind of contract.  But why do you think any ISP would 
agree to not collect this information?

pj capelli
pjcape...@pm.me

No one can build you the bridge on which you, and only you, must cross the 
river of life - Nietzsche

Sent with ProtonMail secure email.

--- Original Message ---

On Thursday, March 24th, 2022 at 1:11 PM, Christian David 
 wrote:

> I think that if the end user at signed contract agreed with this data
> 

> collecting and also if there's a mechanism that the same user could deny
> 

> the data collection, its look fine to me, there's compliant here in
> 

> Brazil with LGPD (our variant from GDPR) and i think that users could
> 

> see it as a "plus" cause the majority of ISPs don't have a service that
> 

> inspect CPE WIFI's quality.
> 

> Em 24/03/2022 14:00, Jay Hennigan escreveu:
> 

> > On 3/24/22 06:26, Josh Luthman wrote:
> > 

> > > I'm surprised we're having this discussion about an internet device
> > > 

> > > that the customer is using to publicize all of their information on
> > > 

> > > Facebook and Twitter.
> > 

> > That's called informed consent. And Facebook and Twitter use TLS to
> > 

> > protect the data in transit.
> > 

> > > Consumers do not care enough about their privacy to the point where
> > > 

> > > they are providing the information willingly.
> > 

> > That's the point. The customer is providing information willingly when
> > 

> > they post to social media. The ISP is collecting data without consent.

signature.asc
Description: OpenPGP digital signature

IPvB performance header

This was the IPvB (nee original IPv6) *performance* header.

We required that each IP variant have its own link layer
designation. Therefore, the IP version number wasn't
needed. We could simply set two upper bits to a value (0)
that would distinguish it from every extant IP version.

Also, many of us thought that the type of service was
poorly defined and rarely used.

The longer length field was requested by Fibre Channel,
and later used for InfiniBand.

Finally, the Flow Label was supposed to aid in NAT mapping,
without the underlying transport layer. One field to
rule them all.

No chains of headers. High performance.

3.2. Performance Header Format

+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
| V | Maximal Length |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
| Flow Label | Hop Limit |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
| |
+Source +
| |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
| |
+ Destination +
| |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
|Security Parameters Index (SPI)| A
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
|Sequence Number| A
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
| | A E
~Transform Data ~ A E
| | A E
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
... Padding | A E
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
| |
~ Authenticator ~
| |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+

For most fields, see above.

Fields to be authenticated are designated by a trailing A.

Fields to be encrypted are designated by a trailing E.

V2 bits. Always 0.

This corresponds to the unused IP
Versions 0 to 3, and is readily
distinguished from all extant
versions.

Maximal Length 30 bits.

The length of the datagram, including internet
header(s) and payload data. The maximum length
supported by the Destination is negotiated for each
Flow Label.

Flow Label 24 bits.

The Flow Label is relative to the IP Source and
Destination pairing, and assigned by the flow’s
originating node. The Flow Label subsumes the
Service and Next Header information.

The Flow Label MUST NOT be altered by an intervening
router. Routers that do not support Flow Label
functionality, or lack state for this Source and
Flow Label combination, MUST treat the Service as
undifferentiated.

Mechanisms for assignment and reservation of Flow
Labels are beyond the scope of this specification.

RE: MAP-T (was: Re: V6 still not supported)

2022-03-25 Thread Vasilenko Eduard via NANOG

Hi Jared,
Theoretically, MAP is better. But 

1. Nobody has implemented it for the router.
The code for the CGNAT engine gives the same cost/performance.
No promised advantage from potentially stateless protocol.

2.MAP needs much bigger address space (not everybody has) because:
a) powered-off subscribers consume their blocks anyway
b) it is not possible to add "on the fly" additional 64 ports to the particular 
subscriber that abuse some Apple application (and go to 1k ports consumption) 
that may drive far above any reasonable limit of ports per subs.
Design should block a big enough number of UDP/TCP ports for every subs (even 
most silent/conservative).

Ed/
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Jared Brown
Sent: Friday, March 25, 2022 4:49 PM
To: nanog@nanog.org
Subject: MAP-T (was: Re: V6 still not supported)

Most IPv6 transition mechanisms involve some form of (CG)NAT. After watching a 
NANOG presentation on MAP-T, I have a question regarding this.

Why isn't MAP-T more prevalent, given that it is (almost) stateless on the 
provider side?

Is it CPE support, the headache of moving state to the CPE, vendor support, or 
something else?


NANOG 2017
Mapping of Address and Port using Translation MAP T: Deployment at Charter 
Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w


- Jared

Re: V6 still not supported

2022-03-25 Thread Matthew Craig

This huge conversation has been fun to follow.


I like my IPv6 transition plan:

Instead of moving the mountains and breaking my back to migrate (by myself) my 
ENTIRE not-so-small organization to IPv6, I keep things going on IPv4 
relatively burden-less to my organization till I retire.


Then the contractor that comes in after me (certainly a contractor, because the 
pool of clueful people to hire is small and getting smaller) can execute the 
transition and make a killing by causing more problems, and draining budgets to 
fix those problems, which cause more problems, etc... in a nice vicious cycle.  
I could even decide to be said contractor!


My CISO is on my side.  He DEMANDS as critical components of his Security 
Posture: IPv4 NAT, and easier-to-type IPv4 ACL segmentation (clueful people to 
hire is small)!  :)




This plan continues to be self-validating.  I like my plan.




-
Matt








On Mar 24, 2022, at 5:44 AM, Mark Delany 
mailto:k...@november.emu.st>> wrote:


On 24Mar22, Pascal Thubert (pthubert) allegedly wrote:
Hello Mark:

Any such "transition plan" whether "working" or "straightforward" is
logically impossible. Why anyone thinks such a mythical plan might yet be
formulated some 20+ years after deploying any of ipv6, ipv4++ or ipv6-lite is
absurd.

This is dishonest

My point is that if there was a real transition plan it would have been 
invented and
executed by now and we'd all be on ipv6. Yet the reality is that here we are 
some 20 years
later with no plan and no ubiquitous ipv6. How is that observation dishonest?

considering that I just proved on this very thread that such ideas existed

I don't know why you're conflating an idea with a plan - they are about as far 
away from
each other as is possible. Frankly no one cares about ideas, they're a dime a 
dozen.

A plan is an actionable, compelling and logical set of steps towards an end 
result. Do you
have such a thing for moving everyone on the planet to ipv6?

Here's a simple test of whether you have a plan or not. I'm connected via my 
legacy ipv4
ISP router completely oblivous to ipv6. How does your plan incentivise me to 
upgrade my
router to support ipv6?

When you have an answer to that, you might have a glimmer of a plan.


Mark.

Re: ISP data collection from home routers

2022-03-25 Thread Kord Martin


On 2022-03-24 10:04 a.m., Giovane C. M. Moura via NANOG wrote:
They can easily profile you and know when you're at home, and when 
you're gone. Some people may find this interesting...


To have a really meaningful discuss on the privacy implications, we 
would need to see the data model, and the frequency that they pool the 
data.


Is your concern that ISPs have access to this information, or that it's 
something they could possibly be selling to a third party? Those are two 
completely different discussions.


K

Re: ISP data collection from home routers

2022-03-25 Thread Mu

You're statement seems to imply that if someone publicizes certain personal 
data on Facebook that they shouldn't care about any other data being collected 
any other entity, do I have that right?

While I agree that many consumers don't place much value on their own data, 
resulting in them not particularly caring about that data, in my experience it 
often stems from ignorance of what can be done with that data (if they even 
know that the data is being collected in the first place). Once the 
implications of sharing specific data is known, my anecdata has shown that the 
average person will make some adjustments to their data-sharing habits. At the 
very least, an informed decision can be made.

However, when it comes to intricate technical data from their home routers 
being hoarded, we can't really expect the average consumer to form an informed 
decision on the data being shared, can we? I don't think the default should be 
"collect as much as we can because they probably won't care" in the absence of 
an informed consumer.

Regards,

Mu

--- Original Message ---
On Thursday, March 24th, 2022 at 9:26 AM, Josh Luthman 
 wrote:

> I'm surprised we're having this discussion about an internet device that the 
> customer is using to publicize all of their information on Facebook and 
> Twitter. Consumers do not care enough about their privacy to the point where 
> they are providing the information willingly.
>
>>Consumers should have legal say in how or wether their data are harvested and 
>>also sold.
>
> They do. https://www.fcc.gov/general/customer-privacy
>
> On Thu, Mar 24, 2022 at 9:12 AM Lady Benjamin Cannon of Glencoe, ASCE 
>  wrote:
>
>> This is an enormous problem, see: 
>> https://www.ftc.gov/news-events/news/press-releases/2021/10/ftc-staff-report-finds-many-internet-service-providers-collect-troves-personal-data-users-have-few
>>
>> Consumers should have legal say in how or wether their data are harvested 
>> and also sold.
>>
>> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
>> 6x7 Networks & 6x7 Telecom, LLC
>> CEO
>> l...@6by7.net
>> "The only fully end-to-end encrypted global telecommunications company in 
>> the world.”
>>
>> FCC License KJ6FJJ
>>
>> Sent from my iPhone via RFC1149.
>>
>>> On Mar 24, 2022, at 3:44 AM, Giovane C. M. Moura via NANOG 
>>>  wrote:
>>
>>> Hello there,
>>>
>>> Several years ago, a friend of mine was working for a large telco and his 
>>> job was to detect which clients had the worst networking experience.
>>>
>>> To do that, the telco had this hadoop cluster, where it collected _tons_ of 
>>> data from home users routers, and his job was to use ML to tell the signal 
>>> from the noise.
>>>
>>> I remember seeing a sample csv from this data, which contained _thousands_ 
>>> of data fields (features) from each client.
>>>
>>> I was _shocked_ by the amount of (meta)data they are able to pull from home 
>>> routers. These even included your wifi network name _and_ password!
>>> (it's been several years since then).
>>>
>>> And home users are _completely_ unaware of this.
>>>
>>> So my question to you folks is:
>>>
>>> - What's the policy regulations on this? I don't remember the features 
>>> (thousands) but I'm pretty sure you could some profiling with it.
>>>
>>> - Is anyone aware of any public discussion on this? I have never seen it.
>>>
>>> Thanks,
>>>
>>> Giovane Moura

Re: ISP data collection from home routers

2022-03-25 Thread Joel Busch

Hi Giovane

On 24.03.22 11:43, Giovane C. M. Moura via NANOG wrote:

Hello there,

Several years ago, a friend of mine was working for a large telco and
his job was to detect which clients had the worst networking experience.

To do that, the telco had this hadoop cluster, where it collected _tons_
of data from home users routers, and his job was to use ML to tell the
signal from the noise.

I remember seeing a sample csv from this data, which contained
_thousands_ of data fields (features) from each client.

I was _shocked_ by the amount of (meta)data they are able to pull from
home routers. These even included your wifi network name _and_ password!

(it's been several years since then).

Creepy. And the provided CPE usually sucks too, what a deal...
I feel validated in preferring to use my own router at home.

And home users are _completely_ unaware of this.

So my question to you folks is:

- What's the policy regulations on this? I don't remember the features
(thousands) but I'm pretty sure you could some profiling with it.

For the policies probably this is a good place to start if you are
interested in US legislation (you didn't specify any location), as it's
not federally regulated from what I gather:

https://www.ncsl.org/research/telecommunications-and-information-technology/2019-privacy-legislation-related-to-internet-service-providers.aspx

- Is anyone aware of any public discussion on this? I have never seen it.

I remember reading some discussion around ISPs selling browsing behavior
data that they collect from their subscribers in the tech press during
Pai's term as the head of the FCC. It was probably on Ars Technica or
Techdirt.

Thanks,

Giovane Moura

Best,
Joel

--
Joel Busch, Network

SWITCH
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 30, direct +41 44 268 16 58
https://switch.ch https://swit.ch/linkedin https://swit.ch/twitter

Re: ISP data collection from home routers

2022-03-25 Thread Christian David

I think that if the end user at signed contract agreed with this data 
collecting and also if there's a mechanism that the same user could deny 
the data collection, its look fine to me, there's compliant here in 
Brazil with LGPD (our variant from GDPR) and i think that users could 
see it as a "plus" cause the majority of ISPs don't have a service that 
inspect CPE WIFI's quality.


Em 24/03/2022 14:00, Jay Hennigan escreveu:

On 3/24/22 06:26, Josh Luthman wrote:
I'm surprised we're having this discussion about an internet device 
that the customer is using to publicize all of their information on 
Facebook and Twitter. 


That's called informed consent. And Facebook and Twitter use TLS to 
protect the data in transit.


Consumers do not care enough about their privacy to the point where 
they are providing the information willingly.


That's the point. The customer is providing information willingly when 
they post to social media. The ISP is collecting data without consent.

Re: ISP data collection from home routers

2022-03-25 Thread Francis Booth via NANOG

That link is more reflective of the FCC circa 2011. More recent actions taken 
by the FCC under Pai had weakened consumer protections for data collected by 
ISPs and was reflected in multiple news articles from 2017-2019.

https://en.wikipedia.org/wiki/2017_Broadband_Consumer_Privacy_Proposal_repeal
https://transition.fcc.gov/Daily_Releases/Daily_Business/2017/db0328/DOC-344116A1.pdf
https://www.ftc.gov/news-events/news/press-releases/2019/08/ftc-revises-list-companies-subject-broadband-privacy-study

Including this relatively recent article by the FTC. The same FTC tapped by the 
FCC as being the more responsible party for enforcing privacy protections for 
consumers. They are even saying that their privacy study showed very little 
protections for consumer data being harvested by ISPs with few options to 
restrict their use.
https://www.ftc.gov/news-events/news/press-releases/2021/10/ftc-staff-report-finds-many-internet-service-providers-collect-troves-personal-data-users-have-few

> On Mar 24, 2022, at 9:26 AM, Josh Luthman  wrote:
> 
> I'm surprised we're having this discussion about an internet device that the 
> customer is using to publicize all of their information on Facebook and 
> Twitter.  Consumers do not care enough about their privacy to the point where 
> they are providing the information willingly.
> 
> >Consumers should have legal say in how or wether their data are harvested 
> >and also sold.
> 
> They do. https://www.fcc.gov/general/customer-privacy
> 
> 
> On Thu, Mar 24, 2022 at 9:12 AM Lady Benjamin Cannon of Glencoe, ASCE 
>  wrote:
> This is an enormous problem, see: 
> https://www.ftc.gov/news-events/news/press-releases/2021/10/ftc-staff-report-finds-many-internet-service-providers-collect-troves-personal-data-users-have-few
> 
> Consumers should have legal say in how or wether their data are harvested and 
> also sold.
> 
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC 
> CEO 
> l...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> 
> FCC License KJ6FJJ
> 
> Sent from my iPhone via RFC1149.
> 
>> On Mar 24, 2022, at 3:44 AM, Giovane C. M. Moura via NANOG  
>> wrote:
>> 
>> Hello there,
>> 
>> Several years ago, a friend of mine was working for a large telco and his 
>> job was to detect which clients had the worst networking experience.
>> 
>> To do that, the telco had this hadoop cluster, where it collected _tons_ of 
>> data from home users routers, and his job was to use ML to tell the signal 
>> from the noise.
>> 
>> I remember seeing a sample csv from this data, which contained _thousands_ 
>> of data fields (features) from each client.
>> 
>> I was _shocked_ by the amount of (meta)data they are able to pull from home 
>> routers. These even included your wifi network name _and_ password!
>> (it's been several years since then).
>> 
>> And home users are _completely_ unaware of this.
>> 
>> So my question to you folks is:
>> 
>> - What's the policy regulations on this? I don't remember the features 
>> (thousands) but I'm pretty sure you could some profiling with it.
>> 
>> - Is anyone aware of any public discussion on this? I have never seen it.
>> 
>> Thanks,
>> 
>> Giovane Moura

IPvB translation header

This was the IPvB (nee original IPv6) *translation* header.

Note that it was cleverly designed to translate from IPv4.
Most of the fields are in exactly the same place. Especially,
the 32-bit Source IP address is in exactly the same place, hoping
that filters could operate on both stacks.

We were implementing on then new i386 32-bit machines, but also
tested on i286 16-bit machines. We knew there would be 64-bit
machines (such as the DEC Alpha), so it was carefully designed
for multiple environments.

3.1. Translation Header Format

+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
|Version| IHV |Service|Minimal Length |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
|Identification | Next Header | Hop Limit |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
| |
+Source +
| |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
| |
+ Destination +
| |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+

Version 4 bits: constant 0xB (1011 binary).

Indicates the format of the internet header. This
document describes version 11.

Note:
The IPv4 Version is 0x4 (0100
binary). IPvB is the complement
(binary inverse) of IPv4.

Although this field is always
present, and may be used internally
by systems, different headers MUST
be distinguished at the link layer.
Some implementations of IPv4 failed
to correctly check (or set) the
IPv4 Version.

IHV 4 bits. Internet Header Variant.

0x0
Invalid; MUST be silently discarded.

0x6
IPv4 header translation. The least significant
bit here reflects the most significant IPv4 Flags
bit, as some systems used that bit in the past.
(See "IPvB Translation for IPv4" [].)

0x8
Flow header (see below).

0xA
Reserved for future use.

The IPvB header is a fixed minimum size. However,
the Version field is a scarce resource Therefore,
larger values are used for format variants,
transient indications, and other purposes.

Note:
For IPv4, this field was the
Internet Header Length (IHL) in
32‐bit words. The minimum value
for a matching IPvB header is 6
words.

Service 8 bits: default 0.

Contains the IPv4 Type of Service (ToS).

Minimal Length 16 bits: minimum 64 (bytes). Smaller values MUST be
silently discarded.

The length of the datagram, including internet
header(s) and payload data. All nodes must be
prepared to accept datagrams of up to 1480 octets.
It is recommended that hosts send datagrams larger
than 1480 octets only after assurance that the
destination is prepared to accept the larger
datagrams.

The number 1480 is selected to allow a reasonable
sized data block to be transmitted in addition to
the required header information, and to allow
typical lower‐layer encapsulations room for their
respective headers. Over time, memory limitations
have eased considerably, and there have been some
indications that a larger minimum datagram size
throughout the internet would be beneficial.

Note:
IPv4 has minimum required 576 and
maximum 65,535 octet datagrams.
Translation to IPv4 requires that

Re: Cogent pulled out of Russia based on risk analysis

2022-03-25 Thread Martin Hannigan

8m20s.



On Fri, Mar 25, 2022 at 8:54 AM Mike Hammett  wrote:

> Timestamp?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Lady Benjamin Cannon of Glencoe, ASCE" 
> *To: *"NANOG Group" 
> *Sent: *Friday, March 25, 2022 7:37:22 AM
> *Subject: *Cogent pulled out of Russia based on risk analysis
>
> Confirmation from their CEO that Cogent shut down service in Russia due to
> increased use of the connections for cyberattacks, and because only $10m in
> rev came from Russia.
>
> Cogent had no equipment in Russia.
>
> Details: https://youtu.be/l_x2LQZOzF8
>
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> l...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company
> in the world.”
>
> FCC License KJ6FJJ
>
> Sent from my iPhone via RFC1149.
>
>

Re: IPv6 "bloat" history


On 3/23/22 2:25 AM, Masataka Ohta wrote:

William Allen Simpson wrote:


  6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol
 (PIP) had some overlapping features, so we also asked them to merge
 with us (July 1993).  More complexity in the protocol header chaining.


With the merger, Paul Francis was saying he was unhappy
because PIP is dead. So the merger is not voluntary for
him and the added complexity is technically meaningless.



He seemed happy at the Amsterdam 1993 meeting, but as time went on he was
sidelined.  Likewise, I eventually regretted having joined with the others.
We lost control of the main ideas.

For example, originally V6 was designed to use shortest path first
interior routing.  All the announcements were Link State, everything was in
place.  I still wince at the memory of the PARC meeting where Eric stated
that RIP was good enough for V4, so it is good enough for V6.

Then he was assigned to be my "co-author".  So I quit.

What you know as Neighbor Discovery was not the original design.  Nor was
RIPv6 needed.

When I was giving a talk at Google 25 years later I was asked why that
happened (by a then member of the IAB).  A sore spot, long remembered.
Committee-itis at its worst.



IPv4 options were recognized as harmful.  SIPP used header chains instead.
But the whole idea was to speed processing, eliminating hop-by-hop.

Then the committees added back the hop by hop processing (type 0).
Terrible!


Really? But, rfc1710 states:

    The SIPP option headers which are currently defined are:

  Hop-by-Hop Option  Special options which require hop by hop
     processing



Yep, that was one of the reasons I quit.

Digging out my files, I'd forked my documents by July 17, 1994.  (That's
the last date I'd touched them, so it was before then.)  RFC 1710 was later.

Also, I registered IPvB with Jon Postel.

These are all old nroff files, but I could hand format a bit and post
things here.  Not that it makes much difference today, yet some of my
ideas made it into Fibre Channel and InfiniBand.

MAP-T (was: Re: V6 still not supported)

2022-03-25 Thread Jared Brown

Most IPv6 transition mechanisms involve some form of (CG)NAT. After watching a 
NANOG presentation on MAP-T, I have a question regarding this.

Why isn't MAP-T more prevalent, given that it is (almost) stateless on the 
provider side?

Is it CPE support, the headache of moving state to the CPE, vendor support, or 
something else?


NANOG 2017
Mapping of Address and Port using Translation MAP T: Deployment at Charter 
Communications
https://www.youtube.com/watch?v=ZmfYHCpfr_w


- Jared

Re: V6 still not supported

2022-03-25 Thread Jared Brown

Owen DeLong via NANOG wrote:
> When your ISP starts charging $X/Month for legacy protocol support

Out of interest, how would this come about?


- Jared

Re: Cogent pulled out of Russia based on risk analysis

2022-03-25 Thread Lady Benjamin Cannon of Glencoe

Yesterday.  Video of CEO is in my OP.

-LB

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
6x7 Networks & 6x7 Telecom, LLC 
CEO 
b...@6by7.net
"The only fully end-to-end encrypted global telecommunications company in the 
world.”
ANNOUNCING: 6x7 GLOBAL MARITIME 

FCC License KJ6FJJ




> On Mar 25, 2022, at 5:51 AM, Mike Hammett  wrote:
> 
> Timestamp?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> Midwest-IX
> http://www.midwest-ix.com 
> 
> From: "Lady Benjamin Cannon of Glencoe, ASCE" 
> To: "NANOG Group" 
> Sent: Friday, March 25, 2022 7:37:22 AM
> Subject: Cogent pulled out of Russia based on risk analysis 
> 
> Confirmation from their CEO that Cogent shut down service in Russia due to 
> increased use of the connections for cyberattacks, and because only $10m in 
> rev came from Russia.
> 
> Cogent had no equipment in Russia.
> 
> Details: https://youtu.be/l_x2LQZOzF8 
> 
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC 
> CEO 
> l...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> 
> FCC License KJ6FJJ
> 
> Sent from my iPhone via RFC1149.

Re: Cogent pulled out of Russia based on risk analysis

2022-03-25 Thread Rubens Kuhl

https://www.youtube.com/watch?v=l_x2LQZOzF8=500s

Rubens

On Fri, Mar 25, 2022 at 9:51 AM Mike Hammett  wrote:
>
> Timestamp?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> 
> From: "Lady Benjamin Cannon of Glencoe, ASCE" 
> To: "NANOG Group" 
> Sent: Friday, March 25, 2022 7:37:22 AM
> Subject: Cogent pulled out of Russia based on risk analysis
>
> Confirmation from their CEO that Cogent shut down service in Russia due to 
> increased use of the connections for cyberattacks, and because only $10m in 
> rev came from Russia.
>
> Cogent had no equipment in Russia.
>
> Details: https://youtu.be/l_x2LQZOzF8
>
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> l...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
>
> FCC License KJ6FJJ
>
> Sent from my iPhone via RFC1149.
>

Re: Cogent pulled out of Russia based on risk analysis