[121732] in North American Network Operators' Group
Re: Using /126 for IPv6 router links
daemon@ATHENA.MIT.EDU (Mark Smith)
Mon Jan 25 23:04:03 2010
Date: Tue, 26 Jan 2010 14:33:35 +1030
From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
To: Tim Durack <tdurack@gmail.com>
In-Reply-To: <9e246b4d1001251150p5be0e8bei941b0dfb2485087b@mail.gmail.com>
Cc: hardenrm@uiuc.edu, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.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
>
