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

Mailman List Mirror (Read Only)
1

I'm putting together my first IPv6 allocation plan. The general layout:
/48 for customers universally and uniformly
/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.

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 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?)

2

Hi,

I'm putting together my first IPv6 allocation plan. The general layout:
/48 for customers universally and uniformly
/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.

Depending on how many regions you have I would just go for /40 as it
is the byte boundary or request a bigger block and use the /32.

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?

Do not spam the BGP table for that. Use firewalls or ACLs to prevent
unwanted access.
You could use Unique Local addresses (ULA) for this if you have some
VPN infrastructure in your network.
Not announcing these blocks does not prevent people on your network to
access these areas.

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?)

I would not use 6to4 as it tunnels the IPv6 traffic over IPv4 which is
a pain to control.

Best regards
Karsten

3

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

4

* William Herrin

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.

For many folks, that's easier said than done.

Think about it: If everyone could just dual-stack their networks, they
might as well single-stack them on IPv4 instead; there would be no
point whatsoever in transitioning to IPv6 for anyone.

Tore

5

I re-read this 3 or 4 times, and it still doesn't make any sense.

I dual-stacked our backbone here at $dayjob 3+ years ago, and it really wasn't painful at all. Sure, there were were some transition pains, but they've been more at the edge (firewalls, wireless, managing users, etc), but getting the backbone to handle both v4 and v6 was the easy part.

Granted, this process can be more or less painful in different environments, but definitely no reason to stick your head in the sand and pretend that IPv6 doesn't exist, especially in 2015.

jms

6

Tore,

   Um, haven't you heard that we are out of IPv4 addresses? The point of IPv6 is to expand address space so that the Internet can keep growing. Maybe you don't want to grow with it, but most people do. Eventually IPv4 will be dropped and the Internet will be IPv6-only. Dual-stack is just a convenient transition mechanism.

-mel

7

Hi Tore,

That's what NAT is for. Use RFC 1918 space for end users, RFC 6598
space for ISPs.

Plan on dual-stacking until IPv6 deployment is ubiquitous. Which won't
be this year. Or next.

Regards,
Bill Herrin

8

Eric Louie <elouie@techintegrity.com> writes:

I'm putting together my first IPv6 allocation plan. The general layout:
/48 for customers universally and uniformly
/38 for larger regions on an even (/37) boundary
/39 for smaller regions on an even (/38) boundary

You really really really don't want to subnet on non-nybble
boundaries. "Technically feasible" does not equate to "good idea".
Optimize for technician brain cells and 2am maintenance windows. Oh,
and rDNS.

If you can't make your regional aggregation scheme fit within a /32
when rounding up on nybble boundaries... get more from ARIN.
Seriously. IPv6 is not scarce. A /32 is the *minimum* initial
allocation for an ISP. See ARIN NRPM 6.5.2.1. "justification" is
viewed in an entirely different light in the IPv6 land-of-plenty that
is IPv6. If you already have a /32 but haven't rolled it out yet, ask
for a do-over.

"Our subnetting scheme [insert description here] requires a /28" is,
at least on paper, an entirely good reason to get a /28 out of ARIN.
If you need it and you are having trouble getting it, it's a sign that
policy needs further evolution; please reach out to folks involved
tightly with the policy process (that would include me) to let us know.

As for giving a /48 to every customer... that's a fine way to go and
eminently defensible. If every human being on the face of the earth
(let's round up and say 2^33 or 8 billion to make it easy) had an end
site, and we assume only 10% efficiency in our allocation scheme due
to the subnetting scheme I outlined above and getting unlucky... that
still uses less than a tenth of a percent of available IPv6 space.

This is one of those things that are easiest to get right the first
time. If "conservation of address space" is in your IPv6 numbering
plan, you're doing it wrong.

My $0.02, FWIW.

-r

9

* Mel Beckman

   Um, haven't you heard that we are out of IPv4 addresses? The point
of IPv6 is to expand address space so that the Internet can keep
growing. Maybe you don't want to grow with it, but most people do.
Eventually IPv4 will be dropped and the Internet will be IPv6-only.
Dual-stack is just a convenient transition mechanism.

Mel,

Dual-stack was positioned to be a convenient transition mechanism 15
years ago (to take the year when RFC 2893 was published). However, that
train left the platform mostly empty years ago, when the first RIRs
started to run out of IPv4 addresses. After all, we were supposed to
have dual-stack everywhere *before* we ran out of IPv4. That didn't
happen.

The key point is: In order to run dual-stack, you need as many IPv4
addresses as you do to run IPv4-only. Or to put it another way: If you
don't have enough IPv4 addresses to run IPv4-only, then you don't have
enough IPv4 addresses to run dual-stack either.

Sure, you can squeeze some more life-time out of IPv4 by adding more
NAT (something which is completely orthogonal to deploying IPv6
simultaneously). However, if you're already out of IPv4, and you
already see no way forward except adding NAT, then you should seriously
consider doing the NAT (or whatever backwards compat mechanism
you prefer) between the residual IPv4 internet and your IPv6
infrastructure, instead of doing it between IPv4 and IPv4.

Running single-stack is simply much easier and less complex than
dual-stack, and once your infrastructure is based on an IPv6-only
foundation, you don't have to bother with any IPv4->IPv6 transition
project ever again.

Tore

10

Single stacking on IPv6 is nice in theory. In practice it just doesn't work
yet. If you as an ISP tried to force all your customers to be IPv6 single
stack, you would go bust.

Therefore the only option is dual stack. The IPv4 can be private address
space with carrier NAT - but you will need to give the users an IPv4 on
their internal network. Otherwise there is simply too much that breaks. But
you also want to give them IPv6, so they can escape your carrier NAT.

Since carrier NAT sucks, we are buying extra IPv4 addresses instead. We
still need to dual stack - our customers want both IPv4 and IPv6.

Currently it might even be cheaper to buy extra addresses compared to
implement carrier NAT. The equipment to do high speed NAT is not free and
neither is the extra support and operating complications.

Regards,

Baldur

11

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

12

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)

Not true. A peek at the global IPv6 routing table shows lots of prefixes that are smaller than /32. One of the hopes with larger allocations and assignments was that there would be less bloat in the global IPv6 routing table because networks would need to announce fewer prefixes. How well that will hold up in practice remains to be seen :slight_smile:

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?

If you assign a customer IPv6 space only, a translation mechanism is needed to allow that customer to reach Internet destinations that only speak IPv4 today. There's no way around that.

jms

13

* Baldur Norddahl

Single stacking on IPv6 is nice in theory. In practice it just doesn't work
yet. If you as an ISP tried to force all your customers to be IPv6 single
stack, you would go bust.

Kabel Deutschland, T-Mobile USA, and Facebook are examples of companies
who have already or are in the process of moving their network
infrastructure to IPv6-only. Without going bust.

What you *do* need, is some form of connectivity to the IPv4 internet.
But there are smarter ways to do that than dual stack. Seriously, if
you're building a network today, consider making IPv4 a legacy "app" or
service running on top of an otherwise IPv6-only infrastructure. Five
years down the road you'll thank me for the tip. :slight_smile:

Tore

14

What IPv6 to IPv4 translation mechanisms are available for networks with
multiple ingress/egress points?

15

A bunch were listed in an earlier post. Translation is generally best done either as close to the customer edge as possible.

jms

16

Hi,

I would not recommend to run any nat over protocol versions for
clients as you would need to break DNSsec.
The clients creating connections should run dual-stack or dual-stack lite.

The only useful thing for service providers would be to proxy/nat lets
say an incoming IPv6 connection to still only IPv4 servers/services.

17

On this point, you may find

https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic
https://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic
  "Deprecating Anycast Prefix for 6to4 Relay Routers", Ole Troan, Brian
  Carpenter, 2015-01-28

of interest. t is coming from the IETF IPv6 Operations Working Group, and in essence suggests that operators not support anycast 6to4. Don’t prevent it, please understand, but don’t deploy it, and if it’s causing you problems, turn it off.

One of the authors, Brian carpenter, is the original designer of 6to4...

18

We are talking about different things. If your business is servers, do
whatever you want. If you are in the business of selling internet, which
quite a few are on this mailinglist, you need to be dual stack.

We are dual stack towards our customers. On our internal network we are
single stack - ipv4 only. This is a new build. Why? Because half of our
equipment does not support ipv6 management and even some of the network
protocols will not function without ipv4 (MPLS). Adding ipv6 to the
internal network seems to have no purpose. It is all private address space
with not even NAT. The internal network is not directly connected to the
internet, so there is no need.

Regards,

Baldur

19

And, we're in sort of the same predicament - I have no choice on the
current infrastructure but to run IPv4. IPv6 is a service we would like to
start to offer to new customers in this current infrastructure. And to
existing customers who believe that they have the need for IPv6 and have
the equipment in their network to support it.

We may end up as IPv6-only on the customer side in new markets because we
don't have enough PUBLIC IPv4 address space to support a new market, but
that will STILL require private IPv4 for management and monitoring of the
equipment that does not support IPv6 yet. (and yes, there's a lot of
equipment that is greater than 2 years old that still works and that does
not support IPv6)

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

20

Hi,

I'm putting together my first IPv6 allocation plan. The general layout:
/48 for customers universally and uniformly
/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.

Depending on how many regions you have I would just go for /40 as it
is the byte boundary or request a bigger block and use the /32.

Given that ARIN policy allows you two levels of nibble-round-up, I’d suggest
putting your regions all at /36, actually, assuming you have enough customers
in your largest region to justify more than 75% of a /40 (which I assume to be the
case given the limited information provided).

Don’t make your network fit inside a /32 if it doesn’t fit conveniently. Get a /28 instead.

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?

Do not spam the BGP table for that. Use firewalls or ACLs to prevent
unwanted access.

Exactly!

You could use Unique Local addresses (ULA) for this if you have some
VPN infrastructure in your network.

But only if you are truly a masochist. It’s so much easier to do this with GUA and
filters.

Not announcing these blocks does not prevent people on your network to
access these areas.

Among other various issues with using announcement control in lieu of actual
security policy.

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?)

I would not use 6to4 as it tunnels the IPv6 traffic over IPv4 which is
a pain to control.

6to4 is in the process of being moved to historic status in the IETF for good reason.
If you’re deploying real IPv6, there’s no need to add any 6to4 headaches into your environment.
At its best, 6to4 was for people who couldn’t get real IPv6 transport. Today, it’s mostly an anachronism.

Owen