[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