Re: can you share ipv6 addressallo cation

[bmanning () vacation karoshi com]

 don't think of this in terms of waste (v6 has an unthinkable number of numbers)
and think of security.  by announceing more space than you are actually using, you create
"dark-space" that attackers can hide in-plain-sight.  so, for example, in your P2P links,
you can use tools that lazy developers  picked a near random number, a /64 as a constant, 
or you can reduce your attack surface by 

a) only announcing what your are actually using, in this case /126 for p2p links

your call, your network, your inducced vulnerabilities.  Your LIABILITY.

/bill


On Sun, Feb 24, 2013 at 12:00:58PM -0500, Deric Kwok wrote:
> Hi Owen and all
>
> Thank you so much for all info.  I do have question about /126 or /64
> as link to link
>
> After getting this
> http://www.clarksys.com/blog/2010/08/18/howto-subnet-ipv6-for-network-links/
>
> Can I know what do you think?
>
> Can we say that to use /64 to replace /126 for network link?
>
> and what do you think the problem to use /64?
>
>
> The website said:
> If you refer back to the presentation I mentioned earlier therebs
> notes about the potential dangers of /64s on network links and why
> people intuitively want to subnet to a /127 or a /126. We ended up
> splitting the difference and actually subnetting the /64 for the
> network link to a /126.
>
> IPv6 is a very large pool of IP space b to paraphrase my favorite
> quote so far bIPv6 has 340 undecillion unique addresses (thatbs a
> 39-digit number). If IPv4 is a golf ball IPv6 is the sun.b Trust me,
> donbt try to over think this. Just follow what all the RFCs say and
> use /64s for your network links.
>
> If you want to read more I found the following links to be very
> helpful in understanding how to properly subnet IPv6:
>
>
> Thank you so much
>
>
> On Wed, Feb 20, 2013 at 9:00 PM, Owen DeLong <owen () delong com> wrote:
> > First, if you are starting from a /32 and deciding how to carve it up from there, you are already approaching the 
> > problem backwards.
> >
> > The correct approach (general broad strokes)  is to:
> >
> >         1.      Identify your subnetting needs.
> >                 A.      Infrastructure addressing
> >                 B.      Internal IT needs within the company
> >                 C.      Customer network needs (usually best to count the Infrastructure and Internal IT as 
> > n*customers at this point when
> >                         rolling this all up into a total number of subnets needed).
> >                 D.      Decide on a customer end-site subnet size (unless this is an exceptional case, /48 is a 
> > good number to use)
> >
> >         2.      Identify the natural aggregation points in your network.
> >
> >         3.      Identify the number of /48s (or whatever other size you decided in D) needed
> >                 in your largest aggregation site. (This should be the sum of all subordinate
> >                 end-user networks as well as any infrastructure networks, etc.
> >
> >                 Round that up to a nibble boundary ensuring at least a 25% free space.
> >
> >         4.      Identify the total number of aggregation points at the hierarchy level identified in (3) above.
> >
> >         5.      Round that up to a nibble boundary as well.
> >
> >         6.      Make a request for the prefix size determined by taking the number in 1D (/48) and
> >                 subtracting the number of bits identified in (3) and (5). e.g. your largest aggregation
> >                 point serves 50,000 customer end sites and you have 196 such aggregation points.
> >                 Each customer end-site is to receive a /48.
> >
> >                 50,000 customer end-sites is 16-bits. To get a 25% min free, we must round up to 20.
> >                 This count includes 2 customer end-sites to support ISP infrastructure and internal IT
> >                 needs, respectively.
> >
> >                 196 aggregation points is 8-bits. To get a 25% min free, we must round up to 12.
> >
> >                 48-20=28-12=16 -- This network should request a /16 from their RIR.
> >
> > Notes:
> >
> > This is a severe oversimplification. Obviously more details will be required and the process must be adapted to 
> > each individual ISP's network topology and other considerations.
> >
> > Your first several iterations of addressing plan will be wrong. Accept it, deploy it, and expect to redo it a few 
> > times before you're completely happy with it.
> >
> > Plan big, deploy small the first few times so that you can learn lessons about the big plan while the deployments 
> > are still small.
> >
> > Owen
> >
> > On Feb 20, 2013, at 14:44 , Deric Kwok <deric.kwok2000 () gmail com> wrote:
> >
> > > Hi all
> > >
> > > I am searching information about ipv6 addressallocation for /32
> > >
> > > Any experience and advice can be shared
> > >
> > > eg: loopback. peer to peer,
> > >
> > > Thank you so much