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