It is explained in RFC3513, section 2.5.1<br><br><div><span class="gmail_quote">On 1/15/07, <b class="gmail_sendername">Byron Sorgdrager</b> <<a href="mailto:bs@posix.co.za">bs@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;">
Hi Bruno,<br><br>Is there an RFC or something I could check out for the Golden Rule?<br>(I am of course assuming that the 7th bit you refer to, is actually<br>the 7th 2^16 word...?)<br><br>Kind Regards,<br>Byron<br><br>Bruno Stevant wrote:
<br>> Hi Mark,<br>><br>> About aggregation :<br>> You are the only responsible of the 16 bits you add after your /32<br>> prefix. And their is no policy about how they are organized, only best<br>> 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<br>> requirements.<br>><br>> About addressing network interfaces:<br>> IPv6 allows you to manually assign any IPv6 addresses you want one
<br>> interfaces.<br>> It is common practice to assign a manual address based on the service<br>> running : for instance a DNS server may have a manual address such as<br>> P:R:E:FIX::53<br>> Just remember the gold rule : manual addresses should have the 7th bit
<br>> set to 0.<br>><br>> Regards,<br>> --<br>> Bruno STEVANT<br>> ENST Bretagne, France<br>><br>> On 1/15/07, * Mark J Elkins* <<a href="mailto:mje@posix.co.za">mje@posix.co.za</a> <mailto:<a href="mailto:mje@posix.co.za">
mje@posix.co.za</a>>><br>> wrote:<br>><br>> 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'<br>> 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>><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<br>> 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><br>> <mailto:
<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> <mailto:<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>><br>><br>><br>> ------------------------------------------------------------------------
<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>_______________________________________________<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>