On Mon, 25 Jan 2010 14:50:35 -0500
Tim Durack <tdur...@gmail.com> wrote:

> On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden <harde...@uiuc.edu> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Our numbering plan is this:
> >
> > 1) Autoconfigured hosts possible? /64
> > 2) Autoconfigured hosts not-possible, we control both sides? /126
> > 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64
> > 4) Loopback? /128
> >
> > Within our /48 we've carved it into (4) /50s.
> > * First, Infrastructure. This makes ACLs cake.
> > ** Within this /50 are smaller allocations for /126s and /128s and /64s.
> > * Second, User Subnets (16k /64s available)
> > ** All non-infrastructure subnets are assigned from this pool.
> > * Third, Reserved.
> > * Fourth, Reserved.
> >
> > We believe this plan gives us the most flexibility in the future. We
> > made these choices based upon what works the best for us and our tools
> > and not to conserve addresses. Using a single /64 ACL to permit/deny
> > traffic to all ptp at the border was extremely attractive, etc.
> >
> > - --
> 
> This is what we have planned:
> 
> 2620:0000:xx00::/41           AS-NETx-2620-0-xx00                             
> 
>       2620:0000:xx00::/44             Infrastructure                          
>         
> 
>               2620:0000:xx01::/48             Pop1 Infrastructure             
>         
> 
>                       2620:0000:xx01:0000::/64                Router Loopback 
> (2^64 x /128)
>                       2620:0000:xx01:0001::/64                Transit net 
> (2^48 x /112)
> 
>                       2620:0000:xx01:0002::/64                Server Switch 
> management
>                       2620:0000:xx01:0003::/64                Access Switch 
> management
> 
>               2620:0000:xx0f::/48             Pop16    Infrastructure         
> 
> 
>       2620:0000:xx10::/44             Sparse Reservation                      
>                 
> 
>       2620:0000:xx20::/44             Sparse Reservation                      
>                 
> 
>       2620:0000:xx30::/44             Pop1 Services                           
>         
> 
>               2620:0000:xx30::/48             Cust1 Services
> 
>                       2620:0000:xx30:0001::/64                VLAN_1
>                       2620:0000:xx30:4094::/64                VLAN_4094
> 
>               2620:0000:xx31::/48             Cust2 Services
> 
>                       2620:0000:xx31:0001::/64                VLAN_1
>                       2620:0000:xx31:4094::/64                VLAN_4094
> 
>               2620:0000:xx32::/48             Cust3 Services
> 
>                       2620:0000:xx31:0001::/64                VLAN_1
>                       2620:0000:xx31:4094::/64                VLAN_4094
> 
>               2620:0000:xx32::/48             Cust4 Services
> 
>                       2620:0000:xx31:0001::/64                VLAN_1
> 
>                       2620:0000:xx31:4094::/64                VLAN_4094
> 
>               2620:0000:xx32::/48     RES-PD-32       (4096 x /60)
>               2620:0000:xx3f::/48     RES-PD-3f       (4096 x /60)
> 
>       2620:0000:xx40::/44             Pop2 Services                           
>         
> 
>       2620:0000:xx50::/44             Pop3 Services                           
>         
> 
>       2620:0000:xx60::/44             Pop4 services                           
>         
> 
>       2620:0000:xx70::/44             Pop5 Services                           
>         
> 
> This is a multiple campus network, customers are all internal. I have
> had to squeeze Residential PDs down to /60s to make it fit. One Pop is
> really 3 sites in one. This has had to be massaged into one Pop also.
> To be safe, I'm thinking of adjusting loopbacks and ptp to be /64s.
> 
> I'm reasonably happy with the plan, but it doesn't seem to have that
> much room to grow.
> 

If you haven't already, you may wish to have a read of RFC3531 - "A
Flexible Method for Managing the Assignment of Bits of an IPv6 Address
Block". It suggests a method of subnet assignment such that you're not
stuck with your initial boundary estimations.


> -- 
> Tim:>
> Sent from Brooklyn, NY, United States
> 

Reply via email to