can you share ipv6 addressallo cation

bmanning at vacation.karoshi.com bmanning at vacation.karoshi.com
Mon Feb 25 15:25:55 UTC 2013


 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 thereb s
> 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 b 
IPv6 has 340 undecillion unique addresses (thatb s a
> 39-digit number). If IPv4 is a golf ball IPv6 is the sun.b 
 Trust me,
> donb t 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 at 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 at 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
> >
> 




More information about the NANOG mailing list