Going smaller than a /64

[neal.browning]

My team works with an allotment of IPv4 and IPv6 space, which is given to us from a larger organization in our company (we treat them like and ISP, where we request and are given IP space and allocate this across our buildings and sites as we deem appropriate), and have been given several /58's and /59's to make do with, which has been fine for years.  Now we are looking at how to better allocate these resources, and I am curious if anyone has decided to carve up smaller than a /64?

My thoughts are, that while we currently use RA for IPv6 autodiscovery, and a /64 is the smallest network the RFC accounts for, I could chop a single /64 into several thousand /96's and uses these for PTP IPv6 routing only.  This would save us a ton of IPv6 space, which as we deploy more and more Vlan interfaces and our network grows, I can see us running out of in the coming year(s), which would require asking for more IPv6 space, that we really don't need.  Doing so would only be for PTP IPv6 routed links, and not use stateless autoconfig, and would allow us to re-IP current IPv6 PTP's using these /96 network and reclaim a large portion of our /64 space which was already deployed as PTP links.

Thoughts?

[Michael Vincent]

RFC 3627 explains /126 is perfectly viable for point to point links and would certainly conserve IPv6 space as a "single network" can create many /126 subnets suitable for all point to point links.

[neal.browning]

Thanks Michael,

  We may still go this direction, however taking a /64 all the way down to a /126 would be quite a chore, so we may just go ahead and use this spec and reserve the entire /64 for PTP only, and just start from one end and track usage of the address space as we begin to parse it out for use.

** Edit - Correction, I assume you mean a /127 which is the equivalent of an IPv4 /30 network?

[Michael Vincent]

No:

IPv4     IPv6     Note

----     ----     ----

/30     /126     Point-to-Point

/31     /127     sketchy use / support = avoid

/32     /128     loopbacks

Take a /64:  2001:db8:1:1::

2001:db8:1:1::1 /126 <--> 2001:db8:1:1::2 /126

2001:db8:1:1::5 /126 <--> 2001:db8:1:1::6 /126

2001:db8:1:1::9 /126 <--> 2001:db8:1:1::a /126

...

This is much the same as taking an IPv4 /16 and chopping it up into /30's for point to point links

[lgijssel]

Using /128 for loopbacks is fine. My personalpreference is using a /120 as the next step.

This is similar to a /24 in ipv4 (254 usable addresses) and one /64 suffices for an awful lot of them.

The way the subnets of size /120 look is easier to understand than those using smaller masks (which really serves no purpose due to the vastness of the address ranges available).

This would go like:

2001:db8:1::0100 - 2001:db8:1::01ff

2001:db8:1::0200 - 2001:db8:1::02ff

2001:db8:1::0300 - 2001:db8:1::03ff

Anyway, at least I would recommend to use masks which are a multiple of 8-bits, just for ease of administration.

If you have a requirement to use SLAAC, /64 is the smallest subnet you can use.

regards,

Leo

[neal.browning]

Thanks for the feedback all -

  I had found some whitepapers and RFC on using /127's and how it was not recommended but with good understanding and proper use was acceptible, nothing I found on /126's.

I think I like Leo's solution the best, in order to prevent accidents and ease of administration.  While I am not very concerned about running low on IPv6 space, we want to use it as best we can since we have to alter our BGP peering whenever we run out and are given more, and this solution would keep that churn lower. 

This would be for PTP use only, we do use SLAAC for vlan interfaces currently, with the other-config-flag, to allow us to push IPv6 DNS pools to the clients as an interim step to going full v6 DHCP, so we will still use /64's here of course.

Neal