Whilst IPv6 deployment will usually "just work", and may even just be handled by a broadband router and an ISP that do IPv6 (like AAISP), if you are setting up a network (e.g. large office, or multiple sites, etc) you have to consider things a tad more carefully.
This is especially important for an ISP like us, as we have to be able to understand the IPv6 addresses themselves if trying to debug the network when things break (and one thing that can break is DNS, or access to it).
Side track: We have had a couple of cases recently with support where a customer has had some issue which means he cannot get on-line properly. Usually with their machine or network. However, they have got on irc to ask for help! This is because the IPv6 just works. Always amusing someone using the Internet to ask for help because the Internet is not working.
Numbering the LAN
Each LAN will be a /64, that is pretty much defacto now. As an ISP we allocate people a /48 to deploy as they wish. If you have many sites you probably want to split the /48 in to parts, e.g. a /56 per site allowing 256 sites, and 256 LANs per site. This will depend a lot on how you manage sites now. If you have any sort of site numbering, you could perhaps use that as part of the address.
If the sites need independent BGP announced routing you will want to consider additional /48's. It seems you can get a /48 to propagate around the Internet to some extent. As long as someone announcing something bigger (e.g. a /32) can see all your /48's then the /48's themselves do not have to go everywhere in the Internet. It is also not nice to make lots of separate /48s in BGP if you can avoid it. As with IPv4 routing there is no guarantee of routeability of any block so you need to play nice if you want things to work.
This weekend we changed our office allocation to a /47, i.e. two adjacent /48s. This allows a single filter in access lists, but allows one /48 at each of the two independent sites we run, though we have the /32 from one site to cover any filtered routes. This means the choice of /48 is simple geography for us.
We have to then think of the LAN allocation. 65536 possible LANs in a /48.
I think the best advice here is try and be as logical as possible - if you have any existing site numbering scheme, see if that can fit in. If not, try and make one that works with the IPv6 allocations as well.
Hex and decimal
One of the interesting things we see a lot, and do ourselves, is the use of a decimal number from something else, put in to an IPv6 address in some way, but as hex.
e.g. if you had site number 42 (decimal), you may use :42: in the IPv6 Address, even though that is actually 66 (decimal) as the "42" is in hex.
Given that the only reason to use numbering from something else, such as a site number, protocol number, machine number, dialling code, etc, is for your own convenience, then I think this makes sense. You do not want to have to be doing hex/decimal conversions to see and use the "logic" you have created here.
If you have a server for some reason, then you will want it in DNS. You could use an automatic address, but that means change of DNS on change of Ethernet card or move to a new machine, etc. It seems logical to make a server address a fixed address.
What we came up with, and I would be interested in comments on, was using the protocol number in the IPv6 address. E.g a web server on port 80 includes 80 (hex) in the address. E.g. 2001:db8::80
In practice we almost always have multiple servers for anything at a site, usually labeled A, B, C, etc. So we chose to make the protocol and instance in the address.
e.g. the 3rd web server at a site is 2001:db8::80:3
Of course, this begs the questions, if we call that c.webserver then why not 2001:db8::80:C but there are cases where we go over F in lettering servers, and so that breaks. Numbering is fine, and maybe we should have 3.webserver rather than c.webserver anyway? Of course I is :9, J is :10, K is :11, up to Z being :26, even though "10" is 16 (decimal) :-)
Bear in mind that you can give a machine multiple addresses, so you could stick to this protocol based address numbering and allow services to move between machines while keeping addresses. e.g. 2001:db8::443:3 and 2001:db8::80:3 may indeed be the same machine (one for https and one for http). You could even ensure the services bind only to the address specified for them.
They work. As long as you don't change the Ethernet interface they are consistent. They can quite validly be what you use and what you put in DNS.
We are moving away from this for any servers (as above), but not sure it is a good or bad idea to use automatic addresses.
PCs on desks can, of course, get automatic addresses. We are not sure if this is the best choice or not. It helps a lot in renumbering but makes it hard to track for reverse DNS, etc.
We did think of matching some other scheme, such as peoples telephone extension numbers being part of the IPv6 address.
Arrrg! Who was so paranoid to invent this. I cannot even turn it off on my iPad. I have even set my LAN to use DHCPv6 and flag the router announcements as "Managed", and it still does privacy addressing. I have no hope of having sensible reverse DNS on access logs to our systems.
OK, yes, I can see why some people want this, but I can't see me using it (apart from the iPad).
We would love a way to set the bottom 64 bits in a config, but leave the top 64 bits (as well as DNS and router) as automatic. This makes renumbering easy, and DNS would be a simple search replace if we did. But I don't know if that can be done on any PCs.
Of course we all want to be clever. Guess who's site is 2620:0:1cfe:face:b00c::3 though we are surprised someone else is not using 6009:1e in their addresses...
So do we make our machines only use A B C D E F I Z S T O ?
We have managed ec-office (ec0f:f1ce), and faceless (face:1e55), and even boxless (b0c5:1e55).
I don't know if this is good or bad. If the words can be made obvious enough, maybe. What do people think?
IPv4 address based
One thing that we have been told, and I am inclined to agree with, is not to base static IPv6 addresses on IPv4 address. Don't make the machine with 203.0.113.123 use 2001:db8::203.0.113.123
For a start it does not help readability as it shows in hex (e.g 2001:db8::cb00:717b).
Secondly it will get out of step, and then be even less use and could cause more confusion.
The first address on an IPv6 LAN is special, as it is an anycast for the router. We have used that with no problem for that purpose.
However, it seems linux does treat it as special when accessing it. I am not 100% sure why (someone quote me an RFC). I.e. a machine accessing it should simply ND for it, and get the address. linux seems unwilling to answer a ping from such an address. Maybe something else is odd about it.
What we have tended to do is put a router address on a LAN as
In general you do not have to say the router address as it is set by router announcements advising the MAC to use. If using VRRP you the router announcements should announce the special VRRP MAC address to ensure fast switching. However, if manually configuring a box so that it does not get an automatic address then we are having to tell the box the router address. So we have to consider what address to use.