[afripv6-discuss] Agrigation with IPv6

Bruno Stevant bruno.stevant at gmail.com
Mon Jan 15 19:20:26 SAST 2007


It is explained in RFC3513, section 2.5.1

On 1/15/07, Byron Sorgdrager <bs at posix.co.za> wrote:
>
> 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
> _______________________________________________
> afripv6-discuss mailing list
> afripv6-discuss at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.afrinic.net/pipermail/afripv6-discuss/attachments/20070115/91ccb6cb/attachment.htm


More information about the afripv6-discuss mailing list