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