<HTML>
<HEAD>
<TITLE>Re: [afripv6-discuss] Agrigation with IPv6</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Hi Bruno, all,<BR>
<BR>
I disagree a bit in the usage of well known service port numbers as part of the address, unless it is a service that you really want to make public and easy to be “attacked”.<BR>
<BR>
If you use well know “addresses” then the attacker will look for them, typically, at the beginning of a port scanning. If instead you randomize the address and don’t make it simple, is not an extra overhead if you use DNS and call the services by DNS name instead of addresses, but will take billions of years for the possible attacker to catch it.<BR>
<BR>
My recommendation is always:<BR>
1) First time you configure IPv6 in a machine that requires a manual configured address, let the OS to run autoconfiguration, so the address is “randomized” from the MAC address. The randomization I’m referring here is not a real one, but it is enough in your network, because is highly improbably that you have several MAC addresses in different machines which are contiguous.<BR>
2) Use that address for a manual configuration. At this way, even if the network card get broken and/or replaced by a new one, the address will stay.<BR>
3) Define a DNS name for that address. Simple to do, and simpler to remember than any IPv6 address. Make sure to avoid zone transfers.<BR>
<BR>
If you don’t like this procedure, what you should also never do is to assign “simple” and/or contiguous addresses, they are easy to track/scan, once the first one is discovered.<BR>
<BR>
Regards,<BR>
Jordi<BR>
<BR>
<BR>
<BR>
<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"><B>De: </B>Bruno Stevant <bruno.stevant@gmail.com><BR>
<B>Responder a: </B>IPv6 in Africa <afripv6-discuss@afrinic.net><BR>
<B>Fecha: </B>Mon, 15 Jan 2007 12:41:58 +0100<BR>
<B>Para: </B>IPv6 in Africa <afripv6-discuss@afrinic.net><BR>
<B>Asunto: </B>Re: [afripv6-discuss] Agrigation with IPv6<BR>
<BR>
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>
On 1/15/07, <B>Mark J Elkins</B> <mje@posix.co.za> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>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>
/| /| / /__ mje@posix.co.za <a href="mailto:mje@posix.co.za"><mailto: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>
afripv6-discuss@afrinic.net<BR>
https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"></SPAN></FONT><FONT SIZE="1"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:9.0px'>_______________________________________________<BR>
afripv6-discuss mailing list<BR>
afripv6-discuss@afrinic.net<BR>
https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss<BR>
</SPAN></FONT></FONT>
<br><br>
**********************************************<br>
The IPv6 Portal: http://www.ipv6tf.org<br>
<br>
Bye 6Bone. Hi, IPv6 !<br>
http://www.ipv6day.org<br>
<br>
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.<br>
<br>
</body>
</HTML>