- Test - lists.nanog.org

Re: Geyserville fire
by Ben Cannon 24 Oct '19

24 Oct '19

Geyser Peak is on fire and will likely soon lose all mobile telecommunications. -Ben > On Oct 24, 2019, at 12:13 AM, Ben Cannon <ben(a)6by7.net> wrote: > > > <image.png> > > > -Ben

3 2

Contact at ESPN?
by Danny Meister 24 Oct '19

24 Oct '19

1 0

Re: IPv4 and Auctions
by Matt Hoppes 24 Oct '19

24 Oct '19

> You can hold onto resources you don't actively need, and nothing in any > RIR agreement I'm aware of (I'm only familiar with ARIN's) says > otherwise. There is no requirement to return resources under any > circumstances. So you're saying you can justify a large amount of IPs with ARIN, then suddenly not need them and just hold onto them? I was under the impression you had to need them in order to hold onto them?

1 0

A New Fiber Optic Network
by Rod Beck 24 Oct '19

24 Oct '19

https://www.telecomramblings.com/2019/10/crosslake-fibre-now-live/?utm_sour… [https://www.telecomramblings.com/files/2019/10/ScreenHunter-052-22-Oct-19-0…]<https://www.telecomramblings.com/2019/10/crosslake-fibre-now-live/?utm_sour…> Crosslake Fibre Now Live | Telecom Ramblings<https://www.telecomramblings.com/2019/10/crosslake-fibre-now-live/?utm_sour…> One of the more unique recent fiber buildouts is now complete. Crosslake Fibre announced this morning that its Toronto-New York cable is now live, adding diversity on a route that hasn't seen anything new in decades while cutting latency.. The nature of Crosslake's project is evident in the name of the company: a 'subsea' cable underneath Lake Ontario from Toronto over to New York State north ... www.telecomramblings.com Roderick Beck VP of Business Development United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> New York City & Budapest rod.beck(a)unitedcablecompany.com 36-70-605-5144 [1467221477350_image005.png]

1 0

Anyone from NTT America here?
by Stephen Satchell 23 Oct '19

23 Oct '19

Routing loop > 11.|-- 129.250.24.196 0.0% 1 28.9 28.9 28.9 28.9 0.0 > 12.|-- 129.250.130.254 0.0% 1 29.0 29.0 29.0 29.0 0.0 > 13.|-- 129.250.130.253 0.0% 1 29.4 29.4 29.4 29.4 0.0 > 14.|-- 129.250.130.254 0.0% 1 29.6 29.6 29.6 29.6 0.0 > 15.|-- 129.250.130.253 0.0% 1 28.5 28.5 28.5 28.5 0.0 > 16.|-- 129.250.130.254 0.0% 1 29.0 29.0 29.0 29.0 0.0 > 17.|-- 129.250.130.253 0.0% 1 28.6 28.6 28.6 28.6 0.0 > 18.|-- 129.250.130.254 0.0% 1 27.9 27.9 27.9 27.9 0.0 > 19.|-- 129.250.130.253 0.0% 1 28.4 28.4 28.4 28.4 0.0 > 20.|-- 129.250.130.254 0.0% 1 27.9 27.9 27.9 27.9 0.0 > 21.|-- 129.250.130.253 0.0% 1 28.2 28.2 28.2 28.2 0.0 > 22.|-- 129.250.130.254 0.0% 1 29.0 29.0 29.0 29.0 0.0 > 23.|-- 129.250.130.253 0.0% 1 27.9 27.9 27.9 27.9 0.0 > 24.|-- 129.250.130.254 0.0% 1 28.6 28.6 28.6 28.6 0.0 > 25.|-- 129.250.130.253 0.0% 1 28.7 28.7 28.7 28.7 0.0

3 2

Request comment: list of IPs to block outbound
by Stephen Satchell 23 Oct '19

23 Oct '19

The following list is what I'm thinking of using for blocking traffic between an edge router acting as a firewall and an ISP/upstream. This table is limited to address blocks only; TCP/UDP port filtering, and IP protocol filtering, is a separate discussion. This is for an implementation of BCP-38 recommendations. I'm trying to decide whether the firewall should just blackhole these addresses in the routing table, or use rules in NFTABLES against source and destination addresses, or some combination. If NFTABLES, the best place to put the blocks (inbound and outbound) would be in the FORWARD chain, both inbound and outbound. (N.B. for endpoint boxes, they go into the OUTPUT chain.) In trying to research what would constitute "best practice", the papers I found were outdated, potentially incomplete (particularly with reference to IPv6), or geared toward other applications. This table currently does not have exceptions -- some may need to be added as a specific "allow" route or list. The Linux rp_filter knob is effective for endpoint servers and workstations, and I turn it on religiously (easy because it's the default). For a firewall router without blackhole routes, it's less effective because, for incoming packets, a source address matching one of your inside netblocks will pass. A subset of the list would be useful in endpoint boxes to relieve pressure on the upstream edge router -- particularly if a ne'er-do-well successfully hijacks the endpoint box to participate in a DDoS flood. IPv4 Address block Scope Description 0.0.0.0/8 Software Current network (only valid as source address). 10.0.0.0/8 Private network Used for local communications within a private network. 100.64.0.0/10 Private network Shared address space[3] for communications between a service provider and its subscribers when using a carrier-grade NAT. 127.0.0.0/8 Host Used for loopback addresses to the local host. 169.254.0.0/16 Subnet Used for link-local addresses between two hosts on a single link when no IP address is otherwise specified, such as would have normally been retrieved from a DHCP server. 172.16.0.0/12 Private network Used for local communications within a private network. 192.0.0.0/24 Private network IETF Protocol Assignments. 192.0.2.0/24 Documentation Assigned as TEST-NET-1, documentation and examples. 192.88.99.0/24 Internet Reserved. Formerly used for IPv6 to IPv4 relay 192.168.0.0/16 Private network Used for local communications within a private network. 198.18.0.0/15 Private network Used for benchmark testing of inter-network communications between two separate subnets. 198.51.100.0/24 Documentation Assigned as TEST-NET-2, documentation and examples. 203.0.113.0/24 Documentation Assigned as TEST-NET-3, documentation and examples. 224.0.0.0/4 Internet In use for IP multicast. 240.0.0.0/4 Internet Reserved for future use. 255.255.255.255/32 Subnet Reserved for the "limited broadcast" destination address. IPv6 Address block Usage Purpose ::/0 Routing Default route. ::/128 Software Unspecified address. ::1/128 Host Loopback address to local host. ::ffff:0:0/96 Software IPv4 mapped addresses. ::ffff:0:0:0/96 Software IPv4 translated addresses. 64:ff9b::/96 Global Internet IPv4/IPv6 translation. 100::/64 Routing Discard prefix. 2001::/32 Global Internet Teredo tunneling. 2001:20::/28 Software ORCHIDv2. 2001:db8::/32 Documentation Addresses used in documentation and example source code. 2002::/16 Global Internet The 6to4 addressing scheme fc00::/7 Private network Unique local address. fe80::/10 Link Link-local address. ff00::/8 Global Internet Multicast address.

15 30

vz deep routing clue?
by Randy Bush 23 Oct '19

23 Oct '19

would appreciate unicast contact with someone withq 70x deep routing clue. researchers want to confirm possible causes of some phemnomona we think we see. thanks. randy

1 1

Fwd: SLAAC renum: Problem Statement & Operational workarounds
by Fernando Gont 23 Oct '19

23 Oct '19

Folks, Your input would be very welcome. Preferably on the v6ops wg mailing-list (https://www.ietf.org/mailman/listinfo/v6ops) but also on this list or multicast to us (authors). Thanks! -------- Forwarded Message -------- Subject: SLAAC renum: Problem Statement & Operational workarounds Date: Wed, 23 Oct 2019 03:51:32 -0500 From: Fernando Gont <fgont(a)si6networks.com> To: IPv6 Operations <v6ops(a)ietf.org> Folks, Earlier this year there was a lot of discussion about slaac renumbering problems. Our original I-D covered everything from the problem statement to proposed protocol updates and operational workarounds. Based on the comments received while discussing this topic on this list and other forums, and in order to keep the discussion better focused on specific aspects of the problem, we have posted a v6ops-targetted document that focuses on: * The problem statement * Discussion of operational workarounds, and associated constraints The document is available at: https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum We'd like to hear from the wg whether we have missed anything, whether the document is useful to the community, etc. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

Is anybody else getting spam from cytranet.com?
by Rich Kulawiec 22 Oct '19

22 Oct '19

I'm guessing -- because spammer Ben Reynolds (breynolds(a)cytranet.com) wrote to me about voice/data services -- that it's possible they've been scraping addresses from here. ---rsk

4 3

RE: BGP over TLS
by Jakob Heitz (jheitz) 22 Oct '19

22 Oct '19

The article linked says no mainstream BGP implementation supports TCP-AO. IOS-XE and IOS-XR support it. While I do not represent the Cisco view, personally I like the idea of BGP over TLS. Regards, Jakob. -----Original Message----- Date: Mon, 21 Oct 2019 19:21:03 +1100 From: Julien Goodwin <nanog(a)studio442.com.au> On 21/10/19 6:30 pm, Bjørn Mork wrote: > Christopher Morrow <morrowc.lists(a)gmail.com> writes: > >> isn't julien's idea more akin to DOT then DOH ? > > Yes, and I really like Julien's proposal. It even looks pretty > complete. There are just a few details missing around how to make the > MD5 => TLS transition smooth. At least for those systems that run on Linux (which is most all of the major's except Juniper) I suspect if we went to the relevant kernel folk with a clear plan on how handling TCP-MD5 in a way that would make transitions much easier they'd listen. The troll response at the top of my post was actually based on a response from one of the kernel folk, who dislike TCP options even more than network operators. > Sorry for any confusion caused by an attempt to make a joke on DoH. I > didn't anticipate the sudden turn to serious discussion :-) Which > obviously was a good one. I am all for BGP over TLS, so let's discuss > https://laptop006.livejournal.com/60532.html If anyone is at all interested in this I'm happy to discuss and flesh out anything that's not clear. After I wrote this (over a few bottles of red on the flight to linux.conf.au this year) I sent it to a bunch of people that had expressed interest, including a few BGP implementations, but nobody bit.

2 1