[afripv6-discuss] Agrigation with IPv6

[Byron Sorgdrager]

Hi Bruno,

Is there an RFC or something I could check out for the Golden Rule?
(I am of course assuming that the 7th bit you refer to, is actually
the 7th 2^16 word...?)

Kind Regards,
Byron

Bruno Stevant wrote:
> 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 <mailto: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 <mailto: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