Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Denis Fondras]

Le Wed, Nov 24, 2021 at 05:08:43PM -0800, William Herrin a écrit :
> I don't recall there being any equipment or software compatibility
> concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. 

Perhaps not the whole /8 but definitely some buggy implementations :
https://seclists.org/nanog/2018/Apr/52

Re: multihoming

[Masataka Ohta via NANOG]

Baldur Norddahl wrote:


Are you proposing SCTP? There is sadly not much more hope for widespread
adoption of that as of IPv6.


My ID describes the architectural framework both for IPv4 and IPv6.

Modification to TCP is discussed, for example, in:

https://datatracker.ietf.org/doc/html/draft-arifumi-tcp-mh-00

I still think something like that is necessary before IPv4 global
routing table size become 16M (ignoring loopback/multicast/ClassE).


Christopher Morrow wrote:

> reading the ID that masataka referenced, it sounded very much like
> shim6 about ~4 yrs prior to shim6's "invention".

No, not at all.

> I also don't recall
> seeing the draft referenced during the shim6 conversations.

Despite my ID saying:

   All the other processing can be
   performed by transport layer (typically in kernel) using
   default or application specific timing of TCP.

   Without TCP, applications must be able to detect loss of
   connectivity in application dependent way

shim6 is wrongly architected to address the issue at the
*connectionless* IP layer, where there is no proper period
for timeout. Also, transport/application layer information
such as TCP sequence numbers may offer proper security.

Notion of connection (including half one such as DNS
query/reply at the application layer) is essential
for proper state maintenance.

Similar layering violation also occurred to network
layer PMTUD, which is why it is rather harmful than
useful.

Masataka Ohta

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[William Herrin]

On Wed, Nov 24, 2021 at 4:36 PM David Conrad  wrote:
>> I like research but what would the RIRs study? The percentage of the
>
> Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC
> and they said similar things when 1.1.1.0/24 was stood up as an
> experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.

Hi David,

I don't recall there being any equipment or software compatibility
concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As
I recall it, there were concerns with prior local use and potential
trash traffic. It seemed likely those concerns could be addressed with
experiments, and the experiments in fact addressed them.

The prior local use worry reared its head again with 240/4 but given
the prior experience with 1.0.0.0/8 I don't personally believe we need
to re-run that experiment just because the numbers are part of a
different block.


> Seems to me that a number of folks on this list and during this
> discussion would disagree with a blanket assertion that 240/4
> is “dysfunctional on the 2021 Internet” - some of them even
> wrote a draft discussing the possibility.

Line them up. Show of hands. Who really thinks that if we assign
240.0.0.1 to a customer tomorrow without waiting for anyone to clean
up their software and hardware, you won't get enough complaints about
things not working that you have to take it back and assign a
different address instead?


> 1. Move 240/4 from "reserved" to "unallocated unicast"
>
> OK, but this seems like a quibble.  The status for 240/4 is “
> RESERVED: designated by the IETF for specific non-global-unicast
> purposes as noted.”  The “as noted” part is “Future Use”.

It's not a quibble. Some vendors take the current status to mean
"treat it like unicast until we're told otherwise." Others take the
status to mean, "packets with these addresses are bogons without a
defined routing behavior until we're told otherwise." The result is
incompatible behavior between vendors. Changing that direction to
"treat it like unicast" without ambiguity is not a quibble.

Regards,
Bill Herrin

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

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Eric Kuhnke]

Anecdotally, anyone that's had reason to manually go through logs for port
5060 SIP for any public facing ipv4 /32 will see the vast amounts of random
"things" out there on the internet trying common extension password combos
to register.

It's been a large amount of background noise on the internet for a very log
time now.



On Wed, Nov 24, 2021 at 5:20 PM Gavin Henry  wrote:

> Hi all,
>
> I hope you don't mind the post, but thought this might be of use and
> in the spirit of release early, release often I've done an alpha
> release:
>
> https://github.com/SentryPeer/SentryPeer
>
> There's a presentation too if you'd like to watch/read where I hope to
> go with this:
>
> https://blog.tadsummit.com/2021/11/17/sentrypeer/
>
> Working on the API and web UI next, then the p2p part of it. Feel free
> to submit any feature requests or have a play :-)
>
> Thanks for reading and any feedback is welcome!
>
> --
> Kind Regards,
> Gavin Henry.
>

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[David Conrad]

Bill,

On Nov 23, 2021, at 11:12 PM, William Herrin  wrote:
>> 1. IAB or IESG requests the IANA team to delegate one of
>> the 240/4 /8s to the RIRs on demand for experimental
>> purposes for a fixed period of time (a year or two?).
> 
> I like research but what would the RIRs study? The percentage of the
> 2021 Internet reachable from a station assigned a 240/4 IP address?
> Suppose it's 95%? Or 50%? Is there a difference? Neither one is enough
> to deploy the addresses for 2021 global use.

Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC and 
they said similar things when 1.1.1.0/24 was stood up as an experiment by 
Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.

>> 5. Armed with hard data on the usability of the 240/4 /8s
>> allocated, people can scream past each other much more
>> authoritatively on the topic of what to do with 240/4.
> 
> Which is not particularly valuable. We already know the addresses are
> dysfunctional on the 2021 Internet. There's no credible disagreement
> on that point.

Seems to me that a number of folks on this list and during this discussion 
would disagree with a blanket assertion that 240/4 is “dysfunctional on the 
2021 Internet” - some of them even wrote a draft discussing the possibility. 

>> 2. IAB or IESG requests the IANA team to delegate one of
>> the 240/4 /8s to the RIRs on demand for experimental
>> purposes for a fixed period of time
> 
> But that still starts with:
> 
>> 1. Move 240/4 from "reserved" to "unallocated unicast"

OK, but this seems like a quibble.  The status for 240/4 is “ RESERVED: 
designated by the IETF for specific non-global-unicast purposes as noted.”  The 
“as noted” part is “Future Use”.  As far as I’m aware, “future use” would not 
preclude “experimental use” however if it makes people feel better to have an 
IANA considerations section that says the prefixes need to be moved to 
ALLOCATED, I struggle to see how that would be a problem.

Regards,
-drc

Re: multihoming

[Christopher Morrow]

On Wed, Nov 24, 2021 at 5:12 PM Geoff Huston  wrote:

>
>
> > On 25 Nov 2021, at 7:57 am, Christopher Morrow 
> wrote:
> >
> > Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.
> >
> > or perhaps MP-TCP? :)  or shim6?
>
> Shim6 died a comprehensive death many yers ago. I recall NANOG played a
> role in it's untimely demise. :-)
>
>
oh, darn! :)

reading the ID that masataka referenced, it sounded very much like shim6
about ~4 yrs prior to shim6's "invention".
I also don't recall seeing the draft referenced during the shim6
conversations.

Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows...
nor IPSEC nor GRE nor...
unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that!

Talk about layer violations! talk about fun!

-chris

Re: multihoming

[Geoff Huston]

> On 25 Nov 2021, at 7:57 am, Christopher Morrow  
> wrote:
> 
> Are you proposing SCTP? There is sadly not much more hope for widespread 
> adoption of that as of IPv6.
> 
> or perhaps MP-TCP? :)  or shim6?

Shim6 died a comprehensive death many yers ago. I recall NANOG played a role in 
it's untimely demise. :-)

Geoff

SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

Hi all,

I hope you don't mind the post, but thought this might be of use and
in the spirit of release early, release often I've done an alpha
release:

https://github.com/SentryPeer/SentryPeer

There's a presentation too if you'd like to watch/read where I hope to
go with this:

https://blog.tadsummit.com/2021/11/17/sentrypeer/

Working on the API and web UI next, then the p2p part of it. Feel free
to submit any feature requests or have a play :-)

Thanks for reading and any feedback is welcome!

-- 
Kind Regards,
Gavin Henry.

Re: multihoming

[Christopher Morrow]

On Wed, Nov 24, 2021 at 9:12 AM Baldur Norddahl 
wrote:

>
>
> On Wed, 24 Nov 2021 at 08:16, Masataka Ohta <
> mo...@necom830.hpcl.titech.ac.jp> wrote:
>
>> So, as modifying end systems is inevitable, there is
>> no reason not to support full end to end multihoming
>> including modifications to support multiple addresses
>> by TCP and some applications.
>>
>> Masataka Ohta
>>
>
> Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.
>
>
or perhaps MP-TCP? :)  or shim6?

Salesforce issues

[Erik Sundberg]

We are receiving latency complaints to Salesforce, anyone else seeing this?

Looks like Vocus Network might be possibly leaking some force.com (Salesforce) 
routes, causing 200ms of latency. Traffic is going Chicago -> Vocus Networks -> 
Australia -> Akamai Atlanta

I have emailed both Vocus Networks and Akamai about this.


dig force.com +short
104.109.10.129 <<< Possible Leaked via Vocus Networks
104.109.11.129  <<< Possible Leaked via Vocus Networks
184.25.179.132 <<< Possible Leaked via Vocus Networks
184.31.3.130  < Route ok  (NTT, TATA, Akamai) 25ms
184.31.10.133 <<< Route ok (NTT, Akamai) 16ms
23.1.35.132 <<< Possible Leaked via Vocus Networks
23.1.99.130 <<< Route ok (Akamai) 15 ms
23.1.106.133 <<< Route ok (NTT, Akamai) 16ms


2021-11-24T13:47:59-0600
Keys:  Help   Display mode   Restart statistics   Order of fields   quit

   
Packets   Pings
Host

Loss%   Snt   Last   Avg  Best  Wrst StDev
1. AS???172.19.1.2 (172.19.1.2) 
 
0.0% 71.7   1.9   0.9   4.8   1.3
2. ???
3. AS53828  207.200.193.193 (207.200.193.193)   
 
0.0% 61.0   1.0   0.9   1.0   0.1
4. AS???eqix-ch1.vocusconnect.com (208.115.136.142) 
 
0.0% 6   41.0  40.8  40.8  41.0   0.1
5. AS4826   be101.bdr04.sjc01.ca.us.vocus.network (114.31.199.38)   

40.0% 6  200.6 200.7 200.6 200.8   0.1
[MPLS: Lbl 24266 Exp 0 S 1 TTL 1]
6. AS4826   be100.bdr03.sjc01.ca.us.vocus.network (114.31.199.32)   
 
0.0% 6  197.4 197.5 197.4 197.5   0.0
[MPLS: Lbl 24807 Exp 0 S 1 TTL 1]
7. AS4826   be202.cor02.syd04.nsw.vocus.network (114.31.199.42) 
 
0.0% 6  197.4 197.4 197.3 197.5   0.1
[MPLS: Lbl 24932 Exp 0 S 1 TTL 1]
8. AS4826   be100.bdr04.syd03.nsw.vocus.network (114.31.192.45) 
 
0.0% 6  197.5 197.5 197.4 197.5   0.0
9. AS4826   static-74.173.255.49.in-addr.VOCUS.net.au (49.255.173.74)   
 
0.0% 6  200.2 200.7 197.4 205.2   3.0
10. AS20940  a23-1-240-228.deploy.static.akamaitechnologies.com (23.1.240.228)  
  
0.0% 6  197.1 197.3 197.1 197.6   0.2
11. ???
12. AS4826   static-73.173.255.49.in-addr.VOCUS.net.au (49.255.173.73)  
  
0.0% 6  197.5 197.6 197.5 197.8   0.1
13. AS4826   be114.cor02.syd04.nsw.vocus.network (114.31.192.44)
  
0.0% 6  348.7 349.0 348.7 349.4   0.3
14. AS4826   be202.bdr03.sjc01.ca.us.vocus.network (114.31.199.43)  
  
0.0% 6  349.0 349.1 348.9 349.3   0.1
15. AS3257   173.205.35.1 (173.205.35.1)
  
0.0% 6  348.8 351.0 348.6 362.1   5.4
16. AS3257   ae18-3416.cr11-fra2.ip4.gtt.net (89.149.180.134)   
  
0.0% 6  356.0 350.5 349.1 356.0   2.7
17. AS3257   ip4.gtt.net (98.124.180.42)
  
0.0% 6  348.9 349.0 348.9 349.2   0.1
18. AS20940  ae12.r01.sjc01.icn.netarch.akamai.com (23.207.232.36)  
  
0.0% 6  368.5 353.4 349.3 368.5   8.4
19. AS20940  ae11.r01.ord01.icn.netarch.akamai.com (23.32.63.46)
  
0.0% 6  393.7 393.8 393.7 394.1   0.2
20. AS20940  ae6.r02.iad01.icn.netarch.akamai.com (23.32.63.21) 
  
0.0% 6  411.4 411.8 411.4 412.4   0.5
21. 

Re: anyone use fbtracert successfully?

[Thomas Scott]

Ha, my apologies, I thought I was writing this for a Linux User Group, not
a NOG. Ignore my simplistic explanations.
- Thomas Scott | mr.thomas.sc...@gmail.com


On Wed, Nov 24, 2021 at 12:47 PM Thomas Scott 
wrote:

> I have used it successfully in a test environment that I was using ECMP
> in. Most of the public networks that I've worked with don't use ECMP as
> often as other methods for steering traffic (LAGs, BGP MEDs, etc).
>
> What I have seen it fantastically useful for was troubleshooting a transit
> provider, or for when they were congested or had a flapping core link.
> Granted I *think *it's still subject to ICMP deprioritization (most SP's
> use it prodigiously), and most MPLS cores don't decrement TTL, but it was
> still useful to be able to show them "no, at this IP, I *always* drop
> traffic, when..."
>
> - Thomas Scott | mr.thomas.sc...@gmail.com
>
>
> On Wed, Nov 24, 2021 at 12:23 PM Adam Thompson 
> wrote:
>
>> The tool fbtracert (http://github.com/facebookarchive/fbtracert) was
>> mentioned here recently as a way to get visibility into multi-pathing.
>>
>> Has anyone here ever used this tool successfully?
>>
>>
>>
>> Supposedly Facebook uses this tool internally, but… that doesn’t help
>> much.
>>
>>
>>
>> I’ve tried it on 4 different platforms/OSes (WSL Ubuntu; RedHat; Debian;
>> OpenBSD), and versions of Go (v1.10 through v1.16), in three very different
>> environments (on-prem public IP; on-prem NAT’d; cloud public IP), and I’ve
>> yet to see it produce any meaningful output – each run/iteration/thread
>> only detects one, single, hop out of the entire chain of routers, making it
>> less than useful.  Granted, that’s not a full regression test by any means,
>> but if anyone here has ever used it successfully, could you please let me
>> know what sort of environment you ran it in/on?
>>
>>
>>
>> Thanks,
>>
>> -Adam
>>
>>
>>
>> *Adam Thompson*
>> Consultant, Infrastructure Services
>> [image: 1593169877849]
>> 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
>>
>>
>>
>

Re: anyone use fbtracert successfully?

[Thomas Scott]

I have used it successfully in a test environment that I was using ECMP in.
Most of the public networks that I've worked with don't use ECMP as often
as other methods for steering traffic (LAGs, BGP MEDs, etc).

What I have seen it fantastically useful for was troubleshooting a transit
provider, or for when they were congested or had a flapping core link.
Granted I *think *it's still subject to ICMP deprioritization (most SP's
use it prodigiously), and most MPLS cores don't decrement TTL, but it was
still useful to be able to show them "no, at this IP, I *always* drop
traffic, when..."

- Thomas Scott | mr.thomas.sc...@gmail.com


On Wed, Nov 24, 2021 at 12:23 PM Adam Thompson 
wrote:

> The tool fbtracert (http://github.com/facebookarchive/fbtracert) was
> mentioned here recently as a way to get visibility into multi-pathing.
>
> Has anyone here ever used this tool successfully?
>
>
>
> Supposedly Facebook uses this tool internally, but… that doesn’t help much.
>
>
>
> I’ve tried it on 4 different platforms/OSes (WSL Ubuntu; RedHat; Debian;
> OpenBSD), and versions of Go (v1.10 through v1.16), in three very different
> environments (on-prem public IP; on-prem NAT’d; cloud public IP), and I’ve
> yet to see it produce any meaningful output – each run/iteration/thread
> only detects one, single, hop out of the entire chain of routers, making it
> less than useful.  Granted, that’s not a full regression test by any means,
> but if anyone here has ever used it successfully, could you please let me
> know what sort of environment you ran it in/on?
>
>
>
> Thanks,
>
> -Adam
>
>
>
> *Adam Thompson*
> Consultant, Infrastructure Services
> [image: 1593169877849]
> 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
>
>
>

anyone use fbtracert successfully?

[Adam Thompson]

The tool fbtracert (http://github.com/facebookarchive/fbtracert) was mentioned 
here recently as a way to get visibility into multi-pathing.
Has anyone here ever used this tool successfully?

Supposedly Facebook uses this tool internally, but… that doesn’t help much.

I’ve tried it on 4 different platforms/OSes (WSL Ubuntu; RedHat; Debian; 
OpenBSD), and versions of Go (v1.10 through v1.16), in three very different 
environments (on-prem public IP; on-prem NAT’d; cloud public IP), and I’ve yet 
to see it produce any meaningful output – each run/iteration/thread only 
detects one, single, hop out of the entire chain of routers, making it less 
than useful.  Granted, that’s not a full regression test by any means, but if 
anyone here has ever used it successfully, could you please let me know what 
sort of environment you ran it in/on?

Thanks,
-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
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

Re: multihoming

[Saku Ytti]

On Wed, 24 Nov 2021 at 16:16, Baldur Norddahl  wrote:

> Are you proposing SCTP? There is sadly not much more hope for widespread 
> adoption of that as of IPv6.

If you use Apple, you use MP-TCP, for better UX while using both
mobile and wifi.

SCTP is no good, because you cannot transition between two
connections, they have to overlap for a period, there is no separation
of identity and location. QUIC actually can do that, in that identity
is PKI and location is IP address, so you could roam from one IP to
another IP without having overlapping connectivity.

-- 
  ++ytti

Re: multihoming

[Baldur Norddahl]

On Wed, 24 Nov 2021 at 08:16, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> So, as modifying end systems is inevitable, there is
> no reason not to support full end to end multihoming
> including modifications to support multiple addresses
> by TCP and some applications.
>
> Masataka Ohta
>

Are you proposing SCTP? There is sadly not much more hope for widespread
adoption of that as of IPv6.

Regards,

Baldur