Hi Mark,<br><br>About aggregation :<br>You are the only responsible of the 16 bits you add after your /32 prefix. And their is no policy about how they are organized, only best current practices ...<br>I can describe to you the example for the French Research Network Renater :
<br>The addressing plan is 2001:660:GGCC<br>Prefix is 2001:660<br>8 bits are assigned to geographic region: GG<br>8 bits are for identifying customers : CC<br>This plan is running since 3 years and it seems to fits well their requirements.
<br><br>About addressing network interfaces:<br>IPv6 allows you to manually assign any IPv6 addresses you want one interfaces.<br>It is common practice to assign a manual address based on the service running : for instance a DNS server may have a manual address such as P:R:E:FIX::53
<br>Just remember the gold rule : manual addresses should have the 7th bit set to 0.<br><br>Regards,<br>-- <br>Bruno STEVANT<br>ENST Bretagne, France<br><br><div><span class="gmail_quote">On 1/15/07, <b class="gmail_sendername">
Mark J Elkins</b> <<a href="mailto:mje@posix.co.za">mje@posix.co.za</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Posix Systems was recently allocated some IPv6/32<br><br>I'm trying to understand how I can best meet both customer needs whilst<br>keeping good aggregation and have come up with the following:<br><br>1) I get assigned a /32 (2001:42a0::) - where '42a0' is what ever is
<br>assigned (ok - what Posix was assigned!)<br><br>2) I am more or less expected to assign /48's to customers..<br>..which generally leaves 16 bits to assign to customers<br><br><br>My goal is to aggregate as much as possible - whilst learning from past
<br>"mistakes".<br><br>It would therefore seem a reasonable thing to split these 16 bits into<br>something like 6 and 10. The first 6 bits (64 permutations) then becomes<br>a logical geographical area - eg. Joburg, Cape Town, Swaziland - etc.
<br>and the last 10 bits (1024 permutations) becomes a customer in that<br>area. This way - if the Cape Town peering point is ever re-resurrected,<br>I can use a single net-mask (ie Route) to advertise all my Cape Town<br>
clients to that peering center. I might in fact reserve more than one<br>set of 6 bits for the Johannesburg area (ie - 4 bits for the area and 12<br>bits for customers) - but that would probably be the only variation.<br>
I'm currently using 4bits for an area and the remainder for customers.<br>I'm also using a /48 in each area for internal use (ie - local hosting,<br>dial-up - etc), so if I loose long distant links - all the 'local' stuff
<br>would still work / be accessable.<br><br>As far as I can see - many LIR's simply allocate the next logical /48<br>block to the next customer and disregard any possibility of<br>regionalising IPv6 addresses.<br><br>
What do others think? Anything better?<br><br> ----------------------------------------------------------<br><br>Posix Systems (like other IPS's) does customer hosting of machines,<br>many of which need multiple IP addresses for different SSL sites - etc.
<br>An assumption is that most people would allocate a full /64 to an<br>Ethernet interface.<br><br>The simple mapping of a MAC address to the Host portion (ie - the last<br>64bits) of an IPv6 address does not allow for the easy addition of
<br>multiple IP's on the same machine. It does however make scanning a /64<br>difficult - unless you know that the hosting company only uses one<br>particular brand of Ethernet card.<br><br>Given a MAC address of: 00:0D:56:FE:CB:08, (which auto
<br>becomes...::020d:56ff:fefe:cb08) I propose to turn this into....<br>...:56fe:cb08:MMMM:NNNN.<br>NNNN would be a simple sequence number (from 0 or 1 upwards) [I have<br>noticed that providing a range of IPv6 addresses on a Linux machine ie...
<br>config_eth1=( "192.96.28.{1..9}/24"<br> "2001:668:0:3::4000:{0092..0099}/124"<br>)<br>.... only works for decimal values - it chokes on Hex values (A-F)]<br><br>The MMMM could map to a security map of what ports that IP address
<br>should be allowed to accept......<br>The 16 bits could be defines as...<br><br>1 - ssh (port 22)<br>2 - web (port 80)<br>3 - ssl web (443)<br>4 - pop3 ( both 110 and 195)<br>5 - imap (both 143, 220 and 993)<br>...<br>
F - anything (no auto firewall)<br><br>..thus a value of :0: would not allow the (upstream) firewall to send<br>through anything, but a value of :ffff: would allow everything<br>through.. thus a hosting client could define for themselves what ports
<br>the firewall would let through...<br><br>I'd then use a common set of filter lists on my firewall - just to look<br>at those bits - for the majority of customers. There will always be<br>exceptions to some customers - but this can be handled in the
<br>traditional way.<br><br>Anyone done anything like this?<br>Other Suggestions?<br><br>--<br> . . ___. .__ Posix Systems - Sth Africa<br> /| /| / /__ <a href="mailto:mje@posix.co.za">mje@posix.co.za
</a> - Mark J Elkins, SCO ACE, Cisco CCIE<br>/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496<br><br>_______________________________________________<br>afripv6-discuss mailing list<br><a href="mailto:afripv6-discuss@afrinic.net">
afripv6-discuss@afrinic.net</a><br><a href="https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss">https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss</a><br></blockquote></div><br>