IPv6 - Internet protocol of Next Generation



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::/48 - ISP use
  2001:db8::/64 - ISP internal routers
   2001:db8::/112 - 65K loopbacks for your routers
    .. through ..
   2001:db8::ffff:ffff:ffff:0/112 - 281 trillion link nets between  
your routers
    .. through ..
   2001:db8:0000:ffff::/64 - 65K-1 /64s for ISP servers, offices, etc.  
  .. through ..
2001:db8:000f::/48 - 9M Customer link nets
  .. 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  
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,  
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.

Last prefix allocated:
Number of bits (range):
Bit Allocation Algorithm: leftmost centermost rightmost
Number of prefixes to generate:
Output format
HTML Tabletxt

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.


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
  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
  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.

networking/ipv6.txt · Last modified: 2012/10/27 13:10 by a
CC Attribution-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0 ipv6 ready