[afripv6-discuss] Agrigation with IPv6

Byron Sorgdrager bs at posix.co.za
Wed Jan 17 11:12:08 SAST 2007


Bruno,

RFC3513, section 2.5.1 only mentions the 'u' bit, which if set to 1, 
indicates a global scope, and if set to 0, indicates a local scope...

It mentions that the motivation behind inverting the 'u' bit, is purely 
to make the admin's job easier in hand configuring non-global 
identifiers when hardware tokens are not available.

I don't see how this relates?

(If I'm missing something fundamental, I do apologise)

Kind Regards,
Byron

Bruno Stevant wrote:
> It is explained in RFC3513, section 2.5.1
> 
> On 1/15/07, *Byron Sorgdrager* <bs at posix.co.za <mailto: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> <mailto: 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>
>      >     <mailto: 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>
>     <mailto: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 <mailto:afripv6-discuss at afrinic.net>
>      > https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss
>     _______________________________________________
>     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


More information about the afripv6-discuss mailing list