Differences

This shows you the differences between two versions of the page.

--- networking:ipv6 [2009/03/24 16:04]
a + IPv6 Reverse DNS Zone Builder for BIND 8/9
+++ networking:ipv6 [2012/10/27 13:10] (current)
a [Subnetting guides]
@@ Line 11: / Line 11: @@
   * [[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]]**
 </box>
 <html></div></html>
@@ Line 18: / Line 19: @@
    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 =====
-The essential initial guidelines are:
+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:**
 <code>
-        ISP             /32
+ISP             /32
-                        Enough for 4billion ISPs
+                Enough for 4billion ISPs
-                        Enough for each ISP to support 65,536 /48 customers or 16.7M /56
+                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.
+                customers, etc. Larger ISPs can get more than a /32 if needed.
-        End Site        /48
+End Site        /48
-                        Enough for 65,536 /64 subnets
+                Enough for 65,536 /64 subnets
-                        Larger organizations can get more than a /48 if needed.
+                Larger organizations can get more than a /48 if needed.
-        Single Subnet   /64
+Single Subnet   /64
-                        Enough for more hosts that most of us can imagine on a single subnet.
+                Enough for more hosts that most of us can imagine on a single subnet.
-                        Support for 64 bit MAC addresses
+                Support for 64 bit MAC addresses
-                        Support for stateless autoconfiguration
+                Support for stateless autoconfiguration
 </code>
+**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>
+<code>
+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)
+:db8::/32
+:db8::/48 - ISP use
+:db8::/64 - ISP internal routers
+:db8::/112 - 65K loopbacks for your routers
+:db8::0001:0/112
+    .. through ..
+:db8::ffff:ffff:ffff:0/112 - 281 trillion link nets between
+your routers
+:db8:0000:0001::/64
+    .. through ..
+:db8:0000:ffff::/64 - 65K-1 /64s for ISP servers, offices, etc.
+etc.
+:db8:0001::/48
+  .. through ..
+:db8:000f::/48 - 9M Customer link nets
+:db8:0010::/48
+  .. through ..
+:db8:ffff::/48 - Assigned to customers
+Some notes:
+) 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.
+) The "Assigned to customers" block can be chopped up in to /48s or /
+s 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.
+) Filter the "ISP internal routers" prefix at your border. This is
+equivalent to your /30s, /31s and /32s in IPv4 land.
+) 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.
+) The reason we have the ISP internal /64s in the first /64s, is for
+the same reason as (4).
+) 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.
+) 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 /
+s 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.
+</code>
+==== 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.
+<html>
+<form method="get" action="http://www.ipv6book.ca/cgi-bin/allocation">
+        <table border="1">
+          <tbody>
+            <tr>
+              <th>Last prefix allocated:</th>
+              <td><input name="prefix" value="2001:db8::/32" size="43"
+ maxlength="43"></td>
+            </tr>
+            <tr>
+              <th>Number of bits (range):</th>
+              <td><input name="nbits" value="6" size="3" maxlength="3"></td>
+            </tr>
+            <tr>
+              <th>Bit Allocation Algorithm:</th>
+              <td><input name="method" value="l" type="radio">leftmost <input
+ name="method" value="c" checked="checked" type="radio">centermost <input
+ name="method" value="r" type="radio">rightmost</td>
+            </tr>
+            <tr>
+              <th>Number of prefixes to generate:</th>
+              <td><input name="nseq" value="25" size="5" maxlength="5"></td>
+            </tr>
+            <tr>
+              <th>Output format<br>
+              </th>
+              <td><input name="output" value="t" checked="checked"
+ type="radio">HTML Table<input name="output" value="r" type="radio">txt</td>
+            </tr>
+          </tbody>
+        </table>
+        <input value="Show Prefix Allocations" type="submit"> <input
+ type="reset"> </form></html>
+=== 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 =====