Using /126 for IPv6 router links

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Tue Jan 26 04:03:35 UTC 2010


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

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




More information about the NANOG mailing list