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 <o...@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.kwok2...@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 > > >
