Randy's Work Blog

Victor-Alexandru Padurean, Oliver Gasser, Randy Bush, Anja Feldmann SRv6: Is There Anybody Out There?. 7th International Workshop on Traffic Measurements for Cybersecurity (WTMC June 2022).

Segment routing is a modern form of source- based routing, i.e., a routing technique where all or part of the routing decision is predetermined by the source or a hop on the path. Since initial standardization efforts in 2013, segment routing seems to have garnered substantial industry and operator support. Especially segment routing over IPv6 (SRv6) is advertised as having several advantages for easy deployment and flexibility in operations in networks. Many people, however, argue that the deployment of segment routing and SRv6 in particular poses a significant security threat if not done with the utmost care.

In this paper we conduct a first empirical analysis of SRv6 deployment in the Internet. First, we analyze SRv6 behavior in an emulation environment and find that different SRv6 implementations have the potential to leak information to the outside. Second, we search for signs of SRv6 deploy- ment in publicly available route collector data, but could not find any traces. Third, we run large-scale traceroute campaigns to investigate possible SRv6 deployments. In this first empirical study on SRv6 we were unable to find traces of SRv6 deployment even for companies that claim to have it deployed in their networks.

Philipp Richter, Mark Allman, Randy Bush, Vern Paxson. A Primer on IPv4 Scarcity, ACM SIGCOMM Computer Communication Review April 2015. Invited paper at SIGCOMM 2015. Not peer reviewed.

With the ongoing exhaustion of free address pools at the registries serving the global demand for IPv4 address space, scarcity has become reality. Networks in need of address space can no longer get more address allocations from their respective registries.

In this work we frame the fundamentals of the IPv4 address exhaustion phenomena and connected issues. We elaborate on how the current ecosystem of IPv4 address space has evolved since the standardization of IPv4, leading to the rather complex and opaque scenario we face today. We outline the evolution in address space management as well as address space use patterns, identifying key factors of the scarcity issues. We characterize the possible solution space to overcome these issues and open the perspective of address blocks as virtual resources, which involves issues such as differentiation between address blocks, the need for resource certification, and issues arising when transferring address space between networks.

Nejc Skoberne, Olaf Maennel, Iain Phillips, Randy Bush, Jan Zorz, and Mojca Ciglaric, IPv4 Address Sharing Mechanism Classification and Tradeoff Analysis, IEEE/ACM Transactions On Networking April 2014.

The growth of the Internet has made IPv4 addresses a scarce resource. Due to slow IPv6 deployment, IANA-level IPv4 address exhaustion was reached before the world could transition to an IPv6-only Internet. The continuing need for IPv4 reachability will only be supported by IPv4 address sharing. This paper reviews ISP-level address sharing mechanisms, which allow Internet service providers to connect multiple customers who share a single IPv4 address. Some mechanisms come with severe and un- predicted consequences, and all of them come with tradeoffs. We propose a novel classification, which we apply to existing mechanisms such as NAT444 and DS-Lite and proposals such as 4rd, MAP, etc. Our tradeoff analysis reveals insights into many problems including: abuse attribution, performance degradation, ad- dress and port usage efficiency, direct inter-customer communication, and availability.

The first problem was a pre-release kernel. I used LuCI, the web interface, to flash openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin, and needed to be patient with 15 minutes of twirly. The flash lost my ssl package, so I also had to

opkg install uhttpd-mod-tls

Thanks for Chris Adams for all clue, and John Brzozowski for diagnostics and support, I loaded the necessary packages

opkg install ip6tables radvd wide-dhcpv6-client ip

Then I hacked /etc/config/dhcp6c

config 'dhcp6c' 'basic'
        option 'enabled' '1'                            # 1 = enabled; 0 = disabled
        option 'interface' 'wan'                        # This is the interface the DHCPv6 client will run on
        option 'dns' 'dnsmasq'                          # Which DNS server you run (only dnsmasq currently supported)
        option 'debug' '0'                              # 1 = enable debugging; 0 = disable debugging

        # Send options (1 = send; 0 = do not send)
        option 'pd' '1'                                 # Prefix Delegation
        option 'na' '1'                                 # Non-Temporary Address
        option 'rapid_commit' '1'                       # Rapid Commit

        # Request options (1 = request; 0 = do not request)
        option 'domain_name_servers' '1'
        option 'domain_name' '0'
        option 'ntp_servers' '0'
        option 'sip_server_address' '0'
        option 'sip_server_domain_name' '0'
        option 'nis_server_address' '0'
        option 'nis_domain_name' '0'
        option 'nisp_server_address' '0'
        option 'nisp_domain_name' '0'
        option 'bcmcs_server_address' '0'
        option 'bcmcs_server_domain_name' '0'

        # Override the used DUID, by default it is derived from the interface MAC
        # The given value must be uppercase and globally unique!
        #option 'duid' '00:03:00:06:D8:5D:4C:A5:03:F2'

        # Script to run when a reply is received
        option 'script' '/usr/bin/dhcp6c-state'

# Define one or more interfaces on which prefixes should be assigned
config 'interface' 'loopback'
        option 'enabled' '0'                            # 1 = enabled; 0 = disabled
        option 'sla_id' '1'                             # Site level aggregator identifier specified in decimal (subnet)
        option 'sla_len' '0'                            # Site level aggregator length (64 - size of prefix being delegated)
                                                        # e.g. /60 from ISP -> 64 - 60 = 4
config 'interface' 'lan'
        option 'enabled' '1'
        option 'sla_id' '1'
        option 'sla_len' '0'

Then /etc/init.d/dhcp6c start and see what you get. You should have an RA-assigned IP on your wan interface and a PD-assigned /64 on the LAN. If you configure radvd (just set it with no prefix listed), dhcp6c will automatically re-configure it to give out addresses from the /64.

Now get Router Advertisement working, hack /etc/config/radvd to

config interface
        option interface        lan
        option AdvSendAdvert    1
        option AdvManagedFlag   0
        option AdvOtherConfigFlag 0
        option ignore           0

config prefix
        option interface        lan
        # If not specified, a non-link-local prefix of the interface is used
        list prefix             ''
        option AdvOnLink        1
        option AdvAutonomous    1
        option AdvRouterAddr    0
        option ignore           0

config rdnss
        option interface        lan
        # If not specified, the link-local address of the interface is used
        list addr               ''
        option ignore           0

config dnssl
        option interface        lan
        list suffix             rg.net
        option ignore           0

Then
/etc/init.d/radvd start
/etc/init.d/dhcp6c start

At this point, we had the /128 on our WAN interface, and the /64 on the LAN interface. But, from the OpenWRT, we could not ping an external IPv6 address. Hours were spent chasing various ghosts, when we found the fix,

sysctl -w net.ipv6.conf.eth1.accept_ra=2

From a hint in New Zealand, accept_ra=1 means “only accept RAs if forwarding is disabled”. Turns out to be documented in the 3.12.4 kernel source clue pages. Once you have forwarding enabled, you have to have accept_ra=2 to override that.

:~# ping6 psg.com
PING psg.com (2001:418:1::62): 56 data bytes
64 bytes from 2001:418:1::62: seq=2 ttl=52 time=70.286 ms
64 bytes from 2001:418:1::62: seq=3 ttl=52 time=70.090 ms
64 bytes from 2001:418:1::62: seq=4 ttl=52 time=71.169 ms
64 bytes from 2001:418:1::62: seq=5 ttl=52 time=77.020 ms


With the generous help of Sato san, I managed to get IPv6 back working on my Tokyo home Soekris gateway to IIJ.

This is the simple view, pretty much focused on IPv4

               .-------------------------.
               |                         |
               |                b --wlan0|
               |                r        | 192.168.0.0/24
    WAN IIJ    |                i --- vr1| LAN hosts,
    PPP/NAT ---|vr0[PPPoE]tun0--d        | DHCP Clients
210.138.216.50 |                g --- vr2| ...
               |                e        |
               |                0 --- vr3|
               |                         |
               `-------------------------'

Here is the /etc/rc.conf

# User ppp configuration.
ppp_enable=YES
ppp_mode=dedicated
ppp_profile=iij

# IPv4 internal LAN
wlans_ath0=wlan0
create_args_wlan0="wlanmode ap mode 11g channel 11 up"
cloned_interfaces=bridge0
ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 up"
ifconfig_vr1=up
ifconfig_vr2=up
ifconfig_vr3=up

gateway_enable=YES
hostapd_enable=YES # Run hostap daemon.

# IPv6 internal LAN
ifconfig_bridge0_ipv6="inet6 fe80::0452:fdff:fe5d:b500/64"
ifconfig_bridge0_alias0="inet6 2001:240:6a8::1/64"

# IPv6 options
ipv6_activate_all_interfaces=YES
ipv6_gateway_enable=YES
route6d_enable=YES
route6d_flags="-A 2001:240:6a8::/48,gif0 -O 2001:240:6a8::/48,gif0"
rtsold_enable=YES
rtadvd_enable=YES
rtadvd_interfaces="vr0 bridge0"
gif_interfaces=gif0
gifconfig_gif0="210.138.216.50 210.138.77.245"
ipv6_static_routes=gif
ipv6_route_gif="default -interface gif0"

and the /etc/ppp/ppp.conf

default:
set log Phase Chat LCP IPCP CCP tun command
ident user-ppp VERSION (built 2008.04.01)
disable ipv6cp

iij:
set device PPPoE:vr0
set MRU 1454 # NTT suggests this value
set MTU 1454
accept CHAP
enable lqr
add default HISADDR
nat enable yes
set authname <user>@bnf1.iij.ad.jp
set authkey <password>

At the 6th Slovene IPv6 Summit, I did the lead preso to a panel with Mark Townsley and Dan Wing on translation vs. encapsulation where I managed a serious anti-CGN rant. See my presentation.

After a lot of pissing and moaning, A+P was finally published as RFC 6346. It only took five years from when I first presented it.

All due to the hard work of Gabor Bajko, Mohamed Boucadair, Steven M. Bellovin, Luca Cittadini, Olaf Maennel, Reinaldo Penno, Teemu Savolainen, and especially Jan Zorz.

Kohno-san’s draft finally made it through the sausage machine!

RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links. M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. April 2011.

At the IETF IPv6/IPv4 coexistence interim meeting in Montréal, I gave a presentation of the A+P proposal.

APNIC 26 attempted to focus on IPv6. It was a major disaster from Layer 2 to Layer 9. The network failed both at Layer 2 in the 802.11 and, for the few who managed to connect for a few minutes, applications at Layer 7 which should have worked did not. And, despite demonstrating on Tuesday that the IPv6 network did not work, APNIC staff persisted in turning the IPv4 network off on Wednesday. And they were proud of it. All in all, it was an impressive demonstration of non-professionalism and operational lack of clue.

And the panel held Tuesday morning was a complete train wreck. People walked away saying they were going home and telling folk that their companies should wait some years for IPv6 and consider just NATting IPv4.

APNIC has set a high bar that future IPv6 train wrecks will find hard to beat.