Re: Assigning IPv6 /48's to CPE's?
* /32 for ISPs unless they can justify more * /48 for subscribers unless they can justify more * /64 when you know for certain that one and only one subnet will ever be required * /128 when you know for certain you're dealing with a single device * Sparse allocation so whichever size you choose you can usually increase it by simply changing the prefix length.
So if /64 is "subnet" rather than "node" then the practice of placing one and only one node per subnet is pretty wasteful. And giving residential users a /48 will leave them with 80 bits for addressing. Even if the household was using 1,000,000,000,000,000 IP addresses in their home, this would mean that they are still not using 99.9999999% of the IP addresses they have been allocated. I know the reason for this is becasue they are allocated IP's based on number of possible subnets, rather than total number of available IP's, so it would be more fair to say they are allocated 65,536 subnets. So Acme DSL has been given a /32 from ARIN. Bob their administrator promptly decides it is a good idea to just give each customer a /48 becasue who knows /what/ their needs may be. This gives Acme Bob enough IP addresses for 2^(48-32) or 65,536 customers assuming bob uses none of these IP addresses for his own equipment and has a single homed network. If Bob has a multihomed network, he can't just give one /48 to a customer in NY and the next one to a customer in CA unless he wants to fill up Internet routing tables with /48's, so he will have to assign large aggregate blocks to each region. Accommodating for this, Bob is unlikely to plan for more than 30% utilization in any one region, with most being less and some aggregate blocks withheld entirely for growth. So lets say Acme DSL's IPv6 deployment places them in the ballpark of 10% utilization (not bad considering end users are wasting 99.99999999999999999999%), this gives them enough blocks for only 6,500 customers. Take someone like Comcast with ~12 million subscribers. It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net efficiency of 10% they are going to need to be allocated 120 million /48's. It would take a /21 to give them 2^(48-21) = ~134 million /48's. So in short, a /48 to subscribers seems like complete overkill, and a /32 to ISP's seems completely inadequate (80 vs 16 bits). I thought one of the goals of IPv6 was to assign ISP's huge blocks with low utilization so they don't have push a bunch of individual prefixes out to the worlds routing tables? It seems to me while being extra super sure we meet goal 1 of making sure NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of prefixes to ISP's that are too small.
On Thu, 3 Jan 2008, Rick Astley wrote:
If Bob has a multihomed network, he can't just give one /48 to a customer in NY and the next one to a customer in CA unless he wants to fill up Internet routing tables with /48's, so he will have to assign large aggregate blocks to each region.
Could you please elaborate on this? Unless Bob is actually breaking the "single AS needs to have common IGP and be connected internally", I don't understand the relevance of your statement above. Just because he's multihomed doesn't mean he can't just announce /32 and then internally handle the routing (of course he should do aggregation though, but perhaps is smaller chunks).
It seems to me while being extra super sure we meet goal 1 of making sure NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of prefixes to ISP's that are too small.
Well, if you need a /20 for your business needs, you should request it. Afaik as long as you justify it, it shouldn't be a problem? But I do agree that /56 should be enough for residential users for quite a while, so let's start there. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Jan 3, 2008 4:10 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Thu, 3 Jan 2008, Rick Astley wrote:
If Bob has a multihomed network, he can't just give one /48 to a customer in NY and the next one to a customer in CA unless he wants to fill up Internet routing tables with /48's, so he will have to assign large aggregate blocks to each region.
Could you please elaborate on this? Unless Bob is actually breaking the "single AS needs to have common IGP and be connected internally", I don't understand the relevance of your statement above. Just because he's multihomed doesn't mean he can't just announce /32 and then internally handle the routing (of course he should do aggregation though, but perhaps is smaller chunks).
Because announcing more specifics is more granular. Lets say we are both nationally connected and I peer with you in only one location (say CA). If we both announce only one aggregate block to each other, if I am trying to get to you in NY from NY, we are going to do it through California (not good). The same scenario happens if we peer on both sides of the country and one of the sessions goes down. In this case the best path is probably me > someone else > you. Now instead what I can do is tag my california routes with a "california" bgp community, and export only those specific routes to you there. This way your traffic to me in NY will not go over this session. Now unless you want a pile of /48's handed to you over this session, it is good practice for me to aggregate my routes based on location as best I can.
Now instead what I can do is tag my california routes with a "california" bgp community, and export only those specific routes to you there. This way your traffic to me in NY will not go over this session.
dunno about the community in which you peer. but the big kids have pretty much insisted on consistent announcements at all peerings unless negotiated otherwise. randy
On Jan 3, 2008 3:52 AM, Rick Astley <jnanog@gmail.com> wrote:
Take someone like Comcast with ~12 million subscribers.
It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net efficiency of 10% they are going to need to be allocated 120 million /48's. It would take a /21 to give them 2^(48-21) = ~134 million /48's.
So in short, a /48 to subscribers seems like complete overkill, and a /32 to ISP's seems completely inadequate (80 vs 16 bits).
I thought one of the goals of IPv6 was to assign ISP's huge blocks with low utilization so they don't have push a bunch of individual prefixes out to the worlds routing tables?
It seems to me while being extra super sure we meet goal 1 of making sure NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of prefixes to ISP's that are too small.
PS. say for example we would like to meet goal 2 while giving customers /48's at the same time. We decide a an initial projected utilization of 1% or .1% is more appropriate for Comcast. In order to give them 1.2 billion /48's (1% utilization), they would need 2 /18's. For 12 billion (0.1% utilization), they would need a /14. In which case the depletion of IPv6 space starts to seem possible. Your response might be "Why would an ISP need 0.1% utilization?" My answer: "Why would a customer need 0.000000000000000000000001%utilization?"
So if /64 is "subnet" rather than "node" then the practice of placing one and only one node per subnet is pretty wasteful.
In an IPv6 network, a /64 is the subnet prefix of a single broadcast domain, i.e. a single unbridged Ethernet segment. Within this subnet, there are many /128s which represent interfaces connected to the broadcast domain. These /128's are not "nodes" in the common sense of the term, i.e. they are not "boxes" or "devices". In some case, a device will only have a single interface connected to the broadcast domain, but ot could have more than one. If the device is a virtualization host, as is increasingly common, then it will have many virtual interfaces connected to the broadcast domain, each of which will have a /128 assigned to it.
And giving residential users a /48 will leave them with 80 bits for addressing.
No, it gives them 16 bits for subnetting. Everybody gets 64 bits for addressing because everybody (except oddballs and enevelope pushers) uses a /64 subnet size. Since 64 bits are more than anyone could ever possibly need for addressing and 16 bits is more than an end site could ever possibly need for subnetting, the /48 is an ideal allocation size. The whole point of IPv6 is to get rid of scarcity and parsimony in network architecture. If you aren't giving people more addresses than they need, then you aren't following the fundamental IPv6 model. Note that it is NOT wasteful to give people more addresses than they need. It allows things like the ULA random subnet selection algorithm to function with minimal probability of collision.
I know the reason for this is becasue they are allocated IP's based on number of possible subnets, rather than total number of available IP's, so it would be more fair to say they are allocated 65,536 subnets.
Yes! In IPv6 we do not allocate addresses, we allocate subnet bits. We don't count addresses either, we use an HD ratio based on counting subnets. People don't "get addresses" or "have addresses". They get subnets and have subnets.
So Acme DSL has been given a /32 from ARIN. Take someone like Comcast with ~12 million subscribers.
Can anybody say "scaling effects"? Comcast will never do things like a small ISP and vice versa.
It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net efficiency of 10% they are going to need to be allocated 120 million /48's. It would take a /21 to give them 2^(48-21) = ~134 million /48's.
Bad calculation. IPv6 usage efficiency is measured using the HD ratio and that is not what you are calculating. This is an especially important point for mid-size ISPs who go for a /32 allocation from ARIN. If you use up that /32 allocation and go back to ARIN to request another /32, you will *NOT* be able to bamboozle them with arbitrary figures like you are throwing around here. You *WILL* need to demonstrate that you meet the current HD ratio guidelines to justify another block.
I thought one of the goals of IPv6 was to assign ISP's huge blocks with low utilization so they don't have push a bunch of individual prefixes out to the worlds routing tables?
It would be good to seem some mid-sized ISPs presenting how they designed their internal addressing architecture taking into account the HD ratio needed to justify an additional allocation. This would include how they handle BGP route aggregation internally and externally. --Michael Dillon
No, it gives them 16 bits for subnetting. Everybody gets 64 bits for addressing because everybody (except oddballs and enevelope pushers) uses a /64 subnet size. Since 64 bits are more than anyone could ever possibly need for addressing and 16 bits is more than an end site could ever possibly need for subnetting, the /48 is an ideal allocation size.
As should be clear from the previous discussion, there are plenty of us who disagree here, and lean towards /56 for end users (typically residential customers) while business users would get a /48 or more based on need. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
No, it gives them 16 bits for subnetting. Everybody gets 64 bits for addressing because everybody (except oddballs and enevelope pushers) uses a /64 subnet size. Since 64 bits are more than anyone could ever possibly need for addressing and 16 bits is more than an end site could ever possibly need for subnetting, the /48 is an ideal allocation size.
As should be clear from the previous discussion, there are plenty of us who disagree here, and lean towards /56 for end users (typically residential customers) while business users would get a /48 or more based on need.
I wouldn't say that is a disagreement, more of an extension. In other words, many of us believe that 16 bits per end site is an ideal customer allocation, but feel that residential customers in their home are not in any way penalized by reducing this to 8 bits. They still have scope for a significant amount of subnetting even in extreme cases like constructing an inlaw suite plus operating a family business out of the home. I do agree that /56 per residential customer is the ideal allocation for a mid-sized to large ISP that has a large number of residential customer sites on its network. I expect that most such ISPs will implement a model with /48's to business and /56's to residential addresses. But I also expect that smaller ISPs or those who mainly supply business access services, will find it simpler to just give everyone a /48. The only place in which people have noted that there is a possibility of running out of bits in the existing IPv6 addressing hierarchy is when they look at a model where every residential customer gets a /48. In that scenario there is a possibility that we might runout in 50 to 100 years from now. If only the ISPs with a large residential user population go to a /56 per residential site, then we have solved the problem. --Michael Dillon
The only place in which people have noted that there is a possibility of running out of bits in the existing IPv6 addressing hierarchy is when they look at a model where every residential customer gets a /48. In that scenario there is a possibility that we might runout in 50 to 100 years from now. Is it even a possibility then? A /48 to everyone means 48 bits left over for the network portion of the address.
That's 281,474,976,710,656 /48 customer networks. It's 16 million times the number of class C's in the current IPv4 Internet. Am I just not thinking large or long term enough? -Don
Is it even a possibility then? A /48 to everyone means 48 bits left over for the network portion of the address.
That's 281,474,976,710,656 /48 customer networks. It's 16 million times the number of class C's in the current IPv4 Internet. Am I just not thinking large or long term enough?
No, you are just counting wrong. When you are talking /48's you are talking "number of bits of of subnet hierarchy", not "pile of pebbles on the beach". If you read the ARIN IPv6 policy you will see that they don't count /48's like pebbles, instead they use something called the HD Ratio. Basically, this recognizes that IP networks are not flat piles of pebbles, but have a hierarchical aggregation structure in them. At each level of aggregation, you have to do a fitting exercise, where you fit what you have into a power of two sized block. If you have 5 subnets that need to be aggregated into a single higher level subnet, then you must use 3 bits of your subnet hierarchy, even though those 3 bits could be used for as many as 8 subnets. This is not waste. It is a fact imposed by the structure of IPv6 (and IPv4) subnet addresses. In fact, when you "throw away" subnets (addresses) like that, you are actually following a prudent conservation policy. That's because this kind of bitwise network addressing is cheaper to implement in hardware and can be processed faster in hardware when doing things like FIB lookups. That conserves MONEY and TIME which are vastly more important to conserve than theoretical counting capacity of a bitstring. Remember, IP addresses don't really exist. They are just bitstrings which some people like to arrange in orderly sets such as: 111000 111001 111010 111011 111100 111101 111110 111111 which is equivalent to 111000/3 or (111000,000111) --Michael Dillon
That's 281,474,976,710,656 /48 customer networks. It's 16 million times the number of class C's in the current IPv4 Internet. Am I just not thinking large or long term enough?
No, you are just counting wrong. When you are talking /48's you are talking "number of bits of of subnet hierarchy", not "pile of pebbles on the beach". If you read the ARIN IPv6 policy you will see that they don't count /48's like pebbles, instead they use something called the HD Ratio. I'm fully aware of HD ratio thanks :)
Basically, this recognizes that IP networks are not flat piles of pebbles, but have a hierarchical aggregation structure in them. At each level of aggregation, you have to do a fitting exercise, where you fit what you have into a power of two sized block. If you have 5 subnets that need to be aggregated into a single higher level subnet, then you must use 3 bits of your subnet hierarchy, even though those 3 bits could be used for as many as 8 subnets.
This is not waste. It is a fact imposed by the structure of IPv6 (and IPv4) subnet addresses. In fact, when you "throw away" subnets (addresses) like that, you are actually following a prudent conservation policy. That's because this kind of bitwise network addressing is cheaper to implement in hardware and can be processed faster in hardware when doing things like FIB lookups. That conserves MONEY and TIME which are vastly more important to conserve than theoretical counting capacity of a bitstring. I'm not sure what your point is here. I'm not remotely trying to argue
My point was to give a rough approximation of the size difference here, not to talk about the specific numbers. this. You made a point about HD ratio- 80% HD with 48 bits of network address still gives us 300,000,000,000 /48 networks (unless my math is very wrong). Again, I'm not sure how we're going to use that up in 50 or 100 years, but I'm sure history will prove me a fool. -Don
So if /64 is "subnet" rather than "node" then the practice of placing one and only one node per subnet is pretty wasteful. The whole point here is flexibility. IEEE defined several standards for globally unique identifiers including EUI-48/MAC-48 and EUI-64.
MAC-48 should last us til 2100, but the IEEE seems to be thinking longer term and also came out with EUI-64. Rather than create a protocol that wouldn't be able to handle longer MAC addresses the IPv6 WG decided to use EUI-64 for the host address in IPv6. This works for two reasons, a) There is a defined method for converting from MAC-48 to EUI-64 addresses (and back) and b) Even if Ethernet (or whatever comes next) uses a longer MAC addresses (up to 64 bits obviously) it will still make sense in IPv6. 64 bits is also a nice multiple for 32 and 64 bit systems which doesn't hurt when you're writing routing software or designing hardware.
And giving residential users a /48 will leave them with 80 bits for addressing. It leaves them with 65k subnets to choose from. Would a /56 make more sense? Right now- sure- becaue we lack the imagination to really guess what might happen in the future. Nanobots each with their own address, IP connected everything, who knows? Assigning a /48 to everyone gives everyone ample room and simplifies provisioning.
I'd rather push for /48 and have people settle on /56 than push for /56 and have people settle on /64.
Take someone like Comcast with ~12 million subscribers.
It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net efficiency of 10% they are going to need to be allocated 120 million /48's. It would take a /21 to give them 2^(48-21) = ~134 million /48's. In answer- so what?
So in short, a /48 to subscribers seems like complete overkill, and a /32 to ISP's seems completely inadequate (80 vs 16 bits). A /32 is the equivalent of a class A. How many small ISP's do you know with a class A? And larger networks? Give Comcast a /18. There is plenty of space.
IPv4 is 32 bits and has room for 4 billion addresses. Adding one additional bit gives you 33 bits and room for 8 billion addresses. Adding two additional bits gives you room for 16 billion. Adding 32 additional bits gives you room for 4 billion times 4 billion addresses. Seriously- stop and think about that for a second. We've taken the entire IPv4 Internet, multiplied it by 4 billion, and set that aside JUST FOR THE NETWORK PORTION of addresses! We've got 4 billion times 4 billion networks- that's a mind numbing increase in size even if you only assign a single host to each /64 subnet. If you put multiple hosts on each subnet then you've got an even larger space. People just can't seem to wrap their head around how large the new address space is. -Don
Once upon a time, Donald Stahl <don@calis.blacksun.org> said:
It leaves them with 65k subnets to choose from. Would a /56 make more sense? Right now- sure- becaue we lack the imagination to really guess what might happen in the future. Nanobots each with their own address, IP connected everything, who knows? Assigning a /48 to everyone gives everyone ample room and simplifies provisioning.
Do you really think that today's allocations are going to be in use (unchanged) when people are building homes out of IPv6-addressed nanobots, or when people are trying to firewall the fridge from the TV remote, etc.? I understand trying to plan for the future, but if someone is setting all this stuff up, getting a new (and larger) IPv6 block from their ISP is going to be the easiest part in the process.
I'd rather push for /48 and have people settle on /56 than push for /56 and have people settle on /64.
Again, why the hang-up on 8 bit boundaries? Why not /52 or /60? /60 is not much bigger than /64, but /52 gives an end-site 16 times as many subnets as /56 while giving the ISP 16 times as many blocks as /48. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
I'd rather push for /48 and have people settle on /56 than push for /56 and have people settle on /64.
Again, why the hang-up on 8 bit boundaries?
Look, why are we arguing about this? Why not split the difference? If /48 is too big and /64 is too small, let's go halfway and use /56, OK? This has the advantage that it is on a 4 bit nibble boundary which makes it the boundary between network and interface much clearer in writing 2001:3ff3:effe:1200::0/56 If you wrote 2001:3ff3:effe:12a0::0/56 then I would immediately see that there are too many bits in the network portion. It also avoids a messy situation with reverse DNS delegations. In the end, the decision had to be made to but the boundary somewhere, and with 16 bits to be divided plus the need to use 4-bit boundaries, the choices were (4,12), (8,8), and (12,4). Split the difference was the least objectionable. ARIN's decision on this boundary point has since been accepted by two other RIRs, so it seems to be community consensus now. --Michael Dillon
In article <D03E4899F2FB3D4C8464E8C76B3B68B001AB7722@E03MVC4-UKBR.domain1.systemhost.net> you write:
I'd rather push for /48 and have people settle on /56 than push for=20 /56 and have people settle on /64. =20 Again, why the hang-up on 8 bit boundaries?
Look, why are we arguing about this? Why not split the difference? If /48 is too big and /64 is too small, let's go halfway and use /56, OK?
This has the advantage that it is on a 4 bit nibble=20 boundary which makes it the boundary between network and interface much clearer in writing 2001:3ff3:effe:1200::0/56=20 If you wrote 2001:3ff3:effe:12a0::0/56 then I would=20 immediately see that there are too many bits in the network portion. It also avoids a messy situation with reverse DNS delegations.
And /48 is easier still. 2001:3ff3:effe:1234:xxxx:xxxx:xxxx:xxxx <--ASSIGNED-->:<ME>:<------auto------->
In the end, the decision had to be made to but the boundary somewhere, and with 16 bits to be divided plus the need to use 4-bit boundaries, the choices were (4,12), (8,8), and (12,4). Split the difference was the least objectionable.
ARIN's decision on this boundary point has since been accepted by two other RIRs, so it seems to be community consensus now.
--Michael Dillon
Do you really think that today's allocations are going to be in use (unchanged) when people are building homes out of IPv6-addressed nanobots, or when people are trying to firewall the fridge from the TV remote, etc.? I certainly hope not- but then again I never thought IPv4 would be around
this long either.
I understand trying to plan for the future, but if someone is setting all this stuff up, getting a new (and larger) IPv6 block from their ISP is going to be the easiest part in the process. You're right of course.
Again, why the hang-up on 8 bit boundaries? Why not /52 or /60? /60 is not much bigger than /64, but /52 gives an end-site 16 times as many subnets as /56 while giving the ISP 16 times as many blocks as /48. Because byte alignment makes for shortcuts in routing softare/hardware allowing higher speeds? Because ARIN says so? :)
-Don
On Jan 3, 2008 3:52 AM, Rick Astley <jnanog@gmail.com> wrote:
* /32 for ISPs unless they can justify more * /48 for subscribers unless they can justify more
Take someone like Comcast with ~12 million subscribers.
It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net efficiency of 10% they are going to need to be allocated 120 million /48's. It would take a /21 to give them 2^(48-21) = ~134 million /48's.
And indeed Rick, British Telecom, France Telecom and Deutsche Telekom did exactly these calculations and used them to justify the /19's and /20s that they were allocated from RIPE. Fortunately, there are only a handful of Comcasts. The vast majority of ISPs have customer counts well shy of the million mark. If you have more than 65,000 customers today, you should have little trouble justifying an initial IPv6 allocation larger than /32. You simply state in your application that you intended to assign a /48 to each. Any such reallocation up to a /48 is deemed to be automatically justified at the registry level.
So in short, a /48 to subscribers seems like complete overkill, and a /32 to ISP's seems completely inadequate (80 vs 16 bits).
This is why some folks recommend a /56 for small subscribers instead of a /48, reducing the waste by two and a half orders of magnitude. In a world where only the largest subscribers choose to deploy more than 4 IPv4 subnets (including their NATed subnets) why should the initial IPv6 assignment exceed 256 subnets?
It seems to me while being extra super sure we meet goal 1 of making sure NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of prefixes to ISP's that are too small.
In my ever so humble opinion, IPv6 will not reach significant penetration at the customer level until NAT has been thoroughly implemented. Corporate information security officers will insist. Here's the thing: a stateful non-NAT firewall is automatically less secure than a stateful translating firewall. Why? Because a mistake configuring a NAT firewall breaks the network causing everything to stop working while a mistake with a firewall that does no translation causes data to flow unfiltered. Humans being humans, mistakes will be made. The first failure mode is highly preferable. This is one of the trifecta that most seriously obstruct the deployment and acceptance of IPv6. The others are: client stack prefers IPv6 to IPv4 when available (so wonderful for Internet stability during the deployment years) and "incompatibility" meaning that instead of simply requiring a software upgrade after which the IPv6 addresses corresponding to your configured IPv4 addresses just work, IPv6 requires an entirely new set of allocations and an entirely new configuration management infrastructure. Double the work. Somewhat less than double the fun. But that's just my opinion. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, January 3, 2008 3:17 pm, William Herrin wrote:
In my ever so humble opinion, IPv6 will not reach significant penetration at the customer level until NAT has been thoroughly implemented. Corporate information security officers will insist. Here's the thing: a stateful non-NAT firewall is automatically less secure than a stateful translating firewall. Why? Because a mistake configuring a NAT firewall breaks the network causing everything to stop working while a mistake with a firewall that does no translation causes data to flow unfiltered. Humans being humans, mistakes will be made. The first failure mode is highly preferable.
Only assuming the nature of your mistake is 'turn it off'. I can fat-finger a 'port-forward *all* ports to important internal server', rather than just '80/TCP' pretty much exactly as easily as I can fat-finger 'permit *all* external to important internal server' rather than just '80/TCP'. Which failure mode is more acceptable is going to depend on the business in question too. If 'seconds connected to the Internet' is a direct driver of 'dollars made', spending a length of time exposed (risk of loss) while fixing a config error may well be preferable to spending a length of time disconnected (actual loss). I'll grant the 'everything is disconnected' case is easier to spot, though - especially if you don't have proper change management to test that the change you made is the change you think you made. Regards, Tim.
On Jan 3, 2008 11:25 AM, Tim Franklin <tim@pelican.org> wrote:
Only assuming the nature of your mistake is 'turn it off'.
I can fat-finger a 'port-forward *all* ports to important internal server', rather than just '80/TCP' pretty much exactly as easily as I can fat-finger 'permit *all* external to important internal server' rather than just '80/TCP'.
Tim, While that's true of firewalled servers that are intended to provide services to the Internet at large, the vast majority of equipment behind a typical NAT firewall provides no services whatsoever to the Internet and do not each map to their own global IP address. They are client PCs and a scattering of LAN servers. You can fat-finger "allow all ports inbound" in a stateful firewall far easier than you fat finger "translate a bank of global IP addresses I don't actually have on a one-to-one basis to this large list of local-scope IP addresses -and- allow all ports inbound" in a NAT firewall. Actually, the latter is pretty hard to configure at all, let alone fat-finger by mistake.
I'll grant the 'everything is disconnected' case is easier to spot, though - especially if you don't have proper change management to test that the change you made is the change you think you made.
Do you mean to tell me there's actually such a thing as a network engineer who creates and uses a test plan every single time he makes a change to every firewall he deals with? I thought such beings were a myth, like unicorns and space aliens! Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, 3 Jan 2008 12:53:24 -0500 "William Herrin" <herrin-nanog@dirtside.com> wrote:
On Jan 3, 2008 11:25 AM, Tim Franklin <tim@pelican.org> wrote:
Only assuming the nature of your mistake is 'turn it off'.
Do you mean to tell me there's actually such a thing as a network engineer who creates and uses a test plan every single time he makes a change to every firewall he deals with? I thought such beings were a myth, like unicorns and space aliens!
I've had to do this. When there's SLAs / money involved for failure, you can't cowboy anything - because you're risking your job if you do. Funny thing is, going through a "rehersal" before you make any change increases significantly your chances of success - and now I prefer to plan my changes in detail before I do them, as it makes me look a lot better at my job. A firewall change in particular, because of the security consequences of mistake, justifies planning and review before implementation. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
Tim Franklin wrote:
On Thu, January 3, 2008 3:17 pm, William Herrin wrote:
In my ever so humble opinion, IPv6 will not reach significant penetration at the customer level until NAT has been thoroughly implemented. Corporate information security officers will insist. Here's the thing: a stateful non-NAT firewall is automatically less secure than a stateful translating firewall. Why? Because a mistake configuring a NAT firewall breaks the network causing everything to stop working while a mistake with a firewall that does no translation causes data to flow unfiltered. Humans being humans, mistakes will be made. The first failure mode is highly preferable.
Only assuming the nature of your mistake is 'turn it off'.
I can fat-finger a 'port-forward *all* ports to important internal server', rather than just '80/TCP' pretty much exactly as easily as I can fat-finger 'permit *all* external to important internal server' rather than just '80/TCP'.
Which failure mode is more acceptable is going to depend on the business in question too. If 'seconds connected to the Internet' is a direct driver of 'dollars made', spending a length of time exposed (risk of loss) while fixing a config error may well be preferable to spending a length of time disconnected (actual loss).
I'll grant the 'everything is disconnected' case is easier to spot, though - especially if you don't have proper change management to test that the change you made is the change you think you made.
Plus an ultimate 'oops, I unapplied the access-list on my internet facing interface' on a firewall should result in all traffic being blocked, at least on decent firewall... I think that's what was being talked about, no? I'm only speaking from experience on Cisco firewalls where a lower security interface cannot pass traffic to a higher level interface without explicit commands. Of course, allowing all traffic through 'by mistake' can just as easily be done with 1-to-1 static NAT configs and allowing all traffic in the access-list/firewall rule set when you are using NAT. Ultimately, someone who understands the equipment should be administering it, but we're all human and mistakes happen I suppose. I personally would not rely on NAT as an exclusive security mechanism in lieu of an actual firewall, but it works decently for most home users. IPv6 enabled SOHO devices will just need to block all ports by default. End users can open ports they need on their SOHO devices just li ke they map them today with NAT... or maybe uPnP will extend to IPv6 (or has it?) to configure firewall rules dynamically for people on their gateway? -- Vinny Abello Network Engineer vinny@tellurian.com (973)940-6100 (NOC) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "There is no objective reality. Only that which is measured exists. We construct reality, and only in the moment of measurement or observation." -- Niels Bohr
On Thu, 03 Jan 2008 10:17:37 EST, William Herrin said:
In my ever so humble opinion, IPv6 will not reach significant penetration at the customer level until NAT has been thoroughly implemented. Corporate information security officers will insist. Here's the thing: a stateful non-NAT firewall is automatically less secure than a stateful translating firewall. Why? Because a mistake configuring a NAT firewall breaks the network causing everything to stop working while a mistake with a firewall that does no translation causes data to flow unfiltered. Humans being humans, mistakes will be made. The first failure mode is highly preferable.
Which is why, if your site has an *actual* clue, the deployed hosts *also* have their own iptables/ipfilters/whatever-windows-calls-it rulesets that say what hosts are allowed to talk to them. So on the server, I can do: ip6tables -A tcp-in -s ! 2001:468:c80/48 -p tcp --dport 22 -j DROP Now, even if our firewall guys fumble-finger something, I won't get SSH connections coming in from outside AS1312. Of course, I can't talk about business pressures from customers that have incompetent security officers that don't understand stuff like multiple layers of defense...
As much as I don't want to resurrect this conversation again or beat a dead (now glued) horse: In the SOHO arena, today's NAT users may or may not opt to use SPI down the road. Many people just opt for the cheapest working solution and use defaults, so what we end up depends on what vendors like Linksys and Netgear decide. I am sure there will be customer demand for firewall functionality as well, but how much is not clear. I am talking about SOHO users because they are a big portion of the large DDoS networks and an important frontier in the fight against worm propagation. I know large mostly unused pools of client IP's make it more difficult to use traditional worm propagation methods in IPv6[1], but if customers move from IPv4 "firewalls" to IPv6 "routers", we still lose an important layer of security. 1. worm propagation strategies in an IPv6 Internet - http://www.cs.columbia.edu/~smb/papers/v6worms.pdf
On Jan 4, 2008 6:02 PM, Rick Astley <jnanog@gmail.com> wrote:
I know large mostly unused pools of client IP's make it more difficult to use traditional worm propagation methods in IPv6[1], but if customers move from IPv4 "firewalls" to IPv6 "routers", we still lose an important layer of security.
Seems like an understatement. Ipv6 addressing doesn't merely make them more difficult, they make traditional propagation methods and attack techniques that rely on 'scanning' a network from outside impossible to execute. If every subnet (end site) has a /64, and you can guess 16 of those bits (say most networks set the top 16 bits to zero and generate the rest using a true random number generator, for security's sake), there are so many IPs that random scanning has a probability of finding hosts so small, it is negligible.... It would take 9 years to probe 10% of the addresses of a single end site, assuming you can scan 100,000 ips per second. If the host id is sufficiently random or opaque to the outside world, then this is every bit as good as a well chosen password; it is essentially private, except to nodes on the local subnet (who can monitor and ping multicast addresses). I don't believe a worm can't effectively propagate and spend 10 years trying to find the IP address of the one or two computers at site X before moving to site Z that has 4 computers in a /64 some where... A worm that has to connect to a remote machine would definitely have to discern the IP through some method other than brute force scanning. Such as a clean system contacting an infected system to make a request (i.e. download a webpage) At which time the infected system stores requestor's ip in a database to probe later. On the other hand, an IPv6 host could in theory bind a new IP address for each group of web requests, not attach any listeners to that IP, and make that IP cease to exist after the web requests complete. Since the /64 is so large... this essentially accomplishes what NAT does for IPv4 users... the IP address is private, by virtue of the fact, that the host primary interface address cannot be guessed. Even if it is guessed, firewall rules may block traffic from the probing address long before they get close to randomly hitting a live IP :) -- -J
On Fri, 04 Jan 2008 23:04:24 CST, James Hess said:
Seems like an understatement. Ipv6 addressing doesn't merely make them more difficult, they make traditional propagation methods and attack techniques that rely on 'scanning' a network from outside impossible to execute.
I believe Steve Bellovin has already written extensively on this, and some of the more plausible alternate non-scanning strategies for worm propagation. I'm sure Steve has a pointer to the paper in question, which I've managed to misplace in my senility... ;)
On Sat, Jan 05, 2008 at 12:42:50AM -0500, Valdis.Kletnieks@vt.edu wrote:
I believe Steve Bellovin has already written extensively on this, and some of the more plausible alternate non-scanning strategies for worm propagation. I'm sure Steve has a pointer to the paper in question, which I've managed to misplace in my senility... ;)
Perhaps this one? http://www.cs.columbia.edu/~smb/papers/v6worms.pdf --Jeff
On Mon, 07 Jan 2008 07:34:22 EST, Jeff Aitken said:
On Sat, Jan 05, 2008 at 12:42:50AM -0500, Valdis.Kletnieks@vt.edu wrote:
I believe Steve Bellovin has already written extensively on this, and some of the more plausible alternate non-scanning strategies for worm propagatio
n.
I'm sure Steve has a pointer to the paper in question, which I've managed to misplace in my senility... ;)
Perhaps this one?
Yes, that's the one...
[lots of comments about the size of a /64]... Am I the only one who imagines most ISPs will just assign the default IP to each /64 (or whatever they issue) (e.g. all zeros or mostly zeros or just the MAC addy of the end CPE).. This would a) dramatically reduce the "breadth" of IPv6 space from a scanning perspective and b) even guessing MAC addys is not that hard given manufacturer codes. IPv6 seems very, very classful to me, and I think the lessons we learned in the pre-CIDR days about amplification and address-guessing and topology determination by remote are still pretty relevant. Obviously the firewall bit changes those expectations -- assuming they are used. But if we assume that 2^96 is enough space to hide in... well, I'm pretty sure we'll see every kind of mess we've had to deal with in the past revisit their gifts upon us. Deepak
It should probably be pointed out: Asking for practical advice on choosing /48 vs. /56 on a residential broadband CPE is largely unanswerable. Why? Because I don't know of any residential broadband CPEs that support IPv6. I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs less than $150US.) IMO, the only answers so far: businesses get /48 dialup gets /64 (by default anyway; there are always exceptions) John
On Mon, 07 Jan 2008 15:27:57 -0600 John Dupuy <jdupuy-list@socket.net> wrote:
It should probably be pointed out:
Asking for practical advice on choosing /48 vs. /56 on a residential broadband CPE is largely unanswerable.
Why?
Because I don't know of any residential broadband CPEs that support IPv6.
I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs less than $150US.)
From recent presentations I've seen, there's plenty of it in Japan and Korea.
IMO, the only answers so far:
businesses get /48 dialup gets /64
(by default anyway; there are always exceptions)
John
-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
Asking for practical advice on choosing /48 vs. /56 on a residential broadband CPE is largely unanswerable. Because I don't know of any residential broadband CPEs that support IPv6.
If you go to http://www.getipv6.info/index.php/IPv6_Presentations_and_Documents there is at least one presentation from Comcast, a residential broadband provider who explained that they simply cannot continue in business without IPv6. They started IPv6 deployment planning in 2005. If you don't know of CPE that supports IPv6, maybe you should ask a broadband ISP that is serious about surviving in business past the crunch of 2010.
I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs less than $150US.)
http://wiki.openwrt.org/IPv6_howto Clearly, this CPE is based on Linux which has had full IPv6 support for many years, including things like firewalling, transition mechanisms like 6to4, DNS and so on. Given the realities of today's low-end network device manufacturing (centered in China where IPv6 is already being deployed, and based on standard hardware designs that are differentiated by software, plastic case design, and packaging) it should take about two months from time of order for mass quantities of CPE devices to appear on the market. The software is already done, the standard hardware designs are fully capable of IPv6. All they are waiting for is customers like Linksys to place an order.
IMO, the only answers so far: businesses get /48 dialup gets /64
Wrong! The answer so far is that EVERYBODY gets a /48, but if you think that there is a risk that you won't be able to get additional /32s when you outgrow your first allocation, then give a /56 to RESIDENTIAL SITES. This is not the same as dialup, i.e. residential sites could be connected with DSL, T1s, wireless, or whatever. In fact, if a business is connected via dialup, you should give them a /48, because businesses have a habit of continuous growth, unlike residences which tend to top out at 5 or 6 residents. --Michael Dillon
If you go to http://www.getipv6.info/index.php/IPv6_Presentations_and_Documents there is at least one presentation from Comcast, a residential broadband provider who explained that they simply cannot continue in business without IPv6. They started IPv6 deployment planning in 2005. If you don't know of CPE that supports IPv6, maybe you should ask a broadband ISP that is serious about surviving in business past the crunch of 2010.
I agree. I regularly ask my vendors when IPv6 support is coming. All of them, from ComTrend to Zoom to 3com to etc. have stated that they are not even started working on IPv6 yet. They all plan on it, though, for what that is worth. The closest I've found so far is the soho boxes from cisco. Not really aimed at the residential market, however. Business-level service is supported now, of course.
IMO, the only answers so far: businesses get /48 dialup gets /64
Wrong! The answer so far is that EVERYBODY gets a /48, but if you think that there is a risk that you won't be able to get additional /32s when you outgrow your first allocation, then give a /56 to RESIDENTIAL SITES. This is not the same as dialup, i.e. residential sites could be connected with DSL, T1s, wireless, or whatever. In fact, if a business is connected via dialup, you should give them a /48, because businesses have a habit of continuous growth, unlike residences which tend to top out at 5 or 6 residents.
We will probably disagree about this one. I will probably give out /48 to residential broadband when we expand IPv6 to residential. But dialup users typically have zero networks; not even the single LAN of res broadband. The "CPE" is the laptop (or PC) they dialed in with. ARIN says "/64 when it is known that one and only one subnet is needed". Not that changing "all" of our IPv6 dialup users would take more than a couple of calls :). Talk about a narrow niche. John
The answer so far is that EVERYBODY gets a /48, but if you think that there is a risk that you won't be able to get additional /32s when you outgrow your first allocation, then give a /56 to RESIDENTIAL SITES. This is not the same as dialup, i.e. residential sites could be connected with DSL, T1s, wireless, or whatever. In fact, if a business is connected via dialup, you should give them a /48, because businesses have a habit of continuous growth, unlike residences which tend to top out at 5 or 6 residents.
We will probably disagree about this one. I will probably give out /48 to residential broadband when we expand IPv6 to residential. But dialup users typically have zero networks; not even the single LAN of res broadband.
I'm not talking about old folks hanging on to their 386 running Windows 3.1. There is a vast expanse of real estate known as rural America that is unlikely to get broadband anytime soon due to the large distance from the exchange. But these residential sites are often also family businesses with a network in the barn, one in the feed silo, etc., etc. They deserve to be assigned an IPv6 allocation under the same terms as urban sites, i.e. a /48. Admittedly there are issues in getting IPv6 access to these folks but in a world in which there aren't enough free IPv4 addresses, it is still doable using an IPv4 island containing their modem gateway, your terminal server and your IPv6 tunnel broker. Because it's an IPv4 island you can hijack any old IPv4 addresses and nobody will notice. And using IPv4 for transport avoids the need to upgrade PPP and terminal servers to support IPv6. Those old IPv4 terminal servers aren't likely to wear out anytime soon.
Not that changing "all" of our IPv6 dialup users would take more than a couple of calls :). Talk about a narrow niche.
For a rural ISP, it might be the core of their business. One size does not fit all. There is still room for good old-fashioned hackery in making an IPv6 Internet functional, just like the early days of the commercial Internet when people were building terminal servers out of Linux boxes, and hacking things like PoP before SMTP to glue things together. --Michael Dillon
John Dupuy wrote:
It should probably be pointed out:
Asking for practical advice on choosing /48 vs. /56 on a residential broadband CPE is largely unanswerable.
Why?
Because I don't know of any residential broadband CPEs that support IPv6.
If one doesn't look then you won't find it.
I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs less than $150US.)
http://buffalo.jp/products/catalog/network/wzr-ampg300nh/ http://www.apple.com/airportextreme/ Any device with a docsis 3.0 cable modem embedded in it (Scientific atlanta/cisco DRG2800 for example) probably more now that CES is going on right now. etc just an anecdote real quick. So I stayed on a small guest house on the southern outskirts of Toyko a couple of weeks ago and along with the luxury of getting breakfast with my $80 a night 9-tatami room, the complimentary wifi shared with 4 other guests had v4 and v6 provided via kddi residental vdsl. My hostess who was 75 if she was a day had email down pretty well but I wouldn't characterize her a technical user.
IMO, the only answers so far:
businesses get /48 dialup gets /64
(by default anyway; there are always exceptions)
John
I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs less than $150US.)
http://buffalo.jp/products/catalog/network/wzr-ampg300nh/
http://www.apple.com/airportextreme/
Any device with a docsis 3.0 cable modem embedded in it (Scientific atlanta/cisco DRG2800 for example)
probably more now that CES is going on right now.
Thanks for the links. I'll have to investigate the airport extreme's IPv6 support. At a $180 it's at the extreme price end for resi, but it's closer. Do you know of a north american vendor for the ampg300nh? I don't know Japanese, so I could not glean it from the page. Not that familiar with the cable modems as we are a dsl CLEC, but it's good to see resi cpes with IPv6. John
John Dupuy wrote:
I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs less than $150US.)
http://buffalo.jp/products/catalog/network/wzr-ampg300nh/
http://www.apple.com/airportextreme/
Any device with a docsis 3.0 cable modem embedded in it (Scientific atlanta/cisco DRG2800 for example)
probably more now that CES is going on right now.
Thanks for the links. I'll have to investigate the airport extreme's IPv6 support. At a $180 it's at the extreme price end for resi, but it's closer.
Do you know of a north american vendor for the ampg300nh? I don't know Japanese, so I could not glean it from the page.
There's currently an injunction preventing buffalo from selling wireless technology in north america. Win lose or settle it seems likely that they'll be back on the shelf at fry's eventually. http://www.buffalotech.com/press/releases/buffalo-issues-a-statement-about-t... The odms that make these things work of a common pile of components (from broadcom marvell atmel etc) includings software so it's only a matter of time before you see the same features in other products.
Not that familiar with the cable modems as we are a dsl CLEC, but it's good to see resi cpes with IPv6.
John
You could always use the Linksys WRT54GL w/ DD-WRT (http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Descri ption=wrt54gl, http://www.dd-wrt.com/dd-wrtv2/downloads.php). I have dual-stack hotspots running at my house and several public locations in Montana right now. Ken -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of John Dupuy Sent: Monday, January 07, 2008 2:28 PM To: NANOG list Subject: Re: Assigning IPv6 /48's to CPE's? It should probably be pointed out: Asking for practical advice on choosing /48 vs. /56 on a residential broadband CPE is largely unanswerable. Why? Because I don't know of any residential broadband CPEs that support IPv6. I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs less than $150US.) IMO, the only answers so far: businesses get /48 dialup gets /64 (by default anyway; there are always exceptions) John
* kmix@transaria.com (Kenneth Mix) [Tue 08 Jan 2008, 00:08 CET]:
You could always use the Linksys WRT54GL w/ DD-WRT ( http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Description=wrt54gl, http://www.dd-wrt.com/dd-wrtv2/downloads.php ). I have dual-stack hotspots running at my house and several public locations in Montana right now.
Recent versions of dd-wrt sadly do not include IPv6 anymore. -- Niels.
On 7-jan-2008, at 22:27, John Dupuy <jdupuy-list@socket.net> wrote:
IMO, the only answers so far:
businesses get /48 dialup gets /64
Hm... How do you provision IPv6 for dial-up, anyway? PPP won't give you an IPv6 address and vendors have different opinions on stateless autoconfig (RAs) over PPP links.
On 2008/01/07 15:27, John Dupuy wrote:
Because I don't know of any residential broadband CPEs that support IPv6.
I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs less than $150US.)
IMO, the only answers so far:
businesses get /48 dialup gets /64
free.fr use their own (broadcom-based) CPE which runs modified 6to4, their subscribers get one /64 (from free's allocation, not the classic 2002:: of normal 6to4). I don't know about costs (it also handles VoIP and video) but it's definitely residential. as you might expect, this results in people doing nasty tricks so they can use their own firewalls, see http://ip6.fr/free-broute/ (in French, but fig.2 tells all).
I can give you a couple of pointers for DSL CPEs that support IPv6: http://www.billion.com/product/adsl/bipac7402r2.php http://www.cisco.com/en/US/products/ps6202/index.html The former is intended for residential users while the latter is intended for SOHO and teleworkers. The 870 cisco series supports IPv6 with the "Cisco IOS Software Features on Cisco 870 Series Routers-Advanced Security Feature Set". I'm not aware of prices though. I guess it depends on local dealers in each region. Regards Miguel
-----Mensaje original----- De: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] En nombre de John Dupuy Enviado el: lunes, 07 de enero de 2008 22:28 Para: NANOG list Asunto: Re: Assigning IPv6 /48's to CPE's?
It should probably be pointed out:
Asking for practical advice on choosing /48 vs. /56 on a residential broadband CPE is largely unanswerable.
Why?
Because I don't know of any residential broadband CPEs that support IPv6.
I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs less than $150US.)
IMO, the only answers so far:
businesses get /48 dialup gets /64
(by default anyway; there are always exceptions)
John
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
participants (23)
-
Chris Adams -
Deepak Jain -
Donald Stahl -
Iljitsch van Beijnum -
James Hess -
Jeff Aitken -
Joel Jaeggli -
John Dupuy -
Kenneth Mix -
Mark Andrews -
Mark Smith -
michael.dillon＠bt.com -
Miguel A. Diaz -
Mikael Abrahamsson -
Niels Bakker -
Randy Bush -
Rick Astley -
sthaug＠nethelp.no -
Stuart Henderson -
Tim Franklin -
Valdis.Kletnieks＠vt.edu -
Vinny Abello -
William Herrin