Http:// Bringing IPv6 connectivity to the general public

http://www.ipng.nl/

Bringing IPv6 connectivity to the general public

IIR - Feb2002 Pim van Pelt <[email protected]> 2

ContentsPim van Pelt, Business Internet

Trends

[email protected]

IP next generations

http://www.ipng.nl/


ContentsIntroduction:

What is a tunnel broker Why should we develop/maintain

them Whom should we addressPart two: How did IPng tackle things Which services do we provide Open discussion: how to procede?


0.0 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


0.1 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


0.2 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


1.0 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


1.1 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


1.2 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


1.3 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


1.4 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


1.5 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(++)


1.6 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 endpointfping ported by Jeroen Massar


1.6 Daily maintenence

Downtime check (once daily) Mail users with excess downtime Try to keep them motivatedAlternatively: 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


1.7 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


1.8 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)


2.0 Services provided Stimulation of end users and

companies IPv6-only public services, such as

IRC (chat) server SMS portal Webhosting Mail and DNS service


2.1 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


3.0 Progress Future plans include

Prolongued tunnelbroker activity Roadmap for ISPs in the Netherlands Creating and maintaining IPv6

exchange points (Ede)


3.1 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


3.2 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


3.3 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


3.4 DiscussionQuestions, comments, discussion.

Dutch contact: [email protected]

Foreign input much appreciated

Documents

Http:// Bringing IPv6 connectivity to the general public