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.999% 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.%), 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.
Re: Assigning IPv6 /48's to CPE's?
On Jan 3, 2008 3:52 AM, Rick Astley [EMAIL PROTECTED] 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.0001%utilization?
Re: Assigning IPv6 /48's to CPE's?
On Wed, 2 Jan 2008, Rick Astley wrote: Some of the comments here have cleared things up a bit. I suspect we will see NAT doing some 4to6 and 6to4 through migration, but there is little reason to use NAT in place of stateful firewall in the v6 to v6 world. I think RFC3041 (Privacy Extensions) and RFC4864 (Local Network Protection) answer my question about MAC address privacy. I have to do some research on this, but does anyone know if Vista's IP stack is RFC3041 compliant today? (I believe OSX is but I don't know if it is enabled by default) On by default in Windows, off by default in Linux (net.ipv6.conf.all.use_tempaddr), OSX and BSD (net.inet6.ip6.use_tempaddr) On to IP address allocation again: So I was thinking of /64 as one subnet consisting of multiple nodes, when in practice a /64 is more like one node. This does open up some interesting possibilities like using multiple IP addresses within a /64 on a single machine. You could do things on the client side like separating applications into different security zones with individual IP addresses, or giving individual users on the system their own IP addresses so you can do user/zone specific firewall policies. In my opinion /64 is very likely not a one-node configuration. Potentially you can put every computer under the world into /64. I agree the functional/operational separation is easy with /64. Earlier in IPv4 you had to think about the subnet sizes: here you have /64 and you can put as many computer as you like in that subnet! Introduction of IPv6 support in your network allows rethinking the subnetting, and address allocation to accomodate better your current need. Best Regards, Janos
Re: /56 for home sites, /48 for business sites billing considerations (Was: European ISP enables IPv6 for all?)
On 23 Dec 2007, at 20:34, Jeroen Massar wrote: [...] When an ISP is not going to provide /48's to endusers then RIPE NCC should revoke the IPv6 prefix they received as they are not following the reasons why they received the prefix for. They received the prefix because they had a plan. That's all, a plan. Not a promise. It is not a plan, it is justification. The 200-rule has been taken out of the allocation already. Right. But circumstances change. And based on the x customers times /48, they justified that they will need a /20 or something else. As such when they are going to give out /56's, they suddenly need 256 times as many customers and unless they are going to grow insanely (for a /32 from ~60k to 15m customers) they won't be able to justify their address space anymore. One issue ISPs with very large IPv6 allocations may be thinking about is that additional allocations are always based on the policies in place when they make their request, not the policies in place when they received their initial allocation. If the policy has become more conservative since the allocation was made there is a chance that the plan that justified the initial allocation will need to be modified to take account of the changed policy. In other words, an allocation that was made based on an ISPs needs for just the next few years might have to last considerably longer. The alternative could be the ISP finding its efficiency is too low to justify the extra block it has requested. So I won't be too surprised if I see some ISPs assigning some /56s when their original plans were only for /48 assignments. Regards, Leo
periodic patterns in juniper netflow exports
hi there, I'm analyzing NetFlow traces from Abilene (which uses Juniper, of course) and I'm seeing a periodic pattern in the traces. I know about the activity and inactivity timeouts that can be set in JunOS to control flow exports, but in the data I'm analyzing it seems like there is some kind of global clock that flushes the flow cache every minute. I mean the router exports *all* flows which are active at the end of a time bin of one minute. Because of this, the flow records look like they are binned in 1 minute intervals. By the way, I'm not talking about any manipulation done by the collector. I'm really looking at the FIRST and LAST time stamps contained in each flow record. Can anyone tell me if there is such a timer in JunOS, i.e., flushing the flow cache every minute (or an interval defined as a parameter)? Thanks in advance and happy Hew Year! Fernando Silveira
Re: periodic patterns in juniper netflow exports
On Jan 3, 2008, at 5:57 PM, Fernando Silveira wrote: Can anyone tell me if there is such a timer in JunOS, i.e., flushing the flow cache every minute (or an interval defined as a parameter)? I don't know about Juniper routers, but there's such a setting in Cisco routers, it's called the active flow timer. If you don't use it and don't tell your collection/analysis system what setting you've used (most folks use between 5 minutes for traffic analysis down to one minute for security-related analysis), you end up with backlogged stats which aren't chronologically representative of the actual traffic, and your graphs are all jagged and useless. My guess would be that Juniper have a similar construct for a similar purpose. Most collection/analysis systems of which I'm aware take this setting into account, as long as you tell them what interval you're using. It's generally considered highly desirable to make use of this functionality, for the aforementioned reasons. --- Roland Dobbins [EMAIL PROTECTED] // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company
Re: Assigning IPv6 /48's to CPE's?
On Jan 3, 2008 4:10 AM, Mikael Abrahamsson [EMAIL PROTECTED] 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.
Re: Assigning IPv6 /48's to CPE's?
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
RE: Assigning IPv6 /48's to CPE's?
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
Re: Assigning IPv6 /48's to CPE's?
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, [EMAIL PROTECTED]
Re: periodic patterns in juniper netflow exports
hi Roland, actually I believe the patterns I'm talking about are not caused by the activity timer. As fair as I know, the activity timer exports a flow which has been active for too long. Therefore, it should be counted from the beginning of the flow (its first packet), right? The patterns I'm talking about would imply an absolute clock (independent of any flow) ticking every minute, and flushing the entire flow cache. The result of this would be the binning effect I mentioned. The patterns I'm talking about seem really specific to Juniper routers. I have another set of traces (which I believe come from Cisco routers) and they don't have the periodic flow export pattern I'm referring here. I have two or three plots that show in detailed what I'm trying to explain, but I'm not sure I can post them here. If you'd like to see them I can send them to you (or anybody interested) or I could post it on the web and send you the URL. Thanks for the quick reply! Fernando On Jan 3, 2008 11:42 AM, Roland Dobbins [EMAIL PROTECTED] wrote: On Jan 3, 2008, at 5:57 PM, Fernando Silveira wrote: Can anyone tell me if there is such a timer in JunOS, i.e., flushing the flow cache every minute (or an interval defined as a parameter)? I don't know about Juniper routers, but there's such a setting in Cisco routers, it's called the active flow timer. If you don't use it and don't tell your collection/analysis system what setting you've used (most folks use between 5 minutes for traffic analysis down to one minute for security-related analysis), you end up with backlogged stats which aren't chronologically representative of the actual traffic, and your graphs are all jagged and useless. My guess would be that Juniper have a similar construct for a similar purpose. Most collection/analysis systems of which I'm aware take this setting into account, as long as you tell them what interval you're using. It's generally considered highly desirable to make use of this functionality, for the aforementioned reasons. --- Roland Dobbins [EMAIL PROTECTED] // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company
Re: periodic patterns in juniper netflow exports
On Jan 3, 2008, at 7:53 PM, Fernando Silveira wrote: The patterns I'm talking about would imply an absolute clock (independent of any flow) ticking every minute, and flushing the entire flow cache. The result of this would be the binning effect I mentioned. Yes, what you're describing is in fact different from the Cisco active flow timer. The Cisco active flow timer is set relative to the beginning of the flow, as you indicate, and not a system-wide purge of the entire cache (I didn't parse that properly in your initial query, apologies) on some sort of fixed-time basis. There are folks involved in various NetFlow collection/analysis efforts on this list, I'm sure one of them or someone from Juniper will respond. juniper-nsp might also be a good place to ask. --- Roland Dobbins [EMAIL PROTECTED] // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company
RE: Assigning IPv6 /48's to CPE's?
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
Re: Assigning IPv6 /48's to CPE's?
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
RE: Assigning IPv6 /48's to CPE's?
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
RE: Assigning IPv6 /48's to CPE's?
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 00 01 10 11 which is equivalent to 111000/3 or (111000,000111) --Michael Dillon
Re: Assigning IPv6 /48's to CPE's?
Once upon a time, Donald Stahl [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
RE: Assigning IPv6 /48's to CPE's?
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
Re: Assigning IPv6 /48's to CPE's?
On Jan 3, 2008 3:52 AM, Rick Astley [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
RE: v6 subnet size for DSL leased line customers
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leo Bicknell Sent: Thursday, December 27, 2007 8:51 AM To: North American Network Operators Group Subject: Re: v6 subnet size for DSL leased line customers In a message written on Thu, Dec 27, 2007 at 11:27:13AM +0100, Iljitsch van Beijnum wrote: 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information. I would note, it's not too late to fix these problems. We don't have wide spread IPv6 deployment yet, and I can't imagine it's all that hard to send a default gateway in DHCPv6, for example. -- Someone earlier threw out an offhand 'preferred gateway' DHCPv6 parameter as a possibility. This is actually a nifty idea... Hey, you there, use potential gateways in the following order! It has the same utility and simplicity that MX records do. Jamie
Re: Assigning IPv6 /48's to CPE's?
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
RE: Assigning IPv6 /48's to CPE's?
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 :) My point was to give a rough approximation of the size difference here, not to talk about the specific numbers. 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 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
Re: Assigning IPv6 /48's to CPE's?
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.
Re: Assigning IPv6 /48's to CPE's?
On Jan 3, 2008 11:25 AM, Tim Franklin [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Assigning IPv6 /48's to CPE's?
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 [EMAIL PROTECTED] (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
Re: Assigning IPv6 /48's to CPE's?
In article [EMAIL PROTECTED] 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:::: --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
Re: v6 subnet size for DSL leased line customers
Thus spake Simon Lyall [EMAIL PROTECTED] On Wed, 2 Jan 2008, Deepak Jain wrote: Is there anything inherently harmful with suggesting that filtering at RIR boundaries should be expected, but those that accept somewhat more lenient boundaries are nice guys??? When the nice guys run out of resources, they can filter at RIR boundaries and say they are doing so as a security upgrade :_). So how would this work for large companies? In theory multinationals like Morgan Stanley, Wall-Mart or HSBC should only get at most a /48 from each RIR. In what theory? They'd get at _minimum_ a /48 from each RIR that has approved PIv6. If they needed more, they merely have to fill out the appropriate paperwork showing justification. If they operate in regions where the RIR hasn't approved PIv6, they'd route around the failure there and use space assigned by other RIRs. (Not saying I approve of that, but it's reality.) Currently ARIN is approving all requests for more than a /48 since there is no definition of what justify means in that context. Ebay, which is hardly the size of the companies you listed, got a /41. That obviously needs fixing, but the problem is the opposite of the one you seem to be theorizing. How should they handle region offices, Especially mutihomed ones? Announce their prefix from all locations, with more-specifics for TE purposes. Presumably their upstreams would carry the more-specifics since they're being paid to, but folks further away would filter them and only see the covering aggregate, which is good enough. (Note this assumes they have an internal network; if they didn't, each disconnected part would be a site and qualify for a /48 on its own. That's a suboptimal solution, though, for reasons too numerous to list.) S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Verizon (DSL) security contact
Could someone from Verizon incident response/security please contact me off list. Thanks -A
