Monthly Archives: December 2015

SSH login with 2-Factor Authentication

During the holiday time, I was discussing with a mate on ways I could make my server more secure and he said why don’t I have 2-Factor Authentication. Of course, I dismissed him as a crazy man saying you can do that on SSH! When I actually looked I saw it could be done and it is a common place to have it done as well. I found a super page that explains how 2-Factor Authentication all works! With this in mind, this post will show how you can enable a SSH server with 2-Factor Authentication.

As always, I’ll be using Ubuntu 14.04 LTS. Because I use Google Authenticator for other things, I was happy to see that you can install Google Authenticator’s time-based one-time password (TOTP) via the apt-get repository. To install 2-factor authentication with Google Authenticator, we’ll need the open-source Google Authenticator PAM module. PAM stands for Pluggable Authentication Modules (PAM) provide dynamic authentication support for applications and services in a Linux. Essentially, it’s a way to easily plug different forms of authentication into a Linux system.

Firstly you will need to have Google Authenticator or Authentication App installed on your phone before doing anything. Personally I use Google’s Authenticator, for iOS App Store, for Android Google Play. Microsoft has their own Authenticator App for Windows Phones.

With the Authenticator installed on your phone, next you will need to install the Google package. You will need to have root and/or sudo access to the server and apt-get libpam-google-authenticator

sudo apt-get install libpam-google-authenticator

With the Module installed, you can set up your users with their OTP token. Run the google-authenticator utility, once ran you will be asked a series of questions that you can answer however best for you environment.

[email protected]:~$ google-authenticator 

Do you want authentication tokens to be time-based (y/n) y
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/[email protected]%3Fsecret%3DXYC73MOQV7SMPOSJ
Your new secret key is: XYC73MOQV7SMPOSJ
Your verification code is 194186
Your emergency scratch codes are:
  28140794
  43020525
  41649070
  99131075
  14555358

Do you want me to update your "/home/marquk01/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) y

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
[email protected]:~$ 
Important Notes
You will need to keep safe the Emergency Scratch codes, just in case you lose access or have an issue with your OTP token. Your secret key will be used on the Authenticator app to generate your verification code. You can either manual enter the code or you can use scan QR-code that is generated on the cli to your phone. This is what you should expect to see when you run the google-authenticator utility. Once that’s has been done you will you should get something like this on your app

Next we will need to activate Google Authenticator within the sshd daemon. Firstly you will need to edit /etc/pam.d/sshd file by adding following lines below:

[email protected]:~$ sudo nano /etc/pam.d/sshd 
{...}
# To allow Google Authenticator for 2 factor authentication 
auth required pam_google_authenticator.so

Then you will need to edit the /etc/ssh/sshd_config file. Look for the ChallengeResponseAuthentication and ensure that this is yes

[email protected]:~$ sudo nano /etc/ssh/sshd_config 
{...}
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

The full files should look something like this sshd and sshd_config

Now we need to restart the sshd daemon.

[email protected]:~$ sudo service ssh restart

Now that the ssh daemon has been restarted when you try and ssh back onto the server, you will be asked for your password and the OTP verification code

[[email protected] ~]$ ssh 10.1.0.137
Password: 
Verification code: 

It also worked with Secure Copy Protocol (SCP), which allows transfer files via Secure Shell (SSH)

[[email protected] ~]$ scp bird.conf.oringial [email protected]:/home/marquk01
Password: 
Verification code: 
bird.conf.oringial                            100% 6222     6.1KB/s   00:00
NOTES
ALL Users will need to be configured to have 2-factor authentication before editing the ssh daemon. When I tried this the first time, I assumed it was pre-user enabled the everything to find out my main account was locked out… #GenuisAtWork! In addition, if you have a key-based authentication, they will take supersede 2-Factor Authentication and this will be ignored
Share this:
Share

Configuring a Dual Stacked DHCP Server

As part of my IPv6 Testing, I needed to test whether we would either use SLAAC or DHCPv6 in a particular situation. Having never setup a DHCP server before, of course, I had to write a post on how I did it 😀

Dynamic Host Configuration Protocol or DHCP is defined in RFC2131:

The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.

DHCP supports three mechanisms of IP address allocation; Automatic, Dynamic and Manual allocation. RFC2131: describes how each of these mechanisms works within the DHCP process

Dynamic allocation is the only one of the three mechanisms that allows automatic reuse of an address that is no longer needed by the client to which it was assigned. Thus, dynamic allocation is particularly useful for assigning an address to a client that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of clients that do not need permanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new client being permanently connected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old clients are retired. Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in environments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.

In a nutshell:

  • Automatic allocation; the DHCP process will assign a permanent IP address to the host/device.
  • Dynamic allocation; the DHCP assigns an IP address to a client for a limited period of time or until the client release the address.
  • Manual allocation; the a client’s IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client.

With DHCPv6 the communication process between server and client is a little different compared DHCPv4, as explained in RFC3315:

Clients and servers exchange DHCP messages using UDP. The client uses a link-local address or addresses determined through other mechanisms for transmitting and receiving DHCP messages. DHCP servers receive messages from clients using a reserved, link-scoped multicast address. A DHCP client transmits most messages to this reserved multicast address, so that the client need not be configured with the address or addresses of DHCP servers.

To allow a DHCP client to send a message to a DHCP server that is not attached to the same link, a DHCP relay agent on the client’s link will relay messages between the client and server. The operation of the relay agent is transparent to the client and the discussion of message exchanges in the remainder of this section will omit the description of message relaying by relay agents. Once the client has determined the address of a server, it may under some circumstances send messages directly to the server using unicast.

NOTE
For more in-depth detail about the DHCP and DHCPv6, I would suggest looking into RFC2131 and RFC3315 respectfully.

For this testing, I used a two ESXi Ubuntu 14.04LTS Hosts, one as the DHCP server and client, and the other was a Juniper EX4200 connecting them together. The switch configuration is extremely basic, both devices are in the same Vlan and the Vlan has a layer-3 interface IPv4: 192.168.1.1/24 and IPv6: 2001:192:168:1::1/64.

With all the talk out of way.. Let’s get cracking 🙂

You will need to have sudo or root privileges

Firstly, a static IPv4 and IPv6 will need to be set on the interface that will be advertising the DHCP to the LAN. For my example I’m using eth1

[email protected]:~$ ifconfig -a eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:d3:ac:77  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fed3:ac77/64 Scope:Link
          inet6 addr: 2001:192:168:1::2/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1308 (1.3 KB)  TX bytes:4204 (4.2 KB)

The DHCP package is available via the apt-get repository

sudo apt-get install isc-dhcp-server

You will need to edit /etc/default/isc-dhcp-server and set the NIC that you want to run DHCP from. In addition, you need to set options with “-6” flag to tell the package we’ll be running IPv6. For my server, I’ll be using interface “eth1”. Make you use the appropriate NIC in your configuration.

[email protected]:~$ cat /etc/default/isc-dhcp-server 
# Defaults for isc-dhcp-server initscript
# sourced by /etc/init.d/isc-dhcp-server
# installed at /etc/default/isc-dhcp-server by the maintainer scripts

#
# This is a POSIX shell fragment
#

# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
#DHCPD_CONF=/etc/dhcp/dhcpd.conf

# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
#DHCPD_PID=/var/run/dhcpd.pid

# Additional options to start dhcpd with.
#    Don't use options -cf or -pf here; use DHCPD_CONF/ DHCPD_PID instead
OPTIONS="-6"

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#    Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES="eth1"

From doing some digging, unfortunately the original isc-dhcp-server doesn’t allow you to run IPv4 and IPv6 under the same config file. I had to create a new file and edit it to be IPv6 specific. I backed the original dhcpd.conf file and created a new dhcpd6.conf file; the two files should look similar to the below if you have a simple set up like myself.

Note
With a DHCP server you can have the server configured to set DNS, hostnames and other administrative settings. You can see examples of this if you look at the full original dhcpd.conf file. This is out of scope of what I was testing currently, but with knowing what else I’ll be testing in the future I’ll likely shown how in a future post 🙂
dhcpd6.confdhcpd.conf
[email protected]:~$ cat /etc/dhcp/dhcpd6.conf 
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed.
ddns-update-style none;

# Option definitions common to all supported networks...
default-lease-time 600; 
max-lease-time 7200; 

# This DHCP server is the official DHCP server for the local network
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
 
# Subnet declaration
subnet6 2001:192:168:1::/64  {
    range6 2001:192:168:1::110 2001:192:168:1::120;
}
[email protected]:~$ cat /etc/dhcp/dhcpd.conf 
#
# Sample configuration file for ISC dhcpd for Debian
#
# Attention: If /etc/ltsp/dhcpd.conf exists, that will be used as
# configuration file instead of this file.
#
#

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

default-lease-time 600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# This is a very basic subnet declaration.

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.110 192.168.1.120;
}

An DHCPv6 lease file will need to be created because, unlike IPv4, there isn’t a predefined file. In addition this file will need to have its owner changed to dhcpd daemon. This is because the daemon will need write, read and execute permissions

sudo touch /var/lib/dhcp/dhcpd6.leases
sudo chown dhcpd:dhcpd /var/lib/dhcp/dhcpd6.leases

To finish up on the server, we will need to start the DCHP processes

sudo service isc-dhcp-server start
sudo service isc-dhcp-server6 start

Once this has been done, the server is configured. Next we will hop to the other VM to see if we can get some IP addresses assigned!

Once on the client, we have to set its interface to listening for DHCP packets. Under /etc/network/interfaces both for IPv4 and IPv6 we will need to DHCP.

[email protected]:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
{...}
auto eth1
iface eth1 inet dhcp

# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

auto eth1
iface eth1 inet6 dhcp

Once this has been set, the interface will automatically pick up an address. If you’re like me and want to see everything, you can manually release any addresses learnt by using the following commands: for IPv6 dhclient -6 -v -r eth1 and for IPv4 dhclient -v -r eth1

dhclient -v -r eth1dhclient -6 -v -r eth1
[email protected]:~$ sudo dhclient -v -r eth1
[sudo] password for marquk01: 
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/00:0c:29:4f:26:c5
Sending on   LPF/eth1/00:0c:29:4f:26:c5
Sending on   Socket/fallback
DHCPRELEASE on eth1 to 192.168.1.2 port 67 (xid=0x45baa909)
[email protected]:~$ sudo dhclient -6 -v -r eth1
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/eth1
Sending on   Socket/eth1
RTNETLINK answers: Cannot assign requested address
XMT: Forming Release, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Release Address 2001:192:168:1::111
XMT:  V IA_NA appended.
XMT: Release on eth1, interval 1000ms.
RCV: Reply message on eth1 from fe80::20c:29ff:fed3:ac77.
RCV:  X-- Server ID: 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77
message status code Success: "Release received."

Running an ifconfig will show that eth1 has no IP addresses set (except for its link-local address)

[email protected]:~$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3487 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1272 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:501952 (501.9 KB)  TX bytes:267192 (267.1 KB)

Now we can request addresses from DHCP server to bind the next available IP addresses to km-vm1 by using the command for IPv4 dhclient -v eth1 and for IPv6 dhclient -6 -v eth1 respectfully.

dhclient -v eth1dhclient -6 -v eth1
[email protected]:~$ sudo dhclient -v eth1
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/00:0c:29:4f:26:c5
Sending on   LPF/eth1/00:0c:29:4f:26:c5
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3 (xid=0x7cae5613)
DHCPREQUEST of 192.168.1.112 on eth1 to 255.255.255.255 port 67 (xid=0x1356ae7c)
DHCPOFFER of 192.168.1.112 from 192.168.1.2
DHCPACK of 192.168.1.112 from 192.168.1.2
bound to 192.168.1.112 -- renewal in 230 seconds.
[email protected]:~$ sudo dhclient -6 -v eth1
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/eth1
Sending on   Socket/eth1
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT:  | X-- Request address 2001:192:168:1::111.
XMT:  | | X-- Request preferred in +7200
XMT:  | | X-- Request valid in     +10800
XMT: Solicit on eth1, interval 1050ms.
RCV: Advertise message on eth1 from fe80::20c:29ff:fed3:ac77.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1447710742
RCV:  | X-- t1 - renew  +0
RCV:  | X-- t2 - rebind +0
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::111
RCV:  | | | X-- Preferred lifetime 7200.
RCV:  | | | X-- Max lifetime 43200.
RCV:  X-- Server ID: 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77
RCV:  Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC:  X-- Initial candidate 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77 (s: 153, p: 0).
XMT: Forming Request, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAADDR 2001:192:168:1::111
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Request on eth1, interval 1040ms.
RCV: Reply message on eth1 from fe80::20c:29ff:fed3:ac77.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1447710744
RCV:  | X-- t1 - renew  +0
RCV:  | X-- t2 - rebind +0
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::111
RCV:  | | | X-- Preferred lifetime 7200.
RCV:  | | | X-- Max lifetime 43200.
RCV:  X-- Server ID: 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77
PRC: Bound to lease 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77.

We can confirm by using ifconfig again:

[email protected]:~$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet addr:192.168.1.110  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link
          inet6 addr: 2001:192:168:1::111/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3647 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1365 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:519662 (519.6 KB)  TX bytes:292435 (292.4 KB)

And with that, we now have a Dual Stacked DHCP server! Although this looks quite straightforward, now I’ll tell you that it took me a few days to get understand and get the IPv6 side of things working as expected. There was plenty of googling, troubleshooting, screen staring and frustration with this one, but I have to give major props to a great page by Jochen Kirstätter on how the IPv6 side of install was done if I hadn’t have found it, I would still be poking in the dark *covers face*! You will find some great nuggets on Jochen’s blog here 🙂

Share this:
Share

IPv6 and Junos – Stateless Address Autoconfiguration (SLAAC)

From my research and testing, I’ve notice there are a few ways you can set IPv6 addresses to hosts. Essentially you have 3 methods; manually setting a Static IP address, Using Stateful Dynamic Address allocation via a DHCPv6 server, or by using Stateless Dynamic Address allocation. The first two methods are pretty standard as addressing with IPv4 is done this way however, the last method is new method that comes with IPv6 and this is actually known as Stateless Address Autoconfiguration (SLAAC). SLAAC, as its name suggestions, allows a host to auto configure itself without any manual intervention.

RFC4862 describe the SLAAC as

The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an “interface identifier” that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link.

In essence, when using SLAAC to get the full 128-bit IPv6 address, it uses the 64-bit prefix that is advertised by the host or router for the first half, then in conjunction with the EUI-64 process, is able to allocation the second 64-bit of the address.

Note
The EUI-64 process in a nutshell, is the method of extending the 48-bit MAC Address and making it into a 64-bit value. This is done by splitting the 48-bit address into two 24-bit halves and adding the 16-bit hex value 0xFFFE in middle to create the last 64-bits

Configuring SLAAC

Enabling SLAAC with Junos is pretty straightforward. For my example, I’ve got an EX4200 connected to an Ubuntu 14.04LTS ESXi host in Vlan 200.

Before enabling the switch, the host’s interface has to be set to auto

[email protected]:~$ cat /etc/network/interfaces
{...}
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

auto eth1
iface eth1 inet6 auto

Once that’s done, to make sure no address was learnt as I configured the switch, the interface was disabled using ifdown.

With the switch configuration, under the protocol router-advertisement stanza, the interface and the prefix (first 64-bits) that will be advertised need to be set. Additionally I enabled a traceoption to see the process from the switch’s perspective.

Interface ConfigurationEnabling SLAAC
{master:0}[edit]
[email protected]# show interfaces vlan unit 200 
family inet6 {
    address 2001:192:168:2::1/64;
}
{master:0}[edit protocols router-advertisement]
[email protected]# show 
traceoptions {
    file RA.log;
    flag all;
}
interface vlan.200 {
    prefix 2001:192:168:2::/64;
}

Verification

With that SLAAC has been enabled, simple isn’t it 🙂

Now, back on the host, I re-enabled the interface using ifup. By using ifconfig we can see that the IPv6 address has been auto configured onto the host.

[email protected]:~$ ifconfig -a eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet addr:192.31.1.2  Bcast:192.31.1.255  Mask:255.255.255.0
          inet6 addr: 2001:192:168:2:20c:29ff:fe4f:26c5/64 Scope:Global
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:563 (563.0 B)  TX bytes:2334 (2.3 KB)

By looking closer at the ifconfig output, we can see how the EUI-64 process has been used to allocate the IPv6 address, as well as its link-local address:

eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet6 addr: 2001:192:168:2:20c:29ff:fe4f:26c5/64 Scope:Global
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link

On the switch, by running the commands: show ipv6 neighbours, we can see the hosts’ link-local and SLAAC allocated addresses, both discovered by the Neighbour Discovery Protocol (NDP). And show ipv6 router-advertisement, which shows how many RA’s and RS’ have been sent and received by the switch.

IPv6 NeighborsRouter Advertisements
{master:0}
[email protected]> show ipv6 neighbors 
IPv6 Address                 Linklayer Address  State       Exp Rtr Secure Interface
2001:192:168:2:20c:29ff:fe4f:26c5
                             00:0c:29:4f:26:c5  stale       1110 no no      vlan.200    
fe80::20c:29ff:fe4f:26c5     00:0c:29:4f:26:c5  stale       1039 no no      vlan.200
{master:0}
[email protected]> show ipv6 router-advertisement 
Interface: vlan.200
  Advertisements sent: 4, last sent 00:04:45 ago
  Solicits received: 2, last received 00:04:46 ago
  Advertisements received: 0

When we look further at the traceoption, we can see the request from the host sent out Router Solicitation (RS) via its link-local address, to the destination of ff02::2 for the presence of routers (in this case a switch) on the link. The switch replies by sending a Router Advertisement (RA) to ff02::1 with the Router’s presence and link prefixes, MTU, and hop limits.

{Apr  7 06:29:13.002388 background dispatch running job ipv6_ra_delete_interface_config_job for task Router-Advertisement
Apr  7 06:29:13.002436 task_job_delete: delete background job ipv6_ra_delete_interface_config_job for task Router-Advertisement
Apr  7 06:29:13.002473 background dispatch completed job ipv6_ra_delete_interface_config_job for task Router-Advertisement
Apr  7 06:29:48.645889 ipv6_ra_receive_solicit: received solicit from fe80::20c:29ff:fe4f:26c5
Apr  7 06:29:48.646013 ipv6_ra_receive_solicit: task Router-Advertisement src fe80::20c:29ff:fe4f:26c5 dst ff02::2 hdr 0x26fc000 count 16 intf 0x283c0e8
Apr  7 06:29:48.646086 task_timer_reset: reset Router-Advertisement_ipv6ra
Apr  7 06:29:48.646137 task_timer_set_oneshot_latest: timer Router-Advertisement_ipv6ra interval set to 0.426219
Apr  7 06:29:49.073743 task_job_create_foreground: create job ipv6 ra for task Router-Advertisement
Apr  7 06:29:49.073857 foreground dispatch running job ipv6 ra for task Router-Advertisement
Apr  7 06:29:49.073978 ipv6_ra_send_advertisement: sending advertisement for ifl 73 to ff02::1
Apr  7 06:29:49.074018 (519322) sending advertisement for ifl 73
Apr  7 06:29:49.074106 	ifa 0x28383f0 2001:192:168:2::1/64
Apr  7 06:29:49.074942 	--> sent 56 bytes
Note
The ff02::1 and ff02::2 addresses are well-known IPv6 Multicast addresses that a host sends out to a RS, to all devices within the all-host multicast group for ff02::2, and for a router, the address ff02::1 is used to reply RS with RA. Although this process could be compared to the IPv4 broadcast address 255.255.255.255, its important to remember that broadcasts are not accepted by any IPv6 protocol.

SLAAC is a really useful way of easily enabling IPv6 across your network and let the host and devices auto configure themselves. In addition, as the EUI-64 process is key to SLAAC, as long as you keep a record of the MAC Addresses of each device, you’ll always be able to know what address goes with what device. Of course, there will be situations where Static or DHCP addressing will be more suitable however; if you need to quickly enable your network with IPv6 then SLAAC is the way to go!

Share this:
Share