IPv6 Address Planning

Mark Andrews Mark_Andrews at isc.org
Thu Aug 11 06:33:30 UTC 2005


In article <1B11954B-DF25-458E-B2A7-E3A5FCBEC74E at muada.com> you write:
>
>On 10-aug-2005, at 18:03, Leo Bicknell wrote:
>
>> IPv6 allocations in the host portion (with /64 boundaries) are
>> sparce, even for the largest networks.  The number of hosts becomes
>> unimportant.  The question we need to ask is how many independant
>> subnets will they need.
>
>> This is why many people are proposing a /56 for home users, as it
>> gives you 256 subnets.  Still more than most people will need.
>
>> Others have proposed /52 and /60, since many want to claim DNS is
>> easier if done in nibbles.
>
>And the extra precision offered by the intermediate values isn't  
>really required at this point in the discussion.  :-)
>
>I'm very much oppossed to /56 because it's still more than most users  
>need. In and of itself that doesn't matter, but it's also less than  
>what some users need. This creates the situation where people try to  
>make do with a /56, find out that they need a /48 after all (all  
>those /64 ptps...) and have to renumber. I.e., /56 provides too much  
>potential for shooting yourself in the foot.

	So they need to renumber.  This really should not be a big
	deal.  IPv6 nodes should all support multiple prefixes,
	unlike the IPv4 world, so they should be able to transition
	gracefully from one prefix to the next.

	Add the new address to the DNS, withdraw the old one after
	a short period.  Similarly for PTR records.  With DNAME they
	don't even need to update the PTR's.  The routers just need
	to add new DNAME records.

	This still leaves firewall and other products which use raw
	IPv6 addresses.  However if the vendors of these products
	were to go through the exercise of renumbering I'm sure the
	most/all of the gotchas would disappear.

>I think we should go for /60 for (presumably) one-router networks.  
>That's still 3 to 5 times as many subnets as most of those will need.  
>Anyone else should get a /48.



More information about the NANOG mailing list