The first step is to enable IPv6 support on your device, if it isn’t already:

set envar ipv6=yes
save
reset save-config yes

After restarting your device, you should find that IPv6 configuration options are available, and the web UI will also have additional pages and config options.Next, we want to configure the untrust interface as IPv6 “host” mode, and permit it to accept router advertisements from your existing upstream IPv6 router.

set interface untrust ipv6 mode host
set interface untrust ipv6 enable
set interface untrust ipv6 ra accept

The untrust interface should configure itself with an address in the prefix advertised on your existing LAN, and create a default IPv6 route (::/0) via your upstream router.

ns5gt-> get int untrust      
Interface untrust:
  description untrust
  number 1, if_info 88, if_index 0, mode route
  link up, phy-link up/full-duplex
  status change:1, last change:11/09/2011 15:55:40
  ipv6 is enable/operable, host mode.
  ipv6 operating mtu 1472, learned mtu 1472
  ipv6 Interface-ID: 0210dbfffe680eb1
  ipv6 fe80::210:dbff:fe68:eb1/64, link local, PREFIX
  ipv6 2001:470:xxxx:xxxx:210:dbff:fe68:eb1/64, global aggregatable, PREFER, AUTO-CONF
  ipv6 ff02::1:ff68:eb1(2), solicited-node scope
  vsys Root, zone Untrust, vr trust-vr
  dhcp client enabled
  PPPoE disabled
  admin mtu 0, operating mtu 1472, default mtu 1500

ns5gt-> get route
IPv6 Dest-Routes for <trust-vr> (3 entries)
--------------------------------------------------------------------------------------
         ID                                   IP-Prefix       Interface
                                                Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*         3                                        ::/0         untrust
                               fe80::226:88ff:fe45:8242   D  252      2     Root
*         4                     2001:470:xxxx:xxxx::/64         untrust
                                                     ::   C    0      0     Root
*         5    2001:470:xxxx:xxxx:210:dbff:fe68:eb1/128         untrust
                                                     ::   H    0      0     Root

We can see above that the untrust interface has assigned itself an address in our Hurricane 2001:470:x:x/64 prefix. Note also that it has lowered the MTU to 1472, as advertised by our perimeter SRX. The PPPoE encapsulation of our VDSL connection incurs 8 bytes overhead, and since it is an IPv6 tunnel, we have to subtract another 20 bytes to ensure that we don’t send fragmented packets via Hurricane (who seem to drop fragmented traffic).

The next step is to configure the trust interface of the 5GT. I tend to use policy NAT, rather than the often-configured default of interface-NAT. Note that if you have existing outbound policies that were depending on the interface being in NAT mode, you will need to adjust those policies to perform source address NAT.

set interface trust route

Enable IPv6 on the trust interface in “router” mode. First we should generate a RFC 4193 Unique Local Address (ULA). SixXS offers an online tool to generate one of these pseudo-random, quasi-unique prefixes from a MAC address at http://www.sixxs.net/tools/grh/ula/

An address from a ULA prefix has a global scope, however the fc00::/7 prefix is filtered by ISPs, so there is no chance of these addresses colliding on the Internet. The pseudo-random prefix generation is simply to minimise the chance of a prefix collision on a LAN. The SixXS tool will generate a /48 prefix for you; choose a /64 prefix from that, and assign it to the trust interface:

set interface trust ipv6 mode router
set interface trust ipv6 ip fd61:b452:a23d::1/64
set interface trust ipv6 enable

Enable IPv6 router advertisements from the trust interface:

set interface trust ipv6 ra link-address
set interface trust ipv6 ra transmit

If your MTU is less than 1500 on the untrust side, you should also advertise it on the trust side:

set interface trust mtu 1472
set interface trust ipv6 ra link-mtu

At this stage, you should be able to connect a host to the trust side of the 5GT and acquire an IPv6 address from the fd61:b452:a23d::/64 prefix.

[root@smurfette ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr D0:27:88:65:21:B5  
          inet addr:192.168.0.5  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fd61:b452:a23d:0:d227:88ff:fe65:21b5/64 Scope:Global
          inet6 addr: fe80::d227:88ff:fe65:21b5/64 Scope:Link

Now we just need to create a NAT policy for our IPv6 traffic. If you had any existing “IP any/any” policies, setting the envar “ipv6=yes” should have converted those policies to “Any-IPv4″ policies. Create a policy for your IPv6 traffic:

set policy from "Trust" to "Untrust"  "Any-IPv6" "Any-IPv6" "ANY" nat src permit

At this point, you should be able to ping from your trust-side host to a host on the untrust-side, and beyond:

[root@smurfette ~]# ping6 2001:470:xxxx:xxxx::1
PING 2001:470:xxxx:xxxx::1(2001:470:xxxx:xxxx::1) 56 data bytes
64 bytes from 2001:470:xxxx:xxxx::1: icmp_seq=1 ttl=63 time=3.48 ms
64 bytes from 2001:470:xxxx:xxxx::1: icmp_seq=2 ttl=63 time=2.52 ms

[root@smurfette ~]# ping6 -n ipv6.google.com
PING ipv6.google.com(2a00:1450:8004::93) 56 data bytes
64 bytes from 2a00:1450:8004::93: icmp_seq=1 ttl=53 time=43.9 ms
64 bytes from 2a00:1450:8004::93: icmp_seq=2 ttl=53 time=44.2 ms

So there it is… the 5GT is performing NAT66 on the fd61:b452:a23d::/64 prefix to the globally routable 2001:470:xxxx:xxxx::/64 prefix, using the source address of the egress (untrust) interface. Using this technique, we can connect this 5GT to any IPv6-enabled LAN, and connect hosts behind the safety of our own firewall, whilst still having outbound IPv6 connectivity.

In the directory /cf/var/db/certs/common you should see at least the following two subdirectories:

drwx------  2 root  wheel  512 Jul 20 16:14 key-pair
drwx------  2 root  wheel  512 Jul 20 16:16 local

In the key-pair directory you should see files for each of your key-pairs, eg. self-cert.priv. In the local directory you will find the actual certificates, eg. self-cert.cert. Both the key-pairs and certificates are stored in binary DER format, which can be read by OpenSSL and converted to the more universal base64-encoded PEM format.

Private keys should really be left alone where they are on the Juniper, but you can safely copy the certificate to other locations, since it does not contain any private key material. Simply scp the certificate file to somewhere that has the OpenSSL tools installed, then use “openssl x509” to read the certificate:

daniel@thinkpad:~$ openssl x509 -in self-cert.cert -inform DER
-----BEGIN CERTIFICATE-----
MIIDSDCCAjCgAwIBAgIRAKybOo9tijNXkhgT9fe0ZFMwDQYJKoZIhvcNAQEFBQAw
TzELMAkGA1UEBhMCREUxJTAjBgNVBAoTHFNldmVudGggU2lnbmFsIEx0ZC4gJiBD
.....
co9vOYXqYv81xnIxg5I0brLqCzruKULy4zc6YHzJAGICMOw2wS9BwRkQUR1B2EZH
2QWUSn4Enj2JJkT3p044U8/q4BKdJ9V52mxQfA==
-----END CERTIFICATE-----

There you have it folks… a base64-encoded PEM-format public certificate.

Different model APs require this option to be in different formats. For example, Aironet 1000 units require the option response to be type 0×66, and a comma-separated ASCII list of controller IP addresses, whereas Aironet 1130, 1200, 1230 and 1240 units require the response to be type 0xF1, followed by the length (number of addresses x four), then the hexadecimal representation of the controller IP address(es).

Cisco documentation exists for this, however their documentation for ISC’s dhcpd is incorrect. Unlike most corporate customers I run into, who run Microsoft DHCP server (for better or worse), this particular customer was running ISC’s dhcpd.

The first step is setting the option 43 type. I’m going to concentrate on the 1130, 1200, 1230 and 1240 units here, since this is the area where Cisco’s documentation is incorrect. I’m going to follow Cisco’s documentation here.

option space LWAPP;
option LWAPP.controller code 43 = string;

Then we have a vendor class, for the 1200 series units:

class "Cisco AP c1200" {
match if option vendor−class−identifier = "Cisco AP c1200";
option vendor−class−identifier "Cisco AP c1200";
vendor−option−space LWAPP;
option LWAPP.controller f1:04:c0:a8:f7:05;
}

Note the “f1:04″ at the start of the string. This means type 0xF1, followed by four bytes of vendor specific data. The “c0:a8:f7:05″ is the hexadecimal representation of the IP address 192.168.247.5. This results in dhcpd transmitting “2b 08 2b 06 f1 04 c0 a8 f7 05″ for option 43.

Ok, let’s take a look at this string. The “2b” indicates this is a vendor encapsulated options field (type 43), and “08″ means it’s eight bytes long. The next “2b” is where things start to go wrong. This is because the Cisco documentation told us to define LWAPP.controller as type 43 also, which is incorrect. The “06″ indicates that six bytes follow for this sub-code, and then we have our “f1 04 c0 a8 f7 05″ string verbatim. This causes the WLC to report an error parsing the option 43, saying that it cannot parse “2b 06 f1 04 c0 a8 f7 05″.

What we should have configured in dhcpd.conf is actually:

option space LWAPP;
option LWAPP.controller code 241 = string;

class "Cisco AP c1200" {
match if option vendor−class−identifier = "Cisco AP c1200";
option vendor−class−identifier "Cisco AP c1200";
vendor−option−space LWAPP;
option LWAPP.controller c0:a8:f7:05;
}

Note that we also dropped the “f1:04″ from the hex string, since we are now correctly specifying LWAPP.controller as code 241 (0xF1), and dhcpd automatically populates the “04″ for us, after counting the length of our hex string (four bytes = one IP address). This results in dhcpd sending “2b 06 f1 04 c0 a8 f7 05″.

Again we have our “2b”, indicating vendor encapsulated options, but this time the field is only six bytes long. Then we have “f1 04″, indicating our LWAPP.controller code, with four bytes of data – our controller IP address. This time around, the AP will correctly see the option 43 “payload” of just “f1 04 c0 a8 f7 05″, and correctly parse the sub-option 0xF1.

Of course, what this field really is (and this is more clearly detailed in Cisco’s instructions for configuring Microsoft DHCP server), is an array of IP addresses. You can eliminate the need to specify the addresses in hexadecimal by defining the LWAPP.controller as:

option LWAPP.controller code 241 = array of ip-address;

and then simply listing your controller IP addresses:

option LWAPP.controller 192.168.247.5, 192.168.247.6;

This would result in dhcp server sending “2b 0a f1 08 c0 a8 f7 05 c0 a8 f7 06″. Note the “f1 04″ changed to “f1 08″, since the array length is now eight bytes (two IP addresses).

Why Cisco didn’t simply publish this, is beyond me. They’ve made it very confusing for users who don’t understand DHCP vendor specific information. I suspect the person who wrote the dhcpd section of the Cisco documentation didn’t fully understand how ISC dhcpd handles vendor specific options.

In any case, our configuration can be made somewhat clearer, and consistent with dhcpd’s documentation, as follows:

option space LWAPP;
option LWAPP.controller code 241 = array of ip-address;

class "LWAPP" {
match option vendor-class-identifier;
}

subclass "LWAPP" "Cisco AP c1200" {
vendor-option-space LWAPP;
option LWAPP.controller 192.168.247.5;
}

For each additional type of AP you have to support, just add another subclass, using the appropriate vendor class identifier string.

A quick n’ dirty solution is to use an unmanaged switch, such as one of the numerous 8-port desktop switches from manufacturers such as D-Link, Netgear, Linksys etc. Configure its upstream switchport as a trunk port, thus allowing your required VLANs to pass tagged frames to your unmanaged desktop switch.

Wait a second, you say…. unmanaged switches can’t do trunk ports. How can an unmanaged switch understand VLAN frames?

It doesn’t need to. What is an 802.1q tagged frame, other than a standard 802.3 ethernet frame with four additional bytes inserted? These four additional bytes are the 802.1q VLAN ID field and 802.1p CoS field. As long as the unmanaged switch does not truncate frames to the 802.3 standard 1518 bytes, it will happily forward the 1522-byte 802.1q tagged frames just like any other. The last time I encountered a switch that would not forward these slightly “oversized” frames, was about four years ago… and it was a very cheap and nasty brand (name withheld to protect the innocent guilty).

This trick also comes in handy when you have a user with a two-port VoIP phone (such as most Cisco, Snom, Polycom etc phones), using a voice-VLAN, and the user requires more switchports than are currently available at his/her desk. Simply connect the 8-port unmanaged switch before the IP phone (ie. to the upstream port), and connect the IP phone to the unmanaged switch. The phone still gets its tagged voice-VLAN frames, the PC gets its untagged data-VLAN frames (tag-stripped if necessary by the IP phone), and the user has 6 other ports available to connect whatever… including, if necessary, other VLANs (so long as they’re tagged, and the end device can work with tagged frames, since the unmanaged switch won’t strip the 802.1q tag).

Beware though, this should only ever be used as a temporary measure, since it does open a few security holes. If the “allowed VLANs” is not carefully configured on the upstream port, the opportunity exists to VLAN-hop, or flood traffic into other VLANs. And of course, since the unmanaged switch is, well, unmanaged, there is no individual “allowed VLANs” security on those 8 ports. All ports are effectively the same as that one upstream trunk port.

Have you used this method before? What brand/model unmanaged switch did you use? What were your experiences with it, and did you encounter any problems?