Bringing IPv6 connectivity to the general public

IIR - Feb2002Pim van Pelt 2 Contents Pim van Pelt, Business Internet Trends IP next generations

IIR - Feb2002Pim van Pelt 3 Contents Introduction: What is a tunnel broker Why should we develop/maintain them Whom should we address Part two: How did IPng tackle things Which services do we provide Open discussion: how to procede?

IIR - Feb2002Pim van Pelt Tunnelbroker A term for an IPv4/IPv6 connected host IPv6 connectivity via proto-41 tunnels IPv4 connectivity at a well connected site Informative web- and portal site A place where end users can turn to with operational matters Tracking and active maintenance of: Users and their activities Peering and transit issues

IIR - Feb2002Pim van Pelt Why deploy ? Bring IPv6 to the public Advocate the use of IPv6 properly to end users (company and individual) Gain a user base, and thus: Gain expertise on the matter with a live network Collect invaluable feedback from the field Present cases and bug reports to vendors

IIR - Feb2002Pim van Pelt Whom to address ? Companies Enabling engineers to take a look at the operational tasks in IPv6 Stimulating provision: top-down from ISP to end user Private individuals Gaining a higher educational level of Internet users Creating demand: bottom-up from end user to ISP

IIR - Feb2002Pim van Pelt Tunnelbroker system Find an answer to the following topics: IPv6 aggregation – pTLA or sTLA Local user authenticity, validity Database structure Tunnelserver OS choice Tunnelserver configuration IP filtering and abuse (DDoS) Addressing local users

IIR - Feb2002Pim van Pelt pTLA or sTLA sTLA are production quality, native connection oriented, b2b pTLA are meant for testing deployments (using proto-41 tunneling), b2bc IPng uses pTLA because Absence of official collaboration between network operators Use of tunnels degrades network stability

IIR - Feb2002Pim van Pelt Registering users Name, address, phone number We require users to create person objects at the 6bone registry Needed to create preliminary barrier Help keeping abuse kids out Help administer IPng at whois.6bone.net We use the nichdl to uniquely identify the user

IIR - Feb2002Pim van Pelt DB Structure MySQL is DBM of choice Table of users, by nichdl Table of tunnels, one per nichdl Table of subnet allocations, one per tunnel Blacklist and deletion tracking Recividist malicious users IPv4 networks denied access (prior abuse) Notes and things for internal use Reasons for tunnel deletion

IIR - Feb2002Pim van Pelt OS choice Linux Pro: dynamic amt of tunnel devices (sit) and /proc for device stats gathering Con: difficult scope handling, uncertain stability BSD Pro: decent IP filtering, proper scope handling (ff02::2%gif0), greater stability Con: static amt. of tunnel devices (gif) Cisco IOS Con: expensive, relatively low pps Pro: solid state, corporate, stable

IIR - Feb2002Pim van Pelt Server config We chose Linux, kernel 2.4 Simple scripting for tunnel maintenance Newtunnel.sh, newsubnet.sh, movetunnel.sh Automatic mailing system with autoresponses Possibility of ‘cronned’ tasks Packet/octet counters Hourly pingstats and daily uptime checks Dynamic filtering Ease of use – perl, sh, pike, c(++)

IIR - Feb2002Pim van Pelt Daily maintenence Traffic statistics (five-minutely) Track bandwidth consumption (bps) Find possible attack victims (pps) rrdtool by Tobias Oetiker Ping statistics (hourly) Check latency Check packet loss Check availability of remote endpoint fping ported by Jeroen Massar

IIR - Feb2002Pim van Pelt Daily maintenence Downtime check (once daily) Mail users with excess downtime Try to keep them motivated Alternatively: Get rid of non-participating users DNS checkup (four times a day) Do not delegate downstream DNS (lame) Grab zone files, process them into a large zone file and publish this via IPng DNS Shellscripts for unix, dig(1) and bind 9.2

IIR - Feb2002Pim van Pelt IP filtering Handle IPv4 incoming traffic Accept traffic only from known destinations Handle IPv4 outgoing traffic Never send proto-41 traffic to unexpecting nodes 24/7 static IP for remote users Deny non-local IPv6 traffic from downstreams

IIR - Feb2002Pim van Pelt DDoS attacks Public IPv6 sites get attacked too Primary reason: IRC abuse Take care with unknown users on IRC Common attack forms Stacheldraht UDP/TCP fragmentation attacks Let IPv4 transit providers block your tunnel endpoint at their border, allow only proto-41 Use PI space and don’t announce to transit providers (no route to you from non peered nets)

IIR - Feb2002Pim van Pelt Services provided Stimulation of end users and companies IPv6-only public services, such as IRC (chat) server SMS portal Webhosting Mail and DNS service

IIR - Feb2002Pim van Pelt Expertise gained Feedback from the users to the vendor User remarks, requests, findings Representing users at conferences Feedback from community to users Relaying new policies from 6bone Forming and commenting on RFCs

IIR - Feb2002Pim van Pelt Progress Future plans include Prolongued tunnelbroker activity Roadmap for ISPs in the Netherlands Creating and maintaining IPv6 exchange points (Ede)

IIR - Feb2002Pim van Pelt Roadmap to IPv6 A working group of predominantly Dutch ISPs (xs4all, bit, intouch) Creating a step-by-step introduction for AMS-IX connected sites Consulting, helping and explaining these businesses how they could start to use IPv6 Ultimately: interconnecting their AS

IIR - Feb2002Pim van Pelt IX activity Connecting to AMS-IX natively Jumpstarting traffic exchange on own hardware – respecting AMS-IX board Offering alternative peering points Ede, Gelderland Almere, Flevoland Amsterdam, Zuid Holland Interconnecting these Exchanges

IIR - Feb2002Pim van Pelt Collaboration Each company chips in to create European and global consensus on how to educate new ISPs and telco industries We offer support and software for those wanting to set up a tunnelbroker

IIR - Feb2002Pim van Pelt Discussion Questions, comments, discussion. Dutch contact: Foreign input much appreciated