How to choose IPv6 addresses for customer links?

[Jeroen Massar]

Martin List-Petersen wrote:
> Martin Horneffer wrote:
> [SNIP]
>> Would that be a sensible addressing scheme? Or would a customer insist
>> to get a completely independet /64 for the link addresses?
> 
> SixXS uses the approach commonly of assigning the link-addresses out of
> a seperate /48 in the PoP. One /40 per PoP.

To put a bit background there for that decision, if you 'steal' a /64
out of the customers /48 then the whole idea that the customer 'never
has to change their numberplan because they keep a /48 when changing
ISPs' goes away. Thus if they move from A t to B, and A uses the first
/64 for the link, but B uses the last /64 or another for the
transfer-link, then they have to renumber their network again. Also, it
quite inconvieniences the customer who can't nicely chunk the /48 into
/56's or something for eg per-building routes etc, as you stole a /64
out of one of those blocks. DHCP-PD also becomes easier as you say to it
"this /48" instead of "this /48 but not this /64 out of that".

Also if the complete /48 goes to the customer, then that is only one
route. If you steal a /64 from it, you have a /48 and a /64 from the
same block. Makes whois entries also clearer (you do register those
/48's nicely with an IRT object in whois do you?)


Thus IMHO and from my POV, use a /48 (or larger if you need >65k of
these links) for transfer links. This also makes it easy for you to
protect access links, eg just allow that /48 to do BGP with your routers
and exclude anything else. And route a full /48 to the customer.

Btw, you should have already done all of this when REQUESTING your
prefix from RIPE. Numberplans are important to them, they should also be
important to you.


Sidenote: In the SixXS case where we effectively fully control the
device that does the routing over the tunnels this addressingplan
simplifies routing a lot as we know that prefixes from <x>/48 are
'interfaces' (read: tunnels) to the users, while everything else has no
specifics, we where thus able to optimize routing a lot because of that
basically ignoring anything else ;)

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090130/bc52fc54/attachment.sig>