Re: Addressing plan exercise for our IPv6 course
On 29 July 2010 18:08, Leo Vegoda leo.veg...@icann.org wrote: There's a good chance that in the long run multi-subnet home networks will become the norm. With all due respect, I can't see it. Why would a home user need multiple subnets? Are they really likely to have CPE capable of routing between subnets at 21st Century LAN speeds? Isn't that needlessly complicating the home environment? Additionally, when it comes to address size, Andy Davidson et al make a good point - you request what you expect to assign, and due to the massive availability of the IPv6 address space, you generally get it assigned within a few days. It just seems *wasteful* to me. /32 is a lot of space, if most customers are only going to have a few machines on one subnet, why not just give them a /64 and have an easy way to just click on a button on your customer portal or similar to assign a /48 and get it routed to them. M
Re: Addressing plan exercise for our IPv6 course
On 2010-07-30 09:27, Matthew Walster wrote: On 29 July 2010 18:08, Leo Vegoda leo.veg...@icann.org wrote: There's a good chance that in the long run multi-subnet home networks will become the norm. With all due respect, I can't see it. Why would a home user need multiple subnets? * Wireless * Wired * DMZ Those three I see a lot at various people's places. Also note that you should stop thinking of today, think about what might be possible in 10, 20, 30, 40, 50 years... You don't have to bother your customers and your customers don't have to bother you anymore. The /48 for end-users might indeed be a bit on the much side, but a /56 is IMHO perfect fit for any home-site. The huge advantage of just giving out /48s though is that you don't have to care about if the connection is terminated at a home or a big corporation, as they say with shirts: one size fits all, simply as it is way too big. Greets, Jeroen
Re: Addressing plan exercise for our IPv6 course
On 30 July 2010 08:32, Jeroen Massar jer...@unfix.org wrote: On 2010-07-30 09:27, Matthew Walster wrote: On 29 July 2010 18:08, Leo Vegoda leo.veg...@icann.org wrote: There's a good chance that in the long run multi-subnet home networks will become the norm. With all due respect, I can't see it. Why would a home user need multiple subnets? * Wireless * Wired * DMZ Those three I see a lot at various people's places. I have *never* seen those three security zones separated outside of a business or the house of a nerd who runs his own Linux distro (Smoothwall etc). Furthermore, you're then pushing all that traffic into a $30 router which almost guaranteed will be underpowered. Look at it this way: When I signed up at tunnelbroker.net, I received a /64. I was happy, and I went about my business. I wanted to have a play with something a bit bigger, I pressed Assign /48 and it was ready to go in under a second. That's how it *should* work, or at least, in my opinion. Also note that you should stop thinking of today, think about what might be possible in 10, 20, 30, 40, 50 years... I'm not thinking of today, I'm thinking about the people who use these services. They don't know about networking, they don't know about security apart from install this virus checker. Most of them will laboriously transfer files from system to system using a USB drive (or floppy disk!) even though there's a big flashing icon on their desktop saying put files here and they'll magically appear on your other machine. These people don't know and don't *care* about networks. They care about the service they get. That isn't going to change in 50 years. If you genuinely think that regular residential users need multiple subnets to create a zoned config... You're wrong. It *will* piss them off, even if transparent. It's not just because of the speed (which as you say, will improve over time) it's because suddenly their wired-in Xbox in front of the TV just won't talk to the wireless Xbox their mate just brought round to have a play with. If you say that's down to education, you've entirely missed the point. The /48 for end-users might indeed be a bit on the much side, but a /56 is IMHO perfect fit for any home-site. The huge advantage of just giving out /48s though is that you don't have to care about if the connection is terminated at a home or a big corporation, as they say with shirts: one size fits all, simply as it is way too big. Completely agree. M
Re: Addressing plan exercise for our IPv6 course
Matthew, On Jul 30, 2010, at 9:27 AM, Matthew Walster wrote: On 29 July 2010 18:08, Leo Vegoda leo.veg...@icann.org wrote: There's a good chance that in the long run multi-subnet home networks will become the norm. Why would a home user need multiple subnets? Even today, people are deploying multiple subnets in their homes. For example, Apple's Airport allows you to trivially set up a guest network that uses a different prefix (192.168.0.0/24) and different SSID than your normal network (10.0.1.0/24). Are they really likely to have CPE capable of routing between subnets at 21st Century LAN speeds? Sure. Given time and Moore's law, I figure that's pretty much guaranteed. Isn't that needlessly complicating the home environment? It's really a question of time horizons. If you buy into a future world of sensornets and massive home automation, rooms in houses would have tens or hundreds of devices, all individually addressable. And that's ignoring devices hung off your body attached via a personal area network. In such an environment, I can easily imagine multiple subnets. Of course, not everyone buys into these ideas (and they're certainly not going to happen tomorrow), however I believe one of the rationales behind /48s is why architect in impediments if you don't have to?. It just seems *wasteful* to me. It is (mindboggling so), in the sense of address utilization. However, there are a lot of /48s in IPv6 (if you multiply the current IPv4 address consumption rate by 1000, the 1/8th of the IPv6 address space currently used for global unicast allocations would last about 120 years), so people are suggesting we optimize for flexibility. As various people have noted, innovation is greatly facilitated when you have plentiful resources (mechanical power: industrial revolution, cpu power: GUIs, bandwidth: on-demand entertainment, etc). I gather the theory is that if you remove the need to be efficient with addresses, you'll see new innovations in the use of the network. /32 is a lot of space, if most customers are only going to have a few machines on one subnet, why not just give them a /64 and have an easy way to just click on a button on your customer portal or similar to assign a /48 and get it routed to them. Unless you allocate the /64 out of the /48 you'd assign to them (in which case, why not simply assign the /48), it would force the customer to renumber. Perhaps not that big a deal, but it seems like work for little benefit. Regards, -drc
Re: Addressing plan exercise for our IPv6 course
On 30 July 2010 09:20, David Conrad d...@virtualized.org wrote: Even today, people are deploying multiple subnets in their homes. For example, Apple's Airport allows you to trivially set up a guest network that uses a different prefix (192.168.0.0/24) and different SSID than your normal network (10.0.1.0/24). Clearly, you think you're in the right and that you're making a valid and salient point. I see the above as unreasonable rationale. The very definition of trivial I would contend here - I honestly don't know a single resi user who has even logged into their modem/router. They're shipped with the username/password already entered by many ISPs these days, so they don't even have to set it up, they just plug it an and use the internet. There's no point in arguing this further. As you rightly say, there's plenty of IPv6 space, I don't dispute the /48 point. I'm saying that there is no need for a /63 let alone a /48. No, I'm not saying /63 is a sensible allocation policy. I've yet to be convinced of any need for more than one subnet in the vast majority of residential internet cases. sensornets or otherwise (a concept invented in the early 20th Century and still not present outside of science fiction and commerce). M
Re: Addressing plan exercise for our IPv6 course
On Jul 30, 2010, at 12:27 AM, Matthew Walster wrote: On 29 July 2010 18:08, Leo Vegoda leo.veg...@icann.org wrote: There's a good chance that in the long run multi-subnet home networks will become the norm. With all due respect, I can't see it. Why would a home user need multiple subnets? Are they really likely to have CPE capable of routing between subnets at 21st Century LAN speeds? Isn't that needlessly complicating the home environment? 1. Because eventually, home environments will become cognizant of the fact that they need more than one security profile for more than one usage. Because the number of devices present in home networks today is a very tiny fraction of the likely number in just a few years as new applications are developed to take advantage of the restoration of the end-to-end model of the internet. Because the devices in homes today represent a small fraction of the diversity that is likely within the next 10 years. 2. Yes, they are already available. A moderate PC with 4 Gig-E ports can actually route all four of them at near wire speed. For 10/100Mbps, you can get full featured CPE like the SRX-100 for around $500. That's the upper end of the residential CPE price range, but, it's a small fraction of the cost of that functionality just 2 years ago. 3. Not at all. In fact, one could argue that limited address space, NAT, uPNP, and a number of the things home users live with today complicate the home environment much more than a relatively simple router with DHCP-PD and some basic default security policies for such subnets as: Home sensor network and/or appliances Kids net (nanny software?) Home entertainment systems Guest wireless General purpose network Additionally, when it comes to address size, Andy Davidson et al make a good point - you request what you expect to assign, and due to the massive availability of the IPv6 address space, you generally get it assigned within a few days. It just seems *wasteful* to me. /32 is a lot of space, if most customers are only going to have a few machines on one subnet, why not just give them a /64 and have an easy way to just click on a button on your customer portal or similar to assign a /48 and get it routed to them. Why go to all that extra effort instead of just giving them the /48 to begin with? What is the gain to the preservation of integers? How's this sound... Try IPv6 as designed with liberal address assignments in favor of good aggregation for 2000::/3. If we run out of that, I'll support any reasonable proposal to be conservative with the other 7/8ths of the address space if I'm still alive when we get there. Owen
Re: Addressing plan exercise for our IPv6 course
On Jul 30, 2010, at 1:13 AM, Matthew Walster wrote: On 30 July 2010 08:32, Jeroen Massar jer...@unfix.org wrote: On 2010-07-30 09:27, Matthew Walster wrote: On 29 July 2010 18:08, Leo Vegoda leo.veg...@icann.org wrote: There's a good chance that in the long run multi-subnet home networks will become the norm. With all due respect, I can't see it. Why would a home user need multiple subnets? * Wireless * Wired * DMZ Those three I see a lot at various people's places. I have *never* seen those three security zones separated outside of a business or the house of a nerd who runs his own Linux distro (Smoothwall etc). Furthermore, you're then pushing all that traffic into a $30 router which almost guaranteed will be underpowered. If you'd like to come by my house, we can arrange that. I don't run linux on anything except one server. It doesn't do any routing. The routers that provide security boundaries are: 1. Juniper SRX-100 2. Apple Airport Extreme Look at it this way: When I signed up at tunnelbroker.net, I received a /64. I was happy, and I went about my business. I wanted to have a play with something a bit bigger, I pressed Assign /48 and it was ready to go in under a second. That's how it *should* work, or at least, in my opinion. That's certainly one way to do it. However, I'm not sure it's how we would do it if we were starting today knowing what we know now. It does add a certain amount of complexity to our address planning and to our systems to make it work that way. IMHO, that complexity is unnecessary. Also note that you should stop thinking of today, think about what might be possible in 10, 20, 30, 40, 50 years... I'm not thinking of today, I'm thinking about the people who use these services. They don't know about networking, they don't know about security apart from install this virus checker. Most of them will laboriously transfer files from system to system using a USB drive (or floppy disk!) even though there's a big flashing icon on their desktop saying put files here and they'll magically appear on your other machine. These people don't know and don't *care* about networks. They care about the service they get. That isn't going to change in 50 years. First, your assumption that their knowledge level remains constant is absurd, so, in that statement you are thinking only of today. 10 years ago, most of those users wouldn't know what a web site was. Most of the do today. Just 10 years ago, most of them didn't know what email was. Most of them use email on a daily basis today. Second, with DHCP-PD and likely future CPE products, they will be able to simply connect pre-defined security zones to the right ports on the CPE based on the port labels. There will likely be a reasonable default security policy pre-installed for each zone. Even my parents could handle plugging things like TiVo, the stereo, etc. into ports labeled Home Entertainment while plugging the Kids computers into Nanny ports and their own computers into General Access ports. It's not significantly harder than the current need to get the LAN and WAN ports right on today's CPE. If you genuinely think that regular residential users need multiple subnets to create a zoned config... You're wrong. It *will* piss them off, even if transparent. It's not just because of the speed (which as you say, will improve over time) it's because suddenly their wired-in Xbox in front of the TV just won't talk to the wireless Xbox their mate just brought round to have a play with. If you say that's down to education, you've entirely missed the point. Why wouldn't they be able to talk to each other? You make assumptions about the future implementations of CPE there that I don't think are entirely accurate. I don't even see a reason to expect that wireless devices wouldn't be able to register for an appropriate security zone by device type in some implementations. Alternatively, the wired Xbox may need to initiate the connection to the wireless, or, vice-versa depending on implementation, but, I would expect CPE vendors to be able to solve that problem in the future. Owen
Re: Addressing plan exercise for our IPv6 course
Hi, * Matthew Walster On 30 July 2010 09:20, David Conradd...@virtualized.org wrote: Even today, people are deploying multiple subnets in their homes. For example, Apple's Airport allows you to trivially set up a guest network that uses a different prefix (192.168.0.0/24) and different SSID than your normal network (10.0.1.0/24). Clearly, you think you're in the right and that you're making a valid and salient point. I see the above as unreasonable rationale. The very definition of trivial I would contend here - I honestly don't know a single resi user who has even logged into their modem/router. They're shipped with the username/password already entered by many ISPs these days, so they don't even have to set it up, they just plug it an and use the internet. I can order VOIP and IP-TV services from the broadband provider I use at home. This is realised by using a separate subnet per service, so with VOIP+IPTV+Internet I'm already using three distinct subnets. I don't have to configure anything - that's all handled by my ISP. I just have to connect the IP telephone and IPTV tuner to the correct port on the CPE and I'm ready to go. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
Re: Addressing plan exercise for our IPv6 course
On 30 July 2010 09:53, Owen DeLong o...@delong.com wrote: 2. Yes, they are already available. A moderate PC with 4 Gig-E ports can actually route all four of them at near wire speed. For 10/100Mbps, you can get full featured CPE like the SRX-100 for around $500. That's the upper end of the residential CPE price range, but, it's a small fraction of the cost of that functionality just 2 years ago. A moderate PC is not a typical CPE. An SRX-100 is not a typical CPE. A Draytek DSL modem/router is not a typical CPE. Your typical CPE is, and always will be, a simple device. It will (and should) contain no user configuration that is required for operation. If it does, it's too complicated for the average user. Home sensor network and/or appliances If it's really necessary to put these on a separate network, I highly doubt anyone but the true gadget geek will bother. Kids net (nanny software?) Should be sorted at the PC-level, not the network level. If it really is going to be a network service, it should be off the home network and a managed service by an ISP somewhere. Home entertainment systems Really? A separate network just for an HTPC? Guest wireless Wireless is polluted enough. Supposing everything's fixed in the future and there is near-unlimited wireless spectrum, your average user is just going to give the encryption key to the router to the guest. Network management is not on the radar for 99.9% of resi users. Seriously, this is getting silly. I'm not even going to respond any more - if you genuinely think users care about network management, you're wrong. They treat it as a black box, and that isn't going to change for a long, long, long time. M
Re: Addressing plan exercise for our IPv6 course
On Fri, 30 Jul 2010 11:11:04 BST, Matthew Walster said: Seriously, this is getting silly. I'm not even going to respond any more - if you genuinely think users care about network management, you're wrong. They treat it as a black box, and that isn't going to change for a long, long, long time. The point you're missing is that users may not care about network management *directly* - but they may care very much about the *features* that the network-ready appliance they bought at Best Buy provides them using multiple subnets under the hood. If the box says provides separate 'Guest' wireless access, that can be a selling point even if the user doesn't know it happens because the unit uses separate subnets for the home and guest addresses. End users are already used to a world where they plug in some hardware, run a program off the CD, have it ask a few questions about how you want to use the device, click the 'Do It!' button, and it all works. If networking is any different experience *for the end user*, we've as an industry screwed up big time. pgppXQSd3SHuA.pgp Description: PGP signature
Re: Addressing plan exercise for our IPv6 course
In a message written on Fri, Jul 30, 2010 at 09:13:54AM +0100, Matthew Walster wrote: On 30 July 2010 08:32, Jeroen Massar jer...@unfix.org wrote: On 2010-07-30 09:27, Matthew Walster wrote: On 29 July 2010 18:08, Leo Vegoda leo.veg...@icann.org wrote: With all due respect, I can't see it. Why would a home user need multiple subnets? * Wireless * Wired * DMZ Those three I see a lot at various people's places. I have *never* seen those three security zones separated outside of a business or the house of a nerd who runs his own Linux distro (Smoothwall etc). Furthermore, you're then pushing all that traffic into a $30 router which almost guaranteed will be underpowered. I know of at least one nationwide DSL provider that ships (with higher end products) a WiFi router with a single checkbox for guest network, which provides a captive portal style guest WiFi network for folks who visit your house. The same box has had for years a DMZ function for your gaming console/machine. The guest network is a separate subnet. The DMZ today is not, it's the wierd IPv4 pass-through thing many NAT boxes do to make weird games work. Still, it's all in a box thats given away for free by an ISP to a new signup; and with IPv6 having more addresses I see no reason each might not be its own subnet in 5-10 more years when IPv6 has taken hold. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpWwj31r4ty2.pgp Description: PGP signature
Re: Addressing plan exercise for our IPv6 course
Matthew Walster wrote: On 29 July 2010 18:08, Leo Vegoda leo.veg...@icann.org wrote: There's a good chance that in the long run multi-subnet home networks will become the norm. With all due respect, I can't see it. Why would a home user need multiple subnets? Are they really likely to have CPE capable of routing between subnets at 21st Century LAN speeds? Isn't that needlessly complicating the home environment? I strongly urge all my competitors to approach IPv6 with this philosophy. In other words, in the long run it will push up your labor costs (for admins, for customer support), and push down your customer satisfaction because you were needlessly worried about the scarcity of a plentiful resource and didn't think ahead to new technologies, new ideas, and hampered your network with an allocation scheme that didn't expand gracefully to acomodate new uses. Look at it this way - most (ISPs, businesses, consumers, appliance vendors) are going to allocate according to the recommendations or be using an allocation according to the recommendations. Why are you even *considering* using a different allocation scheme? What do *you* gain? All I see are headaches from doing it differently. When you hire you will need to retrain admins who are accustomed to the recommended system. When you get new customers, you will have to retrain them to use your non-standard system. When they try to use appliances that are pre-configured to use the recommended system, their appliances won't work right or will need special configuration. Etc. If - IF the recommendations are not conservative enough (which is considered to be a very remote possibility), then we can change the recommendations when we put the next 1/8 of the IPv6 IPs into service. But consider the possible use case where we actually start to run out of IPs in this first 1/8 segment of the IPv6 space. It's not going to happen by IP usage from current services. It's going to happen by IP consumption from new, as yet unimagined, services. And if we have all these new services (devices, appliances) that require IP addresses then it means we WILL need to do subnetting at end user premises. jc
Re: Addressing plan exercise for our IPv6 course
On Jul 30, 2010, at 3:11 AM, Matthew Walster wrote: On 30 July 2010 09:53, Owen DeLong o...@delong.com wrote: 2. Yes, they are already available. A moderate PC with 4 Gig-E ports can actually route all four of them at near wire speed. For 10/100Mbps, you can get full featured CPE like the SRX-100 for around $500. That's the upper end of the residential CPE price range, but, it's a small fraction of the cost of that functionality just 2 years ago. A moderate PC is not a typical CPE. An SRX-100 is not a typical CPE. A Draytek DSL modem/router is not a typical CPE. Your typical CPE is, and always will be, a simple device. It will (and should) contain no user configuration that is required for operation. If it does, it's too complicated for the average user. An Apple Airport Extreme is relatively typical CEP and meets your criteria. I have one forwarding packets at 800Mbps throughput between the LAN and WAN ports. On a gig-E network, that seems close enough to LAN speed. A lot of your simple devices are actually PCs running linux under the hood, so, in fact, a moderate PC today is likely to be tomorrows toaster. Home sensor network and/or appliances If it's really necessary to put these on a separate network, I highly doubt anyone but the true gadget geek will bother. Then you will be surprised. Kids net (nanny software?) Should be sorted at the PC-level, not the network level. If it really is going to be a network service, it should be off the home network and a managed service by an ISP somewhere. We can agree to disagree about this. Home entertainment systems Really? A separate network just for an HTPC? No. A separate network for: Playstation/Wii/etc. Amplifier (See Yamaha RXV-3900 for example) HTPCs Apple TVs TiVOs Mac Minis operating in that role (the new one rocks for that) DVD players Blue Ray players Monitors/Televisions etc. Just because the only home entertainment thing you have today with an ethernet port is an HTPC (which, btw, is way geekier than half the CPE you argued against at this point) does not mean that everyone will be subject to such limitations. Guest wireless Wireless is polluted enough. Supposing everything's fixed in the future and there is near-unlimited wireless spectrum, your average user is just going to give the encryption key to the router to the guest. Network management is not on the radar for 99.9% of resi users. Again, we can agree to disagree. Lots of people I know, including non-technical ones have turned on the guest wireless capability with their Airport Extremes. Seriously, this is getting silly. I'm not even going to respond any more - if you genuinely think users care about network management, you're wrong. They treat it as a black box, and that isn't going to change for a long, long, long time. I don't think they care. I think it will be automated for them in the future. The argument wasn't about whether users care or not. The argument was about whether households would eventually come to a point where the norm was to require more than one subnet per household. You remain in denial, and, that's fine, but, I think enough use cases have been shown and enough people have told you that they already have multiple subnets in IPv4 as a result of default service they receive from their provider to prove that multiple subnets in the average home will be commonplace in the future. Owen
Re: Addressing plan exercise for our IPv6 course
On Tue, 27 Jul 2010 12:34:40 -0700 Owen DeLong o...@delong.com wrote: On Jul 27, 2010, at 12:05 PM, Akyol, Bora A wrote: Please see comments inline. On 7/22/10 10:13 PM, Owen DeLong o...@delong.com wrote: In all reality: 1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. Of course, the problem is that there are millions of customers that believe that NAT == security. This needs to change. 2. In the places where NAT works, it does so at a terrible cost. It breaks a number of things, and, applications like Skype are incredibly more complex pieces of code in order to solve NAT traversal. I look at this as water under the bridge. Yep, it was complicated code and now it works. I can run bittorrent just fine beyond an Apple wireless router and I did nothing to make that work. Micro-torrent just communicates with the router to make the port available. It's only water under the bridge for IPv4. If we start putting NAT66 into play, it will be the same thing all over again. Additionally, it's only water under the bridge for existing applications. Each new application seems to go through the same exercise because for some reason, no two NAT gateways seem to have exactly the same traversal requirements and no two applications seem to implement the same set of traversal code. What is worse about that is that we networking people have ended up shifting the cost of fixing our problem onto the application developers and onto the application users. Because we don't provide end-to-end visibility between peers on the Internet (Internet transparency - see RFC4924), application developers have to try to develop methods of doing that themselves. As you've said, this creates additional application complexity, additional bugs, and duplicate functionality between different applications, all at the application layer. (HTTP has become the de facto substrate protocol of the Internet because firewalls permit it, and client server communication has become the de facto communications method for applications that would truly benefit from peer-to-peer communications (i.e. more scalable, more available), because client server overcomes the lack of global reachability NAT creates)) Who pays this additional application development cost? Everybody, including us networking people, because we also use applications too. We get code that is possibly more buggy because it is more complex, written by people who are usually not networking code experts. We might miss out on better user interfaces or less buggy code that's there to do what the application's purpose is, because that time was instead spent on developing network layer work arounds. It seems to me that the best place to solve problems is whether they exist or where they're caused. Those solutions usually solve the problem properly, and commonly are also the cheapest way to solve it. The network layer is where these problems exist, and that's where they should be solved. We should use IPv6 to restore Internet transparency, so that application developers don't have to do it for us - again. We'll end up with a better and simpler Internet to operate, and better and/or cheaper applications. Regards, Mark. The elimination of NAT is one of the greatest features of IPv6. Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall. I do think that people will get rid of the NAT box by and large, or, at least in IPv6, the box won't be NATing. Whether or not they NAT it, it's still better to give the customer enough addresses that they don't HAVE to NAT. Owen Of course, no disagreement there. The real challenge is going to be education of customers so that they can actually configure a firewall policy to protect their now-suddenly-addressable-on-the-Internet home network. I would love to see how SOHO vendors are going to address this. Not so much... SOHO gateways should implement stateful inspection with the same default policy a NAT box provides today... 1.Outbound packets create a state table entry. 2.Inbound packets are only forwarded if they match an existing state table entry. Pretty simple, actually. Owen
Re: Addressing plan exercise for our IPv6 course
I look at this as water under the bridge. Yep, it was complicated code and now it works. I can run bittorrent just fine beyond an Apple wireless router and I did nothing to make that work. Micro-torrent just communicates with the router to make the port available. So, the security model here is that arbitrary untrusted applications, running on an arbitrary untrusted OS, selected by people who have no understanding of computer or network security are allowed to update the security policy on the perimeter device. I can see why those secure NAT boxes have *totally* stopped the Windows botnet problem in its tracks... Of course, no disagreement there. The real challenge is going to be education of customers so that they can actually configure a firewall policy to protect their now-suddenly-addressable-on-the-Internet home network. I would love to see how SOHO vendors are going to address this. Permit any outbound Permit any inbound established Deny any inbound Achieves essentially the same functionality as a NAT device without the annoying mangling of addresses. Vendors could then continue to offer the UPnP request a hole functionality that they do today, or tweak the labels on their forward this port web GUI to say permit the port instead. For end-users who want to carry on doing exactly what they do today, the changes required for both them and their CPE vendor are trivial. For end-users who are currently frustrated by NAT, they have their real, honest-to-goodness end-to-end Internet restored. Everybody wins, apart those with a vested interest in upselling to business connectivity plans, or those who would prefer that the Internet is TV on new technology, and that end-users remain good little eyeballs, dutifully paying for their Big Business Content. Regards, Tim.
Re: Addressing plan exercise for our IPv6 course
On Sun, 25 Jul 2010 03:56:52 +1000 Karl Auer ka...@biplane.com.au wrote: On Sat, 2010-07-24 at 10:42 -0700, Owen DeLong wrote: You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason. What is the ULA brokenness? If it is address selection policy distribution, then this Internet Draft is aiming to solve that - Distributing Address Selection Policy using DHCPv6 http://tools.ietf.org/html/draft-fujisaki-6man-addr-select-opt-00.html Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
Re: Addressing plan exercise for our IPv6 course
On 23 July 2010 01:45, Karl Auer ka...@biplane.com.au wrote: Unless I've misunderstood Matthew, and he was suggesting that the /64 be the link network. That would indeed effectively give the customer a single address, unless it was being bridged rather than routed at the CPE. Not sure bridging it is such a good idea - most people will probably want their home networks to keep working even if the ISP has an outage. Sorry for the week's delay - I meant delegating a /64 using DHCPv6 PD, I had assumed the link net would be based on provider preference - /64 would obviously make the most sense for the vast majority of scenarios. In my experience, I would have though well over 99% of residential users just require one subnet, if they require additional subnets they'll ask for them, and if it's standardised, a /56 could easily be quickly assigned and added to either the DHCPv6 PD or static routed if required. That would usually be a service the customer would pay extra for. I'm purely looking at residential use here, not SOHO nor SME. M M
Re: Addressing plan exercise for our IPv6 course
On Jul 29, 2010, at 3:51 AM, Mark Smith wrote: On Sun, 25 Jul 2010 03:56:52 +1000 Karl Auer ka...@biplane.com.au wrote: On Sat, 2010-07-24 at 10:42 -0700, Owen DeLong wrote: You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason. What is the ULA brokenness? If it is address selection policy distribution, then this Internet Draft is aiming to solve that - Distributing Address Selection Policy using DHCPv6 http://tools.ietf.org/html/draft-fujisaki-6man-addr-select-opt-00.html Source address selection is one of the problems. Distribution of source address selection policy is part of that problem. Owen
Re: Addressing plan exercise for our IPv6 course
On Jul 29, 2010, at 4:08 AM, Matthew Walster wrote: On 23 July 2010 01:45, Karl Auer ka...@biplane.com.au wrote: Unless I've misunderstood Matthew, and he was suggesting that the /64 be the link network. That would indeed effectively give the customer a single address, unless it was being bridged rather than routed at the CPE. Not sure bridging it is such a good idea - most people will probably want their home networks to keep working even if the ISP has an outage. Sorry for the week's delay - I meant delegating a /64 using DHCPv6 PD, I had assumed the link net would be based on provider preference - /64 would obviously make the most sense for the vast majority of scenarios. In my experience, I would have though well over 99% of residential users just require one subnet, if they require additional subnets they'll ask for them, and if it's standardised, a /56 could easily be quickly assigned and added to either the DHCPv6 PD or static routed if required. That would usually be a service the customer would pay extra for. I'm purely looking at residential use here, not SOHO nor SME. M M Why not just give them a /48 and not worry about who needs what? Why add the cost and complexity of all these different sized assignments based on requests and such? If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. Even if it turns out this is a bad idea and we can't sustain this level of IP consumption, we still have 7/8ths of the address space available to use more conservative addressing plans. Owen
Re: Addressing plan exercise for our IPv6 course
The policies available in all the 5 RIR regions, allow you to request not the default /32, but whatever is appropriate for the size of your network even if you provide to your end-users /48. Not an issue. Regards, Jordi -Original Message- From: Matthew Walster matt...@walster.org To: Owen DeLong o...@delong.com Cc: nanog@nanog.org Date: Thu, 29 Jul 2010 16:00:40 +0100 Subject: Re: Addressing plan exercise for our IPv6 course On 29 July 2010 15:49, Owen DeLong o...@delong.com wrote: If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers. All I'm saying is, why waste the space when they're only going to need 1 subnet? If they want more than one subnet, give them a /48,/56,/60 or whatever, as requested. M ** The IPv6 Portal: http://www.ipv6tf.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.
Re: Addressing plan exercise for our IPv6 course
On 29 Jul 2010, at 8:00, Matthew Walster wrote: On 29 July 2010 15:49, Owen DeLong o...@delong.com wrote: If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers. Why would you initially request and receive a /32 if you know that you'll need far more space to assign subnets to all your customers? All I'm saying is, why waste the space when they're only going to need 1 subnet? If they want more than one subnet, give them a /48,/56,/60 or whatever, as requested. There's a good chance that you want to keep your customers for the long haul. There's a good chance that in the long run multi-subnet home networks will become the norm. Leo
Re: Addressing plan exercise for our IPv6 course
On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote: On 29 July 2010 15:49, Owen DeLong o...@delong.com wrote: If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers. If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space? 1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts. It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you. All I'm saying is, why waste the space when they're only going to need 1 subnet? If they want more than one subnet, give them a /48,/56,/60 or whatever, as requested. For at least the following reasons: 1. A single subnet may be the norm today because residential users and there vendors have been in a scarcity of addresses mentality for so long that applications to take full advantage of internet as it should be haven't been possible. That will change. 2. A single subnet may be enough for many (definitely not all and possibly not even most) today, but, certainly won't be the norm for long once IPv6 is more ubiquitous. 3. It places unnecessary limitations on the user and makes it unnecessarily more difficult to deploy additional capabilities. 4. Your increasing the workload on your own staff as your customers realize that one subnet is no longer enough and come back to you for larger assignments. 5. It's short sighted and assumes that the current IPv4 model will permanently apply to IPv6. Why waste valuable people's time to conserve nearly valueless renewable resources? Owen
Re: Addressing plan exercise for our IPv6 course
Why waste valuable people's time to conserve nearly valueless renewable resources? See my earlier comments on upsell and control. While you have some ISPs starting from the mentality that gives us accepting incoming connections is a chargeable extra, they're also going to be convinced that there's a revenue opportunity in segmenting customers who want N of some resource from those who want 2N, 4N, ... That the resource in question is, for all practical purposes, both free and infinite (cue someone with a 'tragedy of the commons' analysis) does not factor - if they want more, they must pay more! Regards, Tim.
Re: Addressing plan exercise for our IPv6 course
On 2010-07-29 19:32, Tim Franklin wrote: Why waste valuable people's time to conserve nearly valueless renewable resources? See my earlier comments on upsell and control. While you have some ISPs starting from the mentality that gives us accepting incoming connections is a chargeable extra, they're also going to be convinced that there's a revenue opportunity in segmenting customers who want N of some resource from those who want 2N, 4N, ... That the resource in question is, for all practical purposes, both free and infinite (cue someone with a 'tragedy of the commons' analysis) does not factor - if they want more, they must pay more! Ever thought about this tiny thing called BANDWIDTH USAGE? It is what ISPs are charged by their transit providers / peers, thus why not do that do users? Oh yeah.. something with overselling capacity but that is not a big issue either, you can probably figure out what the average is, the lowest and the highest and come up with a good competitive pricing strategy from there. And there is another advantage there: the people who use a lot of bandwidth are actually paying for it then, thus you don't have to ratelimit these folks, as heck, they pay for it! Need more capacity in an area, well, no problem they paid for it already, thus do calculate that into your pricing too of course ;) Thus don't charge folks for the amount of IP addresses they have, that is not what you get charged for by your transit/peers either. Greets, Jeroen
Re: Addressing plan exercise for our IPv6 course
On 29 Jul 2010 12:19, Owen DeLong wrote: On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote: On 29 July 2010 15:49, Owen DeLong o...@delong.com wrote: If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers. If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space? 1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts. ... and paying sixteen times as much in assignment and maintenance fees. See the problem there? It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you. Yes. However, I don't think the RIRs are as willing to give out address space for _potential_ customers, e.g. if a telco or cableco wanted to assign a single block to each CO/head end to account for future growth. OTOH, you can get address space based on a /48 per actual customer, then actually assign a /64 per potential customer and have enough for massive growth. Why waste valuable people's time to conserve nearly valueless renewable resources? By creating artificial scarcity, one can increase profits per unit of nearly-valueless, renewable resources. See also: De Beers and the demonizing of artificial diamonds. 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Addressing plan exercise for our IPv6 course
On Jul 29, 2010, at 10:32 AM, Tim Franklin wrote: Why waste valuable people's time to conserve nearly valueless renewable resources? See my earlier comments on upsell and control. While you have some ISPs starting from the mentality that gives us accepting incoming connections is a chargeable extra, they're also going to be convinced that there's a revenue opportunity in segmenting customers who want N of some resource from those who want 2N, 4N, ... That the resource in question is, for all practical purposes, both free and infinite (cue someone with a 'tragedy of the commons' analysis) does not factor - if they want more, they must pay more! If you want to build a business based on upsell and control by trying to convince users that they should give you extra money to provision a resource that costs you virtually nothing, then more power to you. However, I think this will, in the end, be as popular as american restaurants that charge for ice water. Consumers are moderately ignorant, but, not completely stupid. Address scarcity has allowed this model to succeed to some extent in IPv4, largely due to lack of alternatives and the fact that all consumer ISPs operate on this model. In IPv6, there is no scarcity, some ISPs will offer alternatives, and, consumers will rapidly learn about this disparity and I'm guessing that a model that says: Network Numbers Our CostYou Pay 1 $0.1$0.00 2 $0.2$1.00 4 $0.4$2.00 etc. Is probably going to be at a significant competitive disadvantage vs. a model that says You can have whatever address space you can justify. We'll start you with 65,536 networks which we believe is way more than enough for virtually any residential user. We don't charge you anything for address space. We think charging people for integers is illogical. However, if you think there is a competitive or revenue advantage, more power to you. Owen
Re: Addressing plan exercise for our IPv6 course
On Jul 29, 2010, at 10:41 AM, Stephen Sprunk wrote: On 29 Jul 2010 12:19, Owen DeLong wrote: On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote: On 29 July 2010 15:49, Owen DeLong o...@delong.com wrote: If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers. If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space? 1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts. ... and paying sixteen times as much in assignment and maintenance fees. See the problem there? If you have millions of IPv4 customers, then, you're already paying that for your IPv4 space. Since you pay the greater of your IPv4 or IPv6 utilization, I think the larger you are, the less likely it is that you will be paying more for IPv6 than IPv4, even if you give your customers all /48s of IPv6 instead of /32s of IPv4. It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you. Yes. However, I don't think the RIRs are as willing to give out address space for _potential_ customers, e.g. if a telco or cableco wanted to assign a single block to each CO/head end to account for future growth. OTOH, you can get address space based on a /48 per actual customer, then actually assign a /64 per potential customer and have enough for massive growth. I believe you can actually do this to a pretty large extent within policy. The tricky part comes when you need more space and haven't met the HD Ratio requirements across the board. I agree there's room for improvement in the policy here. Why waste valuable people's time to conserve nearly valueless renewable resources? By creating artificial scarcity, one can increase profits per unit of nearly-valueless, renewable resources. See also: De Beers and the demonizing of artificial diamonds. There are lots of opportunities to exploit people. I was limiting my comments to the layer 0-7 issues for the most part. I think optimizing the exploitation of customers is probably out of charter for this list. Owen
Re: Addressing plan exercise for our IPv6 course
Owen DeLong wrote: If you want to build a business based on upsell and control by trying to convince users that they should give you extra money to provision a resource that costs you virtually nothing, then more power to you. However, I think this will, in the end, be as popular as american restaurants that charge for ice water. Sorry, I need to dial back on the cynicism / sarcasm a bit, it doesn't travel so well through the tubes - that's a rant about the attitudes I encounter, not my views! I *utterly* agree with you that trying to micro-manage the allocation size on a per-customer basis for high-volume residential / SOHO connections is a complete waste of resources. I equally believe that a number of ISPs operating in that market are going to try, not just one or two crazy outliers, based on the attitudes I touched on in my rant (which, again, *aren't* mine). Coming from an IPv4 business model that goes: Extra for a static IP Extra for more than one IP Extra for a contract that doesn't forbid incoming connections Extra for non-generic reverse DNS Extra for not blocking IPSec Extra for... I fully expect some ISPs to extend that into whatever parts of IPv6 they can measure and charge for. Is probably going to be at a significant competitive disadvantage vs. a model that says You can have whatever address space you can justify. We'll start you with 65,536 networks which we believe is way more than enough for virtually any residential user. We don't charge you anything for address space. We think charging people for integers is illogical. I really hope you're right. I'd love to see the Internet opened back up again, for everyone. Regards, Tim.
Re: Addressing plan exercise for our IPv6 course
Jeroen Massar wrote: See my earlier comments on upsell and control. While you have some ISPs starting from the mentality that gives us accepting incoming connections is a chargeable extra, they're also going to be convinced that there's a revenue opportunity in segmenting customers who want N of some resource from those who want 2N, 4N, ... That the resource in question is, for all practical purposes, both free and infinite (cue someone with a 'tragedy of the commons' analysis) does not factor - if they want more, they must pay more! Ever thought about this tiny thing called BANDWIDTH USAGE? [snip] Thus don't charge folks for the amount of IP addresses they have, that is not what you get charged for by your transit/peers either. Apologies - again, my sarcasm doesn't travel well. I don't think selling IP addresses is a good idea - it's an idea I hit against and get annoyed by in the IPv4 world that I expect at least some ISPs to try and perpetuate into the IPv6 world. Regards, Tim.
Re: Addressing plan exercise for our IPv6 course
Please see comments inline. On 7/22/10 10:13 PM, Owen DeLong o...@delong.com wrote: In all reality: 1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. Of course, the problem is that there are millions of customers that believe that NAT == security. This needs to change. 2. In the places where NAT works, it does so at a terrible cost. It breaks a number of things, and, applications like Skype are incredibly more complex pieces of code in order to solve NAT traversal. I look at this as water under the bridge. Yep, it was complicated code and now it works. I can run bittorrent just fine beyond an Apple wireless router and I did nothing to make that work. Micro-torrent just communicates with the router to make the port available. The elimination of NAT is one of the greatest features of IPv6. Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall. I do think that people will get rid of the NAT box by and large, or, at least in IPv6, the box won't be NATing. Whether or not they NAT it, it's still better to give the customer enough addresses that they don't HAVE to NAT. Owen Of course, no disagreement there. The real challenge is going to be education of customers so that they can actually configure a firewall policy to protect their now-suddenly-addressable-on-the-Internet home network. I would love to see how SOHO vendors are going to address this.
Re: Addressing plan exercise for our IPv6 course
On Jul 27, 2010, at 12:05 PM, Akyol, Bora A wrote: Please see comments inline. On 7/22/10 10:13 PM, Owen DeLong o...@delong.com wrote: In all reality: 1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. Of course, the problem is that there are millions of customers that believe that NAT == security. This needs to change. 2. In the places where NAT works, it does so at a terrible cost. It breaks a number of things, and, applications like Skype are incredibly more complex pieces of code in order to solve NAT traversal. I look at this as water under the bridge. Yep, it was complicated code and now it works. I can run bittorrent just fine beyond an Apple wireless router and I did nothing to make that work. Micro-torrent just communicates with the router to make the port available. It's only water under the bridge for IPv4. If we start putting NAT66 into play, it will be the same thing all over again. Additionally, it's only water under the bridge for existing applications. Each new application seems to go through the same exercise because for some reason, no two NAT gateways seem to have exactly the same traversal requirements and no two applications seem to implement the same set of traversal code. The elimination of NAT is one of the greatest features of IPv6. Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall. I do think that people will get rid of the NAT box by and large, or, at least in IPv6, the box won't be NATing. Whether or not they NAT it, it's still better to give the customer enough addresses that they don't HAVE to NAT. Owen Of course, no disagreement there. The real challenge is going to be education of customers so that they can actually configure a firewall policy to protect their now-suddenly-addressable-on-the-Internet home network. I would love to see how SOHO vendors are going to address this. Not so much... SOHO gateways should implement stateful inspection with the same default policy a NAT box provides today... 1. Outbound packets create a state table entry. 2. Inbound packets are only forwarded if they match an existing state table entry. Pretty simple, actually. Owen
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 10:35 PM, Doug Barton wrote: On Sat, 24 Jul 2010, Brandon Butterworth wrote: Eventually ARIN (or someone else will do it for them) may create a site ... Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/ Q.E.D. The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. So, back when ULA was first proposed, some of us said (sometimes privately) that there are only 2 rational options: 1. Do it; with a persistent, guaranteed unique, global registry. 2. Don't do it. Option 2 was a non-starter since there was too much critical mass. The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it? So given the overwhelming force pulling at this thing from both directions, you end up somewhere in the middle where no one wants to be. And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins. Except in the case of ULA, hitting the jackpot is actually losing. Owen
Re: Addressing plan exercise for our IPv6 course
On Jul 25, 2010, at 8:10 AM, Owen DeLong wrote: The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it? None of the sides of IANA pay for anything. There is no binding between what parties pay and what the ICANN staff who perform the IANA function do. In fact, those staff do not have any knowledge of whether any organization has paid anything (other than what they might hear incidentally). The (zero dollar) IANA functions contract has 3 major functions, of which allocating blocks of addresses to the RIRs (and at the direction of the IETF) is one. Failure to perform that function would be interpreted as breach of contract, regardless of whether the RIRs pay anything to ICANN or not. Regards, -drc
Re: Addressing plan exercise for our IPv6 course
Doug Barton wrote: having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) whois. what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2. And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins. This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad.
Re: Addressing plan exercise for our IPv6 course
David Conrad wrote: On Jul 24, 2010, at 7:52 PM, Brandon Butterworth wrote: Indeed, best not listen to vendors As it is best not to listen to doctors that tell you if you continue chain smoking or eating 5000 calories a day, you'll likely regret it. Bad analogy. A doctor tells you these things for your well being. In fact, the doctor's advice, while meeting the goals of his oath, conflict with his business needs (your regret of not following his advice will be lots more doctor bills). Vendors care about their bottom line. Some will happily lie for a sale. Most will highlight their strong points and gloss over their weaknesses. More care goes to those who pay the most. An engineer is closer to a doctor. The engineer cares about the health of their network and how well it performs, even if it means begging for more expensive gear from management. The engineer is less concerned with the bottom line and more concerned with doing things right (especially if it means less work, less headaches, and less problems for the same amount of pay). I rant OT too much. :) Jack
Re: Addressing plan exercise for our IPv6 course
On Jul 25, 2010, at 8:42 AM, Jack Bates wrote: Doug Barton wrote: having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) whois. http://whois.iana.org what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). With the exception of a routing registry (which I wasn't aware was an address allocation requirement), these services are provided by ICANN as part of the IANA functions contract. Out of curiosity, why do you think providing whois, POC management/validity, and even a routing registry requires a large staff? I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2. As you note, ICANN already provides something like this as part of the protocol parameter function of the IANA functions contract for private enterprise numbers (OIDs). This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. I remember arguments like that about why Token Ring was going to win over Ethernet :-) Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad. Indeed. I have stories... Regards, -drc (who no longer works for ICANN)
Re: Addressing plan exercise for our IPv6 course
On Jul 25, 2010, at 8:56 AM, Jack Bates wrote: David Conrad wrote: On Jul 24, 2010, at 7:52 PM, Brandon Butterworth wrote: Indeed, best not listen to vendors As it is best not to listen to doctors that tell you if you continue chain smoking or eating 5000 calories a day, you'll likely regret it. Bad analogy. A doctor tells you these things for your well being. In fact, the doctor's advice, while meeting the goals of his oath, conflict with his business needs (your regret of not following his advice will be lots more doctor bills). I'll stick by the analogy. There are engineers inside routing vendors who have been quite loud in saying that we can't keep adding more routes to the routing system and expect costs to remain linear. Those same engineers will also tell you that the companies they work for will be happy to build what the customer wants, even if it will cost the customer 3 arms and 4 legs. Vendors care about their bottom line. Some will happily lie for a sale. Most will highlight their strong points and gloss over their weaknesses. More care goes to those who pay the most. Which, according to numerous studies, also describes the health care system in the US, but that's not an appropriate topic for this list. An engineer is closer to a doctor. The engineer cares about the health of their network and how well it performs, even if it means begging for more expensive gear from management. The engineer is less concerned with the bottom line and more concerned with doing things right (especially if it means less work, less headaches, and less problems for the same amount of pay). All vendors that expect to remain in business for any length of time have engineering staff that behave as you describe. For just one example, look at the folks behind LISP (not the language). Or the active participants in the IRTF RRG working group. Regards, -drc
Re: Addressing plan exercise for our IPv6 course
whois. what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). routing registry not necessarily needed from address registry. and i am sure even the icann/iana could do the combined rir work for half the combined rir budgets, especially with the insane budgets of the more inflated rirs. randy
Re: Addressing plan exercise for our IPv6 course
On Sun, 25 Jul 2010, Jack Bates wrote: Doug Barton wrote: having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) whois. what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2. You misunderstood. The correct answer to ULA was Don't do it (or, more correctly, do IPv6 PI instead). And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins. This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad. Now that sounds like something it would have been easy for IANA to do. See, you have tension on this topic even in your own line of reasoning. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010, Owen DeLong wrote: On Jul 24, 2010, at 10:35 PM, Doug Barton wrote: On Sat, 24 Jul 2010, Brandon Butterworth wrote: Eventually ARIN (or someone else will do it for them) may create a site ... Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/ Q.E.D. The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. So, back when ULA was first proposed, some of us said (sometimes privately) that there are only 2 rational options: 1. Do it; with a persistent, guaranteed unique, global registry. 2. Don't do it. Option 2 was a non-starter since there was too much critical mass. The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it? David already answered more eloquently than I could, so I'll simply add that what he said applied when I was there as well. The IANA is, and always has been a cost center. You don't want to live in an IANA fee-for-service world. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
Re: Addressing plan exercise for our IPv6 course
On Sun, 2010-07-25 at 01:42 -0500, Jack Bates wrote: This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad. No matter what the odds? A good business person weighs the odds carefully and takes calculated risks. The chance of a conflict if you choose a random ULA prefix is lower than just about any other risk an enterprise would even bother considering. There is much more chance of an employee going postal, of a massive lightning strike, of a disastrous fire or flood, of a two-week power outage, than there is of a ULA prefix conflict, and all those things will cause far more real damage than a ULA prefix conflict. The risk of a ULA prefix conflict is for *all practical purposes* zero. It is a far lower risk than almost anything else you probably have contingency plans for. Not only that, but *even if the event comes to pass*, it is merely an inconvenience. Not only that but it is an inconvenience that can be detected in plenty of time and planned for and mitigated with relative ease. There may be good arguments against ULA, but the risk of prefix conflict is not one of them. Please let's stop behaving as if a ULA conflict is some kind of accident waiting to happen. If an expert stood up in court and said the chances that this fingerprint is the defendant's are a million to one, and the prosecutor then said Aha! So you admit it's *possible*! we would rightly scorn the prosecutor for being an innumerate nincompoop. Yet here we are paying serious heed to the idea that a ULA prefix conflict is a real business risk. Sheesh, if we professionals can't get a grip on what these tiny, tiny probabilities really *mean* then how is anyone else going to? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Addressing plan exercise for our IPv6 course
On (2010-07-25 17:32 +1000), Karl Auer wrote: The risk of a ULA prefix conflict is for *all practical purposes* zero. http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^100+((2^40)-100)!)+ It wouldn't puke nice graph with 'n', it did try, but never finished. So if there are million assigned ULA's there is 36.5% chance of collision, if formula is right. If operator fscks-up their residential DSL product, lets say the assign all the /128 user could want, but from single shared /64 subnet, not routing dedicated /48 to each customer. Users who need to route, will want solution and some vendor will step in, providing router which will auto-assign ULA + NAT66, will that vendor sell million copies of said CPE? But I don't think it is interesting to discuss the random chance of collisions, as human factor will guarantee collisions, many people will assign fd::/48 to get short and memorable addresses in their network. (You've made your bed, now lie in it.) If your IT staff includes personnel who've done painful renumbering due to MA, there is good chance they'll allocate random, otherwise they'll likely opt for short and memorable network, as they did with RFC1918. Just because we get IPv6, doesn't mean people will get sudden burst of insight in design and engineering. -- ++ytti
Re: Addressing plan exercise for our IPv6 course
On Sun, 25 Jul 2010 09:01:33 +0200 David Conrad d...@virtualized.org wrote: On Jul 25, 2010, at 8:42 AM, Jack Bates wrote: Doug Barton wrote: having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) whois. http://whois.iana.org what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). With the exception of a routing registry (which I wasn't aware was an address allocation requirement), these services are provided by ICANN as part of the IANA functions contract. Out of curiosity, why do you think providing whois, POC management/validity, and even a routing registry requires a large staff? I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2. As you note, ICANN already provides something like this as part of the protocol parameter function of the IANA functions contract for private enterprise numbers (OIDs). This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. I remember arguments like that about why Token Ring was going to win over Ethernet :-) +1 +1 +1 (Was quite happy when I was able to have an 10Mpbs ethernet pulled from the floor below when my gov dept. was merged with another gov dept. and I was moved to their IT section - and they were using 4Mbps token ring) Of course being in business is a gamble in itself. They gamble on future profits occurring when they spend on product or service development, government regulation staying stable, cost bases that aren't going to dramatically change, and possibly currency values staying fairly stable (GFC type events being the ones that out bad gamblers). I doubt businesses will be all that uncomfortable with IPv6 ULA collision odds that are worse than winning the lottery. Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad. Indeed. I have stories... Regards, -drc (who no longer works for ICANN)
Re: Addressing plan exercise for our IPv6 course
On Sun, 25 Jul 2010 11:40:19 +0300 Saku Ytti s...@ytti.fi wrote: On (2010-07-25 17:32 +1000), Karl Auer wrote: The risk of a ULA prefix conflict is for *all practical purposes* zero. http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^100+((2^40)-100)!)+ It wouldn't puke nice graph with 'n', it did try, but never finished. So if there are million assigned ULA's there is 36.5% chance of collision, if formula is right. That's duplication, not collision. Collision only occurs when two ULA domains want to interconnect, and have duplicate routes they would like to exchange. Here is what the RFC says about odds - 3.2.3. Analysis of the Uniqueness of Global IDs The selection of a pseudo random Global ID is similar to the selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of [RTP]. This analysis is adapted from that document. Since Global IDs are chosen randomly (and independently), it is possible that separate networks have chosen the same Global ID. For any given network, with one or more random Global IDs, that has inter-connections to other such networks, having a total of N such IDs, the probability that two or more of these IDs will collide can be approximated using the formula: P = 1 - exp(-N**2 / 2**(L+1)) where P is the probability of collision, N is the number of interconnected Global IDs, and L is the length of the Global ID. The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 21.81*10^-12 104.54*10^-11 1004.54*10^-09 10004.54*10^-07 14.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs. If operator fscks-up their residential DSL product, lets say the assign all the /128 user could want, but from single shared /64 subnet, not routing dedicated /48 to each customer. Users who need to route, will want solution and some vendor will step in, providing router which will auto-assign ULA + NAT66, will that vendor sell million copies of said CPE? But I don't think it is interesting to discuss the random chance of collisions, as human factor will guarantee collisions, many people will assign fd::/48 to get short and memorable addresses in their network. (You've made your bed, now lie in it.) That bed was called site locals, and the prefix was fec0::/10. If two separate organisations choose to make ULAs effectively site locals, and then join their ULA domains, then they deserve the pain they'll get because they haven't followed the RFC4193 formula. At the end of the day you can't stop people doing stupid things unless you take away the variables that they can set. If people are arguing that ULA specs won't be followed correctly, then any other IPv6 spec variable may also not be set correctly by the same person. Ultimately that means that incompetent networking people are running the network. I don't think you can use that as a valid reason to dismiss ULAs, and then not use it to dismiss the whole of IPv6 *and* IPv4. If your IT staff includes personnel who've done painful renumbering due to MA, there is good chance they'll allocate random, otherwise they'll likely opt for short and memorable network, as they did with RFC1918. Just because we get IPv6, doesn't mean people will get sudden burst of insight in design and engineering. -- ++ytti
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010 22:35:07 PDT, Doug Barton said: having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) The same way that companies are making money selling people credit reports they are legally able to get for free. Sorry, but you asked. ;) pgpspckYNrpse.pgp Description: PGP signature
Re: Addressing plan exercise for our IPv6 course
On Sun, 25 Jul 2010 11:40:19 +0300, Saku Ytti said: On (2010-07-25 17:32 +1000), Karl Auer wrote: The risk of a ULA prefix conflict is for *all practical purposes* zero. http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^100+((2^40)-100)!)+ It wouldn't puke nice graph with 'n', it did try, but never finished. So if there are million assigned ULA's there is 36.5% chance of collision, if formula is right. Bzzt! Wrong, but thank you for playing. If there exists some screwed-up network design that *interconnects* 1M networks that are all *advertising* ULAs there's a 36% chance of collision. It's a subtle but important difference. You only care about a collision if (a) you and some site in Zimbabwe both chose the same ULA prefix *AND* (b) you wish to set up a private interconnect with them and talk with them *using the ULA prefix*. Very important 'and' there. On the other hand, today if you interconnect *3* private networks that use NAT you have like a 90% chance of collision. And yet, people manage to do this all the time. So ULAs give a way to make it literally a million times easier - and THOSE SAME PEOPLE WHO DO THIS WITH NAT ADDRESSES ALL THE TIME ARE WHINING ULA IS UNWORKABLE. Geez guys, give me a break. pgpRUwjVI6v4y.pgp Description: PGP signature
Re: Addressing plan exercise for our IPv6 course
On (2010-07-25 10:28 -0400), valdis.kletni...@vt.edu and Mark Smith wrote similarly: http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^100+((2^40)-100)!)+ So if there are million assigned ULA's there is 36.5% chance of collision, if formula is right. Bzzt! Wrong, but thank you for playing. Point I was trying to convey is that you should not assume ULA to be globally unique. Visibility of IP can extend past routing, for example someone could use x-forwarded-for and assume rfc4193 to be as unique as any other IPv6 address. I personally have no beef with ULA and I don't mind that it can't be trusted to be globally unique identifier. It'll still allow well planned enterprise networks to avoid renumbering in MA. -- ++ytti
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 11:40 PM, David Conrad wrote: On Jul 25, 2010, at 8:10 AM, Owen DeLong wrote: The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it? None of the sides of IANA pay for anything. There is no binding between what parties pay and what the ICANN staff who perform the IANA function do. In fact, those staff do not have any knowledge of whether any organization has paid anything (other than what they might hear incidentally). The (zero dollar) IANA functions contract has 3 major functions, of which allocating blocks of addresses to the RIRs (and at the direction of the IETF) is one. Failure to perform that function would be interpreted as breach of contract, regardless of whether the RIRs pay anything to ICANN or not. Regards, -drc The point was more that if the RIRs go away, IANA loses significant funding. Owen
Re: Addressing plan exercise for our IPv6 course
For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it? David already answered more eloquently than I could, so I'll simply add that what he said applied when I was there as well. The IANA is, and always has been a cost center. You don't want to live in an IANA fee-for-service world. My point was that as a cost center, IANA depends on funding from other sources. The RIRs are a major source of that funding. Owen
RE: Addressing plan exercise for our IPv6 course
If an expert stood up in court and said the chances that this fingerprint is the defendant's are a million to one, and the prosecutor then said Aha! So you admit it's *possible*! we would rightly scorn the prosecutor for being an innumerate nincompoop. Yet here we are paying serious heed to the idea that a ULA prefix conflict is a real business risk. Yes, but if this prosecutor does this a million times, he's bound to be right at least once. Yes, a good businessperson takes risks. They also do everything possible to mitigate those risks, such as background checks on employees, lightning rods and grounding systems and insurance on the electronics in the building, buy generators and fuel contracts or source an emergency workplace. Yes, a crazy employee may get through a background check, but if the question is the presence of an attempt and prevention, then what is the risk mitigation for ULA? Best Regards, Nathan Eisenberg
Re: Addressing plan exercise for our IPv6 course
On Jul 25, 2010, at 6:02 PM, Owen DeLong wrote: My point was that as a cost center, IANA depends on funding from other sources. The RIRs are a major source of that funding. I guess it depends on your definition of major. From section 5.1 of ICANN's draft FY11 budget (http://www.icann.org/en/financials/proposed-opplan-budget-v1-fy11-17may10-en.pdf if you care): Registry $32,647,000 Registrar$29,159,000 RIR $823,000 ccTLD $1,600,000 IDN ccTLD $780,000 Meeting Sponsorships$500,000 Total$65,509,000 So the RIRs contribute 1.25% of ICANN's budget. Regards, -drc
RE: Addressing plan exercise for our IPv6 course
On Sun, 2010-07-25 at 16:19 +, Nathan Eisenberg wrote: If an expert stood up in court and said the chances that this fingerprint is the defendant's are a million to one, and the prosecutor then said Aha! So you admit it's *possible*! we would rightly scorn the prosecutor for being an innumerate nincompoop. Yet here we are paying serious heed to the idea that a ULA prefix conflict is a real business risk. Yes, but if this prosecutor does this a million times, he's bound to be right at least once. Hm. Would you hire a prosecutor who was, on average, right once in a million times? Yes, a good businessperson takes risks. They also do everything possible to mitigate those risks, such as background checks on employees, lightning rods and grounding systems and insurance on the electronics in the building, buy generators and fuel contracts or source an emergency workplace. Yes, a crazy employee may get through a background check, but if the question is the presence of an attempt and prevention, then what is the risk mitigation for ULA? Choose a random ULA prefix. Done. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Addressing plan exercise for our IPv6 course
On Jul 25, 2010, at 11:54 AM, David Conrad wrote: On Jul 25, 2010, at 6:02 PM, Owen DeLong wrote: My point was that as a cost center, IANA depends on funding from other sources. The RIRs are a major source of that funding. I guess it depends on your definition of major. From section 5.1 of ICANN's draft FY11 budget (http://www.icann.org/en/financials/proposed-opplan-budget-v1-fy11-17may10-en.pdf if you care): Registry $32,647,000 Registrar$29,159,000 RIR $823,000 ccTLD $1,600,000 IDN ccTLD $780,000 Meeting Sponsorships$500,000 Total$65,509,000 So the RIRs contribute 1.25% of ICANN's budget. Regards, -drc Correct, now, what portion of ICANN's budget is related to the NRO sector? My bet is that it's less than 1.25%. I suppose you can make domain owners pay for address administration if you want to make address administration free, but, that seems a bit backwards to me. Owen
Re: Addressing plan exercise for our IPv6 course
Owen DeLong o...@delong.com writes: for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. To state the obvious: People are stupid. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? Well it's not cheaper but using NAT (and multiple NAT) leads to job security as nobody else will understand the network. BTST. Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: Addressing plan exercise for our IPv6 course
Saku Ytti s...@ytti.fi writes: RFC4193 + NAT quite simply is what they know and are comfortable with. NAT is *not simple*. NAT adds one more layer of complexity. When using multiple NAT things get worse. In most cases people don't want or need NAT they are just used to it and old habits die hard. Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: Addressing plan exercise for our IPv6 course
Owen DeLong o...@delong.com writes: You know that, I know that and (hopefully) all people on this list know that. But NAT == security was and still is sold by many people. So is snake oil. Ack, but people are still buying snake oil too. After one of my talks about IPv6 the firewall admins of a company said something like: So we can't use NAT as an excuse anymore and have to configure firewall rules? We don't want this. So how did you answer him? To be honest: I don't remember. I got drunk that evening. ;-) The correct answer is No, you don't have to configure rules, you just need one rule supplied by default which denies anything that doesn't have a corresponding outbound entry in the state table and it works just like NAT without the address mangling. They used NAT as an excuse not to let some applications to the outside. Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: Addressing plan exercise for our IPv6 course
On Mon, Jul 26, 2010 at 06:24:04AM +0200, Jens Link wrote: Owen DeLong o...@delong.com writes: The correct answer is No, you don't have to configure rules, you just need one rule supplied by default which denies anything that doesn't have a corresponding outbound entry in the state table and it works just like NAT without the address mangling. They used NAT as an excuse not to let some applications to the outside. That's OK, if it's NAT unfriendly, chances are it requires deep packet inspection to make the state tables do the right thing anyway. - Matt -- Skippy was a wallaby. ... Wallabies are dumb and not very trainable... The *good* thing...is that one Skippy looks very much like all the rest, hence...one-shot Skippy and plug-compatible Skippy. I don't think they ever had to go as far as belt-fed Skippy -- Robert Sneddon, ASR
Re: Addressing plan exercise for our IPv6 course
Owen, Correct, now, what portion of ICANN's budget is related to the NRO sector? Read the ICANN budget. ICANN does not budget things that way. You asked explain how the numbers side of IANA pays for anything when the RIRs stop funding it? Doug and I, who have a bit of knowledge on the subject, have told you IANA does not pay for anything. ICANN is a signatory to a contract with the US Department of Commerce that requires ICANN to provide the IANA functions, of which numbers allocation is one. Failure to perform any of the functions would be interpreted by DoC as a breach of contract. If the NRO did not contribute the (currently) 1.5% (which they have withheld in the past), ICANN would still be required to perform the number allocation function (as they did even when the RIR contribution was withheld). There is _no_ linkage between the contributions made by any stakeholder and the operation of the IANA functions contract. In the case of coordinating ULA assignments, I have no doubt IANA staff at ICANN _could_ provide the function quite easily since most of the infrastructure and processes are already in place for other services ICANN provides as part of the IANA functions contract. The question of whether or not the community, including folks from the RIR community and the IETF, want ICANN to perform that service is entirely different, and highly non-technical. Regards, -drc
Re: Addressing plan exercise for our IPv6 course
I tend to think a /60 is a reasonable allocation for a residential user. In my home I have two subnets and will in time likely add two more: - general network access - my office (required to be separate by Cisco Information Security policy) - (future) would likely want routable separate bandwidth for A/V at some point - (future) Smart Grid HAN will likely be its own subnet If my wife went to work for a company with an infosec policy like Cisco's, that becomes a fifth subnet. Yes, 16 to choose from seems reasonable. /56 seems appropriate to a small company, /48 for a larger company, and I could see a market for a /52. A company that needs more than a /48 is likely to also be using ULAs for some of its areas, which is an automatic extension, and could always justify another /48 (or one per continent) if it really needed them. Could I do all this within a /64? Of course, with some thought, and by getting the Smart Grid and office prefixes from other sources (Cisco, my utility) and running them over a VPN (which I do anyway). The question is why I should have to. Why four bit boundaries? Because we're using hexadecimal, and each character identifies four bits. It makes tracking numbers simple - no remember to count by N as in IPv4. It's not magic, but to my small mind - and especially for of non-technical residential customers - it seems reasonable. And yes, I think the logic behind a 48 bit MAC address is reasonable too. On Jul 24, 2010, at 7:50 AM, Mark Smith wrote: On Fri, 23 Jul 2010 13:26:43 -0700 Matthew Kaufman matt...@matthew.at wrote: sth...@nethelp.no wrote: It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. I have no problems with giving the customer several subnets. /56 is just fine for that. /56? How about /62? That certainly covers several... and if you're really worried they might have too many subnets for that to work, how about /60? I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer. So we end up with /56 for residential users. Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up. So you're also strongly against 48 bit Ethernet MAC addresses? Dropping the two bits for group and local addresses, that's 70 368 744 177 664 nodes per LAN. How ridiculous! What were those idiots+ thinking! 48-bit Absolute Internet and Ethernet Host Numbers, by Yogan K. Dalal, Robert S. Printis, *July 1981* http://ethernethistory.typepad.com/papers/HostNumbers.pdf + not actually idiots http://www.ipinc.net/IPv4.GIF
Re: Addressing plan exercise for our IPv6 course
On (2010-07-24 03:50 -0400), valdis.kletni...@vt.edu wrote: Firewall != NAT. The former is still needed in IPv6, the latter is not. And I suspect that most Joe Sixpacks think of that little box they bought as a Maybe you are talking strictly in context of residential DSL, in which case I would agree, NAT is killable, if we don't fsck-up in our DSL offerings. (Provide customer /64 and route /56 to ::c/64, so first /64 is bridged, if customer ever wants to start routing, they just add ::c/64 router to LAN.) However it is quite optimistic to think IPv6 would remove completely need for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. This is non-technical problem, enterprises of non-trivial size can't typically even tell without months of research all the devices and software where they've written down the IP addresses. RFC4193 + NAT quite simply is what they know and are comfortable with. It would be hard sell to ask them to design whole IPv6 infra so that they can confidently renumber it in 15min, like you can with RFC4193+NAT. -- ++ytti
Re: Addressing plan exercise for our IPv6 course
On Jul 23, 2010, at 1:26 PM, Matthew Kaufman wrote: sth...@nethelp.no wrote: It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. I have no problems with giving the customer several subnets. /56 is just fine for that. /56? How about /62? That certainly covers several... and if you're really worried they might have too many subnets for that to work, how about /60? /60 at a bare minimum since you can do RDNS delegation on /x boundaries where x%4==0. RDNS for a /62 is do-able, but, it requires 4 zone files and 4 sets of parent NS records instead of 1. /62 for 4 customers ends up requiring 16 zone files and 16 sets of parent NS records instead of 4. I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer. So we end up with /56 for residential users. Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up. Yes... Overkill is a good thing in IPv6. Even with this level of overkill, fully deploying the current world with a /48 for every house consumes less than 0.1% of the address space. (Apprximately 4x10^9 households on earth getting a /48 each = roughly one /16 which is 1/65,536th of the total address space and 1/8192nd of 2000::/3) What is the harm in doing so? Why not minimize provisioning effort and maximize user flexibility by consuming a very tiny fraction of a plentiful resource which costs virtually nothing? Owen
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 1:29 AM, Saku Ytti wrote: On (2010-07-24 03:50 -0400), valdis.kletni...@vt.edu wrote: Firewall != NAT. The former is still needed in IPv6, the latter is not. And I suspect that most Joe Sixpacks think of that little box they bought as a Maybe you are talking strictly in context of residential DSL, in which case I would agree, NAT is killable, if we don't fsck-up in our DSL offerings. (Provide customer /64 and route /56 to ::c/64, so first /64 is bridged, if customer ever wants to start routing, they just add ::c/64 router to LAN.) However it is quite optimistic to think IPv6 would remove completely need for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? Finally, if you think that non-multihomed end sites need PI, then, put a proposal in to change the RIR policies. RIR policies are not immutable. Each RIR has a bottom-up consensus driven process. If you don't like the policies, it really isn't that hard to get them changed. (I say this as an author of the first successful policy to create IPv6 PI) This is non-technical problem, enterprises of non-trivial size can't typically even tell without months of research all the devices and software where they've written down the IP addresses. Sounds like they haven't written them down very well. RFC4193 + NAT quite simply is what they know and are comfortable with. It would be hard sell to ask them to design whole IPv6 infra so that they can confidently renumber it in 15min, like you can with RFC4193+NAT. Why would you need to renumber in 15 minutes? It's easy enough to do in a week, given the above RA-based process. Owen
Re: Addressing plan exercise for our IPv6 course
On (2010-07-24 02:13 -0700), Owen DeLong wrote: This is non-technical problem, enterprises of non-trivial size can't typically even tell without months of research all the devices and software where they've written down the IP addresses. Sounds like they haven't written them down very well. Exactly, unfortunately this is reality in many enterprises today. And it is optimistic to hope any technical change will fix the situation. It would be excessively easy to renumber IPv4 infrastructure if it was built with that goal, yet it can be multiyear MUSDs gig to integrator. -- ++ytti
Re: Addressing plan exercise for our IPv6 course
Owen DeLong wrote: Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Because, although one of the original goals of IPv6 was for hosts to be easily multihomed at multiple addresses like this, host software (and even some of the required specifications) isn't really isn't there yet, and often the wrong thing happens. Never mind that the timescale for IPv6 deployment, no matter how long it is, will be shorter than the timescale for updating PCI, HIPPA, and SOX audit checklists to remove the requirements around hide internal topology and do not use public addresses on any interface of critical hosts. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? This would *also* require multihoming to actually work properly, only worse as the rules for selecting ULA vs PA routes are usually more right than the rules for selecting one PA vs another PA as an outbound interface, even if your host does multiple default routes properly. Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. Matthew Kaufman
Re: Addressing plan exercise for our IPv6 course
On Sat, 2010-07-24 at 08:50 -0700, Matthew Kaufman wrote: Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. I hope I'm not taking the above quote out of context, but why do you think this? How does the fact that interfaces on your host may have more than one public address translate into low odds that they can talk to each other? The only thing I can think of is that if an interface in your network has a public address from only one provider, and another interface in your network has a public address only from another provider, then the connection will go out through one provider and back in from the other, which would be less than optimal. On the other hand, there is no reason to think this would be particularly unreliable, and if such a situation existed it would either indicate a fault or be what you actually wanted. The discussion was in the context of a renumbering exercise. Using the simple method of having a period where both provider ranges are active and allowing the old provider range to time out may result in lost connections; there may also be caching difficulties with some applications. Neither situation is long-lived, and both can be mitigated by careful planning. Is that what you meant? Maybe I've missed your point. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Addressing plan exercise for our IPv6 course
Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist. RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent. With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? And changing all the ACLs based on the old providers addresses And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with 10year+ refresh cycle) brandon
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 6:40 PM, Brandon Butterworth wrote: Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. Oh, we have the technology. It's called memory. Speaking from the perspective of a vendor, I'll happily sell it to you. Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours.
Re: Addressing plan exercise for our IPv6 course
Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 8:50 AM, Matthew Kaufman wrote: Owen DeLong wrote: Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Because, although one of the original goals of IPv6 was for hosts to be easily multihomed at multiple addresses like this, host software (and even some of the required specifications) isn't really isn't there yet, and often the wrong thing happens. Host software is there, but, it requires some education on how to configure it. You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason. Never mind that the timescale for IPv6 deployment, no matter how long it is, will be shorter than the timescale for updating PCI, HIPPA, and SOX audit checklists to remove the requirements around hide internal topology and do not use public addresses on any interface of critical hosts. I expect the PCI changes to be out in less than a year. HIPPA and SOX may take closer to two years, maybe even three. I don't expect enterprise-wide adoption of IPv6 to be significant in less than 5 years. The big push for IPv6 right now needs to be on the public-facing services side which doesn't have hidden topology by definition. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? This would *also* require multihoming to actually work properly, only worse as the rules for selecting ULA vs PA routes are usually more right than the rules for selecting one PA vs another PA as an outbound interface, even if your host does multiple default routes properly. Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. Why use rules for selection... Simply have the RAs contain proper priorities for the ones you want to use at any particular moment and change the RA priorities as needed. Owen
Re: Addressing plan exercise for our IPv6 course
Eventually ARIN (or someone else will do it for them) may create a site ... Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/ Q.E.D. The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. brandon
Re: Addressing plan exercise for our IPv6 course
Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. Oh, we have the technology. It's called memory If that were viable then we'd be doing it. Speaking from the perspective of a vendor, I'll happily sell it to you. Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours. Indeed, best not listen to vendors brandon
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 9:23 AM, Karl Auer wrote: On Sat, 2010-07-24 at 08:50 -0700, Matthew Kaufman wrote: Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. I hope I'm not taking the above quote out of context, but why do you think this? How does the fact that interfaces on your host may have more than one public address translate into low odds that they can talk to each other? The only thing I can think of is that if an interface in your network has a public address from only one provider, and another interface in your network has a public address only from another provider, then the connection will go out through one provider and back in from the other, which would be less than optimal. On the other hand, there is no reason to think this would be particularly unreliable, and if such a situation existed it would either indicate a fault or be what you actually wanted. I would think even that would be unlikely as the border routers would most likely know routes to both sets of internal addresses and worst case, the packets should hairpin inside the border router rather than being forwarded to the external providers. Ideally, this hairpinning should be designed to occur prior to reaching the firewall, or, the firewall(s) must have rulesets to enable such. However, either solution is easily implemented in most topologies. Owen
Re: Addressing plan exercise for our IPv6 course
On Sat, 2010-07-24 at 10:42 -0700, Owen DeLong wrote: You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason. What is the ULA brokenness? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote: Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. SIXXS already has such a registry with a pretty low adoption rate. I still fail to see any advantage whatsoever to this approach and I think that the limited number of sites that implement it is unlikely to get continued support from ISVs. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist. RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode. I agree that easier to get PI addresses is a better alternative. I will support policy initiatives to do that. RFC4193 remains an utterly horrible idea and NATing it to the public internet remains even worse. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent. Right... That identifier is the EUI-64 which is both permanent and unique. The prefix changes when you switch providers, but, that's mostly not particularly horrible since there are tools to make that easier for the bulk of internal hosts. With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap. Actually, if you set things up correctly, most of the security stuff to manage is about the same because you hairpin the stuff that doesn't need filtration at a point before it hits the packet filters. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? And changing all the ACLs based on the old providers addresses Mostly this is a pretty straight forward copy-search-replace problem with prefix changes that can be done with the equivalent of an s/x/y/g construct. And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with 10year+ refresh cycle) That kit won't support IPv6, so, I fail to see the relevance. Any kit that supports IPv6 supports this. Owen
Re: Addressing plan exercise for our IPv6 course
On Sat, 2010-07-24 at 18:49 +0100, Brandon Butterworth wrote: Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/ Q.E.D. The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Sixxs manages prefixes from within the random one, there is as yet nothing set up to properly manage the other one. Dunno why ARIN should necessarily manage it; or any particular RIR for that matter. The random one allows for swift, bureaucracy-free self-allocation. The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. Makes it an interesting question as to whether the managed range is really necessary at all. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Addressing plan exercise for our IPv6 course
The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Later, in some undefined way. A PI lacking enterprise considering doing v6 this way either waits or decides the available space will do as someone will fix the managment later. Sixxs demonstrated that some will see a need With low take up of v6 it's early to know what they will see important The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. So a way to have really unique is reasonable. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. People still play the lotteries. brandon
Re: Addressing plan exercise for our IPv6 course
Karl Auer wrote: The random one allows for swift, bureaucracy-free self-allocation. The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. If it is that important, you'd prefer a managed solution, not a truly random one. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. Makes it an interesting question as to whether the managed range is really necessary at all. 1) While the chance of conflict is small, it is not non-existent, and when the interaction does occur and a conflict does arise, there may be huge costs involved. Random is fine for small deployments. It is a horrifying prospect for a 500+ subnet network. 2) Managing non-globally routed addressing is easy and doesn't require a lot of overhead. IANA itself could manage it, as it does all other globally unique numbers. First come, first serve. Have a nice day. I enjoy my unique enterprise oid. Why shouldn't I enjoy my own unique non-globally routed address space identifier? There shouldn't be a need for justification of the identifier (or services such as whois), so pawning it off on a RIR seems silly. Jack
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010 18:49:55 BST, Brandon Butterworth said: The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. Given our failure rate with registries of AS numbers, IP address blocks, and routing table entries, and the fact we have no special reason to believe that we'll be able to sprinkle Magic ULA Dust all over it and avoid all the failure modes of registries, we're probably better off just randomly generating them and just hope for no collisions. pgpx25ILrqzKX.pgp Description: PGP signature
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 11:41 AM, Brandon Butterworth wrote: The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Later, in some undefined way. A PI lacking enterprise considering doing v6 this way either waits or decides the available space will do as someone will fix the managment later. Sixxs demonstrated that some will see a need Or they forego the kludge and go with PA v6 realizing that they can do overlapping PA v6 transitions with relative ease when they switch providers. Of course during that time of overlap, they are technically multi-homed, so, there are other options as well. With low take up of v6 it's early to know what they will see important Yep. Enterprises are really the least of the concerns right now as well. We have about a year, maybe less to try and get public-facing stuff dual-stacked. We have lots of time yet to address the enterprise issues. The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. So a way to have really unique is reasonable. I think the simplest approach is simply to multihome and get a PI assignment if you don't want to live with PA. That's the cleanest approach too with the added benefit that you can load-balance and gain some redundancy and other optimizations in the process. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. People still play the lotteries. My favorite definition of the term Lottery is: Lottery (n): A tax on people who are bad at math. Owen
Re: Addressing plan exercise for our IPv6 course
On Sat, 2010-07-24 at 14:07 -0500, Jack Bates wrote: The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. Makes it an interesting question as to whether the managed range is really necessary at all. 1) While the chance of conflict is small, it is not non-existent, and when the interaction does occur and a conflict does arise, there may be huge costs involved. Random is fine for small deployments. It is a horrifying prospect for a 500+ subnet network. If two (or four, or ten, or a thousand) ULA prefixes are chosen randomly, the chance that any will conflict with any others is far, far less than the chance that your staff will make a terrible, disastrous mistake that puts you out of commission for weeks. And if you happen to have contingency plans for that, they will do just fine for dealing with a ULA conflict.[1] And of course, to be an actual problem the conflicting prefixes have to be in use by entities whose networks actually interact. Within an administrative domain, uniqueness can be guaranteed anyway. Winning a lottery is *far* more likely[2] than that a randomly chosen prefix from the ULA range will conflict with any other prefix in the same range, randomly chosen or not. Regards, K. [1] A ULA conflict is generally not going to require instant remedial action. People planning interaction at a network level will (one hopes!) do basic stuff like checking what prefixes are in use on the two networks. [2] Depending on the number of players in each game, anything from hundreds of times more likely to millions of times more likely. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 7:52 PM, Brandon Butterworth wrote: Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. Oh, we have the technology. It's called memory If that were viable then we'd be doing it. We are. I'm told that the fully outfitted top-end routers from Cisco and Juniper can handle tens of millions of routes (as long as you're not in a rush to converge and you have lots of cheap power). Of course, the price of said routers is a bit steep, particularly for smaller ISPs and enterprises, so you'll see a shift in the way the Internet works (perhaps not surprisingly, back towards the way telco networks look with a small number of very large companies). Speaking from the perspective of a vendor, I'll happily sell it to you. Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours. Indeed, best not listen to vendors As it is best not to listen to doctors that tell you if you continue chain smoking or eating 5000 calories a day, you'll likely regret it. Regards, -drc
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010 10:57:49 -0700 Owen DeLong o...@delong.com wrote: On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote: Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. SIXXS already has such a registry with a pretty low adoption rate. And I think that is good news. The fd00::/8 range is not defined as guaranteed globally unique. I'm concerned that the SIXXS registry could imply to those people who have used it, that it is. They may think that because that registry exists, and that they've used it, that address space it now theirs, and nobody else is allowed to use it. Once somebody perceives ownership of something they believe is unique, I think they commonly won't listen to reason about their actual lack of global ownership. fc00::/8 is for guaranteed globally unique ULAs. I still fail to see any advantage whatsoever to this approach and I think that the limited number of sites that implement it is unlikely to get continued support from ISVs. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist. RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode. I agree that easier to get PI addresses is a better alternative. I will support policy initiatives to do that. RFC4193 remains an utterly horrible idea and NATing it to the public internet remains even worse. Well I think RFC4193 is a great idea. I don't want my home network addressing to be bound to having a commercial arrangement with an ISP, or having an active Internet connection. I can also use the ULA prefix as a simple designator of trusted verses untrusted traffic sources in firewall rules. I see those advantages equally applicable to enterprise or ISP networks. Then again, I'm happy with the idea of multiple addresses on an interface, and source address selection. They're not much different to those issues in IPv4, such as unnumbered interfaces on routers, designated source addresses for router SNMP traps etc., or source address selection for policy routing. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent. That's IPv4 thinking showing though. People fundamentally don't want change when they don't know of or understand the benefits they will gain. ULAs are an overhead, but they also provide benefits that can't be achieved with global address space assigned by an ISP. (I don't accept the PI argument, because it isn't feasible for residential networks). Right... That identifier is the EUI-64 which is both permanent and unique. The prefix changes when you switch providers, but, that's mostly not particularly horrible since there are tools to make that easier for the bulk of internal hosts. With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap. Actually, if you set things up correctly, most of the security stuff to manage is about the same because you hairpin the stuff that doesn't need filtration at a point before it hits the packet filters. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? And changing all the ACLs based on the old providers addresses Mostly this is a pretty straight forward copy-search-replace problem with prefix changes that can be done with the equivalent of an s/x/y/g construct. And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010 19:41:18 +0100 (BST) Brandon Butterworth bran...@rd.bbc.co.uk wrote: The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Later, in some undefined way. A PI lacking enterprise considering doing v6 this way either waits or decides the available space will do as someone will fix the managment later. Sixxs demonstrated that some will see a need With low take up of v6 it's early to know what they will see important The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. So a way to have really unique is reasonable. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. People still play the lotteries. And those people, and some others by the looks of it, don't appear to understand statistics and chance ... brandon
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010, Brandon Butterworth wrote: Eventually ARIN (or someone else will do it for them) may create a site ... Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/ Q.E.D. The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. So, back when ULA was first proposed, some of us said (sometimes privately) that there are only 2 rational options: 1. Do it; with a persistent, guaranteed unique, global registry. 2. Don't do it. Option 2 was a non-starter since there was too much critical mass. The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) So given the overwhelming force pulling at this thing from both directions, you end up somewhere in the middle where no one wants to be. And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
Re: Addressing plan exercise for our IPv6 course
On 23 jul 2010, at 01:33, Matthew Walster wrote: On 22 July 2010 14:11, Alex Band al...@ripe.net wrote: There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree? I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing. /64 is too small, especially when sensornetworks take off you probably want multple ranges. In fact the CPE we use at the moment already takes a /64 for internals like voip clients, dns resolver and management interfaces and assigns the second one to the LAN. Optionally you want people to create a seperate zone for wifi guests (it supports dual band radio). So in reallife you already need more then one. Giving the way reverse DNS is designed I wouldn't recommend people to leave the 4 bit boundry on which it is organised unless you want to make your life miserable and complicated. So that would make it a /60 at minimum. So why /48 and not /56 or /60 ? We'll first of all we, and I mean the collective group of people that tries to run the internet (which includes you reading this), screwed it up in marketing. First of all we keep telling everybody there are so many addresses we will never run out of them. Now of course this is BS and we all know that someday we find 128 bits wasn't enough. By that time we probably realise that the current almost classfull system wasn't a smart choice and we introduce CIDR again to save our day. Which brings me to the second point and that is introducing semi fixed borders like /64 for a subnet and the original wording 'if you think they ever need more then one subnet, assign a /48'. That amazingly got stuck in peoples head like classfull once did. I still have customers asking for a C-class and some of them are even born in the CIDR era. As far as the customer base understand what IPv6 is, all they ever hear is 'I'll get a /48' even in those cases where you say something else. We told them NATs are going away and we told them we had so many addresses there wasn't a problem at all. /64 subnet, /48 when you need more did the rest. So assume I assign the mass that is unaware a /64, do I reserve some bits for future growth? I'll bet you when IPv6 does hit the market somebody will find an application for it and requires a second subnet (sensors for instance). What do I do when somebody requests this, assign a secondary /64 or renumber ? So maybe I should reserve a /60, but is that different from assigning it directly ? Takes up space anyway. So now I assign a /60, unfortunately the /48 is stuck in people's head so I get people complaining about this. This is amplified by the fact that early adopters, even the ones with tunnels, got a /48. Remember those folks who got a /8 back in the days, did you ever thought 'what if I would have been there' ? So I get into discussions with customers and that has a cost, I at least have to pay for the guy who answers the phone on our end. Next to that, there is that risk that I lose business because the shop across the road does offer /56 or even /48. Which brings me into the economics, we are in a hurry. We need to deploy and we need to deploy yesterday. In fact if you are not running IPv6 by now, you are too late. So I have the choice of creating a really complicated deployment scheme in which I can assign variable subnet lenghts to customers without breaking aggregation and without annoying them with renumbering. One-size-fits-all makes life easy and saves an huge pile of money and not only money but it saves time, time I need, beacuse we are already a bit late. In short, why a /48 'Because we can!'. We had about 15 years to design a proper scheme, we failed. Now we can discuss a redesign, but then we need to squeeze another 10 years out of IPv4. MarcoH
Re: Addressing plan exercise for our IPv6 course
Home wifi router vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls. This will greatly help in deploying IPv6...here is another NAT because we said NATs would disappear. MarcoH
Re: Addressing plan exercise for our IPv6 course
However, even then, there is no guarantee that the common denominator CPE for this service wont have NAT66 features, maybe even turned on by default. I've tested a lot of CPE's and haven't come across one that supports NAT66, they all do support DHCPv6 prefix delegation and actually most of them require it to work as most can't bridge between the WAN and LAN on the same /64. MarcoH
Re: Addressing plan exercise for our IPv6 course
Well said. One more reason is transition mechanisms. For example, 6to4, TBs, manual tunnels, those are just a few examples, which use/provide /48. We have today many customers using /48, which have already their own internal addressing plans, or manual subnets configured internally. Are you going to tell them now that you provide a dual stack service with less subnets and they need to remake their addressing plan and/or renumber ? Those customers are smart, they will look to your competitors and look for a better provider. No economical reason to provide less subnets to customers, many economical reasons to provide them as many subnets as you can, avoid wasting time, renumbering, etc., and being able to provide more applications that may be easily deployed in different subnets. Yes, 16 bits subnets are a lot, but time cost more, announcing more prefixes per customer is even more expensive, even for residential customers that will use more and more applications and services requiring them. You don't want to manage again a more complex network specially if as Tony Hain calculated some time ago, providing /48 for every possible customer in the Earth will mean IPv6 will last 480 years. Do you really believe we will keep using IP (not talking about v4 or v6) as we know it today ? I bet in less than 100 years we will need, for other reasons different than the need for more addresses, a new protocol. Why we insist in making things complicated againg, I guess because humans like complicated life ! Regards, Jordi From: Marco Hogewoning mar...@marcoh.net Reply-To: mar...@marcoh.net Date: Fri, 23 Jul 2010 10:06:43 +0200 To: Matthew Walster matt...@walster.org Cc: nanog list nanog@nanog.org Subject: Re: Addressing plan exercise for our IPv6 course On 23 jul 2010, at 01:33, Matthew Walster wrote: On 22 July 2010 14:11, Alex Band al...@ripe.net wrote: There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree? I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing. /64 is too small, especially when sensornetworks take off you probably want multple ranges. In fact the CPE we use at the moment already takes a /64 for internals like voip clients, dns resolver and management interfaces and assigns the second one to the LAN. Optionally you want people to create a seperate zone for wifi guests (it supports dual band radio). So in reallife you already need more then one. Giving the way reverse DNS is designed I wouldn't recommend people to leave the 4 bit boundry on which it is organised unless you want to make your life miserable and complicated. So that would make it a /60 at minimum. So why /48 and not /56 or /60 ? We'll first of all we, and I mean the collective group of people that tries to run the internet (which includes you reading this), screwed it up in marketing. First of all we keep telling everybody there are so many addresses we will never run out of them. Now of course this is BS and we all know that someday we find 128 bits wasn't enough. By that time we probably realise that the current almost classfull system wasn't a smart choice and we introduce CIDR again to save our day. Which brings me to the second point and that is introducing semi fixed borders like /64 for a subnet and the original wording 'if you think they ever need more then one subnet, assign a /48'. That amazingly got stuck in peoples head like classfull once did. I still have customers asking for a C-class and some of them are even born in the CIDR era. As far as the customer base understand what IPv6 is, all they ever hear is 'I'll get a /48' even in those cases where you say something else. We told them NATs are going away and we told them we had so many addresses there wasn't a problem at all. /64 subnet, /48 when you need more did the rest. So assume I assign the mass that is unaware a /64, do I reserve some bits for future growth? I'll bet you when IPv6 does hit the market somebody will find an application for it and requires a second subnet (sensors for instance). What do I do when somebody requests this, assign a secondary /64 or renumber ? So maybe I should reserve a /60, but is that different from assigning it directly ? Takes up space anyway. So now I assign a /60, unfortunately the /48 is stuck in people's head so I get people complaining about this. This is amplified by the fact that early adopters, even the ones with tunnels, got a /48. Remember those folks who got a /8 back in the days, did you ever thought 'what if I would have been there' ? So I get into discussions with customers and that has a cost, I at least have to pay for the guy who answers the phone on our end. Next to that, there is that risk
Re: Addressing plan exercise for our IPv6 course
Owen DeLong o...@delong.com writes: In all reality: 1.NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. You know that, I know that and (hopefully) all people on this list know that. But NAT == security was and still is sold by many people. Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall. I Agree. But there are also many people who want to believe in NAT as security feature. After one of my talks about IPv6 the firewall admins of a company said something like: So we can't use NAT as an excuse anymore and have to configure firewall rules? We don't want this. cheers Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: Addressing plan exercise for our IPv6 course
Owen DeLong wrote: Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary? The thing is, IPv6 is 128 bits of address space, so a /64 for your home *really* should be enough to have 1 machine online at a time. It'll be a lot easier to change the subnetting rules inside small networks, and we all know that DHCPv6 is far superior to SAA for almost all cases, but especially home users who need things like their DNS entries set up for them by their router. Matthew Kaufman
Re: Addressing plan exercise for our IPv6 course
And then next you can say ok, so /32 bits is big enough for your home, so let's change it again, kill autoconfiguration, ask existing IPv6 users to redo their addressing plans, renumber, etc., and use all the rest of the bits for routing ? And so on, of course, where is the limit ? You should propose this to 6man at the IETF. You're not getting it. Autoconfiguration is a very good feature. More bits for the user to subnet means more business for smart ISPs who don't want to sell addresses but instead services and applications much more easier to deploy thanks to a uniform /48 ways to address all end sites. Regards, Jordi From: Matthew Kaufman matt...@matthew.at Reply-To: matt...@matthew.at Date: Fri, 23 Jul 2010 07:04:17 -0700 To: Owen DeLong o...@delong.com Cc: nanog list nanog@nanog.org Subject: Re: Addressing plan exercise for our IPv6 course Owen DeLong wrote: Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary? The thing is, IPv6 is 128 bits of address space, so a /64 for your home *really* should be enough to have 1 machine online at a time. It'll be a lot easier to change the subnetting rules inside small networks, and we all know that DHCPv6 is far superior to SAA for almost all cases, but especially home users who need things like their DNS entries set up for them by their router. Matthew Kaufman ** The IPv6 Portal: http://www.ipv6tf.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.
Re: Addressing plan exercise for our IPv6 course
JORDI PALET MARTINEZ wrote: And then next you can say ok, so /32 bits is big enough for your home, so let's change it again, kill autoconfiguration, ask existing IPv6 users to redo their addressing plans, renumber, etc., and use all the rest of the bits for routing ? I *really* don't understand why a /32 isn't big enough for a home. Even if you insist on SAA for getting the addresses. How many IPv6 devices is the guy going to plug in / attach wirelessly anyway? And so on, of course, where is the limit ? You should propose this to 6man at the IETF. The same IETF that until just a few months ago believed that DCCP and SCTP would be wildly successful as new IP protocols because NATs don't matter? You're not getting it. Autoconfiguration is a very good feature. No, no it isn't. It goes on the list of interesting ideas for IPv6 that were good enough to be implemented, and refined (in this case as DHCP), for IPv4. Insisting on SAA is basically saying well, you know all those things we learned when we deployed DHCP... lets go ahead and forget them and pretend that home machine OS vendors *and* IT departments are wrong. More bits for the user to subnet means more business for smart ISPs who don't want to sell addresses but instead services and applications much more easier to deploy thanks to a uniform /48 ways to address all end sites. I fail to see how a household, even a really big one, is going to attach more bandwidth-consuming devices (which I presume is how the ISP does more business) to a link with a /48 on it vs a link with a /64 on it. A /64 allows more machines in your house than today's entire Internet has connected. Unless you have a new plan for electric power delivery to the home, there's no need to go beyond that. Matthew Kaufman
Re: Addressing plan exercise for our IPv6 course
It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. The ISP new business is not just about more bandwidth but also about offering new services, which they can charge for. Those services are very difficult to deploy in NATed scenarios such as the one that we have today with IPv4. And I'm not saying to forget about what we have learn with DHCP, in fact DHCPv6 has many new and good features, but for many reasons, autonconfiguration is good enough, and much more simple. Regards, Jordi From: Matthew Kaufman matt...@matthew.at Reply-To: matt...@matthew.at Date: Fri, 23 Jul 2010 07:22:53 -0700 To: Jordi Palet Martínez jordi.pa...@consulintel.es Cc: nanog@nanog.org Subject: Re: Addressing plan exercise for our IPv6 course JORDI PALET MARTINEZ wrote: And then next you can say ok, so /32 bits is big enough for your home, so let's change it again, kill autoconfiguration, ask existing IPv6 users to redo their addressing plans, renumber, etc., and use all the rest of the bits for routing ? I *really* don't understand why a /32 isn't big enough for a home. Even if you insist on SAA for getting the addresses. How many IPv6 devices is the guy going to plug in / attach wirelessly anyway? And so on, of course, where is the limit ? You should propose this to 6man at the IETF. The same IETF that until just a few months ago believed that DCCP and SCTP would be wildly successful as new IP protocols because NATs don't matter? You're not getting it. Autoconfiguration is a very good feature. No, no it isn't. It goes on the list of interesting ideas for IPv6 that were good enough to be implemented, and refined (in this case as DHCP), for IPv4. Insisting on SAA is basically saying well, you know all those things we learned when we deployed DHCP... lets go ahead and forget them and pretend that home machine OS vendors *and* IT departments are wrong. More bits for the user to subnet means more business for smart ISPs who don't want to sell addresses but instead services and applications much more easier to deploy thanks to a uniform /48 ways to address all end sites. I fail to see how a household, even a really big one, is going to attach more bandwidth-consuming devices (which I presume is how the ISP does more business) to a link with a /48 on it vs a link with a /64 on it. A /64 allows more machines in your house than today's entire Internet has connected. Unless you have a new plan for electric power delivery to the home, there's no need to go beyond that. Matthew Kaufman ** The IPv6 Portal: http://www.ipv6tf.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.
Re: Addressing plan exercise for our IPv6 course
On 7/23/2010 9:07 AM, JORDI PALET MARTINEZ wrote: It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. The ISP new business is not just about more bandwidth but also about offering new services, which they can charge for. Those services are very difficult to deploy in NATed scenarios such as the one that we have today with IPv4. And I'm not saying to forget about what we have learn with DHCP, in fact DHCPv6 has many new and good features, but for many reasons, autonconfiguration is good enough, and much more simple. Regards, Jordi Jordi - the real issues are in guaranteed delivery of certain evidence-grade services and what it takes to offer those. Todd From: Matthew Kaufman matt...@matthew.at Reply-To: matt...@matthew.at Date: Fri, 23 Jul 2010 07:22:53 -0700 To: Jordi Palet Martínez jordi.pa...@consulintel.es Cc: nanog@nanog.org Subject: Re: Addressing plan exercise for our IPv6 course JORDI PALET MARTINEZ wrote: And then next you can say ok, so /32 bits is big enough for your home, so let's change it again, kill autoconfiguration, ask existing IPv6 users to redo their addressing plans, renumber, etc., and use all the rest of the bits for routing ? I *really* don't understand why a /32 isn't big enough for a home. Even if you insist on SAA for getting the addresses. How many IPv6 devices is the guy going to plug in / attach wirelessly anyway? And so on, of course, where is the limit ? You should propose this to 6man at the IETF. The same IETF that until just a few months ago believed that DCCP and SCTP would be wildly successful as new IP protocols because NATs don't matter? You're not getting it. Autoconfiguration is a very good feature. No, no it isn't. It goes on the list of interesting ideas for IPv6 that were good enough to be implemented, and refined (in this case as DHCP), for IPv4. Insisting on SAA is basically saying well, you know all those things we learned when we deployed DHCP... lets go ahead and forget them and pretend that home machine OS vendors *and* IT departments are wrong. More bits for the user to subnet means more business for smart ISPs who don't want to sell addresses but instead services and applications much more easier to deploy thanks to a uniform /48 ways to address all end sites. I fail to see how a household, even a really big one, is going to attach more bandwidth-consuming devices (which I presume is how the ISP does more business) to a link with a /48 on it vs a link with a /64 on it. A /64 allows more machines in your house than today's entire Internet has connected. Unless you have a new plan for electric power delivery to the home, there's no need to go beyond that. Matthew Kaufman ** The IPv6 Portal: http://www.ipv6tf.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.
Re: Addressing plan exercise for our IPv6 course
On Jul 23, 2010, at 2:50 AM, Jens Link wrote: Owen DeLong o...@delong.com writes: In all reality: 1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. You know that, I know that and (hopefully) all people on this list know that. But NAT == security was and still is sold by many people. So is snake oil. Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall. I Agree. But there are also many people who want to believe in NAT as security feature. After one of my talks about IPv6 the firewall admins of a company said something like: So we can't use NAT as an excuse anymore and have to configure firewall rules? We don't want this. So how did you answer him? The correct answer is No, you don't have to configure rules, you just need one rule supplied by default which denies anything that doesn't have a corresponding outbound entry in the state table and it works just like NAT without the address mangling. In my experience, other than a small handful of religious zealots, that explanation is sufficient to get the point across to most such admins. Owen
Re: Addressing plan exercise for our IPv6 course
It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. I have no problems with giving the customer several subnets. /56 is just fine for that. I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer. So we end up with /56 for residential users. And I'm not saying to forget about what we have learn with DHCP, in fact DHCPv6 has many new and good features, but for many reasons, autonconfiguration is good enough, and much more simple. For our scenarios DHCPv6 is needed, autoconfiguration is *not* good enough. It seems quite likely that in many cases the CPE will use the /56 it gets from us (via DHCPv6 PD) as basis for autoconfiguration on the LAN side - and that's just fine and dandy. [I see no point in repeating the arguments for why autoconfiguration is not good enough - this has been beaten to death, repeatedly, on lots of IPv6 lists.] Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: Addressing plan exercise for our IPv6 course
Owen DeLong wrote: On Jul 22, 2010, at 9:51 PM, Joe Maimon wrote: Funny how so much concern is given to eliminating the possibility of end users returning for more space, yet for ISP's we have no real concern with what will happen when they near depletion of their /32 what with /48s to some thousands customers, aggregation, churn, what have you. There's no need to give it a lot of concern because that process is pretty well understood and not particularly different from the current process in IPv4. There are a whole lot of organizations who do not view getting IPv4 from ARIN as particularly easy or well understood. Whether IPv6 requests will be better or worse for more or less of the population is completely unpredictable at this time. My point is that very little concern is being given to them and all of it to the end user, who all understand how to contact their service provider to request more service. When an ISP runs out, they apply for more from either their upstream, or, their RIR. Just that simple. When an end user runs out, they apply for more from either their upstream, or, their RIR. Just that simple. The effort and cost of that on the organization is hard to predict, especially as how it may vary from size to size, organization to organization. Furthermore, everyone else pays with a DFZ slot. Yeah, but, the number of DFZ slots consumed by this in IPv6 will be so much smaller than IPv4 that I really find it hard to take this argument seriously. Early days yet. And each IPv6 is worth four of IPv4. We are already proposing doubling the allocation rate for transitional mechanisms. Additionally, it's not necessarily true due to allocation by bisection. /48 per customer gives the customer as many potential subnets as you have potential customers. You say that like it is a bad thing. I say it as if it is a curious thing worthy of real consideration whether we are indeed following the wisest course of action. With more address space than we need, the value we get is addressing convenience (just like we've had in Ethernet addressing since 1982). There is no need to make IPv6 addressing artificially precious and as costly as IPv4 addressing is. A balance should be struck and for that to happen, weight must be given to both sides. And it has. /32 is merely the default minimum allocation to an ISP. Larger blocks can be given, and, now that the RIRs are allocating by bisection, it should even be possible in most cases for that additional space to be an expansion of the existing allocation without changing the number of prefixes. e.g. 2001:db8::/32 could be expanded to 2001:db8::/28 16 times as much address space, same number of DFZ slots. Owen Yes, the one saving grace of this system. Joe
Re: Addressing plan exercise for our IPv6 course
sth...@nethelp.no wrote: It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. I have no problems with giving the customer several subnets. /56 is just fine for that. /56? How about /62? That certainly covers several... and if you're really worried they might have too many subnets for that to work, how about /60? I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer. So we end up with /56 for residential users. Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up. Matthew Kaufman
RE: Addressing plan exercise for our IPv6 course
-Original Message- From: Matthew Kaufman [mailto:matt...@matthew.at] Sent: Thursday, July 22, 2010 8:38 PM To: valdis.kletni...@vt.edu Cc: nanog list Subject: Re: Addressing plan exercise for our IPv6 course Home wifi router vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls. If that's what you want, you'd better submit that feature request, because it's not in queue yet. IPv6 will be in production before that comes out. Re: NAT vs firewall: draft-ietf-v6ops-ipv6-cpe-router-06 says Use draft-ietf-v6ops-cpe-simple-security which says Block bogons and have a stateful firewall. Lee
Re: Addressing plan exercise for our IPv6 course
On Fri, 2010-07-23 at 17:53 +0200, sth...@nethelp.no wrote: And I'm not saying to forget about what we have learn with DHCP, in fact DHCPv6 has many new and good features, but for many reasons, autonconfiguration is good enough, and much more simple. [...] For our scenarios DHCPv6 is needed, autoconfiguration is *not* good enough. [...] I see no point in repeating the arguments for why autoconfiguration is not good enough - this has been beaten to death, repeatedly, on lots of IPv6 lists. It's not like there can be only one. If autoconf is good enough for your purposes, that's great! If not, there's DHCP. That's great too! Or use autoconf AND stateless DHCP - that's great too! Heck, some of us will be using static addressing in a lot of places and that's great too. Most of us will be using all four methods. Understanding the advantages and limitations of each method and combo is important, but just because something has a limitation doesn't make it completely useless for everybody. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
