Today was a more hands on introduction to IPv6. John Barlow the Advanced Communications Services Coordinator for AARnet gave all of today's presentations and started out the day with "IPv6 101 Hands On". This in some respects was a rehash of some things covered yesterday, but it did cover some more technical type issues.

One interesting comment made was that NAT has a happy side effect of enhancing security (which I know and exploit regularly). However, John tells us that NAT can be hacked to get at machines behind the NAT gateway, which is something I really need to investigate further. The

basic structure of the IPv6 address space is as follow: The IPv6 equivalent of 127.0.0.1 is ::1. Most globally routable IPv6 IP's start with 2001: and current best practice dictates that these are the only IPs to be routed across the backbone. IPv6 IP's starting with fe80: indicate a "link local" address. Link local addresses are used for bootstrapping, autoconfiguration, etc and should not be propagated beyond a router.

Fec0::/10 are site local addresses (similar to the private IP ranges in IPv4) ut the use of these has been or will be deprecated shortly. :FFFF:a.b.c.d are mapped IPv4 addresses, and don't actually exist, but might show up in logs. ::a.b.c.d addresses are used to arrange tunnels. There are more prefixes allocated, but many are not currently used, so the above are the commonly seen IPv6 addresses.

Unlike DHCP, IPv6 autoconfiguration does not assign name servers, time servers, etc. Other solutions such as anycast addressing, etc can be used to work around this, but no mechanism has been standardized at this stage.

IPv6 uses a simpler header than IPv4, many un used, or less commonly used fields are dropped or moved into extension headers. An IPv4 header is a fixed 40 bytes, with important fields aligned on 64 bit boundaries for faster processing on 64 bit architectures. Extension headers are a fixed 64 bits each in length and follow the main header. One of the design goals of IPv6 was to ensure that routers do minimal processing of packets. IPv6 packets can't be fragmented in transit, which makes ICMP MTU discovery mandatory.

A workshop session followed, during which we were walked through IPv6 setup on our own machines. The demo was done on Linux. However the WiFi coverage where I was sitting in the Lecture Theatre was pretty spotty (more off than on), so I wasn't able to get much going, gave up and went to lunch.

After lunch John finished off the workshop session by showing an IPv6 router setup on Linux. There is a daemon called radvd (Router Advertisement Daemon) which handles the router multicast packets required for autoconfiguration. Quogga (used to be Zebra) handles the BGB, etc required for serious internet routing.

Next up was a session on Provider Independent Addressing (PIA). From the sounds of things this is now pretty much dead in the water, and in fact current best practices will prevent PIA packets from being routed.

Essentially PIA allocates a /48 network to every 10 x 10 metre square of the earths surface (including oceans). The network prefix is mathematically derived from the Latitude and Longitude coordinates of your current locations. However there are no algorithms for resolving conflicts (e.g. multiple floors of a building, or an aircraft flying overhead), and in fact the suggested remedy was to "pick some random suare of ocean and use that" in the event of conflicts.

We then covered IPv6 Global Routing. Essentially obtaining an IPv6 address block is simple. You just go to APNIC and commit to handing out 200 /48's to customers in the next two years. However, most of us will simply obtain our allocations from our ISP, but this means that you can't take your allocation with you when you change ISP's. However the old days of getting your own class C and having it routed via any ISP are over with IPv6. To control the growth of the routing tables IPv6 address space is being allocated only to ISPs, hence the requirement to allocate 200 networks above.

Finally we had an "Issues with IPv6" presentation which covered some of the issues in an IPv6 migration.

Autoconfiguration will mean that Dynamic DNS will become almost a necessity for mot organizations. However, most common DNS servers (e.g. BIND) will handle IPv6 addresses.

Application support is pretty good, but traditional network file sharing protocols such as SMB and NFS are yet to be upgraded to IPv6.

The Linux IPv6 HOWTO is updated regularly and is an excellent source of information related to IPv6 and migration issues.

IPv6 should run over pretty much any Layer 2 hardware (e.g. hubs, network cards, wireless gear) without problems. Most Layer 3 devices (such as routers) should only need a software upgrade in order to deal with IPv6, but some switches and routers which use hardware acceleration to process packets and therefore may need to be replaced before they achieve full throughput/functionality.

Because all IPv6 addresses are provider assigned multihoming for reliability becomes awkward and usually becomes something that needs to be negotiated with the ISP's concerned. In theory it should work, but in practice its difficult.

There is also a thing called NAT-PT which is an IPv6 NAT into IPv4 and back again. As per traditional NAT each protocol needs to be handled individually. NAT-PT is achieved via a DNS Server hack and some additional bindings on the IPv6 interface. Its pretty nasty, but is a reasonable migration tool.

All slides from today's (and some of yesterdays) presentations can be found on AARNet's site . Overall I've learnt a lot from the IPv6 MiniConf, and its been a pretty worthwhile experience. The main conference starts tomorrow, can't wait.