can you share ipv6 addressallo cation

Deric Kwok deric.kwok2000 at gmail.com
Sun Feb 24 17:00:58 UTC 2013


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 there’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 – to paraphrase my favorite
quote so far “IPv6 has 340 undecillion unique addresses (that’s a
39-digit number). If IPv4 is a golf ball IPv6 is the sun.” Trust me,
don’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