IPv6 - Internet protocol of Next Generation
IPv6 links
Tools
sudo apt-get install sipcalc
NAP-TPd
see: Building an IPv6 router with GNU/Linux and Official NAPTD download site
patched version (ubuntu/debian): naptd-0.4.aufbix1.tar.gz
Ubuntu 9.4 notes - should compile out-of-the-box
Debian 5.0 notes
you need changes around 690 line in src/alg_dns.cc:
+ next_byte = v6_address->in6_u.u6_addr8[15 - i]; - next_byte = v6_address->__in6_u.__u6_addr8[15 - i];
Ecdysis - open-source implementation of a NAT64 gateway
See: http://ecdysis.viagenie.ca/
Ecdysis is aimed to develop an open-source implementation of a NAT64 gateway to run on open-source operating systems such as Linux and BSD. The gateway is comprised of two distinct modules: the DNS ALG and the IP translator. The DNS ALG is implemented in two DNS open-source server: Unbound and Bind. The IP translator is implemented in Linux as kernel module using Netfilter faclities and in openBSD as a modification of PF.
Subnetting guides
see also:
The essential initial guidelines are:
ISP /32 Enough for 4billion ISPs Enough for each ISP to support 65,536 /48 customers or 16.7M /56 customers, etc. Larger ISPs can get more than a /32 if needed. End Site /48 Enough for 65,536 /64 subnets Larger organizations can get more than a /48 if needed. Single Subnet /64 Enough for more hosts that most of us can imagine on a single subnet. Support for 64 bit MAC addresses Support for stateless autoconfiguration
IPv6 Relative Network Sizes
128 | 1 IPv6 address | A network interface |
/64 | 1 IPv6 subnet | 18,446,744,073,709,551,616 IPv6 addresses |
/56 | 256 LAN segments | Popular prefix size for one subscriber site |
/48 | 65,536 LAN segments | Popular prefix size for one subscriber site |
/32 | 65,536 /48 subscriber sites | Minimum IPv6 allocation |
/24 | 16,777,216 subscriber sites | 256 times larger than the |
another great example from Nathan Ward <http://mailman.nanog.org/pipermail/nanog/2009-August/012681.html>
I have some things to say on this. I've padded some of the following with zeros to make it easier to read/understand. Let's say your allocation is 2001:db8::/32 (doc prefix) 2001:db8::/32 2001:db8::/48 - ISP use 2001:db8::/64 - ISP internal routers 2001:db8::/112 - 65K loopbacks for your routers 2001:db8::0001:0/112 .. through .. 2001:db8::ffff:ffff:ffff:0/112 - 281 trillion link nets between your routers 2001:db8:0000:0001::/64 .. through .. 2001:db8:0000:ffff::/64 - 65K-1 /64s for ISP servers, offices, etc. etc. 2001:db8:0001::/48 .. through .. 2001:db8:000f::/48 - 9M Customer link nets 2001:db8:0010::/48 .. through .. 2001:db8:ffff::/48 - Assigned to customers Some notes: 1) The "Customer link nets" block should be long enough for you to get one link net per customer tail. You should do /64s for link nets to customers, unless you are *certain* that *all* customer devices will support whatever else you choose to use. The 15 I have suggested here gives you ~9M. 2) The "Assigned to customers" block can be chopped up in to /48s or / 56s or /60s or whatever your want. I recommend chopping customer prefixes on 4-bit boundaries (4 bits per hex digit). Less IP math in your head = easier life. Especially for helpdesk staff, and customers themselves. 3) Filter the "ISP internal routers" prefix at your border. This is equivalent to your /30s, /31s and /32s in IPv4 land. 4) The reason we have the loopbacks in the very first /112, is you will have to type them a lot, and fudging them can make your network melt down. 5) The reason we have the ISP internal /64s in the first /64s, is for the same reason as (4). 6) The reason we have ISP servers etc. in the following /64s, is these are also short to type, which means customers and first line support can type your DNS server addresses easily, read them over the phone, etc. 7) Allow the first /48 through all your filters that normally impact customers - and rate shaping, etc. etc. This first /48 is for ISP stuff, no customers should ever be on it. This is the only place where ISP stuff should ever live. You will have a temptation to chop your customer address space up in to "City", "POP", etc. I recommend resisting that - you are reinventing classful addressing, and when one POP or city grows too large, you have to make exceptions to your rules. Instead, when you need new addresses in an area (ie. you need more than zero IPv6 addresses at a POP) assign it a /48. Then when you need more, assign it another /48. You can do this intelligently, using the binary chop/sparse allocation method that Geoff Huston has written about. This lets you grow your / 48s in to /47s, or /46s as need arises. By doing your assignment this way, you don't get tied in to silly rules, nor do you get IGP bloat. I have an extensible IP management tool that I've been hacking on heaps in the last week that does this stuff for you. It should be ready for people to tinker with in the next few weeks.
IPv6 Optimal Address Plan and Allocation Tool
As described in section 23.3.31 of the [http://www.ipv6book.ca/index.html Migrating to IPv6 book] and in RFC 3531, this web tool implements [http://www.ipv6book.ca/ietf/rfc/rfc3531.txt RFC 3531] and helps network managers to make an IPv6 address plan for any network, such as provider and enterprise networks, specially when there are multiple levels of delegations.
Usage Example
You are a provider and own the prefix 2001:db8::/32. You want to generate a list of /40 prefixes for your downstream providers.
- Enter the start prefix (i.e. 2001:db8::/32).
- Specify the number of bits you want to allocate. If you allocate 25 downstream providers, choose 6 bits (for a maximum of 32).
- Choose the bit allocation algorithm.
- leftmost when you have the leftmost prefix and you are the first(highest) level of delegation.
- centermost when you are not the first(highest) nor the last(lowest) level of delegation
- rightmost where you are the last level of delegation (usually when you are generating /64).
- Choose the number of prefixes to generate on the output.
- Select the output format: txt means no HTML formatting: one prefix per line.
DHCPv6
Howto have 2 or more IPv6 tunnels on one machine (Multihomed IPv6 Setup)
Version: 0.1.0, 2007-09-08
Philipp Kolmann <philipp at kolmann.at>
Since 2.6.19 linux has support for CONFIG_IPV6_MULTIPLE_TABLES (Support multiple routing tables) and since 2.6.20 CONFIG_IPV6_SUBTREES (Enable routing by source address or prefix).
With this infrastructure it is possible to have multiple IPv6 addresses on different subnets (read differnet SixxS tunnels to different POPs) working. With a normal setup, you would end up with one default route and route all traffic through this link.
My setup is the following:
One SixxS tunnel Maribor, Slovenia (sixxs-si), and one to Hamburg, Germany (sixxs-de).
First added a new table to /etc/iproute2/rt_tables: echo "100 sixxs" >> /etc/iproute2/rt_tables
In /etc/network/interfaces
I have the following setup (Static IPv4 Adress):
auto sixxs-si iface sixxs-si inet6 v4tunnel address 2001:1::2 netmask 64 endpoint 212.18.63.73 ttl 64 up ip link set mtu 1280 dev sixxs-si up ip route add default via 2001:1::1 dev sixxs-si auto sixxs-de iface sixxs-de inet6 v4tunnel address 2001:ffff::2 netmask 64 endpoint 212.224.0.188 ttl 64 up ip link set mtu 1280 dev sixxs-de up ip -6 rule add from 2001:ffff::2 table sixxs up ip -6 route add default via 2001:ffff::1 table sixxs down ip -6 rule del table sixxs down ip -6 route flush table sixxs
IPv6 adresses are not the actual ones.