Networks

NAT exists in IPv6:

• IPv6-to-IPv6 Network Prefix Translation exists (RFC 6296, June 2011).

NATing between IPv6 and IPv4:

• Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (RFC 6146, April 2011)
• Mapping of Address and Port using Translation (MAP-T) (RFC 7599, July 2015)

Delivering a virtual IPv4 link over IPv6:

• Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (RFC 6333, August 2011)
• 464XLAT: Combination of Stateful and Stateless Translation (RFC 6877, April 2013)
• Mapping of Address and Port with Encapsulation (MAP-E) (RFC 7597, July 2015)

As for firewalls see:

• Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service (RFC 6092, January 2011)
• Thousands of ISP’s are using these RFCs to deliver working IPv4 and IPv6 to their customers today. Often the customer doesn’t even know they are using them.

If you don’t want to do a forklift upgrade deploy routers which support these RFCs as the old ones die and slowly migrate to a IPv6-only IPV4AAS model. Nobody has ever said that forklift upgrades where required.

Seen 2021/09/14 mailing list

• cloudflare 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
• comodo: 8.26.56.26 8.20.247.20
• dyn: 216.146.35.35 216.146.36.36
• google: 8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
• level3: 4.2.2.2 4.2.2.1
• norton: 199.85.126.10 199.85.127.10
• opendns: 208.67.222.222 208.67.220.220
• quad9: 9.9.9.9 149.112.112.112 2620:fe::fe 2620:fe::9
• ultradns: 156.154.71.1 156.154.70.1

A reference to Open DNS Resolvers, whether they are meant to be or not: public-dns.info

Another interesting resolvers.

And from a definition perspective: wikipedia.

Unrelated, but kinda a DNS question:

Is there a tool that would allow me to identify all the DNS servers on our networks that are using dnsmasq?

Response: github.com/kirei/fpdns, which was derived in reference to determining versions of DNSMasq due to the dnspooq attack.

For those that don't know this, if you want to know which cluster you're hitting, you can run:

$ dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8
"172.253.192.142"
"edns0-client-subnet x.x.x.0/24"

That will return the ipv4/ipv6 address of the server that handled your request. To get a list of what subnets map to which locations (airport codes), you can run:

$ dig -t TXT +short locations.publicdns.goog. @8.8.8.8

snip... "172.253.192.0/24 cbf ..snip

cbf = Council Bluffs, IA

Since my NFDump/DFSen Upgrade post many moons ago, I am once again doing an install for analyzing Netflow, this time on a server running Open vSwitch (OVS).

NFDump is a netflow collector. NFSen analyzes the netflow entries captured by NFDump.

Installing NFDump is easy using Debian's package:

apt install nfdump
systemctl stop nfdump
systemctl disable nfdump

The last two lines stop and disable the default service. Service control is provided with NFSen.

From a visualization perspective, there are a number of possibilities:

• NFSen Documentation is the main starting page for the code at SourceForge.
• NFSen on Github is p-alik's unofficial updated version of the original repository - my preferred location as it has some primary bug fixes and stays with the times
• mbolli / nfsen-ng - a modernized version of NFSen but doesn't appear to have the flexible query capability
• robcowart / elastiflow - I saw a link to this from Netflow collection and visualization with Elastiflow - which may have not relationship to NFDump / NFSen but seems promising none-the-less. Installation notes are at Installing Elastiflow flow monitoring solution.

From an NFSen perspective, here are the steps I used on a Debian Bullseye installation:

apt install wget less vim
apt install php rrdtool  librrd-dev librrds-perl php-rrd
apt install libmailtools-perl
apt install libsocket6-perl
apt install git
cd /usr/src
git clone https://github.com/p-alik/nfsen.git
cd nfsen
cp etc/nfsen-dist.conf etc/nfsen.conf
vim etc/nfsen.conf
./install.pl ./etc/nfsen.conf
/usr/local/bin/nfsen start
diff nfsen-dist.conf nfsen.conf

These are the changes to the nfsen.conf file: Continue reading "Netflow with NFDUMP, NFSEN and Open vSwitch and..." »

From a networking list serve:

Question:

Can anyone suggest tools, techniques and helpful contacts for backtracking spoofed packets? At the moment someone is forging TCP syns from my address block. I'm getting the syn/ack and icmp unreachable backscatter. Enough that my service provider briefly classified it a DDOS. I'd love to find the culprit.

Response:

It's not complete, but if you're receiving the ICMP net/port unreachable backscatter it should include a portion of the original packet. This might provide some insight into the TTL left on TCP the packet when it reached its destination which could provide a rough radius that you would need to look at. Also, if the TTL is constant it would support the idea that one or few hosts are spoofing your address block, but if the TTL varies widely it might indicate that many bots are spoofing your address block.

You might check looking glass tools or something like https://radar.qrator.net to see if someone is not only spoofing your address range, but has gone farther and has hijacked it.

Quite some ago, there was a discussion around [ovs-dev] Creating a libopenvswitch-dev package, back in 2016. Since then libraries have been updated for C++ inclusion, plus other improvements.

From somewhere, I don't have the reference, maybe my own blog, but since I have this in a note on my desktop, I'll include it here:

• Build a string formatted as the “ovs-ofctl” command would do, for example “table=1,cookie=0xdeadbeef,in_port=1,actions=resubmit(,2)”
• Pass this to parser_ofp_flow_mod_str(). The parser will magically parse the string in to a rich struct.
• Pass the struct to ofputil_encode_flow_mod(). This returns a struct with a serialized OpenFlow message buffer.
• Send this buffer on the wire either via a socket you manage yourself or let OpenVswitch do it for you.

• OpenWebRX -for listening to On-Line SDRs using a web browser. It is a web based server and interface for remotely accessing RTL-SDRs and SDRPlay's. Another link: Open Source SDR Web App for Everyone
• NYC Mesh - community-owned network for fast, affordable and fair access to the Internet - Most of the devices we use, such as a LiteBeam or NanoStation, are self-contained so they have an antenna, radio and ethernet router all in one.

To build a wpa_supplicant configuration file:

# wpa_passphrase testap >> /etc/wpa_supplicant/testap.conf
  a_password
# cat /etc/wpa_supplicant/testap.conf
  # reading passphrase from stdin
  network={
          ssid="testap"
          #psk="a_password"
          psk=1b97a5c02076ac80739263fb33db49c7c50d3199202872e06097e7baf305f35e
  }

Additional info at How to connect to a WPA/WPA2 WiFi network using Linux command line.

From a mailing list:

One way to avoid knowing or typing the specific LL address is to ping the all-nodes link scoped multicast address, and looking for the address you're after in the response.

E.g. under Linux, the following command will show all IPv6 link local addresses on the link (assuming they reply to an ICMPv6 echo request) that respond within 1 second:

# ping -w 1 -I wlp6s0 ff02::1
ping6: Warning: source address might be selected on device other than wlp6s0.
PING ff02::1(ff02::1) from :: wlp6s0: 56 data bytes
64 bytes from fe80::e54:15ff:fe66:3b9a%wlp6s0: icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from fe80::aca7:4aff:fed2:a7dd%wlp6s0: icmp_seq=1 ttl=64 time=3.47 ms (DUP!)
64 bytes from fe80::400:55ff:fe40:5%wlp6s0: icmp_seq=1 ttl=64 time=3.51 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:6709%wlp6s0: icmp_seq=1 ttl=64 time=216 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:66ff%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::fe90:d8d2:7ec5:3c8%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::a65d:36ff:fe40:e31c%wlp6s0: icmp_seq=1 ttl=64 time=250 ms (DUP!)

--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +6 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.074/130.707/249.971/111.633 ms

Comment:

Can you write the code which tells you when you have the no IPv4 “thing” without trying the IPv4 thing on a network which by definition should not have the IPv4 thing where you want people not to try the IPv4 thing?

Response:

We've been here before - I don't think there is any way to write an algorithm that can differentiate between "I can see IPv4 chatter and I should join in because this network is completely IPv6 only yet" and "I can see IPv4 chatter and I shouldn't join in because this network is supposed to be IPv6 only but some other nodes don't understand that". If a key part of the algorithm is "there aren't other IPv4 nodes chattering" then you only need one device on the network to prevent everything else shutting down IPv4.

Because ovsdb is a generic database tool, some one may have build other schemas. But for a native open vswitch install, this is the default state:

# ovsdb-client list-dbs
Open_vSwitch
_Server

It is possible to add a tcp connection to gain access to the database:

# ovs-appctl -t ovsdb-server ovsdb-server/add-remote ptcp:6640
# netstat -antp |grep ovs
tcp        0      0 0.0.0.0:6640            0.0.0.0:*               LISTEN      746/ovsdb-server
tcp        0      0 127.0.0.1:57424         127.0.0.1:6633          ESTABLISHED 397/ovs-vswitchd

But on linux, there is an existing linux stream available:

# lsof|grep ovsdb|grep STREAM
ovsdb-ser   746                   root    5u     unix 0x000000001740f722        0t0   59425581 /var/run/openvswitch/db.sock type=STREAM
ovsdb-ser   746                   root   16u     unix 0x0000000021edd23e        0t0      12914 /var/run/openvswitch/db.sock type=STREAM
ovsdb-ser   746                   root   19u     unix 0x000000001b392a81        0t0      20287 /var/run/openvswitch/ovsdb-server.746.ctl type=STREAM

# ovs-vsctl list open_vswitch
_uuid               : 8cfeb1c0-34ca-4f91-a162-7e9aef141344
bridges             : [e65f5e97-36ec-45e3-b83e-64129dae61d3]
cur_cfg             : 65
datapath_types      : [netdev, system]
db_version          : "7.16.1"
dpdk_initialized    : false
dpdk_version        : none
external_ids        : {hostname="nuc8i7hvk01.burkholder.net", rundir="/var/run/openvswitch", system-id="02700cd5-96f5-4b4e-90b4-5e67fe06abf7"}
iface_types         : [erspan, geneve, gre, internal, "ip6erspan", "ip6gre", lisp, patch, stt, system, tap, vxlan]
manager_options     : []
next_cfg            : 65
other_config        : {}
ovs_version         : "2.10.1"
ssl                 : []
statistics          : {}
system_type         : debian
system_version      : []

# ovs-appctl dpif/show
system@ovs-system: hit:50661581 missed:207452
  ovsbr0:
    eno1 5/3: (system)
    enp5s0 2/1: (system)
    ovsbr0 65534/2: (internal)
    veth-nvpn-v90 6/6: (system)
    vlan110 4/5: (internal)
    vlan90 3/4: (internal)

# ovs-appctl dpctl/show -s
system@ovs-system:
  lookups: hit:50661616 missed:207458 lost:0
  flows: 6
  masks: hit:211426886 total:10 hit/pkt:4.16
  port 0: ovs-system (internal)
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1428 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:0  TX bytes:177489 (173.3 KiB)
  port 1: enp5s0
    RX packets:19439356 errors:0 dropped:0 overruns:0 frame:0
    TX packets:30374161 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:10608677166 (9.9 GiB)  TX bytes:29950322693 (27.9 GiB)
  port 2: ovsbr0 (internal)
    RX packets:333032 errors:0 dropped:29829 overruns:0 frame:0
    TX packets:1428 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:23060625 (22.0 MiB)  TX bytes:177489 (173.3 KiB)
  port 3: eno1
    RX packets:6037565 errors:0 dropped:0 overruns:0 frame:0
    TX packets:5719808 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:4726094728 (4.4 GiB)  TX bytes:3277870100 (3.1 GiB)
  port 4: vlan90 (internal)
    RX packets:0 errors:0 dropped:274558 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:0  TX bytes:0
  port 5: vlan110 (internal)
    RX packets:0 errors:0 dropped:274101 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:0  TX bytes:0
  port 6: veth-nvpn-v90
    RX packets:5000388 errors:0 dropped:0 overruns:0 frame:0
    TX packets:5788139 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:3055006377 (2.8 GiB)  TX bytes:4647166781 (4.3 GiB)

IPv6 Transition and Coexistence IPv6 - only and IPv4 as - a - Service

You can use Jool for both 464XLAT and just NAT64.

Question:

Thanks... that is what I don't understand: Why is NAT64 such a difficult concept to put into routers and firewalls? We already do NAT with IPv4 just fine.

I feel like IPv6 adoption would be much faster if there was a transition mechanism other than dual stacking.

Think: Corporate offices. Rather than renumbering everything inside, they just turn on NAT64 and now they can begin a slow and controlled transition.

Answer:

This document, which is already in the IESG review, may answer your question: draft-ietf-v6ops-transition-ipv4aas

Also take a look into this one: draft-ietf-v6ops-nat64-deployment.

Remember that if your enterprise network has apps that use literals, or they don't support IPv6, you still need dual-stack in the LANs, but access IPv6-only is just fine.

Other comments:

It’s not s difficult concept but you need to remember NAT44 breaks stuff and NAT64/NAT46 breaks more stuff.

Dual stacking is SIMPLE. REALLY. Turn on IPv6 with the M bit set and configure the DHCPv6 server. If you don’t need that level of control of address assignments leave the M bit off. 99.99% of your machines will just add a second address to the interface without you having to do anything more.

Getting to IPv6 resources from IPv4 address is a *much* harder problem that getting to IPv4 resources from IPv6 which is what you are describing here with the “no renumber everything as they already have a IPv4 address” requirement. NAT64 allows IPv6 devices to get to legacy IPv4 servers. To allow IPv4 devices to get to IPv6 servers you need to map the IPv6 addresses you want to talk to in to a pool of IPv4 addresses and push that mapping to a NAT46 (not NAT64) device.

Go dual stack then, once IPv6 is stable, turn off IPv4 if you want to be single stacked. You are then no longer dependent on the services you want want to access continuing to be offered over IPv4. 464XLAT will only work as a stop gap for IPv4 clients while services are offered over IPv4. After ~20 years of IPv6 being available (Windows XP had IPv6 support and it was not the first major OS to have it) just turn on IPv6.

Some ideas from a mailing list:

quick and dirty:

jens@screen:~$ dig nanog.org @8.8.8.8 | grep "Query time"
;; Query time: 16 msec
jens@screen:~$ dig nanog.org @1.1.1.1 | grep "Query time"
;; Query time: 3 msec

Indeed. For instance, the delay depends wether the cache it hot or cold (measuring response time for an authoritative server is easier).

also could use ripe atlas ...

Which embeds clients for ICMP Echo, DNS, NTP, TLS, arbitrary TCP (with some hacks), and, with serious limitations, HTTP.

use dig -u to get microsecond resolution, e.g.

$ dig -u @131.111.8.42 nanog.org | grep time:
;; Query time: 611 usec

I recommend that eyeball networks don't run any external recursive server for optimal CDN performance. Yes, some CDNs support other methods, but not all. If not all do, then the requirement remains. See On Firefox Moving DNS to a Third Party

freeware GRC tool for benchmarking DNS performance

• PacketLife's Armory - encryption, exploitation, intrusion detection, forensics, vulnerability scanning, system monitoring, packet crafting, spoofing, ...
• IpCisco's Network Tools - packet analyzers, security audit, simulators, intrusion detection, ...
• packages found in Debian Linux for generating packets and sending, useful for testing openflow controllers: packeth, ostinato, netexpect, tgn (simpler netexpect), sendip, 4g8 (l2 interception)

• Telegeography.com
• Hurricane Electric
• Cablemap
• Submarine Cable Map