IPv6 allocation plan, security, and 6-to-4 conversion
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?)
Hi, 2015-01-30 0:28 GMT+01:00 Eric Louie <elouie@techintegrity.com>:
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
On Jan 30, 2015, at 07:12 , Karsten Elfenbein <karsten.elfenbein@gmail.com> wrote:
Hi,
2015-01-30 0:28 GMT+01:00 Eric Louie <elouie@techintegrity.com>:
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
On Thu, Jan 29, 2015 at 6:28 PM, Eric Louie <elouie@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@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
* 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
On Fri, 30 Jan 2015, Tore Anderson wrote:
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.
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
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 On Jan 30, 2015, at 5:03 AM, "Justin M. Streiner" <streiner@cluebyfour.org> wrote:
On Fri, 30 Jan 2015, Tore Anderson wrote:
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.
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
* 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
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 On 30 January 2015 at 19:46, Tore Anderson <tore@fud.no> wrote:
* 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
* 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. :-) Tore
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 Den 30/01/2015 21.23 skrev "Tore Anderson" <tore@fud.no>:
* 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. :-)
Tore
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 On Fri, Jan 30, 2015 at 4:54 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
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 Den 30/01/2015 21.23 skrev "Tore Anderson" <tore@fud.no>:
* 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. :-)
Tore
Den 30/01/2015 21.23 skrev "Tore Anderson" <tore@fud.no>:
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.
Assuming larger service providers are using MPLS in some form, is this even possible? How long will we be forced to have an IPv4 backbone due to MPLS?
On Fri, Jan 30, 2015 at 11:44 AM, Tore Anderson <tore@fud.no> wrote:
* William Herrin
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.
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 -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Jan 30, 2015, at 09:39 , William Herrin <bill@herrin.us> wrote:
On Fri, Jan 30, 2015 at 11:44 AM, Tore Anderson <tore@fud.no> wrote:
* William Herrin
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.
Hi Tore,
That's what NAT is for. Use RFC 1918 space for end users, RFC 6598 space for ISPs.
And here I thought NAT was merely a tool used by sadists to satisfy masochists. Oh, wait… We’re saying the same thing.
Plan on dual-stacking until IPv6 deployment is ubiquitous. Which won't be this year. Or next.
I think you’re right about this year, Not completely sure about next year. Current growth rates in the two protocols suggest at least that there will be more devices with unique IPv6 addresses than IPv4 addresses somewhere in the latter half of next year. I guess it depends on your definition of ubiquitous, but to me, when a protocol has the majority of the deployed addresses, I think it counts for this purpose. Owen
On Fri, Jan 30, 2015 at 8:44 PM, Owen DeLong <owen@delong.com> wrote:
I guess it depends on your definition of ubiquitous, but to me, when a protocol has the majority of the deployed addresses, I think it counts for this purpose.
LOL, Owen, IPv6 had that with the first /64 ethernet LAN it was used on. How about this: when Verizon starts decommissioning its IPv4 infrastructure on the basis that IPv6 is widespread enough to no longer require the expense of dual-stack, IPv6 will have achieved ubiquity. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Fri, 30 Jan 2015 21:07:25 -0500, William Herrin said:
How about this: when Verizon starts decommissioning its IPv4 infrastructure on the basis that IPv6 is widespread enough to no longer require the expense of dual-stack, IPv6 will have achieved ubiquity.
Using that logic, what does Verizon FIOS tell us about US broadband?
On Fri, Jan 30, 2015 at 9:48 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Fri, 30 Jan 2015 21:07:25 -0500, William Herrin said:
How about this: when Verizon starts decommissioning its IPv4 infrastructure on the basis that IPv6 is widespread enough to no longer require the expense of dual-stack, IPv6 will have achieved ubiquity.
Using that logic, what does Verizon FIOS tell us about US broadband?
I don't know but tonight the 100 ms lag is really pissing me off. 3 T1-3-0-4.WASHDC-LCR-22.verizon-gni.net (130.81.221.218) 5.268 ms 5.316 ms 5.556 ms 4 * * * 5 0.ae2.BR1.IAD8.ALTER.NET (140.222.229.165) 6.985 ms 10.824 ms 11.039 ms 6 xe-2-1-0.er2.iad10.us.zip.zayo.com (64.125.13.173) 92.949 ms 91.437 ms 91.660 ms 5 xe-4-0-0.cr2.dca2.us.zip.zayo.com (64.125.31.118) 2.008 ms 2.038 ms 1.841 ms 6 ae1.er2.iad10.us.zip.zayo.com (64.125.20.122) 2.484 ms 2.411 ms 2.685 ms 7 zayo-vzb.iad10.us.zip.zayo.com (64.125.13.174) 94.578 ms 94.839 ms 94.589 ms 8 xe-0-3-0-0.WASHDC-VFTTP-312.verizon-gni.net (130.81.221.217) 101.677 ms 101.670 ms 101.593 ms -Bill -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Jan 30, 2015, at 18:07 , William Herrin <bill@herrin.us> wrote:
On Fri, Jan 30, 2015 at 8:44 PM, Owen DeLong <owen@delong.com> wrote:
I guess it depends on your definition of ubiquitous, but to me, when a protocol has the majority of the deployed addresses, I think it counts for this purpose.
LOL, Owen, IPv6 had that with the first /64 ethernet LAN it was used on.
If you want to nit-pick, by “deployed addresses”, I mean addresses actually deployed on hosts and being used for cummunications. This was a really stupid nit, even for you.
How about this: when Verizon starts decommissioning its IPv4 infrastructure on the basis that IPv6 is widespread enough to no longer require the expense of dual-stack, IPv6 will have achieved ubiquity.
Um, no. The judgment of one traditional telephone company is hardly where I would look to contemplate the future of the internet. Heck, to a large degree, Verizon hasn’t even figured out how to do IPv6 for FIOS customers yet, let alone their DSL subscribers. Really not the shining example I would turn to. No. Certainly not the worst, but definitely not the leader, either. Owen
On Jan 30, 2015, at 9:49 PM, Owen DeLong <owen@delong.com> wrote:
On Jan 30, 2015, at 18:07 , William Herrin <bill@herrin.us> wrote: How about this: when Verizon starts decommissioning its IPv4 infrastructure on the basis that IPv6 is widespread enough to no longer require the expense of dual-stack, IPv6 will have achieved ubiquity.
Um, no. The judgment of one traditional telephone company is hardly where I would look to contemplate the future of the internet.
Then AT&T, Comcast, Cox, Level3, etc, could be reasonable examples? I think the general point is worth considering - when v4 gear is regularly being pulled out of commission by large carriers because "who needs it?" and replaced with v6 only gear, we will have achieved true ubiquity. I think you'll see v4 for quite a while. Heck, I still run across SNA, Token Ring, and other really old stuff occasionally... David Barak Sent from a mobile device, please forgive autocorrection.
On Fri, Jan 30, 2015 at 3:23 PM, Tore Anderson <tore@fud.no> wrote:
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.
Hi Tore, T-Mobile uses something called 464XLAT. Don't let the "translation" part fool you: it's a tunnel. IPv4 in one side, IPv4 out the other. Kabel Deutschland uses something called "Dual Stack Lite." It's also a tunnel: the Kabel-owned CPE encapsulates the customer's IPv4 packets within IPv6 and delivers them to the Kabel's IPv4 carrier NAT box. So sure, if you don't mind dissembling a little bit you can say that they moved their "infrastructure" to IPv6-only. In my mind, tunnelling IPv4 over IPv6 where it both enters and exits the carrier's area of control as an IPv4 packet doesn't count as "IPv6-only." On Fri, Jan 30, 2015 at 11:44 AM, Tore Anderson <tore@fud.no> wrote:
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.
What do you mean "if"? Carrier NAT means we *can* single-stack on IPv4 for the next 20 to 30 years, if we're so inclined. We'd have to rely on address markets to move the needed public IPs from low-value applications to high-value ones. When you take back all the globally routable IPs assigned to grandma's webmail PC and Joe's cell phone there are plenty left to support growth in server counts. Yes, Joe's cell phone really does have that many IPs.<note sarcasm> Worse, IPv6's promises are falling one by one. You saw an example in this thread: Eric wants to break up his announcements for traffic engineering purposes because, as it turns out, one announcement per ISP isn't actually enough, Registry practices aren't the primary drivers behind routing disaggregation. That was a bad assumption baked in to IPv6's addressing strategy. Years ago I cracked a joke about IPv6: http://bill.herrin.us/network/ipxl.html These days I don't know whether to laugh or cry. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Worse, IPv6's promises are falling one by one. You saw an example in this thread: Eric wants to break up his announcements for traffic engineering purposes because, as it turns out, one announcement per ISP isn't actually enough, Registry practices aren't the primary drivers behind routing disaggregation. That was a bad assumption baked in to IPv6's addressing strategy.
Traffic engineering still won’t be anywhere near as bad as the current IPv4 routing table, so no, that doesn’t indicate a failure in the promise of IPv6. Traffic engineering (and other factors) will probably prevent the ideal of one prefix advertised per ASN, but IPv6 will still likely top out somewhere around 4 or 5 on average vs. the current IPv4 average which is north of 10 last time I looked. That’s still a pretty substantial win. Further, technology in routers continues to advance and we are starting to see routers capable of holding very large routing tables. (So far, necessary to cope with the abomination of keeping IPv4 on life support). Once IPv4 can be deprecated, even just in the backbone, it’s a huge win in terms of routing slots available. Further, your statement about registry practices doesn’t hold water. It wasn’t a bad assumption, it was the facts on the ground as they existed for IPv4 at the time. In the 20 years since, the world has changed. Registry practices aren’t a factor in IPv6, but they are, in fact, still a factor (though somewhat less than they used to be) in IPv4.
Years ago I cracked a joke about IPv6: http://bill.herrin.us/network/ipxl.html <http://bill.herrin.us/network/ipxl.html>
I didn’t realize you thought it was a joke. I thought it was just more of your misguided railing against IPv6 because you love NAT so much for reasons passing understanding.
These days I don't know whether to laugh or cry.
Given your past statements and apparent position along with the fact that despite various efforts, IPv6 deployment continues to accelerate, I’m guessing cry, but that’s certainly your decision. Owen
* William Herrin
T-Mobile uses something called 464XLAT. Don't let the "translation" part fool you: it's a tunnel. IPv4 in one side, IPv4 out the other.
464XLAT is not a tunnel. Protocol translation is substantially different from tunneling. With tunneling, the original layer-3 header is kept intact as it is encapsulated inside another layer-3 header. With translation, the original layer-3 header is removed and replaced with another layer-3 header. They come with a different set of trade-offs, such as: - Protocol translation may be lossy (e.g., exotic IPv4 options may not survive the translation to IPv6 and would therefore not reappear after translation back to IPv4). Tunneling, OTOH, is not lossy. - Tunneling moves the original layer-4 header into another encapsulation layer, so e.g. an ACL attempting to match an IPv6 HTTP packet using something like "next-header tcp, dst port 80" will not work. With translation, it will.
Kabel Deutschland uses something called "Dual Stack Lite." It's also a tunnel: the Kabel-owned CPE encapsulates the customer's IPv4 packets within IPv6 and delivers them to the Kabel's IPv4 carrier NAT box.
Yep. DS-Lite is indeed tunneling.
So sure, if you don't mind dissembling a little bit you can say that they moved their "infrastructure" to IPv6-only. In my mind, tunnelling IPv4 over IPv6 where it both enters and exits the carrier's area of control as an IPv4 packet doesn't count as "IPv6-only."
I guess we disagree about the definitions, then. In my view, a dual-stack network is one where IPv4 and IPv6 are running side-by-side like "ships in the night" with no fate sharing. You might be running two different IGP protocols (like OSPFv2 and OSPFv3) and a duplicated set of iBGP sessions. ACLs and the like must exist both for IPv4 and IPv6. And so on. If you turn off one protocol, and the other one keeps on running just like before. This is in contrast with a single-stack network; turn off that single stack, and nothing works. That doesn't mean that cannot simultaneously transport other layer-3 protocols across that single-stack network; just that there is a clear distinction between which is the main layer-3 protocol and others being transported across it. You might very well simultaneously transport IPv6, AppleTalk, and IPX/SPX across an IPv4-only network - but that doesn't mean that the network is "quad-stack" - IMHO, it's still single-stack IPv4.
On Fri, Jan 30, 2015 at 11:44 AM, Tore Anderson <tore@fud.no> wrote:
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.
What do you mean "if"? Carrier NAT means we *can* single-stack on IPv4 for the next 20 to 30 years, if we're so inclined.
I suppose that's true - if you ignore that a number of other folks are deploying IPv6 to deal with their IPv4 exhaustion, and that products and services are being put to market that recommends the use of IPv6 connectivity above NATed IPv4 (e.g., Xbox One). So much earlier than 30 years from now you'll be wanting to have IPv6 in your network anyway, and once you come to that realisation you might also realise that operating a dual-stack network for those 30 years is not going to be any fun at all due to the increased complexity it causes. Especially if the IPv4 part of that dual-stack network is in itself getting increasingly complex due to more and more NAT being added to deal with growth. So IMHO dual-stack is a bad recommendation, or at least it is rather shortsighted. If you're in a position to do single-stack IPv6-only with IPv4 as a service (like T-Mobile USA or Kabel Deutschland), you'll end up with a much simpler network that it'll be much easier to maintain over the years. This also facilitates the use of IPv4 address sharing solutions like lw4o6 and MAP, whose stateless nature makes them vastly superior to traditional stateful Carrier Grade NAT44 boxes. YMMV, of course. Tore
On 1 February 2015 at 20:10, Tore Anderson <tore@fud.no> wrote:
- Tunneling moves the original layer-4 header into another encapsulation layer, so e.g. an ACL attempting to match an IPv6 HTTP packet using something like "next-header tcp, dst port 80" will not work. With translation, it will.
But on the other hand you will mess up with the routing of the network. In our network both IPv4 and IPv6 are routed to different transit points depending on the destination. With translation you need to ensure that the traffic passes a translation point before it leaves the network. If that translation involves NAT, then you also need to ensure that the return traffic hits the same translation device. On some links you might need twice as much capacity if the traffic needs to travel both ways due to the exit point being in one direction and the translation device in the other direction. In our dual stack setup we have none of this worry. The majority of our traffic never goes through a datacenter. It will be MPLS tagged and sent of to the correct edge router directly - for both v4 and v6 traffic.
I guess we disagree about the definitions, then.
In my view, a dual-stack network is one where IPv4 and IPv6 are running side-by-side like "ships in the night" with no fate sharing. You might be running two different IGP protocols (like OSPFv2 and OSPFv3) and a duplicated set of iBGP sessions. ACLs and the like must exist both for IPv4 and IPv6. And so on. If you turn off one protocol, and the other one keeps on running just like before.
By that definition my dual stack network is single stack: kill ipv4 and MPLS goes down => everything is down. On the other hand there are actually two IPv4 networks, since the IPv4 network under MPLS does not carry internet traffic directly. BOTH IPv4 and IPv6 can be said to be tunneled through the MPLS network. I do not see the point in making this mess even bigger by adding another layer by shoehorning v4 traffic into v6 packets.
So much earlier than 30 years from now you'll be wanting to have IPv6 in your network anyway, and once you come to that realisation you might also realise that operating a dual-stack network for those 30 years is not going to be any fun at all due to the increased complexity it causes. Especially if the IPv4 part of that dual-stack network is in itself getting increasingly complex due to more and more NAT being added to deal with growth.
So IMHO dual-stack is a bad recommendation, or at least it is rather shortsighted. If you're in a position to do single-stack IPv6-only with IPv4 as a service (like T-Mobile USA or Kabel Deutschland), you'll end up with a much simpler network that it'll be much easier to maintain over the years. This also facilitates the use of IPv4 address sharing solutions like lw4o6 and MAP, whose stateless nature makes them vastly superior to traditional stateful Carrier Grade NAT44 boxes.
I fail to see the complexity. You are advocating that I should have spent money on more equipment and force my users to use a ISP supplied CPE (currently my users can use any CPE they want). On the other hand, there is little actual complexity to route both protocols in the backbone. We do not run two IGP protocols and all the iBGP sessions are MP-BGP which takes care of both v4 and v6. I see it the other way, trying to have only v6 in the backbone will add substantial complexity. It requires me to buy into some kind of carrier NAT, which it is not time for yet. It forces me to ban older CPEs, which might even be IPv6 capable. There are still brand new CPEs which can not do this correctly. Regards, Baldur
Hi Baldur, * Baldur Norddahl <baldur.norddahl@gmail.com>
On 1 February 2015 at 20:10, Tore Anderson <tore@fud.no> wrote:
- Tunneling moves the original layer-4 header into another encapsulation layer, so e.g. an ACL attempting to match an IPv6 HTTP packet using something like "next-header tcp, dst port 80" will not work. With translation, it will.
But on the other hand you will mess up with the routing of the network. In our network both IPv4 and IPv6 are routed to different transit points depending on the destination. With translation you need to ensure that the traffic passes a translation point before it leaves the network.
Sure, but you could scatter these translation points all over your network, so that the flow of traffic remains optimal. You could enable the translation functionality on your aggregation and/or your border routers, for example. The traffic would need to pass those anyway, so there's no real change to how traffic is being routed.
If that translation involves NAT, then you also need to ensure that the return traffic hits the same translation device.
No, with stateless solutions like MAP and lw6o4, there is no such requirement. Anycast them or use ECMP towards them however way you like. This is in my view one of the great advantages of such solutions over IPv4 CGN. To the best of my knowledge, there exists no stateless IPv4 sharing mechanism. So the CGN-ed traffic must flow bidirectionally across the same translation device, which then could easily become a choke point. Also, should the CGN device fail, all the existing sessions it was handling would be disrupted.
In my view, a dual-stack network is one where IPv4 and IPv6 are running side-by-side like "ships in the night" with no fate sharing. You might be running two different IGP protocols (like OSPFv2 and OSPFv3) and a duplicated set of iBGP sessions. ACLs and the like must exist both for IPv4 and IPv6. And so on. If you turn off one protocol, and the other one keeps on running just like before.
By that definition my dual stack network is single stack: kill ipv4 and MPLS goes down => everything is down.
On the other hand there are actually two IPv4 networks, since the IPv4 network under MPLS does not carry internet traffic directly. BOTH IPv4 and IPv6 can be said to be tunneled through the MPLS network.
While MPLS certainly blurs the lines a bit, based on your description I think that your network could reasonably be described as single-stack MPLS/IPv4-only at its core, while IPv6 (using 6PE I guess?) and another instance of IPv4 (distinct from the one used for MPLS signaling) is being transported as a "service" across that single-stack network.
I do not see the point in making this mess even bigger by adding another layer by shoehorning v4 traffic into v6 packets.
Agreed, considering that you seem to already be enjoying the benefits of having a single-stack network. That is after all what I am saying folks should be considering, rather than automatically going down the dual-stack road. While you're using MPLS instead of IPv6, the principle is similar.
I fail to see the complexity. You are advocating that I should have spent money on more equipment and force my users to use a ISP supplied CPE (currently my users can use any CPE they want).
I'm just advocating that people should seriously *consider* it, especially if they're buidling something new. I'm not saying it's for everyone everywhere, nor for you specifically. For a provider that controls the user equipment, going IPv6-only certainly a possibility, as demonstrated by T-Mobile USA and Kabel Deutschland. If OTOH there is a requirment to support legacy IPv4-only CPEs, then clearly IPv6-only isn't going to work out too well. Tore
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@herrin.us> wrote:
On Thu, Jan 29, 2015 at 6:28 PM, Eric Louie <elouie@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@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Fri, 30 Jan 2015, Eric Louie wrote:
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 :)
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
On Fri, Jan 30, 2015 at 8:29 AM, Justin M. Streiner <streiner@cluebyfour.org
wrote:
On Fri, 30 Jan 2015, Eric Louie wrote:
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 :)
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
What IPv6 to IPv4 translation mechanisms are available for networks with multiple ingress/egress points?
On Fri, 30 Jan 2015, Eric Louie wrote:
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.
What IPv6 to IPv4 translation mechanisms are available for networks with multiple ingress/egress points?
A bunch were listed in an earlier post. Translation is generally best done either as close to the customer edge as possible. jms
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. 2015-01-30 21:32 GMT+01:00 Eric Louie <elouie@techintegrity.com>:
On Fri, Jan 30, 2015 at 8:29 AM, Justin M. Streiner <streiner@cluebyfour.org
wrote:
On Fri, 30 Jan 2015, Eric Louie wrote:
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 :)
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
What IPv6 to IPv4 translation mechanisms are available for networks with multiple ingress/egress points?
On 1/30/15 8:29 AM, Justin M. Streiner wrote:
On Fri, 30 Jan 2015, Eric Louie wrote:
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 :)
Direct assignments exist down to /48s so you can expect to have to accept announcements down to that size given that they can't concievably be covered by an aggregate.
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
On Jan 30, 2015, at 07:51 , William Herrin <bill@herrin.us> wrote:
On Thu, Jan 29, 2015 at 6:28 PM, Eric Louie <elouie@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.
Yes and no. First, assuming you are limited to a /32 is absurd. I’ve personally helped multiple organizations obtain various size allocations ranging from /32 to /24 with little or no difficulty so long as the size of the network warranted it. (The biggest challenge was a large organization that I had to work at showing ARIN was, in fact, an ISP and not merely an end-user. They got a /24. In fairness to ARIN, it took me a while to realize myself that they were an ISP before I approached ARIN. It was an odd situation.) /48 for all customer sites is not at all unreasonable and is fully supported by ARIN policy. Where Bill is correct is that some customers may have more than one site. The official policy definition of a site is a single building or structure, or, in the case of a multi-tenant building or structure, a single tenant within that building. Yes, this could technically mean that a college dorm contains thousands of sites and could justify thousands of /48s. Owen
On Jan 30, 2015, at 07:37 , Owen DeLong <owen@delong> wrote:
/48 for all customer sites is not at all unreasonable and is fully supported by ARIN policy.
Where Bill is correct is that some customers may have more than one site. The official policy definition of a site is a single building or structure, or, in the case of a multi-tenant building or structure, a single tenant within that building. Yes, this could technically mean that a college dorm contains thousands of sites and could justify thousands of /48s.
Is this your recommendation for colleges? Or, are you simply pointing out a possible interpretation of ARIN policy?
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
On Jan 29, 2015, at 3:28 PM, Eric Louie <elouie@techintegrity.com> wrote:
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?)
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...
Hey Eric, I did not see anyone else post this, but the NANOG BCOP (Best Current Operating Practices) group has released the following document to help guide new IPv6 allocation plans which you and others may find helpful: http://bcop.nanog.org/images/6/62/BCOP-IPv6_Subnetting.pdf Another useful document from Department of Defense on IPv6 Addressing: http://www.v6.dren.net/AddressingPlans.pdf BCOP Conclusions 1. Every individual network segment requires at a minimum, one /64 prefix 2. Only subnet on nibble boundaries 3. Implement a hierarchical addressing plan to allow for aggregation a. Each individual site should be allocated a /48 prefix 4. One /48 from each region should be reserved for infrastructure a. Loopbacks should be allocated from the top /64 b. Point-to-point links should be allocated a /64 and configured with a /126 or /127 5. Sites/PoPs/locations and regions, etc. should be laid out such that within each level of the hierarchy, each subnet prefix is of equal size a. Each ³site² should likewise have an equalized internal hierarchy Regarding your management block, I would use the recommendation above to maintain a /48 in each region for management with the top /64 used for loopbacks. However I definitely would NOT bother removing this network from your advertised blocks as there are much better ways to implement security and it would screw with your ability to cleanly aggregate your IPv6 allocation. Thanks, Dustin Melancon Sr. Network Engineer Venyu
participants (15)
-
Baldur Norddahl -
Crawford, Scott -
David Barak -
Dustin Melancon -
Eric Louie -
Fred Baker (fred) -
joel jaeggli -
Justin M. Streiner -
Karsten Elfenbein -
Mel Beckman -
Owen DeLong -
Rob Seastrom -
Tore Anderson -
Valdis.Kletnieks＠vt.edu -
William Herrin