What Is Wrong with the Ipv6 RA Protocol ? – Some Analysis and Proposed Solutions –

What is wrong with the IPv6 RA protocol ? – Some analysis and proposed solutions –

Manuel Grob, Erwin Hoﬀmann

FH Frankfurt am Main April 2012

Abstract

Within IPv6 Stateless Address Autoconﬁguration (SLAAC) the Router Advertisement Pro- tocol plays an important rôle to provide the Preﬁx and the Default Gateway. We investigate the current state of the standard, the implementation on some OS and routers, investigate it’s weaknesses and discuss possible solutions.

1 The Router Advertisement 1. Message container [fig.1] Protocol as part of ICMPv6 ICMPv6 type 133 defines the Router So- licitation and the Unlike ICMP for IPv4, ICMPv6 [11] is an in- type 134 the Router Advertisement mes- dispensable part of the IPv6 protocol family. sage. ICMPv6 provides core functionalities for IPv6: 2. Mechanism Stateless Address Autoconfiguration Router Solicitation RS requested from a SLAAC [15] by means of the mecha- host for Prefix Discovery and answered nisms Neighbor Discovery and Router by a (solicited) Router Advertisement Advertisement. RA by a router and the Duplicate Address Detection DAD using Unsolicited Router Advertisement URA Neighbor Discovery. (periodically) send by router in the link Neighbor Unreachable Detection NUD, segment. again based on Neighbor Discovery. Routing Support. a ) b ) 18 1 6 2 4 3 2 1 8 1 6 2 4 3 2 Type=133 Code = 0 Checksum Type=134 Code = 0 Checksum These mechanisms are described within R e s e r v e d CHL M O R e s . R outer Lifetim e O ptions ... Reachable Tim e R etrans Tim er RFC 4861 [12] as part of IPv6 Neighbor Dis- O ptions ... covery. Here – and in the forthcoming discus- sion – we need to understand the dual rôle of Figure 1: Structure of a) Router Solicitation, ICMPv6 usage of Router Solicitation/Adver- b) Router Advertisement messages; CHL=Current tisements implementation used for Prefix and Hop Limit, M=Managed, O=Others flag Router discovery:

1 1.1 Options in RA messages 1.2 Prefix Discovery using Router Solicitations RA message include default information: In case a host is newly attached to a link seg- The Cur hop limit (CHL), typically set ment or after the interface has been restarted, to 64. a Router Solicitation RS message is sent from The Router lifetime – in case 0 is set, the that interface using the ICMPv6 message type router identifies itself to be a none-Default 133 as multicast to the All-Router group Gateway. ff02::2 while providing it’s link-local unicast The Reachable time, and the (LLU) address fe80::X as source [fig.2]. Retransmission timer; both may be 0. This procedure is part of the Neighbor Dis- covery ND. In order to support a quick Neigh- The additional Options carried out in the bor Discovery and to set up the Neighbor RA message depend on the mechanism: Cache immediately, in the Option field the MAC address of the sender is included in the Source Link-Layer Address (type 1) is the most usual option and typically is set RS message. in any RA (and RS) message. Prefix Discovery employs option of type L i n k 3 IPv6-A ddr = fe80::0a00:21ff:fe48:d461 R M A C-A ddr = 08-00-21-48-d4-61 3. In addition to the Prefix and the Prefix L ink 1 (E thernet) Length the lifetime of these parameters can R L i n k 2 be provided. Furthermore, the flag L de- 1

fines whether the prefix is (locally) available I P v 6 { S o u r c e -IP-A ddr = fe80::a00:21ff:fe48:d461, Target-IP-A ddr = ff02::1, on the segment, the flag A tells the host R A [..., R eachable T im e, R etrans T im er, 1 O p t i o n (Type=1, Source Link-Layer A ddr = 08-00-21-48-d4-61 ), to use Stateless Address Autoconfiguration O p t i o n (T ype=3, Link-Prefix), O p t i o n (Type=5, M TU Size)]} with this prefix, whereas M is managed flag, URA : U nsolicited R outer A dvertisem ent perhaps followed by the O (other) flag. Figure 2: Prefix Discovery by means of Router So- Routing (type 24) informs the host to send licitations any packets for this destination via this router. In order to allow load-balancing, a router may include a hint about the priority Though RFC 4861 [12] requires a particu- and route lifetime. lar validation of the received Router Adver- Since IPv6 requires packet fragmentation at tisement message (6.6.1) at the node, it is not the sending host the maximum packet size entirely clear how the advertising router en- can be announced by means of the MTU (type capsulated the RA message in the IPv6 packet 5) option. targeting the (potential) recipients. It states Recursive DNS Server (type 25) allows in section [12] 6.2.6: the router to include the IPv6 addresses of DNS forwarders. This option is often disre- "In addition to sending periodic, garded at the host. unsolicited advertisements, a router sends advertisements in response to The options potentially provided in RA valid solicitations received on an ad- messages can be used to set up an IPv6 net- vertising interface. A router MAY work almost entirely and relaxes the need for choose to unicast the response di- DHCPv6. rectly to the soliciting host’s address

2 (if the solicitation’s source address 2 The Operating System’s is not the unspeciﬁed address), but view on RA the usual case is to multicast the response to the all-nodes group." For any (none-router) hosts the following un- favourable situation is encountered:

This situation can be depict from [fig.3] Employing RA messages targeting the where one router employs an All-Node multi- All-Nodes ff02::1 (upon solicitation) ad- cast in response to a Router Solicitation while dress is indistinguishable from a Unsolicited the other has chosen to use the host’s LLU Router Advertisement since no ’address cor- destination address in the IPv6 packet. relation’ is possible at the node side. Even worse, according to [12] section 6.2.6, the router is required to delay the ad- 1.3 Unsolicited Router Advertise- vertisement "within the range 0 through ments MAX_RA_DELAY_TIME". Thus, no In an IPv6 network the router attached to ’time correlation’ of the messages can be ac- the local segment might not to be ’silent’ but complished. rather multicast their configuration to all at- On the other hand, a host need to be pre- tached nodes. Since several router might exist pared to receive and process different in- in a network, they may send independent Un- formation (i.e. Link Prefixes) from differ- solicited Router Advertisement URA to the ent routers unless the implementation of the hosts. IPv6 stack picks up the option and "MAY The RA protocols requires to send chose not to store of the router addresses URA messages not strictly periodical, discovered via advertisements" ([12] section but rather randomly chosen between the 6.3.4). configured values MinRtrAdvInterval and In case of contradictory information "the MaxRtrAdvInterval. The advertising router most recently information is considered au- needs to care about it’s sending period in thoritative" ([12] section 6.3.4). terms of a state engine. In practice the IPv6 host – being targeted The following situations impact sending of by (multicast) Router Advertisements – has URA messages: little control upon the received information. We investigate now the workaround and so- The router or it’s interface becomes ac- lutions of the major operating systems. Unlike tive or a new configuration is to be pro- IPv4 – being based on the initial BSD socket cessed. Now the router sends up to interface – IPv6 has three independent imple- MAX_INITIAL_RTR_ADVERTISEMENTS. mentations: The router receives an Router Solicitation 1. The outcome of the WIDE/KAME [8, 18] from an host on the segment, triggering the project, which is the foundation of *BSD sending of a Router Advertisement. OS and MacOS X IPv6. The router is going to be de-actived. In this 2. The Linux IPv6 implementation [13]. case, a final Router Advertisement is multi- 3. The IPv6 interface available for the Win- casted announcing a Router lifetime of 0. dows operating systems [9].

3 IPv6-A ddr = fe80::21e:90ff:fead:5e08 M A C-A ddr = 00-1e-90-ad-5e-08 IPv6-A ddr = fe80::a00:21ff:fe48:d461 IPv6-A ddr: X M A C-A ddr = 08-00-21-48-d4-61 R 2 M AC-Addr: a L i n k 1 R 1 L i n k 2

1 2 1 R outer Solicitation 3 2 3 R outer A dvertisem ent LL All-Router I P v 6 {Source-IPv6-A ddr = X , Target-IPv6-A ddr = ff02::2, M u l t i c a s t 1 R S [ . . . , O p t i o n (Type=1, Source Link-Layer A ddr = a)]}

LL All-N ode I P v 6 { S o u r c e -IP-A ddr = fe80::a00:21ff:fe48:d461, Target-IP-A ddr = ff02::1, M u l t i c a s t R A [..., R eachable T im e, R etrans T im er, 2 O p t i o n (Type=1, Source Link-Layer A ddr = 08-00-21-48-d4-61 ), O p t i o n (T ype=3, Link-Prefix), O p t i o n (Type=5, M TU Size)]} L L I P v 6 { Source-IPv6-A ddr = fe80::21e:90ff:fead:fe08, Target -IPv6-A ddr = X , U n i c a s t R A [ . . . , R eachable Tim e, R etrans Tim er, 3 O p t i o n (Type=1, Source Link-Layer A ddr = 00-1e-90-ad-5e-08 ), O p t i o n (T ype=3, L ink-Prefix), O p t i o n (Type=5, M TU Size)]}

RS : R outer Solicitation RA : R outer A dvertisem ent

Figure 3: Multiple Router Advertisements on a link segment

2.1 Linux sysctl kernel configurations. Linux accepts by construction RA messages and acts upon In order to configure the IPv6 settings on a those accordingly. Linux host, one may apply the following settings: Linux provides the following settings [lis.1]: The standard ifconfig command. net.ipv6.conf.all. accept_ra_defrtr=1 net.ipv6.conf.all. accept_ra_pinfo=1 The Linux-specific ip command. net.ipv6.conf.default. accept_ra_defrtr=1 net.ipv6.conf.default. accept_ra_pinfo=1 The kernel configuration command sysctl. net.ipv6.conf.lo. accept_ra_defrtr=1 The /proc file system, in particular net.ipv6.conf.lo. accept_ra_pinfo=1 net.ipv6.conf.eth0. accept_ra_defrtr=1 /proc/sys/net/ipv6/. net.ipv6.conf.eth0. accept_ra_pinfo=1 net.ipv6.conf.sit0. accept_ra_defrtr=1 The Linux kernel imposes a silent con- net.ipv6.conf.sit0. accept_ra_pinfo=1 currency limit on the received RA informa- Listing 1: Linux sysctl default settings tion. Only a limited number of Prefixes are accepted. The RA option DNS Recursive We realize that the RA options Prefix and Resolvers however is ignored. Routing can be fine-tuned specifically. It is Neither the ifconfig nor the ip command remarkable, that the ’all’ and ’default’ param- can be used to configure the processing of ND eter settings have no influence on a specific or RA messages; rather this is subject of the interface. Further, it is doubtful to include

4 specific settings for the loopback interface Actually, FreeBSD offers two interfaces to and other virtual interfaces as well. Thus to tailor the IPv6 settings: disable the acceptance of any new IPv6 prefix on the Ethernet eth0 interface, one has to set: The ifconfig command. Unlike it’s Linux pendant layer 2 (MAC) and layer 3 (in par- sysctl net.ipv6.conf.eth0.accept_ra_pinfo=0 ticular IP) settings can be customized. The sysctl kernel configuration. Of course, this might be configured persis- FreeBSD sysctl kernel interface provides a tently within /etc/sysctl.conf. Linux allows in addition to set IPv6 vari- few setting only. Here we have two ’knobs’ to be effective [5]: ables in the /proc filesystem. Since the Linux developers [4] are very creative, they have ex- sysctl net.inet6.ip6.accept_rtadv=0|1 tended the understanding of the variable type sysctl net.inet6.ip6.forwarding=0|1 BOOLEAN ... /proc/sys/net/ipv6/ and posses the following meaning: ¡ accept_ra BOOLEAN accept_rtadv forwarding role of the node Accept Router Advertisements; 0 0 host (to be manually con- autoconfigure using them. figured) 0 1 router Possible values are: 1 0 autoconfigured host (spec 0 Do not accept Router Advertisements. assumes that host has sin- 1 Accept Router Advertisements gle interface only, autocon- i f forwarding is disabled. figured host with multiple 2 Overrule forwarding behaviour. interface is out-of-scope) Accept Router Advertisements 1 1 invalid, or experimental even i f forwarding is enabled. (out-of-scope of spec) Functional default: enabled if local forwarding is disabled. Table 1: FreeBSD sysctl setting for RA messages disabled if local forwarding is enabled. However, ifconfig allows an enhanced han- Listing 2: Linux RA setting according to [4] dling of RA messages per interface [lis.3]: Depending on the distribution, prefix and accept_rtadv router might be disabled including Set a flag to enable accepting IPV6_AUTOCONF=no ICMPv6 Router Advertisement messages. into /etc/sysconfig/network, which will ¡accept_rtadv work for Red Hat and CentOS 5 Linux. Clear a f l a g accept_rtadv. Listing 3: FreeBSD RA settings by means of if- 2.2 FreeBSD config

IPv6 support in FreeBSD is based on the Initially, FreeBSD is set up NOT to sup- KAME development [8] and was available al- port IPv6 and need to be conﬁgured explicitly ready very early – since FreeBSD 4.x. Prob- within /etc/rc.conf. The following scenar- ably, all other *BSD systems, like NetBSD, ios are possible: OpenBSD, and Dragonﬂy use the same implementation. Since FreeBSD 4.x some im- Global support for IPv6 and acceptance of provements have been included in the current RA messages: FreeBSD (8.2 and 9.0). ipv6_enable="YES".

5 Qualified support for IPv6 with SLAAC 2.4 Windows configured per interface: ifconfig_IF_ipv6="inet6 Starting with Windows XP, Microsoft offers accept_rtadv"; IPv6 support [9] – and with Windows Vista here ’IF’ denotes the name of the interface. this is the preferred protocol enabled by default – using SLAAC and IPv6 privacy ad- Restricted global support for IPv6 disabling dress extension as well. Unlike IPv4 – which RA on a particular interface: uses to a large extend the BSD socket inter- ipv6_enable="YES" face – Microsoft developed their own IPv6 im- ifconfig_IF_ipv6="inet6 plementation close to the emerged IPv6 stan- -accept_rtadv" dards. While for Linux the command ip exists, Thus, FreeBSD provides the same level of Windows makes the powerful netsh [10] tool control for RA message comparable to Linux. [lis.5] available; but lacks support for filtering FreeBSD restricts the amount of accepted and/or disabling RA messages in the WinXP IPv6 prefixes received by RA messages em- versions. ploying the limit PRLSTSIZE=10. netsh interface ipv6>show prefixpolicy Active status will be queried ...

2.3 MacOS X Predecessor Label Prefix ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ Apple’s MacOS X kernel is a fork of FreeBSD 5 5 2001::/32 10 4 ::ffff:0:0/96 4.1x particular customized and called Darwin 20 3 : : / 9 6 [1]. Thus, MacOS X supports IPv6 natively 30 2 2002::/16 40 1 : : / 0 originating from the KAME project as well. 50 0 : : 1 / 1 2 8 However, Apple did not include the en- hancements of FreeBSD but rather followed netsh interface ipv6>show siteprefixes their own philosophy, providing IPv6 support Prefix Valid until Interface ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ out-of-the-box. Customization is provided 2001:4dd0: ff00 ::/48 23h59m57s LAN connection by means of the System Preferences.app GUI and some kernel parameters available via the Listing 5: IPv6 prefix information derived from the sysctl [2] command [lis.4]: netsh command net.inet6.ip6 .kame_version: 20010528/apple¡darwin Starting with Windows Server 2008 and net.inet6.ip6. forwarding: 0 Windows vista, RA can be disabled my means net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 of the netsh per interface [16]: net.inet6.ip6. accept_rtadv: 0 netsh interface ipv6 set interface IFIDX routerdiscovery=disabled Listing 4: Some MacOS X IPv6 kernel parameters Here, IFIDX is the interface index. While in general autoconfiguration of the Together with Microsoft’s choice to accept IPv6 address can be disabled by the GUI, nei- any number of prefixes announced via RA ther the kernel, nor the ifconfig command al- messages until the entire memory is consumed, lows a specific setting how to react on RA makes Windows vulnerable for any kind of messages. ICMPv6 DoS attacks.

6 3 Routing Advertisement RADVD Settings Options Meaning AdvSendAdvert enables sending Router Ad- Daemons vertisements via the given interface MinRtrAdvInterval lower and upper limit for the Using a Unix system as a RA Router, to- interval an URA is sent day’s choice is the Router Advertisement Dae- MaxRtrAdvInterval AdvDefaultLifetime provide the number of sec- mon RADVD, which is the follower of onds a router should be kept the RTADV daemon (developed within the in a host’s default router list, WIDE [18] project), to be found rarely only. if not set to 0 AdvManagedFlag tells the recipients hosts to In the next section, we discuss the merits of use stateful address configu- RADVD version 1.8.5 [14]. ration in addition to SLAAC UnicastOnly hosts with IPv6 specifically included in the client option 3.1 The RADVD receive RA messages as unicast Upon activation, the RADVD tailors the clients list of IPv6 addresses for hosts to be services with RA *nix OS such the required IPv6 kernel settings unicasts are activated. prefix defines the prefix provided to the clients for generat- RADVD uses a per-interface configuration. ing (usually) a global scoped Thus, for every physical and virtual interface IPv6 address AdvOnLink tells the host this prefix can attached to a link segment an unique config- be used for on-link determi- uration can be defined, as can be seen in the nation following generic sample [lis.6]: AdvAutonomous permits the hosts to use SLAAC for IPv6 address set i n t e r f a c e eth0 { up AdvSendAdvert on; route route information for which MinRtrAdvInterval 3; the router is able to route MaxRtrAdvInterval 10; IPv6 traffic to. AdvRouteLifetime denotes the default lifetime p r e f i x 2001:db8:1:0::/64 { }; a route is valid AdvRoutePreference defines the preference for the route 2001::/64 { denoted route. Thus, multi- AdvRoutePreference high; ple router instances within a AdvRouteLifetime 3600; link segment can be set up }; to announce the same route with different preferences RDNSS 2001:db8::1 2001:db8::2 { }; RDNSS defines a list of DNS For- warders used for name reso- DNSSL branch.example.com example.com { }; lutions DNSSL informs the nodes about the c l i e n t s fe80::a:b:c:d fe80::1:2:3 { }; DNS Search List } Table 2: Some settings and options for Neighbor Listing 6: Sample of the file radvd.conf Discovery available within radvd.conf radvd.conf provides three levels of control [tab.2]:

1. The interfaces the RADVD services. It should be mentioned, that the current 2. RA settings to be configured for this inter- RADVD implementation supports RFC 5006 face. [6] and RFC 6106 [7] deploying the DNS search 3. Which additional options are advertised for suffix, though the man page does not reflect a particular setting. this.

7 3.2 Sending Unicast RA messages the link segment is required to follow a router which is advertising new prefix information Though the current implementation of the and to process the received information ac- RADVD supports in principal – according cordingly. to RFC 4861 section 6.2.6 – sending of uni- Current Microsoft Windows systems suf- cast RA messages, this mechanism is almost fer from not limiting the generated IPv6 ad- useless, since dresses triggered by router advertisements. As a result, it is possible to freeze such systems it requires to register the respective clients by simply send them a huge amount of router per IPv6 address, advertisements containing prefix information. and therefore does by construction not sup- Windows will try to handle all of them un- port IPv6 privacy extension, til resource exhaustion. To gain access to the does not allow a mixture of multicast and machine again a cold reboot is necessary. unicast RA messages. Route obfuscation: In fact, if this option is turned on – By the virtue of the RA protocol routers are but no IPv6 clients are explicitly included – able to define a route preference. This infor- RADVD does not respond to any Router So- mation is used to enable the possibility setting lications nor does it offer Unsolicited Router up multiple routers within a link segment and Advertisements, since they depend on multi- denoting their order to the nodes. casting. As with the prefix information, a node is not able to determine whether the announced 3.3 Abuse of Router Advertise- routing information is valid or not. ments According to that, an attacker can set up a fake router trying to announce itself as default The simplicity of setting up a IPv6 network gateway with the highest preference. As a re- with Router Advertisement Daemons has (of sult, the attacker is able to capture the entire course) disadvantages. IPv6 traffic routed outside the link segment. Prefix exhaustion: Router Advertisements cause hosts with en- The ’Hackers Choice’ 1 released a set of tools abled Prefix Discovery to generate new IPv6 [3] to investigate weaknesses in the current im- addresses based on the advertised Prefix plementations of the IPv6 protocol. A more and/or to update their routing table. This detailed presentation about the tools can be procedure is triggered by solicited or unso- found at 27C3’s website [17]. licited advertisement on the (local) link seg- Two of them cover the attacks listed above: ment. Any router advertisements – as we discussed – are addressed to the All-Nodes mul- flood_router6 is a tool to flood the link ticast address ff02::1. segment with router advertisements con- A recipient node is unable to distinguish taining prefix information. When started, whether the sender of RA message is a valid the resulting attack causes a DoS on af- router or not. Any malicious node can send fected systems. All current Windows sys- prefix information with (in)valid data to the tems are impacted. All-Nodes address and thereby undermining all attached nodes. In contrast, any node on 1http://thc.org/

8 fake_router6 sets up a router instance try- 4.1 Proposed corrections to RFC ing to announce itself as the default router 4861 within a link segment. RFC 4681 allows RA messages to be sent ei- ther as (Link Local) Since Router Advertisements are sent to the All-Node multicast address, all IPv6 enabled LL multicast – to the All-Node address systems within a link segment are potentially ff02::1 – or vulnerable for DoS or spoofing attacks of ma- LL unicast (’MAY’) to individual hosts. licious systems. Especially router advertisements containing We propose the following adjustments in the prefix information are able to cause a denial way a RADV router acts on Router Solicita- of service on systems not limiting the amount tions: of IPv6 addresses for the interface. 1. Router Advertisements sent upon a received Router Solicitation SHOULD be 4 Towards a common under- send to the soliciting host’s LLU address. 2. Router Advertisements following Router standing and safe imple- Solicitations SHOULD be send prompt – mentation of the RA proto- without delay – to the soliciting host. col 3. Router Advertisements sent upon Router Solicitations don’t impact the timing of pe- Router Advertisement messages target two dif- riodically send unsolicited advertisements. ferent nodes: 4.2 RA message handling at the interface 1. Router them-self: The standard (RFC 4861) provides an outline what any other Section 2 of your proposal discussed some router should do, receiving RA messages. means to drop Router Advertisements mes- 2. A standard host: Re-acting upon the re- sages typically at the host’s interface. In fact, ception of RA messages, once SLAAC is this disables to some extend SLAAC which is active. an undesired side effect. However, following our proposed solution this situation can be relaxed in the following The ICMPv6 RFCs provide some means to way assuming a flag accept_rtadv: shelter the RADV router from Router Solic- itations, but reversely usual hosts on the link accept_rtadv = 0: No processing of segment left unprotected against Router Ad- any Router Advertisements, thus SLAAC vertisements. is (partially) disabled (discarding any Unlike DHCP, where the client requests in- ICMPv6 type 134 messages). formation, now with ICMPv6 the RADV accept_rtadv = 1: Only Unicast Router router commands the hosts on the network Advertisements following a Router Solicita- and their IPv6 settings. We now propose some tion are accepted (discarding RA messages minor changes to the RA protocol to balance with IPv6 target address ff02::1 and in- this situation. cluding a type 3 option).

9 accept_rtadv = 2: Any Router Advertise- In order to achieve backward compatibility ments are processed. a new option MulticastRS shall be intro- duced. Due to our proposed changes, these functionalities can be easily realized by simple It should be investigated, whether the IPv6 address filters. In addition, a qualified client option really makes sense. If is op- handling of RA messages including a type tion is valid only for virtual interfaces (as can be picked up from the docs) more user- 3 option should include the following mechanisms: friendly settings should be considered. However, considering the default of unicasts 1. Upon sending a Router Solicitation for pre- in case of Router Solicitations it is question- fix discovery a state flag is set which is able, whether this mechanism is required at initialised to some value, typically four all. times the value of the (initial) Round Trip Timer RTT. Only Router Advertisements received within that period are accept; oth- 4.4 Recommendations for Switch ers – even targeting the node’s LLU – are vendors and Multicast filtering discarded. The proposed changes to the implementation 2. Per interface a upper limit for accepted of the ICMPv6 protocol will not be realised link prefixes shall be imposed and perhaps over night. However, there is the urgent de- may be configurable by a particular vari- mand to protect the (current existing) nodes able (accept_maxprefix = 12). against forged Router Advertisements. These changes to the current implementa- The vendors of intelligent switches could tions would greatly reduce the node’s risk to greatly improve this situation applying the fol- be subject of obfuscating Router Advertise- lowing logic: ments. In fact, one might argue, that including a particular token (challenge) in the One (or perhaps several) switch port(s) are Router Solicitation message could even im- dedicated to the RADVD router. prove this situation because this token must Rule 1: On those ports, ICMPv6 packets of be present in the received Router Advertise- type 134 (Router Advertisements) from the ments. However, since the Router Solicitation attached nodes targeting the All-Node LL is multicasted to the All-Router address, any addresses with the corresponding MAC des- potential attacker is able to pick up and to tination address 33-33-00-00-00-01 are process it accordingly. accepted and forwarded. Rule 2: For all other ports, drop any 4.3 Modifications to the RADVD ICMPv6 packets of type 134 with All- Node IPv6 destination address. In spite of the distinguished usage of unicast and multicast address for RA messages, Of course, this requires that the switch is we suggest the following changes to the able to filter Ethernet frames not only based RADVD: on MAC addresses but rather requires inves- The default behaviour answering Router So- tigating the IPv6 packet and even further the licitations should be changed, thus unicast ICMPv6 messages, which might be tricky in address are used instead. the presence of IPv6 header extensions.

10 5 Summary [7] J. Jeong, S. Park, L. Beloeil, and S. Man- danpalli. IPv6 Router Advertisement Options We investigated the current state of the for DNS Configuration. http://tools.ietf. ICMPv6 implementation available on contem- org/html/rfc6106, 2010. porary Operating Systems and the Router Ad- [8] KAME. The KAME project. http://www. vertising Daemon RADVD. kame.net/, 1998. We proposed a modification of RFC 4861 to balance the requirements of hosts and routers [9] Microsoft. IPv6. http://technet. microsoft.com/en-us/network/bb530961, regarding Router Solicitation/Router Adver- 2012. tisements. These modifications can be rel- atively easily incorporated into the existing [10] Microsoft. Using Netsh. http: IPv6 stack providing backward compatibility. //www.microsoft.com/resources/ documentation/windows/xp/all/ Further, the vendors of network compo- proddocs/en-us/netsh.mspx?mfr=true, nents, in particular intelligent switches may 2012. enhance their products to support the confine- ment of Router Advertisements traffic with re- [11] T. Narten, E. Normark, and W. Simp- spect to some dedicated ports. son. Neighbor Discovery for IP Ver- sion 6 (IPv6). http://www.ietf.org/rfc/ rfc2461.txt, 1998. References [12] T. Narten, E. Normark, W. Simpson, and H. Soliman. Neighbor Discovery for IP ver- [1] Apple. inet6(4) Mac OS X Manual Page. sion 6 (IPv6). http://www.ietf.org/rfc/ https://developer.apple.com/library/ rfc4861.txt, 2007. mac/#documentation/Darwin/Reference/ Manpages/man4/inet6.4.html#//apple_ [13] USAGI Project. Linux IPv6 Develop- ref/doc/man/4/inet6, 1999. ment Project. http://www.linux-ipv6. org/, 2006. [2] Apple. Disabling kernel IPv6 support? http://lists.apple.com/archives/ [14] Pekka Savola. Linux IPv6 Router Advertise- macos-x-server/2004/Jul/msg00013. ment Daemon (radvd). http://www.litech. html, 2004. org/radvd/, 2011.

[3] The Hacker’s Choice. CCC Camp release [15] S. Thomson and T. Narten. IPv6 State- less Address Autoconﬁguration. v1.8. http://thc.org/thc-ipv6/, 2012. http://www. ietf.org/rfc/rfc2462.txt, 1998. [4] Cybercity. /proc/sys/net/ipv4/* Vari- [16] Usecurity.org. IPv6 Unsecurity – ables:. http://www.cyberciti.biz/ Router Advertisement is evil. http: files/linux-kernel/Documentation/ //it-unsecurity.org/2011/04/15/ networking/ip-sysctl.txt. ipv6-unsecurity-router-advertisment-is-evil/, 2011. [5] FreeBSD. Developer’s Handbook. http://www.freebsd.org/doc/en/books/ [17] van Hauser. Recent advances in IPv6 inse- developers-handbook/ipv6.html. curities. http://events.ccc.de/congress/ 2010/Fahrplan/events/3957.en.html, [6] J. Jeong, S. Park, L. Beloeil, and S. Man- 2010. danpalli. IPv6 Router Advertisement Option for DNS Conﬁguration. http://tools.ietf. [18] WIDE. WIDE v6 working group. http:// org/html/rfc5006, 2007. www.v6.wide.ad.jp/, 2003.