Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
networking:ipv6 [2009/02/15 17:30] a |
networking:ipv6 [2012/10/27 13:10] (current) a [Subnetting guides] |
||
---|---|---|---|
Line 10: | Line 10: | ||
* [[http:// | * [[http:// | ||
* [[http:// | * [[http:// | ||
+ | * **[[http:// | ||
+ | * **[[http:// | ||
</ | </ | ||
< | < | ||
Line 18: | Line 20: | ||
sudo apt-get install sipcalc | sudo apt-get install sipcalc | ||
+ | ===== NAP-TPd ===== | ||
+ | see: [[http:// | ||
+ | |||
+ | patched version (ubuntu/ | ||
+ | |||
+ | **Ubuntu 9.4 notes** - should compile out-of-the-box | ||
+ | |||
+ | **Debian 5.0 notes** \\ | ||
+ | you need changes around 690 line in src/ | ||
+ | + next_byte = v6_address-> | ||
+ | - next_byte = v6_address-> | ||
+ | |||
+ | ===== Ecdysis - open-source implementation of a NAT64 gateway ===== | ||
+ | |||
+ | See: http:// | ||
+ | |||
+ | //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 | ||
+ | |||
+ | ===== Subnetting guides ===== | ||
+ | see also: | ||
+ | * [[: | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | \\ | ||
+ | **The essential initial guidelines are:** | ||
+ | |||
+ | < | ||
+ | ISP /32 | ||
+ | Enough for 4billion ISPs | ||
+ | Enough for each ISP to support 65,536 /48 customers or 16.7M / | ||
+ | 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 | ||
+ | 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 | ||
+ | | /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/ | ||
+ | |||
+ | Let's say your allocation is 2001: | ||
+ | |||
+ | 2001: | ||
+ | 2001: | ||
+ | 2001: | ||
+ | | ||
+ | | ||
+ | .. through .. | ||
+ | | ||
+ | your routers | ||
+ | | ||
+ | .. through .. | ||
+ | | ||
+ | etc. | ||
+ | 2001: | ||
+ | .. through .. | ||
+ | 2001: | ||
+ | 2001: | ||
+ | .. through .. | ||
+ | 2001: | ||
+ | |||
+ | |||
+ | Some notes: | ||
+ | 1) The " | ||
+ | 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 " | ||
+ | 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" | ||
+ | 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 " | ||
+ | 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, | ||
+ | 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:// | ||
+ | < | ||
+ | <form method=" | ||
+ | <table border=" | ||
+ | < | ||
+ | <tr> | ||
+ | |||
+ | < | ||
+ | < | ||
+ | | ||
+ | </tr> | ||
+ | <tr> | ||
+ | < | ||
+ | < | ||
+ | </tr> | ||
+ | <tr> | ||
+ | |||
+ | < | ||
+ | < | ||
+ | | ||
+ | | ||
+ | </tr> | ||
+ | <tr> | ||
+ | < | ||
+ | < | ||
+ | |||
+ | </tr> | ||
+ | <tr> | ||
+ | < | ||
+ | </th> | ||
+ | < | ||
+ | | ||
+ | </tr> | ||
+ | </ | ||
+ | |||
+ | </ | ||
+ | <input value=" | ||
+ | | ||
+ | |||
+ | === Usage Example === | ||
+ | |||
+ | You are a provider and own the prefix 2001: | ||
+ | |||
+ | * Enter the start prefix (i.e. 2001: | ||
+ | * 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:// | ||
+ | * http:// | ||