[afripv6-discuss] Agrigation with IPv6

Mon Jan 15 17:20:16 SAST 2007

Hi Bruno, all,

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².

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.

My recommendation is always:
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.
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.
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.

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.

Regards,
Jordi

De: Bruno Stevant <bruno.stevant at gmail.com>
Responder a: IPv6 in Africa <afripv6-discuss at afrinic.net>
Fecha: Mon, 15 Jan 2007 12:41:58 +0100
Para: IPv6 in Africa <afripv6-discuss at afrinic.net>
Asunto: Re: [afripv6-discuss] Agrigation with IPv6

Hi Mark,

About aggregation :
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 ...
I can describe to you the example for the French Research Network Renater :
The addressing plan is 2001:660:GGCC
Prefix is 2001:660
8 bits are assigned to geographic region: GG
8 bits are for identifying customers : CC
This plan is running since 3 years and it seems to fits well their
requirements. 

About addressing network interfaces:
IPv6 allows you to manually assign any IPv6 addresses you want one
interfaces.
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 
Just remember the gold rule : manual addresses should have the 7th bit set
to 0.

Regards,
-- 
Bruno STEVANT
ENST Bretagne, France

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

_______________________________________________
afripv6-discuss mailing list
afripv6-discuss at afrinic.net
https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.afrinic.net/pipermail/afripv6-discuss/attachments/20070115/57f6f8a0/attachment-0001.htm