[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