Re: Using /126 for IPv6 router links

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

On Mon, 25 Jan 2010 14:50:35 -0500
Tim Durack <tdurack () gmail com> wrote:

> On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden <hardenrm () 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