1-wire: is a serial bus from Dallas Semiconductor/Maxim that only requires 1 data line, there are a number of cheap sensors and other devices for this bus. The strength of this bus is not its speed but that it supports large ranges (up to 300 meters).
Also, each 1-wire device has a permanent unique 64-bit serial number.

IPv6: Insanely large address space. It’s common to use a 64-bit netmask for site networks so that EUI-64 based addresses can be used for auto configuration. This leaves 64-bit for the node address – do you see where this is going now…

Yes..I’ve built a device that assigned each 1-wire device it’s connected to its own IPv6 address. Why? you ask, mostly because I can.

Hardware

As mentioned above, the device is based on an AVR ATmega644. It has 64KB of flash memory for program code and 4KB of RAM. It’s running on its built-in oscillator at 8MHz. The ENC28J60 Ethernet chip is connected to the AVR using SPI. The rest of the hardware is mostly for power distribution and management.

The PCB was manufactured by BatchPCB, cheap service but a bit slow turn-around time.

Unfortunately I screwed up the SPI connection but I managed to fix that with some green wires (or black wires in this case). You’ll note them in the picture above.
I also intended to run the AVR at 5V and the ethernet chip at 3.3V. This is what the quad AND-gate in the upper right
corner was for, but since I screwed up the SPI routing it’s disconnected and the whole circuit is running at 3.3V.
The ENC28J60 can only run at 3.3V, the AVR has a range from 2.8-5V and 1-wire should be ran at 5V but works at 3.3V. Hence the need for TTL voltage translation.

As for the 1-wire devices I had implemented a bus master in software that generated the require waveforms. It worked great up to about 10-15 meters. Any cable length greater than that refused to work.
This was a bit unexpected and without an oscilloscope it was more or less impossible to figure out where and how the signals got mangled. So I simply got a DS2480 1-wire line driver that generates the required signals in hardware with more precise timing.

Add-on board with a 1-wire master

This required an add-on board and because I didn’t want to wait for a new PCB I used a 2.54mm prototype board. With the DS2480 only available in SOIC8 packages it required some “creative” soldering .
The DS2480 required 5V, thus It had to get its own power supply and also required level translation on the UART line between this device and the AVR. I choose an approach using MOSFETs and a few resistors for this (the TO92 packages in the picture above). This turned out to work really good and I think I’m going to use this for the SPI level translation in the next revision of the board.
The wire leaving the board on the left side leads to the 1-wire sensor devices.

The add-on board is extremely ugly. But hey, it works.

Future improvements for the next revision

• Use of external crystal at 16MHz instead of internal 8MHz clock.
• Use MOSFETs for 3.3-5 V translation. Need to test it at 16MHz before manufacturing a PCB though.
• Obviously fix all PCB errors
• All SMD parts (resistors and voltage regulators) to shrink PCB size even more.
• Better power distribution. I was a bit too conservative with the decoupling capacitors resulting in some weird power problems (fixable with some caps)
• Create a real add-on board

I’ll publish the PCB CAD files when the next revision is complete.

Software

The only small IPv6 stack I know of is the uIPv6 stack in the Contiki operating system created by Adam Dunkel et al. This is unfortunately only available together with Contiki and not as a stand alone package as the originally uIP (IPv4) stack.

Contiki is a great operating system, but when you only have 4KB of RAM it becomes a bit heavy weight. So I broke out the uIPv6 stack from Contiki and made it run stand alone and ported in to AVR. I also ported the web server application from Contiki and made it run on AVR. As I wanted to use multiple IPv6 addresses I also had to add support for IP aliases to the uIPv6 stack.

Since the uIPv6 was integrated with Contiki it used the Contiki process model which it self is based on “proto-threads” (another thing invented by Adam Dunkel). I felt that this didn’t fit so I turned all processes into a polling mode instead. So one has to call a set of polling functions from the main application loop or from timers.

The other major parts of the code are drivers for ENC28J60, DS2480 and DS1820.

Software

1-wire devices

30 second polling interval with auto-discovery of new devices.
Each device is assigned its own IPv6 address, requires a /64 network to be available.

Webserver

Integrated web server makes it possible to visit each address. An XML file with the latest sensor reading is returned. An “age timestamp” is also provided which makes it possible to determine how old the reading is.

Currently, with 5 1-wire devices connected it uses about 3KB of RAM.

• Source code
• uIPv6 port

In-action

I only have temperature sensors connected at the moment. If you happen to have an IPv6 capable connection you can access the sensors through a web browser.

2001:16d8:ffe5:002:2894:eaf6:100:0c7
2001:16d8:ffe5:002:28c1:b4f6:100:035
2001:16d8:ffe5:002:2809:aef6:100:0ca
2001:16d8:ffe5:002:28c5:a5f6:100:058
2001:16d8:ffe5:002:2813:caf6:100:050

(If you don’t have IPv6 you should get it, or you can view graphs based on the sensor values at lindberg.tl instead).

The “Authenticated sender” is added when a user has been authenticated by the MTA through SASL and the directive smtpd_sasl_authenticated_header have been set to yes.  The header_checks directive takes a file containing a regular expression which rewrites the header data and removes sensitive information.

This all works well – with IPv4. The regular expression posted on the pages mentioned above does not take IPv6 addresses into account, I modified it slightly to accept both IPv4 and IPv6 addresses.

/^Received: from (.* \(\[?[-._[:alnum:]]+\]? \[([\.0-9]{7,15}|IPv6[\:a-fA-F0-9]+)\]\))(.*)
\(Authenticated sender: ([^)]+)\)(.*)(by mx1\.example\.com) \(([^)]+)\) with (E?SMTPS?A?) id
 ([A-F[:digit:]]+)(.*)/ REPLACE Received: from smtp-auth.example.com (smtp-auth.example.com
 [127.0.0.1]) (Authenticated sender: hidden)$5$6 ($7) with $8 id $9 $10

Note that this should be one single line.

Put this in a file, for example /usr/local/etc/postfix/obscure_smtp_auth and add the following to your Postfix configuration (assuming you have SASL working).

header_checks = pcre:/usr/local/etc/postfix/obscure_smtp_auth
smtpd_sasl_authenticated_header = yes

The first header will now be rewritten, for both IPv4 and IPv6 clients and will look something like this.

Received: from smtp-auth.example.com (smtp-auth.example.com [127.0.0.1]) 127.0.0.1 (Authenticated sender: hidden)
	by mx1.example.com (Postfix) with ESMTPSA id 3677033C6F
	for &lthostmaster@example.se>; Wed, 10 Dec 2008 16:31:51 +0100 (CET)

instead of

Received: from [IPv6:2001:xxxx:xxxx:xxxx:xxxx:xxxx:fedd:7914] (unknown [IPv6:2001:xxxx:xxxx:xxxx:xxxx:xxxx::fedd:7914])
	(Authenticated sender: someuser@example.com)
	by mx1.example.com (Postfix) with ESMTPSA id 3677033C6F
	for  &lthostmaster@example.se>;  Wed, 10 Dec 2008 16:31:51 +0100 (CET)

Oh, and to put things in perspective. An IPv6 address is 128 bits, 48-bits (aka /48) for the net leaves 80 bits for hosts. That’s 1.20892582 × 10²⁴ hosts, or 65536 /64 sub-nets with 1.84467441 × 10¹⁹ hosts in each. But of course you already knew that

Let’s kick start the post by showing a pretty picture of how the network looks.

IPv6 net

IPv6 is statically routed from the SixXS PoP to my IPv6 border router. The routers within my administrative zone are spread geographically and talk IPv6 to each other over 6-in-4 tunnels. They also run OSPFv3 for convenience and because static routing is a pain (I’ll admit that the current setup is doable with static routing, but if I add one or more routers things will get ugly).

6-in-4 tunnels

There are many ways to tunnel traffic. Since we’re dealing with public IP-addresses here (hence already insecure traffic) I didn’t feel the need to secure the traffic between my routers as the packets will be routed to the Internet in an insecure way anyhow. I therefore opted for one of the easier tunneling methods of simply putting the complete IPv6 packet directly into a IPv4 packet and setting protocol field to 41 (IPv6 protocol number). This kind of tunnel is available in most operating systems.  My routers run FreeBSD and the pseudo-interface gif(4) provides this functionality.

Numbering IPv6 point-to-point links

Numbering these links was not as easy as one would have though. These are point-to-point links and in IPv4 you would normally use a /30 (possibly a /31). However sub-netting in IPv6 is not as liberal as IPv4. RFC3513 section 2.5.4 says that the node id should be 64-bit (ie a /64 net). Using a /64 on one point-to-point link is not very attractive as it wastes A LOT of addresses (sure I have plenty, but it’s ugly).

Fortunately, more people feel this way and /127 nets have become popular on p2p-links. After reading RFC3627 “Use of /127 Prefix Length Between Routers Considered Harmful” and compared the pros and cons I decided to use /126 on my point-to-point links (which is equivalent to a /30 in the IPv4 world).

Configuring this is trivial, watch out for firewall issues though. You need to allow protocol 41 (same level as tcp and udp) between the IPv4 hosts.

gif1: flags=8051 metric 0 mtu 1280
	tunnel inet X.X.X.X --> Y.Y.Y.Y
	inet6 fe80::218:71ff:fe68:d071%gif1 prefixlen 64 scopeid 0x5
	inet6 2001:16d8:ffe5::1 prefixlen 126

The observant reader might notice the configured fe80::/10 network, which is an auto configured link-local network (only valid on the p2p-link). I didn’t initially have this configured, but it turned out that this was extremely important for reasons that will become clear in the following sections.

OSPFv3

As stated previously I run OSPFv3 (OSPF with IPv6 extensions) on the routers for flexibility.  I choose Quagga for this and the routers run ospf6d and zebra.

zebra

The zebra daemon handles the interaction with the kernel and installs the selected routes into the kernels forwarding table (FIB) (which quite erroneously is called routing table in most operating systems).

zebra configuration at the border router
Terminal access lists and settings have been left out for readability

hostname border
password somepassword
log file /var/log/quagga/zebra.log
!
# Static default route which is injected as an external route
# into OSPF
ipv6 route 2000::/3 2001:16d8:ff00:2be::1
!
# Enable IPv6 forwarding (if not already enabled by the OS)
ipv6 forwarding
!

Why are we injecting 2000::/3 as a default route?  Because 2001::/3 covers the currently valid global unicast addresses. See ipv6-unicast-address-assignments and RFC4147.

zebra configuration at internal routers
Terminal access lists and settings have been left out for readability

hostname router1
password somepassword
log file /var/log/quagga/zebra.log
!
# Enable RA (router advertisements) on the internal interface so that clients on the LAN
# are able to auto configure an IPv6 address within the correct prefix.
interface internal0
 link-detect
 ipv6 address 2001:16d8:ffe5:2::1/64
 no ipv6 nd suppress-ra
 ipv6 nd ra-interval 10
 ipv6 nd prefix 2001:16d8:ffe5:2::/64
!
# Enable IPv6 forwarding (if not already enabled by the OS)
ipv6 forwarding
!

ospf6d

ospf6d is the daemon in the Quagga suite that implements OSPFv3. My setup is quite simple and does not involve any areas.

ospf6d configuration at border router
Terminal access lists and settings have been left out for readability

password somepassword
log file /var/log/quagga/ospf6d.log
!
# Tunnel interface on which
interface gifX
ipv6 ospf6 instance-id 0
!
# Redistribute connected subnets and static (from zebra) routes to neighbors
router ospf6
router-id 0.0.0.1
redistribute connected
redistribute static
# Add one interface line for each tunnel
interface gifX area 0.0.0.0
!

ospf6d configuration at internal routers

password somepassword
log file /var/log/quagga/ospf6d.log
!
interface gifX
 ipv6 ospf6 instance-id 0
!
# The internal interface is configured as passive to suppress OSPF hello-messages
# on the internal network but still allow the configured subnet to be injected into
# OSPF
interface internal0
 ipv6 ospf6 instance-id 0
 ipv6 ospf6 passive
!
# Redistribute connected subnets
router ospf6
 router-id 0.0.0.2
 redistribute connected
 # Tunnel interface (external)
 interface gifX area 0.0.0.0
 # Internal interface, marked as passive above.
 interface internal0 area 0.0.0.0
!

Note that you need to remove the passive flag if you intend to have more OSPFv3 routers on the network connected to the internal interface. Otherwise they would be unable to find each other.

OSPFv3 on Point-to-point links

As I used numbered point-to-point links I figured this would “just work”. Turned out that it was not that simple.

The routers successfully formed an adjacency

router1# show ipv6 ospf6 neighbor
Neighbor ID     Pri    DeadTime  State/IfState         Duration I/F[State]
0.0.0.1           1    00:00:37   Full/PointToPoint    01:14:38 gif0[PointToPoint]

Routes were distributed correctly, but all received routes had the next hop set to :: which is the unspecified IPv6 address (equal to 0.0.0.0), which of course caused zebra to reject the route and not install it into the FIB.

Most routes have been left out from the output below

router1# show ipv6 ospf6 route
*N E1 2000::/3                       ::    gif0 01:14:45
...

I though this didn’t make any sense as a packet dump showed LSA being exchanged correctly. After actually reading the ospf6d source code and some of the OSPFv3 specifications it finally hit me. OSPFv3/IPv6 Point-to-point links must use the link-local address space fe80::/10. And what do you know, after I turned on auto link local addresses on the tunnel interfaces routes were properly exchanged and ospf6d set the next hop correctly on received routes.

router1# show ipv6 ospf6 route
*N E1 2000::/3                        fe80::218:71ff:fe68:d071   gif0 01:14:45
...

IPv6 clients

As ospf6d on the LAN router is configured to send router advertisements clients connected to the LAN simply needs to enable IPv6 (and accept router advertisements in case it’s disabled) to get an IPv6 address and a default route.  This kind of stateless auto configuration is one of the advantages of IPv6, but it has one big weakness. It’s not possible to distribute name server information without DHCPv6.

Currently all my clients are dual-stacked and get name server information through DHCPv4.  I plan to add a stateless DHCPv6 server that distribute information only (no addresses) so that it’s possible to get name server information without involving IPv4.

Firewall considerations

IPv6 needs to be protected by firewalls just as IPv4.

Protecting the tunnels and tunnel endpoints

The 6-in-4 tunnels requires a bit of special care, simply allowing everything on the tunnel interface could open up some nasty holes and allow traffic to daemons running on the routers.  How rules should be applied depends on which kind of tunnel type you are using, the following assumes an IPv6 packet directly inside a IPv4 packet without other encapsulation.

• Allow protocol 41(IPv6) inside IPv4 packets between the IPv4 endpoints.  This is similar to for example allowing TCP between two IPv4 hosts.
• Allow IPv6 traffic from/to fe80::/10 (link-local), fe00::/8 (multicast) and your configured /126.
• At the end router allow traffic to/from the configured /64 subnet.
• Make sure daemons (that are not supposed to be exposed) are listening on ::1/128 only or block traffic from other subnets than your own so that only valid hosts are able to create connections to IPv6 addresses configured on the router.

Protecting public services

No real difference from IPv4 services, only expose ports that should be exposed. If services and tunnels are running on the same machine make sure that it’s not possible to connect to the daemons through the IPv6 address configured at the tunnel (see previous section).

Protecting clients

Protecting LAN clients are a bit different from IPv4. IPv4 clients are usually behind NAT (unless you’ve got an insanely large IPv4 space and waste it on client hosts).  A fundamental consequence of NAT is that it’s impossible to establish inbound connections to hosts, thus providing protection from incoming connections from malicious hosts.

It’s tempting to simply block all incoming connections to IPv6 clients giving them the same level of protection as IPv4 NAT-hosts. This is however a quite bad idea, one of the advantages of IPv6 and the large address space is that clients are able to establish peer-to-peer (client to client) connections between each other. A large number of applications benefit from this, for example VoIP, Video-chat, file transfers etc.

Still, it’s probably a good idea to block incoming connections to commonly “abused” ports at the LAN border. For example

• 137/TCP, 138/UDP, 139/TCP – NetBIOS
• 135/TCP – RPC
• 445/TCP – SMB
• 389/TCP – LDAP
• 1512 – WINS
• 515 – LPD

Golden rule, don’t block too much, but don’t block too little either , clients should run a local firewall as well if possible.

References

• http://www.quagga.net/docs.php – Quagga Documentation
• http://tools.ietf.org/html/rfc4291 – IP Version 6 Addressing Architecture
• http://tools.ietf.org/html/rfc3627 – Use of /127 Prefix Length Between Routers Considered Harmful
• http://tools.ietf.org/html/rfc4861 – Neighbor Discovery for IP version 6 (IPv6)
• http://support.microsoft.com/kb/832017 – Service overview and network port requirements for the Windows Server system

The IP address for www.shapeshifter.se is 2001:16d8:ffe5:1:1::1 (from 2001:16d8:ffe5:1::/64)

It has got some shiny AAAA/PTR records too.

shapeshifter.se has IPv6 address 2001:16d8:ffe5:1:1::1
1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.1.0.0.0.5.e.f.f.8.d.6.1.1.0.0.2.ip6.arpa domain name pointer www.shapeshifter.se.

I played with IPv6 several years ago (back during the 6BONE days) and recently decided to give it another shot.  Most of my services are now available through IPv6 and my local LAN has IPv6 connectivity. I’ll write more about that in another post.