IPv6 allocation plan, security, and 6-to-4 conversion

Fri Jan 30 20:20:16 UTC 2015

I'm just beginning to grasp the concepts of IPv6 operations here, so please
pardon my seeming ignorance.

If I'm reading properly, the best common practice (at least the original)
was allocating a minimum /48 to customers, though I did see one that
referenced a /56.

If I do everything on nibble boundaries, then that would mean the natural
breaks are /44, /40 and /36.  It makes the regions pretty large in terms of
customer count - just plain arithmetic, a /44 allocation for a region with
/56 for customers is a capability of 2**12 customers or 4096 where a /36
allocation for a region with /48 customers would be 4096.

It also sounds like the Internet (aka the upstream/Tier 1 carriers) don't
want me to advertise anything longer than my /32 into BGPv6.  Is that true?
 (I'm getting that from the spamming comments made by others)  Am I
supposed to be asking ARIN for a /32 for each region that I want to
address?  (They turned down my request for an increase to a /28 last year)

As far as the v6 to v4 translation is concerned, I'm looking at that for
the future - for the time being, we will be dual-stacked.  However, if we
move into a new area, based on our current IPv4 inventory, I don't really
have enough to assign to each new customer, so I was looking for ways to
allow those customers access to properties that are still IPv4 only.  Is
there yet another way to do that?

Thanks
Eric

eric at techintegrity dot com
619-335-8148 voice & text
www.techintegrity.com
ericlouie on Twitter

On Fri, Jan 30, 2015 at 7:51 AM, William Herrin <bill at herrin.us> wrote:

> On Thu, Jan 29, 2015 at 6:28 PM, Eric Louie <elouie at techintegrity.com>
> wrote:
> > I'm putting together my first IPv6 allocation plan.  The general layout:
> > /48 for customers universally and uniformly
>
> Hi Eric,
>
> Good luck with that. Personally, I'd be inclined to think that some
> customers will (reasonably) want more than a /48 and I'd be in less of
> a rush to burn through my /32 for the sake of customers who would have
> been perfectly happy with a /56. The only deliberately static sizes
> I'd endorse is /64 for an ethernet LAN and the 4-bit nibble boundary
> for any delegations.
>
> > /38 for larger regions on an even (/37) boundary
> > /39 for smaller regions on an even (/38) boundary
> > A few /48's for "internal use" to allow us to monitor and maintain
> systems.
>
> Suggest you delegate to regions, purposes and customers on the 4-bit
> nibble boundary. This makes it easier to read your IPv6 addresses and
> it simplifies DNS operations.
>
>
> > For security sake, do I need (am I better off) to "reserve" a "management
> > block" (/39, /40, /41 or something of that nature) that does NOT get
> > advertised into BGP to my upstreams, and use that for my device
> management
> > and monitoring address space?  In other words, make a small "private"
> > address space for management?  What are folks doing around that?
>
> If it is strictly internal (not used for router interfaces that have
> to transmit destination unreachables) select and use a ULA block. That
> way when you find you really need to advertise a covering route for
> your /32 to get full IPv6 connectivity, your management network still
> won't be exposed to the Internet at large.
>
> Otherwise, address with firewalls and access lists. If you try to
> micromanage your /32's advertisement you'll both earn yourself grief
> and engender the annoyance of other IPv6 participants trying to keep
> the routing table small.
>
>
> > If I have to do 6-to-4 conversion, is there any way to do that with
> > multiple diverse ISP connections, or am I "restricted" to using one
> > entry/exit point?  (If that's true, do I need to allocate a separate
> block
> > of addresses that would be designated "6 to 4" so they'd always be routed
> > out that one entry/exit point?)
>
> Let's clarify some terminology:
>
> 6to4 - a system for facilitating IPv4-only end sites creating a
> configuration-free local IPv6 network that reaches out to the native
> IPv6 Internet. Run by unaffiliated volunteers. Algorithmically matched
> an IPv6 /48 to every possible IPv4 address. It did good service in
> IPv6's experimental days but is not production grade and basically
> should never be used again. Replace with free tunnels from Hurricane
> Electric or similar.
>
> 6rd - allows ISPs to deploy IPv6 to their customers without
> dual-stacking the ISP's network. Get your feet wet at minimal cost and
> then wait to see what happens before undertaking the substantial risk
> and expense of dual-stacking your entire network. Uses the network
> protocols developed for 6to4 but is implemented entirely within your
> organization and is production grade. 6rd uses *your* IPv6 addresses,
> so you route those IPv6 addresses with your peers as normal -- no
> special considerations needed.
>
> nat64/nat46 - allows an IPv6-only host to interact in limited ways
> with IPv4-only hosts. Don't go down this rabbit hole. This will
> probably be useful in the waning days of IPv4 when folks are
> dismantling their IPv4 networks but for now the corner cases will
> drive you nuts. Plan on dual-stacking any network which requires
> access to IPv4 resources such as the public Internet.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>