====== IPv6 - Internet protocol of Next Generation ======
* **[[http://www.liquidalchemy.com/liquidalchemy/|IPv6 Subnet Calculator]]**
* **[[http://techie.devnull.cz/ipv6/ipv6gen/|ipv6gen - IPv6 prefix generator]]**
* [[http://www.ripe.net/rs/ipv6/|IPv6 Home on RIPE.net site]]
* [[https://www.sixxs.net/|SixXS - IPv6 Deployment & Tunnel Broker]]
* [[http://www.kfu.com/~nsayer/6to4/|Public IPv6 2 IPv4 relay routers]]
* [[http://tools.ietf.org/html/rfc5375|IPv6 Unicast Address Assignment Considerations]]
* [[http://tools.ietf.org/html/rfc1930|Guidelines for creation, selection, and registration of an Autonomous System (AS)]]
* **[[http://www.fpsn.net/index.cgi?pg=tools&tool=ipv6-inaddr|IPv6 Reverse DNS Zone Builder for BIND 8/9]]**
* **[[http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-628652.html|Use Domain Name System and IP Version 6]]**
===== Tools =====
* http://www.routemeister.net/projects/sipcalc/index.html
sudo apt-get install sipcalc
===== NAP-TPd =====
see: [[http://lucastomicki.net/ipv6.router.php|Building an IPv6 router with GNU/Linux]] and [[http://lucastomicki.net/naptd.download.php|Official NAPTD download site]]
patched version (ubuntu/debian): {{networking: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|openBSD]] as a modification of PF.//
===== Subnetting guides =====
see also:
* [[:networking:ipv6-subnetting|IPv6 subnetting guides]]
* [[http://www.ripe.net/info/info-services/addressing.html|IP Allocation Rates on RIPE-NCC site]]
* [[http://www.getipv6.info/index.php/IPv6_Addressing_Plans|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**
|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
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 =====
* https://fedorahosted.org/dhcpv6/
* http://klub.com.pl/dhcpv6/
===== Howto have 2 or more IPv6 tunnels on one machine (Multihomed IPv6 Setup) =====
[[http://www.kolmann.at/philipp/linux/IPv6-Multihome-Howto.txt|Version: 0.1.0, 2007-09-08]] \\
Philipp Kolmann
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.