Differences

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

--- networking:ipv6 [2009/05/25 00:35]
127.0.0.1 external edit
+++ 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 31: / Line 32: @@
    - 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: [[http://www.ripe.net/info/info-services/addressing.html|IP Allocation Rates on RIPE-NCC site]]
+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:**
@@ Line 64: / Line 70: @@
 | /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 =====