Monthly Archives: April 2013

How to get familiar with IPv6

As there is no real progress in my piano sessions due to the lack of time and blah :) I just have another nice topic which costs me a couple of hours I want you to spend more efficient.

This is meant to be a double post, as it is handling the IPv6 tunneling topic in two variations: as a setup on a linux host and as one on a Cisco router.

– the linux part:

I was using a DSL modem in bridged mode with ppp dailup on a linux host behind becuase the modem was not able to handle IPv6 not even in an unstable mode.

As I now got a Cisco 877VA as my new CPE I am now able to use IPv6 natively if my provider would also support IPv6 on the dialup accounts. I was to nosy to see what IPv6 can do for me and my annoying NAT issueus on the Cisco router that I decided to go for an 6to4-tunnel for the first sight.
There the services of SixXS (http://www.sixxsx.net) came in place because they are giving you your first tunnel for free.
To asure that you are using IPv6 they are monitoring your first connection and your’re earning ISK for keepong up the tunnel to get more services as a /64 net and another tunnel and more.

So first of all (before the Cisco setup) I built the tunnel with the recommended linux client aiccu which is well documented and easy to set up

#aiccu.conf

username your-SIXXS-user
password your-SIXXS-pass
protocol tic
server tic.sixxs.net

ipv6_interface sixxs
tunnel_id your-SIXXS-tunnel-id

verbose true
daemonize true
automatic true
requiretls false
pidfile /run/aiccu.pid
defaultroute true

If you’re happy to only have an tunnel running to repack your IPv4 traffic to the IPv6 network on your default gateway your’re fine by now. If not, you’re a bit like me: I was also interesed in running my own v6 network to shut down IPv4 step by step as most of my devices at home are able to run on v6.

So there your earned ISK’s are good to check out a /64 net and set up radvd as a route advertiser to spread IPv6 addresses to all devices which are responding properly on a v6 broadcast. This radvd is also easy to set up and can autoconfigure your devices in a single second.

#radvd.conf

interface eth1
{
	AdvSendAdvert on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 10;
	prefix 2001:your-SIXXS-IPv6-prefix::/64
	{
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
	};
};

– the cisco part:

there is a pretty good documentation in the wiki of SixXS (https://www.sixxs.net/wiki/Cisco/) itself, so I just give you a quick look on the tunnel interface and the _really needed_ access-lists in the ZBF (zone based firewall) on the router which are covering the security issues you’ll have as there is no NAT in a default IPv6 network.

!
interface Tunnel6
 description +++ 4to6 Tunnel to SIXXS +++
 no ip address
 ip tcp adjust-mss 1420
 ipv6 address 2001:your-SIXXS-Linknet::2/64
 ipv6 enable
 ipv6 inspect cbac-ipv6 out
 ipv6 traffic-filter ipv6-internet-in in
 tunnel source Dialer0
 tunnel mode ipv6ip
 tunnel destination your-SIXXS-ipv4-tunneldest
end
!
ipv6 route ::/0 Tunnel6

to let the garbage outside you should apply at least this

ipv6 access-list ipv6-internet-in
 remark allow ping by SixXS PoP to determine tunnel status
 permit icmp host 2001:your-SIXXS-Linknet::1 host 2001:your-SIXXS-Linknet::2 echo-request
 remark Prevent spoofing
 deny ipv6 2001:your-SIXXS-Prefix::/64 any log
 remark prevent ingress of all addresses except global unicast and multicast
 deny ipv6 ::/3 any log
 deny ipv6 8000::/2 any log
 deny ipv6 C000::/3 any log
 deny ipv6 E000::/4 any log
 deny ipv6 F000::/5 any log
 deny ipv6 F800::/6 any log
 deny ipv6 FC00::/7 any log
 deny ipv6 FE00::/8 any log
 permit icmp any any time-exceeded
 permit icmp any any packet-too-big
 permit icmp any any echo-request
 permit icmp any any echo-reply
 deny ipv6 any any log

So if all is aisd and done, you can check on http://kame.net if your turtle is dancing; if so, you did everything right, congratulations! Have fun using next genration IP network.

die MTU, dein Freund und Kopfzerbrecher

Liebe Leute lasst euch sagen: ppp encapsultaion kann schon glücklich machen im österreichischen ADSL-Land, dann wenn man vergisst, dass die Einkapselung die MTU/MSS-Sizes automatisch repariert, wenn man via pptp-client über ein (gutes) altes Thomson Modem einwählt.

Ersetzt man nun, wie in meinem Fall, dieses “Linux-Host macht Einwahl über Modem”-Konstrukt durch einen Cisco als Zugang ins weite Internetz, dann muss man den Tanz der Segments, Frames & Packets tanzen:

MTU 1500 ist im LAN noch ok, aber über WAN meist ungünstig, daher prüft man am besten mittels swipe-ping, welche maximale Größe denn überhaupt unterstützt wird:

dsl-knecht#ping
Protocol [ip]:
Target IP address: 195.96.0.4
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1400
Sweep max size [18024]: 1520
Sweep interval [1]:
Type escape sequence to abort.
Sending 121, [1400..1520]-byte ICMP Echos to 195.96.0.4, timeout is 2 seconds:
!!!!!!!!!!!!!!!......!!!!!!!!!!!!!!!!!!......!!......!!......!!......!
!......!!......!!......!!..........................
Success rate is 38 percent (47/121), round-trip min/avg/max = 124/132/136 ms
dsl-knecht#

Hier sieht man also schön, daß bei 1415 byte die ersten Packets gedropped werden, was also die max. MTU darstellt…

daher hab ich auf die Schnelle in meinem Dialer-Interface am Cisco 887 VA folgende Zeilen konfiguriert, um den Bits wieder uneingeschränkten, aber fragmentierten Lauf zu lassen:

interface Dialer0
mtu 1415
ip tcp adjust-mss 1349
end

Der Wert der max. Segmentation Size (MSS sollte 40 byte unter der MTU liegen, da auf Layer 4 noch weitere Bytes für Falgging und Tagging verwendet werden – wenn man IPSec/GRE einsetzten will, dann sollte man – wie ich auch – nochmal 4 Bytes, also insgesamt 44 Bytes geringer  segmentieren. Dann funktionieren wieder alle Webseiten- und Datenaufrufe, welche die Payload des ETH-Frames mit den standardmässigen 1500 Bytes befüllen wollen wieder!

Ein Beispiel aus der Wikipedia, welches die Fragmentierung, Segemtierung und Tagging anschaulich darstellt:

# ping -s 1472 10.0.0.1
          1472 bytes Nutzlast des ICMP-Protokolles (Transportschicht)
        +    8 bytes ICMP-Header (Transportschicht)
        +   20 bytes IPv4-Header (der Vermittlungsschicht)
       -------------
        = 1500 bytes (Nutzlast von Ethernet)
        +   14 bytes (Header der Sicherungsschicht)
        +    4 bytes (Frame Check Sequence)
       -------------
        = 1518 bytes (kompletter Ethernetrahmen)

warum denn überhaupt?

…eine Frage, die ich mir viel zu oft stelle und beinahe genauso oft gestellt bekomme. Die Gründe dafür können zwar unterschiedlicher nicht sein, aber im Grunde läufts immer auf eines hinaus: mangelndes Verständnis. 😉

Wer jetzt noch nicht verwirrt ist, kann bleiben, jeder andere natürlich auch – hier gibt’s in erster Linie zu berichten, was mich so beschäftigt, ob das nun Klavier im Selbststudium, ein offenes Terminalfenster oder nette Seitenstränge in der Nacherzählung meines Lebens sind.

Klavier stellt für mich derzeit auch die größte und neueste Herausforderung dar. Um da nicht zu schnell aufzugeben braucht man gute Lehrbücher und gute Lehrmeister; mein Glück dass ich mit beidem ‘beschenkt’ wurde und der Ehrgeiz groß genug ist, um gleichmal mit der Ode an die Freude begonnen habe, weil mir diese thematisch auch am passendsten erschien. 😉