IPv6 - Internet protocol of Next Generation

• http://www.routemeister.net/projects/sipcalc/index.html

 sudo apt-get install sipcalc

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];

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.

see also:

• IPv6 subnetting guides
• IP Allocation Rates on RIPE-NCC site
• IPv6 Addressing Plans

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

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.

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.

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.

• https://fedorahosted.org/dhcpv6/
• http://klub.com.pl/dhcpv6/

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.