From DSchnell at corp.ptd.net Mon Sep 13 13:24:19 2010 From: DSchnell at corp.ptd.net (Schnell, Darryl) Date: Mon, 13 Sep 2010 13:24:19 -0400 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: Can anyone recommend a good IPV6 website for Beginners? I've read about eight web sites which say the same things and I feel like my head is going to explode. I guess the problem I'm having is trying to understand how an IPv4 CIDR notation translates in an IPv6 CIDR in order to fill out ARIN IPV6 Allocation Template future usage section. My actual question is - If I assigned a customer say an IPV4 /21 in IPV6 this would translate into a /56? If I'm not mistaken a /56 would translate into something like 65,000 host addresses? That just seems like a lot of hosts to me, especially when most of the time I'm working with networks that are /26 or smaller. I guess my big problem is confusion over labeling. What would be the equivalent of a /26, /27, /28 or have we done away with blocks that small and simply would just assign a /56 instead? Does any of the gibberish I wrote make any sense at all? Any help anyone can offer is much appreciated. D - -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaronh at bind.com Mon Sep 13 13:39:50 2010 From: aaronh at bind.com (Aaron Hughes) Date: Mon, 13 Sep 2010 10:39:50 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: References: Message-ID: <20100913173950.GP2192@trace.bind.com> Darryl, I have yet to see a good website on this and am actively working with a few folks to write a BCP on the subject. The short general operational practice is (and there is a lot of debate on this subject).. Customers who get 1 subnet (like a collocation customer with a server) get assigned a /64. Customers with more than 1 subnet get a /48. There are many people who would argue this is wasting IP space (I believe this will start a thread here) and /56s are a nice middle option. The point of this is to think in terms of number of subnets rather than number of hosts. 1 subnet = 1 /64 256 subnets = 1 /56 65,536 subnets = /48 I made a quick and dirty table here: http://bind.com/?path=netmasks6 that may help. As we make progress on the IPv6 subnetting BCP, I'll certainly share with this list. Cheers, Aaron On Mon, Sep 13, 2010 at 01:24:19PM -0400, Schnell, Darryl wrote: > Can anyone recommend a good IPV6 website for Beginners? I've read about eight web sites which say the same things and I feel like my head is going to explode. I guess the problem I'm having is trying to understand how an IPv4 CIDR notation translates in an IPv6 CIDR in order to fill out ARIN IPV6 Allocation Template future usage section. My actual question is - > > If I assigned a customer say an IPV4 /21 in IPV6 this would translate into a /56? If I'm not mistaken a /56 would translate into something like 65,000 host addresses? That just seems like a lot of hosts to me, especially when most of the time I'm working with networks that are /26 or smaller. I guess my big problem is confusion over labeling. What would be the equivalent of a /26, /27, /28 or have we done away with blocks that small and simply would just assign a /56 instead? > > Does any of the gibberish I wrote make any sense at all? > > Any help anyone can offer is much appreciated. > > D - > > -- > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. -- Aaron Hughes aaronh at bind.com +1-831-824-4161 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From ggiesen at akn.ca Mon Sep 13 13:48:03 2010 From: ggiesen at akn.ca (Gary T. Giesen) Date: Mon, 13 Sep 2010 13:48:03 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: References: Message-ID: <1284400083.4032.411.camel@ggiesen-workstation.netsurf.net> Darryl, The first mistake you're making is trying to use IPv6 like IPv4. Utilization for IPv6 is measured differently from IPv4. One of the main goals of v6 addressing is aggregation, and to ensure this, you should provide your customer with a large enough allocation that they won't need a second one. For most, this means a /48. Every customer is entitled to a /48, which means they cna have up to 65536 *subnets*. In IPv6 each subnet is fixed at a /64, so they will have 16 bits available to them for subnetting. There is some debate over whether residential customers (the kind who are typically running with a single IP and a NAT gateway right now) should receive a /48 or a /56 (which still gives them 256 subnets), but for anyone that qualified for anything larger than a /29 before (or any type of business customer), definitely give them a /48. All but the very largest ISPs will receive a /32, regardless of what they have in IPv4. It may seem like a lot of hosts (and it is), but with the fixed subnet size it's good to think of it differently. With a /32 (which leaves 32 bits for subnetting) *each* ISP will have more *subnets* than all of IPv4 had IP *addresses*. Again, ARIN wants to avoid ISPs coming back for a second allocation if possible. So to answer your question, if you customer was eligible for a /21 before, then by all means give them a /48. They will be able to create a ton of subnets, and should not have to go back for a second allocation (which is the main strategy for IPv6). GG On Mon, 2010-09-13 at 13:24 -0400, Schnell, Darryl wrote: > Can anyone recommend a good IPV6 website for Beginners? I?ve read > about eight web sites which say the same things and I feel like my > head is going to explode. I guess the problem I?m having is trying to > understand how an IPv4 CIDR notation translates in an IPv6 CIDR in > order to fill out ARIN IPV6 Allocation Template future usage section. > My actual question is ? > > > > If I assigned a customer say an IPV4 /21 in IPV6 this would translate > into a /56? If I?m not mistaken a /56 would translate into something > like 65,000 host addresses? That just seems like a lot of hosts to me, > especially when most of the time I?m working with networks that > are /26 or smaller. I guess my big problem is confusion over labeling. > What would be the equivalent of a /26, /27, /28 or have we done away > with blocks that small and simply would just assign a /56 instead? > > > > Does any of the gibberish I wrote make any sense at all? > > > > Any help anyone can offer is much appreciated. > > > > D - > > > > From swm at emanon.com Mon Sep 13 13:46:28 2010 From: swm at emanon.com (Scott Morris) Date: Mon, 13 Sep 2010 13:46:28 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: References: Message-ID: <4C8E6374.7050904@emanon.com> An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Mon Sep 13 14:29:52 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Sep 2010 14:29:52 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8E6374.7050904@emanon.com> References: <4C8E6374.7050904@emanon.com> Message-ID: try: and see where that leads you? If things are missing I'm sure additions/pointers/etc would be welcome... -chris On Mon, Sep 13, 2010 at 1:46 PM, Scott Morris wrote: > There really isn't a great repository for things, at least that I've > seen...? But keep in mind that the binary works the same in IPv6 as it does > in IPv4.? :) > > So when you look at a /21, do you look at it as 2000'ish IPv4 addresses? > (At which point a single /64 is more than enough) > Or do you look at it as 8 x /24 networks (at which point a /61 is the > technical equivalent) > > /64 is used by many people as the de facto "network" addressing for any > subnet because of all the magical EUI-64 addressing to work (e.g. less whiny > customer calls = better).? But anyone doing DHCPv6 will quickly learn that a > /64 is a SERIOUS amount of addresses than can be broken down internally to > any variation they really feel like.? (/126 = /30, etc.) > > So to best answer that questions, you have to know a little about your > customer and how they'll use the addresses.? /56 seems to be the way many > folks are going with things, but that's 256 /64 networks or the veritable > "boatload" of addresses that will be wasted beyond belief. > > Remember in the old days everyone gave out IPv4 addresses like candy.? Back > then 4.2 billion addresses seemed like a lot...? Today, 340 undecillion > addresses seems like a lot... Times change though! > > > > Scott Morris, CCIEx4 (R&S/ISP-Dial/Security/Service Provider) #4713, > > CCDE #2009::D, JNCIE-M #153, JNCIS-ER, CISSP, et al. > > CCSI #21903, JNCI-M, JNCI-ER > > swm at emanon.com > > Knowledge is power. > > Power corrupts. > > Study hard and be Eeeeviiiil...... > > On 9/13/10 1:24 PM, Schnell, Darryl wrote: > > Can anyone recommend a good IPV6 website for Beginners? I?ve read about > eight web sites which say the same things and I feel like my head is going > to explode. I guess the problem I?m having is trying to understand how an > IPv4 CIDR notation translates in an IPv6 CIDR in order to fill out ARIN IPV6 > Allocation Template future usage section. My actual question is ? > > > > If I assigned a customer say an IPV4 /21 in IPV6 this would translate into a > /56? If I?m not mistaken a /56 would translate into something like 65,000 > host addresses? That just seems like a lot of hosts to me, especially when > most of the time I?m working with networks that are /26 or smaller. I guess > my big problem is confusion over labeling. What would be the equivalent of a > /26, /27, /28 or have we done away with blocks that small and simply would > just assign a /56 instead? > > > > Does any of the gibberish I wrote make any sense at all? > > > > Any help anyone can offer is much appreciated. > > > > D - > > > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > From michael.dillon at bt.com Mon Sep 13 14:32:33 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 13 Sep 2010 19:32:33 +0100 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: References: Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> > If I assigned a customer say an IPV4 /21 in IPV6 this would translate > into a /56? If I'm not mistaken a /56 would translate into something > like 65,000 host addresses? That just seems like a lot of hosts to me, Anyone in this position should simply assign a /48 to every customer site no matter how big or small. A one bedroom apartment gets a /48. A manufacturing plant with 5 buildings including a 4-story office block, gets a /48. No exceptions. Later, when you have learned more, you might want to shift to only give a /56 to residential customers if there is a good business reason, but you are more likely to conclude that there is only a reason for large ISPs to introduce this complexity. > especially when most of the time I'm working with networks that are /26 > or smaller. I guess my big problem is confusion over labeling. What > would be the equivalent of a /26, /27, /28 or have we done away with > blocks that small and simply would just assign a /56 instead? The equivalent to everything that you mentioned is /48. Only use /56 for private residence customers and even that is optional and probably a bad idea when doing forecasting. ARIN has a wiki at http://www.getipv6.info with some good basic info and links to lots of tutorials on other sites. Spend some time there. --Michael Dillon From tony at lava.net Mon Sep 13 14:50:46 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 13 Sep 2010 08:50:46 -1000 (HST) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100913173950.GP2192@trace.bind.com> References: <20100913173950.GP2192@trace.bind.com> Message-ID: On Mon, 13 Sep 2010, Aaron Hughes wrote: > I have yet to see a good website on this and am actively working with a > few folks to write a BCP on the subject. There is a wiki that you can add it to: http://getipv6.info Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From tim.h at bendtel.com Mon Sep 13 15:01:50 2010 From: tim.h at bendtel.com (Tim Howe) Date: Mon, 13 Sep 2010 12:01:50 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> Message-ID: <20100913120150.94bb573c.tim.h@bendtel.com> On Mon, 13 Sep 2010 19:32:33 +0100 wrote: > > If I assigned a customer say an IPV4 /21 in IPV6 this would translate > > into a /56? If I'm not mistaken a /56 would translate into something > > like 65,000 host addresses? That just seems like a lot of hosts to me, > > Anyone in this position should simply assign a /48 to every customer site > no matter how big or small. A one bedroom apartment gets a /48. A manufacturing > plant with 5 buildings including a 4-story office block, gets a /48. > No exceptions. This is slightly different than I have been led to think... It seems wise, when you know the customer has no intention of having multiple networks, to provide a /64. Not because you fear wasting address space. Currently, most folks will have a single IP (half of the connecting range to their provider) and their LAN in RFC1918 space using that address for NAT. The IPv6 equiv to that would be a /64 connecting range and another /64 range to use for their LAN. This has been my plan as most of these customers don't know (and don't wish to know) how to subnet v4, so I am sure handing them a /48 and expecting them to use it correctly is out of the question and unnecessary. This seems to be what HE is doing for tunnel accounts. Anyone wanting/needing multiple networks (or who even thinks they might, and knows what a /48 is) can and should have a /48, no problem. I am just a small provider with mostly small business accounts and colo, so maybe my situation isn't typical... /64 per network /48 per customer with more than one network (so they can have /64 per network) Is this flawed or no longer the prevailing way of thinking? -- Tim Howe From dwhite at olp.net Mon Sep 13 15:27:45 2010 From: dwhite at olp.net (Dan White) Date: Mon, 13 Sep 2010 14:27:45 -0500 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100913120150.94bb573c.tim.h@bendtel.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> Message-ID: <20100913192745.GA2625@dan.olp.net> On 13/09/10?12:01?-0700, Tim Howe wrote: >On Mon, 13 Sep 2010 19:32:33 +0100 > wrote: > >> > If I assigned a customer say an IPV4 /21 in IPV6 this would translate >> > into a /56? If I'm not mistaken a /56 would translate into something >> > like 65,000 host addresses? That just seems like a lot of hosts to me, >> >> Anyone in this position should simply assign a /48 to every customer site >> no matter how big or small. A one bedroom apartment gets a /48. A manufacturing >> plant with 5 buildings including a 4-story office block, gets a /48. >> No exceptions. > > This is slightly different than I have been led to think... It >seems wise, when you know the customer has no intention of having >multiple networks, to provide a /64. Not because you fear wasting Consider a long range scenario for that customer. A scenario in which they may purchase networking equipment for multiple purposes in 5 or 10, or 20 years that performs layer two separation between different functions in their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, visitor access, alarm system, automobiles, utilities, etc. I find it benefitial to consider that I probably don't know what a customer's network will look like in 20 years, and a /48 per customer is probably wisest until we've gained more operational experience with IPv6 in our own network. -- Dan White From owen at delong.com Mon Sep 13 15:30:15 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Sep 2010 12:30:15 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8E6374.7050904@emanon.com> References: <4C8E6374.7050904@emanon.com> Message-ID: <7B253F23-755F-4515-88A0-7585EDB20758@delong.com> Scott, Let's put the true numbers in a little bit of perspective... First, when 4.2 billion addresses seemed like a lot, it was because the internet was not anticipated to be something everyone would use every day. It was expected to be a research community project used by a much smaller research community and if that had continued to be the case, 4.2 billion addresses would still seem like a lot. Compared to 6,8 Billion people, however, 4.2 billion addresses (actually more like 3.2 billion unicast addresses) doesn't seem like much at all. On the other hand... Consider that there are approximately 30,000 ISPs world-wide. If we were to give every single ISP a pair of /28s (that's 32 of the current /32 allocations) in each of the 5 regions (AfriNIC, APNIC, ARIN, LACNIC, RIPE), we would still only consume the majority of the current single /12 allocated to each RIR. There would still be 506 /12s left in the current /3. There were some very good reasons to give out IPv4 addresses like candy, and, having done so is one of the major contributing factors to the success and broad deployment of the internet. Is it remotely possible that in 50 or 60 years, we will still be using IPv6 addressing and that current liberal allocation efforts could prove to be unwise for that future? Actually, yes, it is possible. However, I propose that we approach that logically. For the time being, liberal allocation seems to have little consequence and provide the best opportunities for improving the user experience and the scalability of the network. As such, let's go ahead and be liberal in our allocations and assignments. Give each end site no less than a /48 (even a residential customer). Let's try this experiment until we have used up 20 /12s. If we get to the point where we have used 20 of the first 512 /12s in less than 30 years, then, we have plenty of time after that point to develop different allocation policy for the remaining 492 /12s before we exhaust the first 1/8th of the address space. OK? Owen On Sep 13, 2010, at 10:46 AM, Scott Morris wrote: > There really isn't a great repository for things, at least that I've seen... But keep in mind that the binary works the same in IPv6 as it does in IPv4. :) > > So when you look at a /21, do you look at it as 2000'ish IPv4 addresses? (At which point a single /64 is more than enough) > Or do you look at it as 8 x /24 networks (at which point a /61 is the technical equivalent) > > /64 is used by many people as the de facto "network" addressing for any subnet because of all the magical EUI-64 addressing to work (e.g. less whiny customer calls = better). But anyone doing DHCPv6 will quickly learn that a /64 is a SERIOUS amount of addresses than can be broken down internally to any variation they really feel like. (/126 = /30, etc.) > > So to best answer that questions, you have to know a little about your customer and how they'll use the addresses. /56 seems to be the way many folks are going with things, but that's 256 /64 networks or the veritable "boatload" of addresses that will be wasted beyond belief. > > Remember in the old days everyone gave out IPv4 addresses like candy. Back then 4.2 billion addresses seemed like a lot... Today, 340 undecillion addresses seems like a lot... Times change though! > > > Scott Morris, CCIEx4 (R&S/ISP-Dial/Security/Service Provider) #4713, > CCDE #2009::D, JNCIE-M #153, JNCIS-ER, CISSP, et al. > CCSI #21903, JNCI-M, JNCI-ER > swm at emanon.com > > Knowledge is power. > Power corrupts. > Study hard and be Eeeeviiiil...... > > On 9/13/10 1:24 PM, Schnell, Darryl wrote: >> >> Can anyone recommend a good IPV6 website for Beginners? I?ve read about eight web sites which say the same things and I feel like my head is going to explode. I guess the problem I?m having is trying to understand how an IPv4 CIDR notation translates in an IPv6 CIDR in order to fill out ARIN IPV6 Allocation Template future usage section. My actual question is ? >> >> If I assigned a customer say an IPV4 /21 in IPV6 this would translate into a /56? If I?m not mistaken a /56 would translate into something like 65,000 host addresses? That just seems like a lot of hosts to me, especially when most of the time I?m working with networks that are /26 or smaller. I guess my big problem is confusion over labeling. What would be the equivalent of a /26, /27, /28 or have we done away with blocks that small and simply would just assign a /56 instead? >> >> Does any of the gibberish I wrote make any sense at all? >> >> Any help anyone can offer is much appreciated. >> >> D - >> >> >> _______________________________________________ >> ARIN-Discuss >> You are receiving this message because you are subscribed to >> the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-discuss >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 13 15:37:04 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Sep 2010 12:37:04 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100913120150.94bb573c.tim.h@bendtel.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> Message-ID: <0D038EBD-5AE6-4E38-AF72-AB997B37070F@delong.com> On Sep 13, 2010, at 12:01 PM, Tim Howe wrote: > On Mon, 13 Sep 2010 19:32:33 +0100 > wrote: > >>> If I assigned a customer say an IPV4 /21 in IPV6 this would translate >>> into a /56? If I'm not mistaken a /56 would translate into something >>> like 65,000 host addresses? That just seems like a lot of hosts to me, >> >> Anyone in this position should simply assign a /48 to every customer site >> no matter how big or small. A one bedroom apartment gets a /48. A manufacturing >> plant with 5 buildings including a 4-story office block, gets a /48. >> No exceptions. > > This is slightly different than I have been led to think... It > seems wise, when you know the customer has no intention of having > multiple networks, to provide a /64. Not because you fear wasting > address space. Currently, most folks will have a single IP (half of the > connecting range to their provider) and their LAN in RFC1918 space using > that address for NAT. The IPv6 equiv to that would be a /64 connecting > range and another /64 range to use for their LAN. This has been my plan > as most of these customers don't know (and don't wish to know) how to > subnet v4, so I am sure handing them a /48 and expecting them to use it > correctly is out of the question and unnecessary. This seems to be what > HE is doing for tunnel accounts. > That is what HE is doing for tunnel accounts. However, if I were designing the tunnel service today, I would do it differently. If I were designing it, I would assign every customer a /48 and those customers that did not yet need the /48 would simply use the first /64 from that /48. > Anyone wanting/needing multiple networks (or who even thinks they > might, and knows what a /48 is) can and should have a /48, no problem. > > I am just a small provider with mostly small business accounts > and colo, so maybe my situation isn't typical... > More so than you may think. > /64 per network > /48 per customer with more than one network (so they can have /64 per network) > > Is this flawed or no longer the prevailing way of thinking? > Not entirely, but, as I said, if I were building a network from scratch today, I would assign every customer a /64 for link and a /48 for each end site. If they don't need more than one network at an end site, then just have them use the first /64 from that /48 and everything still works just fine. That way, expansion does not require renumbering and when they figure out that they need the /48 you have already given it to them. Improved customer service through the illusion of ESP. (A term I believe was originally coined by E. Zwicky for systems administration) Owen From rs at seastrom.com Mon Sep 13 15:40:25 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 13 Sep 2010 15:40:25 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100913120150.94bb573c.tim.h@bendtel.com> (Tim Howe's message of "Mon, 13 Sep 2010 12:01:50 -0700") References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> Message-ID: <8662y9xwie.fsf@seastrom.com> Tim Howe writes: > On Mon, 13 Sep 2010 19:32:33 +0100 wrote: >> Anyone in this position should simply assign a /48 to every customer site >> no matter how big or small. A one bedroom apartment gets a /48. A manufacturing >> plant with 5 buildings including a 4-story office block, gets a /48. >> No exceptions. > > This is slightly different than I have been led to think... It > seems wise, when you know the customer has no intention of having > multiple networks, to provide a /64. Stop right there. How do you *know* that they have no intention of having multiple networks... *ever*? Sure you might have strong suspicions if they are residential, but I already run guest and resident subnets at home and if I had kids I'd be running two more, and that's without even thinking about things that are uncommon or because I'm a network guy - they are what you can reasonably expect will start showing up in appliance home router/firewall/AP stuff that supports IPv6. Fast forward 8 years from now. Do you want to be kicking yourself or having your successor's successor cursing your name for trying to conserve IPv6 space instead of conserving the brain cells of network engineers? Why do you care how many subnets your customer uses? There is a business cost to every bit of understanding the customer's use case. Understanding how many subnets they need is only relevant in the austerity environment of IPv4, not in the new world of IPv6. > Not because you fear wasting > address space. Currently, most folks will have a single IP (half of the > connecting range to their provider) and their LAN in RFC1918 space using > that address for NAT. The IPv6 equiv to that would be a /64 connecting > range and another /64 range to use for their LAN. This has been my plan > as most of these customers don't know (and don't wish to know) how to > subnet v4, so I am sure handing them a /48 and expecting them to use it > correctly is out of the question and unnecessary. This seems to be what > HE is doing for tunnel accounts. I think HE is absolutely doing the right thing here. Everyone gets a /48. No exceptions. Why? It makes things easy for you, the network vendor. > Anyone wanting/needing multiple networks (or who even thinks they > might, and knows what a /48 is) can and should have a /48, no problem. > > I am just a small provider with mostly small business accounts > and colo, so maybe my situation isn't typical... > > /64 per network > /48 per customer with more than one network (so they can have /64 per network) > > Is this flawed or no longer the prevailing way of thinking? It certainly is setting your competitors up with a way to effectively sell against you. If staying small is in your business plan, have at it. :-) -r From ggiesen at akn.ca Mon Sep 13 15:43:05 2010 From: ggiesen at akn.ca (Gary T. Giesen) Date: Mon, 13 Sep 2010 15:43:05 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8E6374.7050904@emanon.com> References: <4C8E6374.7050904@emanon.com> Message-ID: <1284406985.4032.418.camel@ggiesen-workstation.netsurf.net> Using anything less than /64 for a subnet can be dangerous, especially as a lot of devices are hard-coded to not accept any other subnet mask. While I'd argue /64's should be used everywhere, there is some merit to using /112's or similar on point-to-point links between routers, where it's a known quantity what the devices support. In an environment where you could have a large number of heterogeneous devices, you're asking for a support headache to use anything else. /64's are the safe choice, and we're in no danger of running out of them anytime soon (and probably not in my lifetime). GG On Mon, 2010-09-13 at 13:46 -0400, Scott Morris wrote: > There really isn't a great repository for things, at least that I've > seen... But keep in mind that the binary works the same in IPv6 as it > does in IPv4. :) > > So when you look at a /21, do you look at it as 2000'ish IPv4 > addresses? (At which point a single /64 is more than enough) > Or do you look at it as 8 x /24 networks (at which point a /61 is the > technical equivalent) > > /64 is used by many people as the de facto "network" addressing for > any subnet because of all the magical EUI-64 addressing to work (e.g. > less whiny customer calls = better). But anyone doing DHCPv6 will > quickly learn that a /64 is a SERIOUS amount of addresses than can be > broken down internally to any variation they really feel like. (/126 > = /30, etc.) > > So to best answer that questions, you have to know a little about your > customer and how they'll use the addresses. /56 seems to be the way > many folks are going with things, but that's 256 /64 networks or the > veritable "boatload" of addresses that will be wasted beyond belief. > > Remember in the old days everyone gave out IPv4 addresses like candy. > Back then 4.2 billion addresses seemed like a lot... Today, 340 > undecillion addresses seems like a lot... Times change though! > > > > Scott Morris, CCIEx4 (R&S/ISP-Dial/Security/Service Provider) #4713, > > CCDE #2009::D, JNCIE-M #153, JNCIS-ER, CISSP, et al. > > CCSI #21903, JNCI-M, JNCI-ER > > swm at emanon.com > > > Knowledge is power. > > Power corrupts. > > Study hard and be Eeeeviiiil...... > > > > On 9/13/10 1:24 PM, Schnell, Darryl wrote: > > Can anyone recommend a good IPV6 website for Beginners? I?ve read > > about eight web sites which say the same things and I feel like my > > head is going to explode. I guess the problem I?m having is trying > > to understand how an IPv4 CIDR notation translates in an IPv6 CIDR > > in order to fill out ARIN IPV6 Allocation Template future usage > > section. My actual question is ? > > > > > > > > If I assigned a customer say an IPV4 /21 in IPV6 this would > > translate into a /56? If I?m not mistaken a /56 would translate into > > something like 65,000 host addresses? That just seems like a lot of > > hosts to me, especially when most of the time I?m working with > > networks that are /26 or smaller. I guess my big problem is > > confusion over labeling. What would be the equivalent of > > a /26, /27, /28 or have we done away with blocks that small and > > simply would just assign a /56 instead? > > > > > > > > Does any of the gibberish I wrote make any sense at all? > > > > > > > > Any help anyone can offer is much appreciated. > > > > > > > > D - > > > > > > > > > > > > _______________________________________________ > > ARIN-Discuss > > You are receiving this message because you are subscribed to > > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-discuss > > Please contact info at arin.net if you experience any issues. From owen at delong.com Mon Sep 13 15:53:45 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Sep 2010 12:53:45 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <1284406985.4032.418.camel@ggiesen-workstation.netsurf.net> References: <4C8E6374.7050904@emanon.com> <1284406985.4032.418.camel@ggiesen-workstation.netsurf.net> Message-ID: <60DDADEA-EF14-4973-8B24-4E5ADD4175D6@delong.com> On Sep 13, 2010, at 12:43 PM, Gary T. Giesen wrote: > Using anything less than /64 for a subnet can be dangerous, especially > as a lot of devices are hard-coded to not accept any other subnet mask. > Those devices are broken and violate the RFCs. They should be fixed. I agree that you should not be using non /64 subnets unless you have a very good reason and know what you are doing and why you are doing it. However, the mere existence of bad IPv6 stack implementations is not the reason to use /64s. > While I'd argue /64's should be used everywhere, there is some merit to > using /112's or similar on point-to-point links between routers, where > it's a known quantity what the devices support. In an environment where > you could have a large number of heterogeneous devices, you're asking > for a support headache to use anything else. > What, exactly, is this supposed merit? Owen From mike at netwright.net Mon Sep 13 16:17:37 2010 From: mike at netwright.net (Mike Lieberman) Date: Mon, 13 Sep 2010 14:17:37 -0600 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100913192745.GA2625@dan.olp.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> Message-ID: <0a4e01cb5380$b539e260$1fada720$@net> I have been reading all these discussions (mostly silently) for a long, long time. I understand what a /48 is and a /56, /64 and /128. I understand the notation. Quite frankly what I don't get is why anyone thinks that consumers want public numbers inside their home/LANs. Once my customers understood the benefit of hiding behind a NAT, they embraced it quite emphatically. Put a private residence on public IPv6? Sorry but that makes no sense. Yes I agree that I don't know what people will need in 20 years. And YES it is nice that we will have address space in 20 years. But allocating a /48 to a home that today uses an IPv4 /30 with a private NAT seems beyond humorous. It just sounds insane. Using private addressing that home already potentially has access thousands of subnets and millions of addresses. RFC 4193 provides even more addresses for use with firewall/NAT appliances. Why does a home or business using RFC 4193 need a /48 or even a /56 or /64. Just because we have the numbers does not mean we should distribute them. _________________________ Mike Lieberman, President Net Wright LLC Tel: +1-307-857-4898 Fax: +1-307-857-4872 -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Dan White Sent: Monday, September 13, 2010 1:28 PM To: Tim Howe Cc: arin-discuss at arin.net Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 On 13/09/10?12:01?-0700, Tim Howe wrote: >On Mon, 13 Sep 2010 19:32:33 +0100 > wrote: > >> > If I assigned a customer say an IPV4 /21 in IPV6 this would translate >> > into a /56? If I'm not mistaken a /56 would translate into something >> > like 65,000 host addresses? That just seems like a lot of hosts to me, >> >> Anyone in this position should simply assign a /48 to every customer site >> no matter how big or small. A one bedroom apartment gets a /48. A manufacturing >> plant with 5 buildings including a 4-story office block, gets a /48. >> No exceptions. > > This is slightly different than I have been led to think... It >seems wise, when you know the customer has no intention of having >multiple networks, to provide a /64. Not because you fear wasting Consider a long range scenario for that customer. A scenario in which they may purchase networking equipment for multiple purposes in 5 or 10, or 20 years that performs layer two separation between different functions in their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, visitor access, alarm system, automobiles, utilities, etc. I find it benefitial to consider that I probably don't know what a customer's network will look like in 20 years, and a /48 per customer is probably wisest until we've gained more operational experience with IPv6 in our own network. -- Dan White _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: 09/13/10 00:35:00 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4208 bytes Desc: not available URL: From matthew at crocker.com Mon Sep 13 16:44:00 2010 From: matthew at crocker.com (Matthew S. Crocker) Date: Mon, 13 Sep 2010 16:44:00 -0400 (EDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a4e01cb5380$b539e260$1fada720$@net> Message-ID: <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> In short because NAT is evil. Customers don't normally have a clue what NAT means or if it actually provides security or not. A properly configured home IPv6 appliance can provide the same levels of security without NAT. Stateful packet inspection and real IPv6 addresses on all devices is far superior to NATted IPv4 NAT is the bane of my existence as a VoIP provider. If only my phones supported IPv6... -Matt ----- Original Message ----- > From: "Mike Lieberman" > To: arin-discuss at arin.net > Sent: Monday, September 13, 2010 4:17:37 PM > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > I have been reading all these discussions (mostly silently) for a > long, long > time. I understand what a /48 is and a /56, /64 and /128. I understand > the > notation. > > Quite frankly what I don't get is why anyone thinks that consumers > want > public numbers inside their home/LANs. Once my customers understood > the > benefit of hiding behind a NAT, they embraced it quite emphatically. > > Put a private residence on public IPv6? Sorry but that makes no sense. > > > Yes I agree that I don't know what people will need in 20 years. And > YES it > is nice that we will have address space in 20 years. But allocating a > /48 to > a home that today uses an IPv4 /30 with a private NAT seems beyond > humorous. > It just sounds insane. Using private addressing that home already > potentially has access thousands of subnets and millions of addresses. > > > RFC 4193 provides even more addresses for use with firewall/NAT > appliances. > Why does a home or business using RFC 4193 need a /48 or even a /56 or > /64. > > Just because we have the numbers does not mean we should distribute > them. > > > _________________________ > Mike Lieberman, President > Net Wright LLC > Tel: +1-307-857-4898 > Fax: +1-307-857-4872 > > > -----Original Message----- > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net] > On Behalf Of Dan White > Sent: Monday, September 13, 2010 1:28 PM > To: Tim Howe > Cc: arin-discuss at arin.net > Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 > > On 13/09/10?12:01?-0700, Tim Howe wrote: > >On Mon, 13 Sep 2010 19:32:33 +0100 > > wrote: > > > >> > If I assigned a customer say an IPV4 /21 in IPV6 this would > translate > >> > into a /56? If I'm not mistaken a /56 would translate into > something > >> > like 65,000 host addresses? That just seems like a lot of hosts > to me, > >> > >> Anyone in this position should simply assign a /48 to every > customer site > >> no matter how big or small. A one bedroom apartment gets a /48. A > manufacturing > >> plant with 5 buildings including a 4-story office block, gets a > /48. > >> No exceptions. > > > > This is slightly different than I have been led to think... It > >seems wise, when you know the customer has no intention of having > >multiple networks, to provide a /64. Not because you fear wasting > > Consider a long range scenario for that customer. A scenario in which > they > may purchase networking equipment for multiple purposes in 5 or 10, or > 20 > years that performs layer two separation between different functions > in > their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, > visitor > access, alarm system, automobiles, utilities, etc. > > I find it benefitial to consider that I probably don't know what a > customer's network will look like in 20 years, and a /48 per customer > is > probably wisest until we've gained more operational experience with > IPv6 in > our own network. > > -- > Dan White > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: > 09/13/10 > 00:35:00 > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From scottleibrand at gmail.com Mon Sep 13 16:47:01 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 13 Sep 2010 13:47:01 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a4e01cb5380$b539e260$1fada720$@net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> Message-ID: <4C8E8DC5.1020106@gmail.com> On Mon 9/13/2010 1:17 PM, Mike Lieberman wrote: > I have been reading all these discussions (mostly silently) for a long, long > time. I understand what a /48 is and a /56, /64 and /128. I understand the > notation. > > Quite frankly what I don't get is why anyone thinks that consumers want > public numbers inside their home/LANs. Once my customers understood the > benefit of hiding behind a NAT, they embraced it quite emphatically. Yes, the stateful firewall aspect of their NAT box is quite useful. I suspect all IPv6-capable home routers will still run a stateful firewall with a default-closed policy on incoming traffic. > Put a private residence on public IPv6? Sorry but that makes no sense. I'd like to be able to have my phone communicate with my home boxes, at line rate, regardless of whether I'm on my home wi-fi, or out on someone else's network. If both devices have public IPv6 addresses, I could initiate a connection, in either direction, using IPsec to provide end-to-end security, and ensure that everything is always instantly in sync between the devices, without having to go through a server. Both Apple (with Bonjour) and Microsoft are doing a good job of getting us back to seamless network device discovery and integration using IPv6 link-local addresses on the local LAN. There's no reason as we deploy v6 globally that we shouldn't be able to extend this across the Internet. But if you implement v6 NAT, that's exactly the kind of innovation you'd prevent. > Yes I agree that I don't know what people will need in 20 years. And YES it > is nice that we will have address space in 20 years. But allocating a /48 to > a home that today uses an IPv4 /30 with a private NAT seems beyond humorous. > It just sounds insane. Using private addressing that home already > potentially has access thousands of subnets and millions of addresses. > > RFC 4193 provides even more addresses for use with firewall/NAT appliances. > Why does a home or business using RFC 4193 need a /48 or even a /56 or /64. > > Just because we have the numbers does not mean we should distribute them. Quite a few home networks run two SSIDs, one WPA2-encrypted for private use, and one open for guests. Each of those should have its own /64. That means I need at least a /56. -Scott > > _________________________ > Mike Lieberman, President > Net Wright LLC > Tel: +1-307-857-4898 > Fax: +1-307-857-4872 > > > -----Original Message----- > From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] > On Behalf Of Dan White > Sent: Monday, September 13, 2010 1:28 PM > To: Tim Howe > Cc: arin-discuss at arin.net > Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 > > On 13/09/10 12:01 -0700, Tim Howe wrote: >> On Mon, 13 Sep 2010 19:32:33 +0100 >> wrote: >> >>>> If I assigned a customer say an IPV4 /21 in IPV6 this would translate >>>> into a /56? If I'm not mistaken a /56 would translate into something >>>> like 65,000 host addresses? That just seems like a lot of hosts to me, >>> Anyone in this position should simply assign a /48 to every customer site >>> no matter how big or small. A one bedroom apartment gets a /48. A > manufacturing >>> plant with 5 buildings including a 4-story office block, gets a /48. >>> No exceptions. >> This is slightly different than I have been led to think... It >> seems wise, when you know the customer has no intention of having >> multiple networks, to provide a /64. Not because you fear wasting > Consider a long range scenario for that customer. A scenario in which they > may purchase networking equipment for multiple purposes in 5 or 10, or 20 > years that performs layer two separation between different functions in > their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, visitor > access, alarm system, automobiles, utilities, etc. > > I find it benefitial to consider that I probably don't know what a > customer's network will look like in 20 years, and a /48 per customer is > probably wisest until we've gained more operational experience with IPv6 in > our own network. > > > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at netwright.net Mon Sep 13 16:52:01 2010 From: mike at netwright.net (Mike Lieberman) Date: Mon, 13 Sep 2010 14:52:01 -0600 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> Message-ID: <0a8401cb5385$839d48f0$8ad7dad0$@net> We run VoIP over NAT today and while there is a learning curve it is manageable. Make a mistake in NAT'ed network and NAT will save you in-spite of yourself. Make a mistake in Public IP and you are potentially sunk. As an advocate for the end user - even when it makes my job harder.... NAT isn't evil. Network Engineers who expect all consumers to be knowledgeable are evil. We need to employ technologies that are safe even when used badly. Public addresses on residences fails the test. It's nice that some of you trust public institutions to always behave and do right. Do I offend you that you are in the aggregate in the extreme minority? -----Original Message----- From: Matthew S. Crocker [mailto:matthew at crocker.com] Sent: Monday, September 13, 2010 2:44 PM To: Mike Lieberman Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] Trying to Understand IPV6 In short because NAT is evil. Customers don't normally have a clue what NAT means or if it actually provides security or not. A properly configured home IPv6 appliance can provide the same levels of security without NAT. Stateful packet inspection and real IPv6 addresses on all devices is far superior to NATted IPv4 NAT is the bane of my existence as a VoIP provider. If only my phones supported IPv6... -Matt ----- Original Message ----- > From: "Mike Lieberman" > To: arin-discuss at arin.net > Sent: Monday, September 13, 2010 4:17:37 PM > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > I have been reading all these discussions (mostly silently) for a > long, long > time. I understand what a /48 is and a /56, /64 and /128. I understand > the > notation. > > Quite frankly what I don't get is why anyone thinks that consumers > want > public numbers inside their home/LANs. Once my customers understood > the > benefit of hiding behind a NAT, they embraced it quite emphatically. > > Put a private residence on public IPv6? Sorry but that makes no sense. > > > Yes I agree that I don't know what people will need in 20 years. And > YES it > is nice that we will have address space in 20 years. But allocating a > /48 to > a home that today uses an IPv4 /30 with a private NAT seems beyond > humorous. > It just sounds insane. Using private addressing that home already > potentially has access thousands of subnets and millions of addresses. > > > RFC 4193 provides even more addresses for use with firewall/NAT > appliances. > Why does a home or business using RFC 4193 need a /48 or even a /56 or > /64. > > Just because we have the numbers does not mean we should distribute > them. > > > _________________________ > Mike Lieberman, President > Net Wright LLC > Tel: +1-307-857-4898 > Fax: +1-307-857-4872 > > > -----Original Message----- > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net] > On Behalf Of Dan White > Sent: Monday, September 13, 2010 1:28 PM > To: Tim Howe > Cc: arin-discuss at arin.net > Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 > > On 13/09/10 12:01 -0700, Tim Howe wrote: > >On Mon, 13 Sep 2010 19:32:33 +0100 > > wrote: > > > >> > If I assigned a customer say an IPV4 /21 in IPV6 this would > translate > >> > into a /56? If I'm not mistaken a /56 would translate into > something > >> > like 65,000 host addresses? That just seems like a lot of hosts > to me, > >> > >> Anyone in this position should simply assign a /48 to every > customer site > >> no matter how big or small. A one bedroom apartment gets a /48. A > manufacturing > >> plant with 5 buildings including a 4-story office block, gets a > /48. > >> No exceptions. > > > > This is slightly different than I have been led to think... It > >seems wise, when you know the customer has no intention of having > >multiple networks, to provide a /64. Not because you fear wasting > > Consider a long range scenario for that customer. A scenario in which > they > may purchase networking equipment for multiple purposes in 5 or 10, or > 20 > years that performs layer two separation between different functions > in > their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, > visitor > access, alarm system, automobiles, utilities, etc. > > I find it benefitial to consider that I probably don't know what a > customer's network will look like in 20 years, and a /48 per customer > is > probably wisest until we've gained more operational experience with > IPv6 in > our own network. > > -- > Dan White > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: > 09/13/10 > 00:35:00 > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: 09/13/10 00:35:00 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4208 bytes Desc: not available URL: From nate.lyon at nfldwifi.net Mon Sep 13 16:57:16 2010 From: nate.lyon at nfldwifi.net (Nathaniel B. Lyon) Date: Mon, 13 Sep 2010 15:57:16 -0500 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a8401cb5385$839d48f0$8ad7dad0$@net> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> Message-ID: <24F349B8030E5A47A8BDC2FE0E13D13E03F9916228@nfldnet6.NFLDWIFI.LOCAL> We are starting to NAT customers behind our modem/CPE. We used to be a fully bridged network, and now are handing the IP to the CPE and NAT'ing the customer behind our CPE's. Much more secure. That's for sure. NAT'ing isn't all evil, but NAT'ing 500 - 1000 customers behind 1 IP isn't the best of ideas. IMO -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Mike Lieberman Sent: Monday, September 13, 2010 3:52 PM To: 'Matthew S. Crocker' Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] Trying to Understand IPV6 We run VoIP over NAT today and while there is a learning curve it is manageable. Make a mistake in NAT'ed network and NAT will save you in-spite of yourself. Make a mistake in Public IP and you are potentially sunk. As an advocate for the end user - even when it makes my job harder.... NAT isn't evil. Network Engineers who expect all consumers to be knowledgeable are evil. We need to employ technologies that are safe even when used badly. Public addresses on residences fails the test. It's nice that some of you trust public institutions to always behave and do right. Do I offend you that you are in the aggregate in the extreme minority? -----Original Message----- From: Matthew S. Crocker [mailto:matthew at crocker.com] Sent: Monday, September 13, 2010 2:44 PM To: Mike Lieberman Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] Trying to Understand IPV6 In short because NAT is evil. Customers don't normally have a clue what NAT means or if it actually provides security or not. A properly configured home IPv6 appliance can provide the same levels of security without NAT. Stateful packet inspection and real IPv6 addresses on all devices is far superior to NATted IPv4 NAT is the bane of my existence as a VoIP provider. If only my phones supported IPv6... -Matt ----- Original Message ----- > From: "Mike Lieberman" > To: arin-discuss at arin.net > Sent: Monday, September 13, 2010 4:17:37 PM > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > I have been reading all these discussions (mostly silently) for a > long, long time. I understand what a /48 is and a /56, /64 and /128. I > understand the notation. > > Quite frankly what I don't get is why anyone thinks that consumers > want public numbers inside their home/LANs. Once my customers > understood the benefit of hiding behind a NAT, they embraced it quite > emphatically. > > Put a private residence on public IPv6? Sorry but that makes no sense. > > > Yes I agree that I don't know what people will need in 20 years. And > YES it is nice that we will have address space in 20 years. But > allocating a > /48 to > a home that today uses an IPv4 /30 with a private NAT seems beyond > humorous. > It just sounds insane. Using private addressing that home already > potentially has access thousands of subnets and millions of addresses. > > > RFC 4193 provides even more addresses for use with firewall/NAT > appliances. > Why does a home or business using RFC 4193 need a /48 or even a /56 or > /64. > > Just because we have the numbers does not mean we should distribute > them. > > > _________________________ > Mike Lieberman, President > Net Wright LLC > Tel: +1-307-857-4898 > Fax: +1-307-857-4872 > > > -----Original Message----- > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net] > On Behalf Of Dan White > Sent: Monday, September 13, 2010 1:28 PM > To: Tim Howe > Cc: arin-discuss at arin.net > Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 > > On 13/09/10 12:01 -0700, Tim Howe wrote: > >On Mon, 13 Sep 2010 19:32:33 +0100 > > wrote: > > > >> > If I assigned a customer say an IPV4 /21 in IPV6 this would > translate > >> > into a /56? If I'm not mistaken a /56 would translate into > something > >> > like 65,000 host addresses? That just seems like a lot of hosts > to me, > >> > >> Anyone in this position should simply assign a /48 to every > customer site > >> no matter how big or small. A one bedroom apartment gets a /48. A > manufacturing > >> plant with 5 buildings including a 4-story office block, gets a > /48. > >> No exceptions. > > > > This is slightly different than I have been led to think... It > >seems wise, when you know the customer has no intention of having > >multiple networks, to provide a /64. Not because you fear wasting > > Consider a long range scenario for that customer. A scenario in which > they may purchase networking equipment for multiple purposes in 5 or > 10, or 20 years that performs layer two separation between different > functions in their network. E.g. Wifi, Bluetooth/USB, appliances, > voice, video, visitor access, alarm system, automobiles, utilities, > etc. > > I find it benefitial to consider that I probably don't know what a > customer's network will look like in 20 years, and a /48 per customer > is probably wisest until we've gained more operational experience with > IPv6 in > our own network. > > -- > Dan White > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to the ARIN > Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: > 09/13/10 > 00:35:00 > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to the ARIN > Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: 09/13/10 00:35:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3132 - Release Date: 09/13/10 01:35:00 From mksmith at adhost.com Mon Sep 13 17:02:29 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 13 Sep 2010 14:02:29 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a4e01cb5380$b539e260$1fada720$@net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com><20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> Message-ID: <17838240D9A5544AAA5FF95F8D52031608C90D2A@ad-exh01.adhost.lan> > -----Original Message----- > From: arin-discuss-bounces at arin.net [mailto:arin-discuss- > bounces at arin.net] On Behalf Of Mike Lieberman > Sent: Monday, September 13, 2010 1:18 PM > To: arin-discuss at arin.net > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > I have been reading all these discussions (mostly silently) for a long, long > time. I understand what a /48 is and a /56, /64 and /128. I understand the > notation. > > Quite frankly what I don't get is why anyone thinks that consumers want > public numbers inside their home/LANs. Once my customers understood > the > benefit of hiding behind a NAT, they embraced it quite emphatically. > > Put a private residence on public IPv6? Sorry but that makes no sense. Why not have valid addresses all the way through? There is nothing that a stateful firewall does now that it cannot do without the NAT component. We've all been told that NAT adds security but it's not the NAT that does that, it's the firewall (and there are arguments there as well, but that's another thread). NAT obfuscates internal hosts and allows you to overload internal addresses onto a scarce outside resource - the IPv4 address(es) you have from your upstream. With IPv6 we don't *have* to NAT. But, if you want to NAT, you still can. We actually have one scenario where we NAT from one /64 of our ARIN-assigned space to multiple /64's of our ARIN-assigned space to use the load-balancing functionality of PF. At the end of the day, they're just addresses. Inside, outside, whatever. If you want to have a virtual wall between some inside and outside resource at Layer 3, you can. Given that some huge percentage of miscreant traffic uses exploits at Layer 7, I just don't see that it buys you much. > > Yes I agree that I don't know what people will need in 20 years. And YES it > is nice that we will have address space in 20 years. But allocating a /48 to > a home that today uses an IPv4 /30 with a private NAT seems beyond > humorous. > It just sounds insane. Using private addressing that home already > potentially has access thousands of subnets and millions of addresses. > > RFC 4193 provides even more addresses for use with firewall/NAT > appliances. > Why does a home or business using RFC 4193 need a /48 or even a /56 or /64. > > Just because we have the numbers does not mean we should distribute > them. > It's a paradigm shift, to be sure. But, the concept of 1:1 mapping of an address to a "thing" (be it a server, toaster, etc.) is one that is specific to IPv4. If you want to apply IPv4 concepts to your IPv6 network then you certainly can, although you have to be careful because some implementations may not be agreeable to a prefix longer than a /64, and all of the auto-configuration stuff goes out the window as well. I'm hoping for a day where every device in my house that has power has an address that provides some useful function to me - primarily in cost savings. Hopefully we'll get there during my lifetime. But, if we continue fighting IPv6 based upon its differences from IPv4, then it probably won't. Regards, Mike From matthew at crocker.com Mon Sep 13 17:05:15 2010 From: matthew at crocker.com (Matthew S. Crocker) Date: Mon, 13 Sep 2010 17:05:15 -0400 (EDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <774361542.374272.1284411815252.JavaMail.root@zimbra1.crocker.com> Message-ID: <640167645.374288.1284411915207.JavaMail.root@zimbra1.crocker.com> ----- Original Message ----- > From: "Mike Lieberman" > To: "Matthew S. Crocker" > Cc: arin-discuss at arin.net > Sent: Monday, September 13, 2010 4:52:01 PM > Subject: RE: [arin-discuss] Trying to Understand IPV6 > > We run VoIP over NAT today and while there is a learning curve it is > manageable. Yes it is manageable, My Acme SD does a wonderful job gluing the RTP streams together. With IPv6 endpoints we wouldn't need to hairpin the RTP streams. > > Make a mistake in NAT'ed network and NAT will save you in-spite of > yourself. > Make a mistake in Public IP and you are potentially sunk. > Customers manage to find the viruses just fine on their own, even behind NAT. I don't think IPv6 to the desktop is going to change that. > As an advocate for the end user - even when it makes my job harder.... > NAT > isn't evil. Network Engineers who expect all consumers to be > knowledgeable are > evil. We need to employ technologies that are safe even when used > badly. > Public addresses on residences fails the test. > Properly configured network devices with a centralized device management/config/firmware server could be a service a competent ISP would provide. End users don't need to be knowledgeable if their provider does their job. My end users don't manage their Phone config files or firmware, why would I have them manage their firewall? > It's nice that some of you trust public institutions to always behave > and do > right. AAAAH, so that is the real issue, you are afraid that 'Big Brother' will spy on your IPv6 enabled computer. Do you really think that NAT stops that? Backdoors in your NAT router? Viruses that poke holes in your NAT router? It is all possible and quite easily do-able. NAT doesn't offer any real security. > Do I offend you that you are in the aggregate in the extreme minority? uh, huh? > > -----Original Message----- > From: Matthew S. Crocker [mailto:matthew at crocker.com] > Sent: Monday, September 13, 2010 2:44 PM > To: Mike Lieberman > Cc: arin-discuss at arin.net > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > > > In short because NAT is evil. Customers don't normally have a clue > what NAT > means or if it actually provides security or not. A properly > configured home > IPv6 appliance can provide the same levels of security without NAT. > Stateful > packet inspection and real IPv6 addresses on all devices is far > superior to > NATted IPv4 > > NAT is the bane of my existence as a VoIP provider. If only my phones > > supported IPv6... > > -Matt > > ----- Original Message ----- > > > From: "Mike Lieberman" > > To: arin-discuss at arin.net > > Sent: Monday, September 13, 2010 4:17:37 PM > > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > > > I have been reading all these discussions (mostly silently) for a > > long, long > > time. I understand what a /48 is and a /56, /64 and /128. I > understand > > the > > notation. > > > > Quite frankly what I don't get is why anyone thinks that consumers > > want > > public numbers inside their home/LANs. Once my customers > understood > > the > > benefit of hiding behind a NAT, they embraced it quite > emphatically. > > > > Put a private residence on public IPv6? Sorry but that makes no > sense. > > > > > > Yes I agree that I don't know what people will need in 20 years. > And > > YES it > > is nice that we will have address space in 20 years. But allocating > a > > /48 to > > a home that today uses an IPv4 /30 with a private NAT seems beyond > > humorous. > > It just sounds insane. Using private addressing that home already > > potentially has access thousands of subnets and millions of > addresses. > > > > > > RFC 4193 provides even more addresses for use with firewall/NAT > > appliances. > > Why does a home or business using RFC 4193 need a /48 or even a /56 > or > > /64. > > > > Just because we have the numbers does not mean we should distribute > > them. > > > > > > _________________________ > > Mike Lieberman, President > > Net Wright LLC > > Tel: +1-307-857-4898 > > Fax: +1-307-857-4872 > > > > > > -----Original Message----- > > From: arin-discuss-bounces at arin.net > > [mailto:arin-discuss-bounces at arin.net] > > On Behalf Of Dan White > > Sent: Monday, September 13, 2010 1:28 PM > > To: Tim Howe > > Cc: arin-discuss at arin.net > > Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 > > > > On 13/09/10 12:01 -0700, Tim Howe wrote: > > >On Mon, 13 Sep 2010 19:32:33 +0100 > > > wrote: > > > > > >> > If I assigned a customer say an IPV4 /21 in IPV6 this would > > translate > > >> > into a /56? If I'm not mistaken a /56 would translate into > > something > > >> > like 65,000 host addresses? That just seems like a lot of > hosts > > to me, > > >> > > >> Anyone in this position should simply assign a /48 to every > > customer site > > >> no matter how big or small. A one bedroom apartment gets a /48. > A > > manufacturing > > >> plant with 5 buildings including a 4-story office block, gets a > > /48. > > >> No exceptions. > > > > > > This is slightly different than I have been led to think... It > > >seems wise, when you know the customer has no intention of having > > >multiple networks, to provide a /64. Not because you fear wasting > > > > Consider a long range scenario for that customer. A scenario in > which > > they > > may purchase networking equipment for multiple purposes in 5 or 10, > or > > 20 > > years that performs layer two separation between different > functions > > in > > their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, > > visitor > > access, alarm system, automobiles, utilities, etc. > > > > I find it benefitial to consider that I probably don't know what a > > customer's network will look like in 20 years, and a /48 per > customer > > is > > probably wisest until we've gained more operational experience with > > IPv6 in > > our own network. > > > > -- > > Dan White > > _______________________________________________ > > ARIN-Discuss > > You are receiving this message because you are subscribed to > > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-discuss > > Please contact info at arin.net if you experience any issues. > > No virus found in this incoming message. > > Checked by AVG - www.avg.com > > Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: > > 09/13/10 > > 00:35:00 > > > > _______________________________________________ > > ARIN-Discuss > > You are receiving this message because you are subscribed to > > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-discuss > > Please contact info at arin.net if you experience any issues. > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: > 09/13/10 > 00:35:00 From Tim.McCracken at KAMOPower.com Mon Sep 13 17:01:32 2010 From: Tim.McCracken at KAMOPower.com (Tim McCracken) Date: Mon, 13 Sep 2010 16:01:32 -0500 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> Message-ID: <5B283D97E14585459278D7345D04A20B62034368@Mail.kamopower.local> I agree completely. As I recall, NAT was created primarily to slow the exhaustion of IpV4 addresses, which it did very well. However it causes numerous other problems. Since address exhaustion should not be a problem with IpV6, its time to get rid of NAT. The protection it provided was very limited at the time, and is more or less completely obsolete today with the more sophisticated hacking techniques. Tim McCracken IT Director KAMO Power -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Matthew S. Crocker Sent: Monday, September 13, 2010 3:44 PM To: Mike Lieberman Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] Trying to Understand IPV6 In short because NAT is evil. Customers don't normally have a clue what NAT means or if it actually provides security or not. A properly configured home IPv6 appliance can provide the same levels of security without NAT. Stateful packet inspection and real IPv6 addresses on all devices is far superior to NATted IPv4 NAT is the bane of my existence as a VoIP provider. If only my phones supported IPv6... -Matt ----- Original Message ----- > From: "Mike Lieberman" > To: arin-discuss at arin.net > Sent: Monday, September 13, 2010 4:17:37 PM > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > I have been reading all these discussions (mostly silently) for a > long, long time. I understand what a /48 is and a /56, /64 and /128. I > understand the notation. > > Quite frankly what I don't get is why anyone thinks that consumers > want public numbers inside their home/LANs. Once my customers > understood the benefit of hiding behind a NAT, they embraced it quite > emphatically. > > Put a private residence on public IPv6? Sorry but that makes no sense. > > > Yes I agree that I don't know what people will need in 20 years. And > YES it is nice that we will have address space in 20 years. But > allocating a > /48 to > a home that today uses an IPv4 /30 with a private NAT seems beyond > humorous. > It just sounds insane. Using private addressing that home already > potentially has access thousands of subnets and millions of addresses. > > > RFC 4193 provides even more addresses for use with firewall/NAT > appliances. > Why does a home or business using RFC 4193 need a /48 or even a /56 or > /64. > > Just because we have the numbers does not mean we should distribute > them. > > > _________________________ > Mike Lieberman, President > Net Wright LLC > Tel: +1-307-857-4898 > Fax: +1-307-857-4872 > > > -----Original Message----- > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net] > On Behalf Of Dan White > Sent: Monday, September 13, 2010 1:28 PM > To: Tim Howe > Cc: arin-discuss at arin.net > Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 > > On 13/09/10?12:01?-0700, Tim Howe wrote: > >On Mon, 13 Sep 2010 19:32:33 +0100 > > wrote: > > > >> > If I assigned a customer say an IPV4 /21 in IPV6 this would > translate > >> > into a /56? If I'm not mistaken a /56 would translate into > something > >> > like 65,000 host addresses? That just seems like a lot of hosts > to me, > >> > >> Anyone in this position should simply assign a /48 to every > customer site > >> no matter how big or small. A one bedroom apartment gets a /48. A > manufacturing > >> plant with 5 buildings including a 4-story office block, gets a > /48. > >> No exceptions. > > > > This is slightly different than I have been led to think... It > >seems wise, when you know the customer has no intention of having > >multiple networks, to provide a /64. Not because you fear wasting > > Consider a long range scenario for that customer. A scenario in which > they may purchase networking equipment for multiple purposes in 5 or > 10, or > 20 > years that performs layer two separation between different functions > in their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, > visitor access, alarm system, automobiles, utilities, etc. > > I find it benefitial to consider that I probably don't know what a > customer's network will look like in 20 years, and a /48 per customer > is probably wisest until we've gained more operational experience with > IPv6 in > our own network. > > -- > Dan White > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to the ARIN > Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: > 09/13/10 > 00:35:00 > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to the ARIN > Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. From mike at netwright.net Mon Sep 13 17:13:15 2010 From: mike at netwright.net (Mike Lieberman) Date: Mon, 13 Sep 2010 15:13:15 -0600 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <968208847.374244.1284411684734.JavaMail.root@zimbra1.crocker.com> References: <0a8401cb5385$839d48f0$8ad7dad0$@net> <968208847.374244.1284411684734.JavaMail.root@zimbra1.crocker.com> Message-ID: <0a9401cb5388$7b848090$728d81b0$@net> Matthew! Good heavens, no technology is the panacea. Yes with NAT/CiscoASA5500/and AV software my 12 yo daughter does a fine job of making a mess on her PC... But to suggest that NATs don't knock down a huge amount of unwanted traffic is simply unrealistic. Stateful firewalls can only knock down what they are looking for. Yes proper rules the in/out traffic with internal public IP can work nicely, but they are far more susceptible to really bad results if done wrong... Good solutions are the ones that continue to provide better protection were improperly implemented. Murphy was an optimist. The Average residence has no IT knowledge under the roof. Our network designs should always assume that. Public IP fails that test to the residential end user. -----Original Message----- From: Matthew S. Crocker [mailto:matthew at corp.crocker.com] Sent: Monday, September 13, 2010 3:01 PM To: Mike Lieberman Cc: arin-discuss at arin.net; Matthew S. Crocker Subject: Re: [arin-discuss] Trying to Understand IPV6 > From: "Mike Lieberman" > To: "Matthew S. Crocker" > Cc: arin-discuss at arin.net > Sent: Monday, September 13, 2010 4:52:01 PM > Subject: RE: [arin-discuss] Trying to Understand IPV6 > > We run VoIP over NAT today and while there is a learning curve it is > manageable. Yes it is manageable, My Acme SD does a wonderful job gluing the RTP streams together. With IPv6 endpoints we wouldn't need to hairpin the RTP streams. > Make a mistake in NAT'ed network and NAT will save you in-spite of > yourself. > Make a mistake in Public IP and you are potentially sunk. Customers manage to find the viruses just fine on their own, even behind NAT. I don't think IPv6 to the desktop is going to change that. > > As an advocate for the end user - even when it makes my job harder.... > NAT > isn't evil. Network Engineers who expect all consumers to be > knowledgeable are > evil. We need to employ technologies that are safe even when used > badly. > Public addresses on residences fails the test. Properly configured network devices with a centralized device management/config/firmware server could be a service a competent ISP would provide. End users don't need to be knowledgeable if their provider does their job. My end users don't manage their Phone config files or firmware, why would I have them manage their firewall? > > It's nice that some of you trust public institutions to always behave > and do > right. AAAAH, so that is the real issue, you are afraid that 'Big Brother' will spy on your IPv6 enabled computer. Do you really think that NAT stops that? Backdoors in your NAT router? Viruses that poke holes in your NAT router? It is all possible and quite easily do-able. NAT doesn't offer any real security. >Do I offend you that you are in the aggregate in the extreme minority? Huh? > > -----Original Message----- > From: Matthew S. Crocker [mailto:matthew at crocker.com] > Sent: Monday, September 13, 2010 2:44 PM > To: Mike Lieberman > Cc: arin-discuss at arin.net > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > > > In short because NAT is evil. Customers don't normally have a clue > what NAT > means or if it actually provides security or not. A properly > configured home > IPv6 appliance can provide the same levels of security without NAT. > Stateful > packet inspection and real IPv6 addresses on all devices is far > superior to > NATted IPv4 > > NAT is the bane of my existence as a VoIP provider. If only my phones > > supported IPv6... > > -Matt > > ----- Original Message ----- > > > From: "Mike Lieberman" > > To: arin-discuss at arin.net > > Sent: Monday, September 13, 2010 4:17:37 PM > > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > > > I have been reading all these discussions (mostly silently) for a > > long, long > > time. I understand what a /48 is and a /56, /64 and /128. I > understand > > the > > notation. > > > > Quite frankly what I don't get is why anyone thinks that consumers > > want > > public numbers inside their home/LANs. Once my customers > understood > > the > > benefit of hiding behind a NAT, they embraced it quite > emphatically. > > > > Put a private residence on public IPv6? Sorry but that makes no > sense. > > > > > > Yes I agree that I don't know what people will need in 20 years. > And > > YES it > > is nice that we will have address space in 20 years. But allocating > a > > /48 to > > a home that today uses an IPv4 /30 with a private NAT seems beyond > > humorous. > > It just sounds insane. Using private addressing that home already > > potentially has access thousands of subnets and millions of > addresses. > > > > > > RFC 4193 provides even more addresses for use with firewall/NAT > > appliances. > > Why does a home or business using RFC 4193 need a /48 or even a /56 > or > > /64. > > > > Just because we have the numbers does not mean we should distribute > > them. > > > > > > _________________________ > > Mike Lieberman, President > > Net Wright LLC > > Tel: +1-307-857-4898 > > Fax: +1-307-857-4872 > > > > > > -----Original Message----- > > From: arin-discuss-bounces at arin.net > > [mailto:arin-discuss-bounces at arin.net] > > On Behalf Of Dan White > > Sent: Monday, September 13, 2010 1:28 PM > > To: Tim Howe > > Cc: arin-discuss at arin.net > > Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 > > > > On 13/09/10 12:01 -0700, Tim Howe wrote: > > >On Mon, 13 Sep 2010 19:32:33 +0100 > > > wrote: > > > > > >> > If I assigned a customer say an IPV4 /21 in IPV6 this would > > translate > > >> > into a /56? If I'm not mistaken a /56 would translate into > > something > > >> > like 65,000 host addresses? That just seems like a lot of > hosts > > to me, > > >> > > >> Anyone in this position should simply assign a /48 to every > > customer site > > >> no matter how big or small. A one bedroom apartment gets a /48. > A > > manufacturing > > >> plant with 5 buildings including a 4-story office block, gets a > > /48. > > >> No exceptions. > > > > > > This is slightly different than I have been led to think... It > > >seems wise, when you know the customer has no intention of having > > >multiple networks, to provide a /64. Not because you fear wasting > > > > Consider a long range scenario for that customer. A scenario in > which > > they > > may purchase networking equipment for multiple purposes in 5 or 10, > or > > 20 > > years that performs layer two separation between different > functions > > in > > their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, > > visitor > > access, alarm system, automobiles, utilities, etc. > > > > I find it benefitial to consider that I probably don't know what a > > customer's network will look like in 20 years, and a /48 per > customer > > is > > probably wisest until we've gained more operational experience with > > IPv6 in > > our own network. > > > > -- > > Dan White > > _______________________________________________ > > ARIN-Discuss > > You are receiving this message because you are subscribed to > > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-discuss > > Please contact info at arin.net if you experience any issues. > > No virus found in this incoming message. > > Checked by AVG - www.avg.com > > Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: > > 09/13/10 > > 00:35:00 > > > > _______________________________________________ > > ARIN-Discuss > > You are receiving this message because you are subscribed to > > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-discuss > > Please contact info at arin.net if you experience any issues. > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: > 09/13/10 > 00:35:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: 09/13/10 00:35:00 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4208 bytes Desc: not available URL: From dwhite at olp.net Mon Sep 13 17:18:52 2010 From: dwhite at olp.net (Dan White) Date: Mon, 13 Sep 2010 16:18:52 -0500 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <956B9AF7-01D5-4C74-8003-A20DFC037116@delong.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <956B9AF7-01D5-4C74-8003-A20DFC037116@delong.com> Message-ID: <20100913211852.GC2625@dan.olp.net> On 13/09/10?12:48?-0700, Owen DeLong wrote: >> Consider a long range scenario for that customer. A scenario in which they >> may purchase networking equipment for multiple purposes in 5 or 10, or 20 >> years that performs layer two separation between different functions in >> their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, visitor >> access, alarm system, automobiles, utilities, etc. >> >I think you mean layer three separation. Well, by extension. I do really mean layer two separation as a way to force layer three separation, like with VLAN per subscriber configurations you can do with Cisco Wifi gear. If I had the equipment and addressing to support it today, I'd firewall many devices into their own broadcast domain and subnet, especially any opaque devices I don't have source code to. I don't think it's going to be very long at all before do-it-yourselfers at home, running a consumer wifi router, are going to see the same type of complex network growth seen in small to medium sized business networks today. I predict per-device layer two separation to be one, of many, solutions to address that level of complexity in consumer gear. -- Dan White From farmer at umn.edu Mon Sep 13 17:28:21 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 13 Sep 2010 16:28:21 -0500 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> References: <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> Message-ID: <4C8E9775.8020108@umn.edu> On 9/13/10 15:44 CDT, Matthew S. Crocker wrote: > > > In short because NAT is evil. Customers don't normally have a clue what NAT means or if it actually provides security or not. A properly configured home IPv6 appliance can provide the same levels of security without NAT. Stateful packet inspection and real IPv6 addresses on all devices is far superior to NATted IPv4 Can we please not have another thread go down the NAT vs. no-NAT argument drain. > NAT is the bane of my existence as a VoIP provider. If only my phones supported IPv6... While I tend to agree with the no-NAT camp personally. IPv6 transition cannot afford to be bogged down by NAT v. no-NAT. It is a bad idea for IPv6 to require a no-NAT network design. > -Matt > > ----- Original Message ----- > >> From: "Mike Lieberman" >> To: arin-discuss at arin.net >> Sent: Monday, September 13, 2010 4:17:37 PM >> Subject: Re: [arin-discuss] Trying to Understand IPV6 >> >> I have been reading all these discussions (mostly silently) for a >> long, long >> time. I understand what a /48 is and a /56, /64 and /128. I understand >> the >> notation. >> >> Quite frankly what I don't get is why anyone thinks that consumers >> want >> public numbers inside their home/LANs. Once my customers understood >> the >> benefit of hiding behind a NAT, they embraced it quite emphatically. >> >> Put a private residence on public IPv6? Sorry but that makes no sense. >> >> >> Yes I agree that I don't know what people will need in 20 years. And >> YES it >> is nice that we will have address space in 20 years. But allocating a >> /48 to >> a home that today uses an IPv4 /30 with a private NAT seems beyond >> humorous. >> It just sounds insane. Using private addressing that home already >> potentially has access thousands of subnets and millions of addresses. Standardization and one-size fits all has a number of technical, logistical and marketing advantages in many fields of endeavor, assigning /48s to sites IPv6 is just following that well understood idea and bringing it into the networking world. >> RFC 4193 provides even more addresses for use with firewall/NAT >> appliances. >> Why does a home or business using RFC 4193 need a /48 or even a /56 or >> /64. RFC 4193, provides a locally assigned /48, by providing a /48 public assignment this allows a 1-to-1 NAT gateway to be used, this can be implemented fully stateful or stateless. So even if your customers plan to implement NAT in IPv6, there are advantages to assigning /48s to all sites. >> Just because we have the numbers does not mean we should distribute >> them. What are you going to do with them then? You can't eat them. :) Take a look at Owen's analysis earlier in the thread. While it may not seem like it, /48 is actually a relatively conservative amount of address space to give to a site. Remember there are 128 bits to work with, a /48 in IPv6 is about 6 orders of magnitude more conservative than a /29 in IPv4. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Mon Sep 13 17:26:57 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Sep 2010 14:26:57 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a4e01cb5380$b539e260$1fada720$@net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> Message-ID: On Sep 13, 2010, at 1:17 PM, Mike Lieberman wrote: > I have been reading all these discussions (mostly silently) for a long, long > time. I understand what a /48 is and a /56, /64 and /128. I understand the > notation. > > Quite frankly what I don't get is why anyone thinks that consumers want > public numbers inside their home/LANs. Once my customers understood the > benefit of hiding behind a NAT, they embraced it quite emphatically. > Really? Wow, once my customers have understood the advantages of having public addresses, they have thoroughly bemoaned the limitations imposed by NAT. > Put a private residence on public IPv6? Sorry but that makes no sense. > It makes a lot of sense. Stateful inspection has useful advantages and consumers definitely should be behind stateful firewalls. However, there is absolutely no advantage whatsoever to reducing them to NAT. > Yes I agree that I don't know what people will need in 20 years. And YES it > is nice that we will have address space in 20 years. But allocating a /48 to > a home that today uses an IPv4 /30 with a private NAT seems beyond humorous. Why? > It just sounds insane. Using private addressing that home already > potentially has access thousands of subnets and millions of addresses. > Right, but, they have no option of using their cellphone to log into the refrigerator from the grocery store and find out what they are running low on. They can't put up a public web cam without engaging some third party to proxy traffic for them. They can't run a home PBX solution without registering it with some third-party SIP proxy in order to receive calls. The list of limitations goes on and on and on. On the other hand, the list of advantages provided by NAT (not the firewall, NAT itself) is short... Here it is: See... Very short. > RFC 4193 provides even more addresses for use with firewall/NAT appliances. > Why does a home or business using RFC 4193 need a /48 or even a /56 or /64. > RFC 4193 provides no way for those addresses to communicate with the rest of the internet. They are LOCAL addresses for local use. There is no NAT in IPv6. > Just because we have the numbers does not mean we should distribute them. > What better purpose can they possibly serve not being distributed? Owen From jradel at vantage.com Mon Sep 13 17:28:55 2010 From: jradel at vantage.com (Jon Radel) Date: Mon, 13 Sep 2010 17:28:55 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a9401cb5388$7b848090$728d81b0$@net> References: <0a8401cb5385$839d48f0$8ad7dad0$@net> <968208847.374244.1284411684734.JavaMail.root@zimbra1.crocker.com> <0a9401cb5388$7b848090$728d81b0$@net> Message-ID: <4C8E9797.5060905@vantage.com> On 9/13/10 5:13 PM, Mike Lieberman wrote: > Matthew! Good heavens, no technology is the panacea. Yes with > NAT/CiscoASA5500/and AV software my 12 yo daughter does a fine job of making a > mess on her PC... But to suggest that NATs don't knock down a huge amount of > unwanted traffic is simply unrealistic. > > Stateful firewalls can only knock down what they are looking for. Yes proper > rules the in/out traffic with internal public IP can work nicely, but they are > far more susceptible to really bad results if done wrong... You'd be amazed what people with SOHO routers can do to circumvent NAT. Not too long ago I worked with a very annoyed VOIP customer who wanted to know why his phone kept ringing with wrong numbers and weird caller ids. Turns out he thought it would be a useful thing to port forward all SIP traffic arriving at the outside interface to his phone. So much for NAT. > Good solutions are the ones that continue to provide better protection were > improperly implemented. Some believe that good solutions are those where the benefits outweigh the costs, not simply those where there is some benefit. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3648 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Mon Sep 13 17:51:11 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Sep 2010 14:51:11 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a9401cb5388$7b848090$728d81b0$@net> References: <0a8401cb5385$839d48f0$8ad7dad0$@net> <968208847.374244.1284411684734.JavaMail.root@zimbra1.crocker.com> <0a9401cb5388$7b848090$728d81b0$@net> Message-ID: On Sep 13, 2010, at 2:13 PM, Mike Lieberman wrote: > Matthew! Good heavens, no technology is the panacea. Yes with > NAT/CiscoASA5500/and AV software my 12 yo daughter does a fine job of making a > mess on her PC... But to suggest that NATs don't knock down a huge amount of > unwanted traffic is simply unrealistic. > > Stateful firewalls can only knock down what they are looking for. Yes proper > rules the in/out traffic with internal public IP can work nicely, but they are > far more susceptible to really bad results if done wrong... > Huh? No. A properly configured stateful firewall knocks down everything that isn't a specifically permitted flow. NAT doesn't knock down anything other than by preventing you from permitting inbound flows (or at least adding a couple of hoops to that process). There's nothing security-wise in NAT that isn't available in stateful inspection. > Good solutions are the ones that continue to provide better protection were > improperly implemented. > By this line of thinking, the best solution is to merely remove the power supply. There is always a tradeoff between functionality and reliability. > Murphy was an optimist. The Average residence has no IT knowledge under the > roof. Our network designs should always assume that. Public IP fails that test > to the residential end user. > And a stateful inspection firewall with a default-deny-all-inbound policy does exactly the same job here that you are claiming NAT does on today's IPv4 boxes. No difference. If the user chooses to change that configuration on their own firewall, then, they are choosing to change their risk profile. That should be up to the user. Just as doctors are not allowed to inflict treatment on patients contrary to the patients wishes, the network should not limit a users choice of permitted network applications without the users consent. Owen > > -----Original Message----- > From: Matthew S. Crocker [mailto:matthew at corp.crocker.com] > Sent: Monday, September 13, 2010 3:01 PM > To: Mike Lieberman > Cc: arin-discuss at arin.net; Matthew S. Crocker > Subject: Re: [arin-discuss] Trying to Understand IPV6 > >> From: "Mike Lieberman" >> To: "Matthew S. Crocker" >> Cc: arin-discuss at arin.net >> Sent: Monday, September 13, 2010 4:52:01 PM >> Subject: RE: [arin-discuss] Trying to Understand IPV6 >> >> We run VoIP over NAT today and while there is a learning curve it is >> manageable. > > Yes it is manageable, My Acme SD does a wonderful job gluing the RTP streams > together. With IPv6 endpoints we wouldn't need to hairpin the RTP streams. > >> Make a mistake in NAT'ed network and NAT will save you in-spite of >> yourself. >> Make a mistake in Public IP and you are potentially sunk. > > Customers manage to find the viruses just fine on their own, even behind NAT. > I don't think IPv6 to the desktop is going to change that. > > >> >> As an advocate for the end user - even when it makes my job harder.... >> NAT >> isn't evil. Network Engineers who expect all consumers to be >> knowledgeable are >> evil. We need to employ technologies that are safe even when used >> badly. >> Public addresses on residences fails the test. > > Properly configured network devices with a centralized device > management/config/firmware server could be a service a competent ISP would > provide. End users don't need to be knowledgeable if their provider does > their job. > > My end users don't manage their Phone config files or firmware, why would I > have them manage their firewall? > >> >> It's nice that some of you trust public institutions to always behave >> and do >> right. > > AAAAH, so that is the real issue, you are afraid that 'Big Brother' will spy > on your IPv6 enabled computer. Do you really think that NAT stops that? > Backdoors in your NAT router? Viruses that poke holes in your NAT router? It > is all possible and quite easily do-able. NAT doesn't offer any real > security. > >> Do I offend you that you are in the aggregate in the extreme minority? > > Huh? > >> >> -----Original Message----- >> From: Matthew S. Crocker [mailto:matthew at crocker.com] >> Sent: Monday, September 13, 2010 2:44 PM >> To: Mike Lieberman >> Cc: arin-discuss at arin.net >> Subject: Re: [arin-discuss] Trying to Understand IPV6 >> >> >> >> In short because NAT is evil. Customers don't normally have a clue >> what NAT >> means or if it actually provides security or not. A properly >> configured home >> IPv6 appliance can provide the same levels of security without NAT. >> Stateful >> packet inspection and real IPv6 addresses on all devices is far >> superior to >> NATted IPv4 >> >> NAT is the bane of my existence as a VoIP provider. If only my phones >> >> supported IPv6... >> >> -Matt >> >> ----- Original Message ----- >> >>> From: "Mike Lieberman" >>> To: arin-discuss at arin.net >>> Sent: Monday, September 13, 2010 4:17:37 PM >>> Subject: Re: [arin-discuss] Trying to Understand IPV6 >>> >>> I have been reading all these discussions (mostly silently) for a >>> long, long >>> time. I understand what a /48 is and a /56, /64 and /128. I >> understand >>> the >>> notation. >>> >>> Quite frankly what I don't get is why anyone thinks that consumers >>> want >>> public numbers inside their home/LANs. Once my customers >> understood >>> the >>> benefit of hiding behind a NAT, they embraced it quite >> emphatically. >>> >>> Put a private residence on public IPv6? Sorry but that makes no >> sense. >>> >>> >>> Yes I agree that I don't know what people will need in 20 years. >> And >>> YES it >>> is nice that we will have address space in 20 years. But allocating >> a >>> /48 to >>> a home that today uses an IPv4 /30 with a private NAT seems beyond >>> humorous. >>> It just sounds insane. Using private addressing that home already >>> potentially has access thousands of subnets and millions of >> addresses. >>> >>> >>> RFC 4193 provides even more addresses for use with firewall/NAT >>> appliances. >>> Why does a home or business using RFC 4193 need a /48 or even a /56 >> or >>> /64. >>> >>> Just because we have the numbers does not mean we should distribute >>> them. >>> >>> >>> _________________________ >>> Mike Lieberman, President >>> Net Wright LLC >>> Tel: +1-307-857-4898 >>> Fax: +1-307-857-4872 >>> >>> >>> -----Original Message----- >>> From: arin-discuss-bounces at arin.net >>> [mailto:arin-discuss-bounces at arin.net] >>> On Behalf Of Dan White >>> Sent: Monday, September 13, 2010 1:28 PM >>> To: Tim Howe >>> Cc: arin-discuss at arin.net >>> Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 >>> >>> On 13/09/10 12:01 -0700, Tim Howe wrote: >>>> On Mon, 13 Sep 2010 19:32:33 +0100 >>>> wrote: >>>> >>>>>> If I assigned a customer say an IPV4 /21 in IPV6 this would >>> translate >>>>>> into a /56? If I'm not mistaken a /56 would translate into >>> something >>>>>> like 65,000 host addresses? That just seems like a lot of >> hosts >>> to me, >>>>> >>>>> Anyone in this position should simply assign a /48 to every >>> customer site >>>>> no matter how big or small. A one bedroom apartment gets a /48. >> A >>> manufacturing >>>>> plant with 5 buildings including a 4-story office block, gets a >>> /48. >>>>> No exceptions. >>>> >>>> This is slightly different than I have been led to think... It >>>> seems wise, when you know the customer has no intention of having >>>> multiple networks, to provide a /64. Not because you fear wasting >>> >>> Consider a long range scenario for that customer. A scenario in >> which >>> they >>> may purchase networking equipment for multiple purposes in 5 or 10, >> or >>> 20 >>> years that performs layer two separation between different >> functions >>> in >>> their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, >>> visitor >>> access, alarm system, automobiles, utilities, etc. >>> >>> I find it benefitial to consider that I probably don't know what a >>> customer's network will look like in 20 years, and a /48 per >> customer >>> is >>> probably wisest until we've gained more operational experience with >>> IPv6 in >>> our own network. >>> >>> -- >>> Dan White >>> _______________________________________________ >>> ARIN-Discuss >>> You are receiving this message because you are subscribed to >>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-discuss >>> Please contact info at arin.net if you experience any issues. >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: >>> 09/13/10 >>> 00:35:00 >>> >>> _______________________________________________ >>> ARIN-Discuss >>> You are receiving this message because you are subscribed to >>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-discuss >>> Please contact info at arin.net if you experience any issues. >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: >> 09/13/10 >> 00:35:00 > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: 09/13/10 > 00:35:00 > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From dwhite at olp.net Mon Sep 13 18:29:25 2010 From: dwhite at olp.net (Dan White) Date: Mon, 13 Sep 2010 17:29:25 -0500 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a4e01cb5380$b539e260$1fada720$@net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> Message-ID: <20100913222925.GD2625@dan.olp.net> On 13/09/10?14:17?-0600, Mike Lieberman wrote: >Quite frankly what I don't get is why anyone thinks that consumers want >public numbers inside their home/LANs. Once my customers understood the >benefit of hiding behind a NAT, they embraced it quite emphatically. There are many benefits, but one benefit that really hits at the heart of NAT is ip address namespace collisions. I expect to see lots of services pop-up in a post NAT world where 3rd party vendors are supplying appliances to my customers that have no need for internet access per se, only in so far as to establish an IPSec connection to that 3rd party vendor's network to provide a service. Assigning unique addressing to devices in a network can have benefits beyond public access to that device. >Just because we have the numbers does not mean we should distribute them. That actually sounds pretty risky to me, as a business decision, in a competitive service provider environment. -- Dan White From alan at peak.org Mon Sep 13 18:49:36 2010 From: alan at peak.org (Alan Batie) Date: Mon, 13 Sep 2010 15:49:36 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100913222925.GD2625@dan.olp.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> <20100913222925.GD2625@dan.olp.net> Message-ID: <4C8EAA80.4040300@peak.org> On 9/13/10 11:32 AM, michael.dillon at bt.com wrote: > Anyone in this position should simply assign a /48 to every customer site > no matter how big or small. A one bedroom apartment gets a /48. A manufacturing > plant with 5 buildings including a 4-story office block, gets a /48. > No exceptions. > > Later, when you have learned more, you might want to shift to only give > a /56 to residential customers if there is a good business reason, but > you are more likely to conclude that there is only a reason for large > ISPs to introduce this complexity. I like to have my cake and eat it to: if you give /48, it's gone. If you give /56, using 1 bits from the left (reserving the first 4 bits: 1 customer block, 1 us block, 14 in reserve), you have a sparse allocation that, if the customer needs /48, you can easily expand them into by shrinking the netmask. Eventually the bits from the left will run into the bits from the right, but by that time, we'll have a lot more experience with the subject. If we need more /56's, we'll have them. Up until that point, if people turn out to need /48's (or more!), no problem. From alan at peak.org Mon Sep 13 18:48:19 2010 From: alan at peak.org (Alan Batie) Date: Mon, 13 Sep 2010 15:48:19 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: References: <0a8401cb5385$839d48f0$8ad7dad0$@net> <968208847.374244.1284411684734.JavaMail.root@zimbra1.crocker.com> <0a9401cb5388$7b848090$728d81b0$@net> Message-ID: <4C8EAA33.3000606@peak.org> On 9/13/10 2:51 PM, Owen DeLong wrote: > There's nothing security-wise in NAT that isn't available in stateful inspection. except fail-safety. It's inherent in the way NAT works that incoming connections are blocked unless you specifically do something to forward them. A stateful firewall router is a router. It may be implemented with default rules to block incoming connections, but that is an active activity that, if it fails for some reason, opens you up. I'm in favor of banishing NAT also, but recognize that the home router vendors really need take care that it is clear and obvious when and which incoming connections are permitted, and to have some hoops to jump to do it. In general, get us as close to the NAT default as possible. From mike at netwright.net Mon Sep 13 19:02:26 2010 From: mike at netwright.net (Mike Lieberman) Date: Mon, 13 Sep 2010 17:02:26 -0600 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100913222925.GD2625@dan.olp.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> <20100913222925.GD2625@dan.olp.net> Message-ID: <0b0201cb5397$bb7d9dd0$3278d970$@net> Dan, Huh? I never suggested we should restrict giving out addresses that were requested, only that a /48 of public IP to my 96yo mother who is quite happy with her NAT'ed little IP world make no sense. -----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: Monday, September 13, 2010 4:29 PM To: Mike Lieberman Cc: arin-discuss at arin.net Subject: Re: Trying to Understand IPV6 >Just because we have the numbers does not mean we should distribute them. That actually sounds pretty risky to me, as a business decision, in a competitive service provider environment. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4208 bytes Desc: not available URL: From owen at delong.com Mon Sep 13 19:23:44 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Sep 2010 16:23:44 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8EAA80.4040300@peak.org> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> <20100913222925.GD2625@dan.olp.net> <4C8EAA80.4040300@peak.org> Message-ID: <0B68D603-5AA8-4834-8426-A52AEAE7144B@delong.com> On Sep 13, 2010, at 3:49 PM, Alan Batie wrote: > On 9/13/10 11:32 AM, michael.dillon at bt.com wrote: > >> Anyone in this position should simply assign a /48 to every customer site >> no matter how big or small. A one bedroom apartment gets a /48. A > manufacturing >> plant with 5 buildings including a 4-story office block, gets a /48. >> No exceptions. >> >> Later, when you have learned more, you might want to shift to only give >> a /56 to residential customers if there is a good business reason, but >> you are more likely to conclude that there is only a reason for large >> ISPs to introduce this complexity. > > I like to have my cake and eat it to: if you give /48, it's gone. If > you give /56, using 1 bits from the left (reserving the first 4 bits: 1 > customer block, 1 us block, 14 in reserve), you have a sparse allocation > that, if the customer needs /48, you can easily expand them into by > shrinking the netmask. Eventually the bits from the left will run into > the bits from the right, but by that time, we'll have a lot more > experience with the subject. If we need more /56's, we'll have them. Up > until that point, if people turn out to need /48's (or more!), no problem. > This is a really horrible approach... Yes, if you give a /48, it's gone. So what? If you need more /48s, then, get another /32 or even a shorter than /32 prefix. Really... There's plenty of space to do this for quite a while and still not even use 0.2% of the first 1/8th of the IPv6 address space. For sparse allocation, allocate your /48s by bisection... Customers (in order of allocation): Internal: XXXX:XXXX:0000::/48 First: XXXX:XXXX:8000::/48 Second: XXXX:XXXX:4000::/48 Third: XXXX:XXXX:C000::/48 Fourth: XXXX:XXXX:2000::/48 Fifth: XXXX:XXXX:6000::/48 Sixth: XXXX:XXXX:A000::/48 Seventh: XXXX:XXXX:E000::/48 Eighth: XXXX:XXXX:1000::/48 Ninth: XXXX:XXXX:3000::/48 ... Fifteenth: XXXX:XXXX:f000::/48 16th: XXXX:XXXX:0800::/48 17th: XXXX:XXXX:1800::/48 ... 31st: XXXX:XXXX:f800::/48 32nd: XXXX:XXXX:0400::/48 33rd: XXXX:XXXX:0C00::/48 34th: XXXX:XXXX:1400::/48 35th: XXXX:XXXX:1C00::/48 ... 63rd: XXXX:XXXX:fC00::/48 64th: XXXX:XXXX:0200::/48 65th: XXXX:XXXX:0600::/48 ... As you can see, you get lots and lots and lots of customers installed before they get packed with any level of density. Specifically, you get 255 customers installed before you have to put any of them close enough that they can't all be expanded to 256 /48s (a /40). You get 4095 customers installed before you have to worry about any of them not being able to expand to a /44. You can have your cake and eat it too without complicating your network as you describe. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 13 19:30:07 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Sep 2010 16:30:07 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0b0201cb5397$bb7d9dd0$3278d970$@net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> <20100913222925.GD2625@dan.olp.net> <0b0201cb5397$bb7d9dd0$3278d970$@net> Message-ID: On Sep 13, 2010, at 4:02 PM, Mike Lieberman wrote: > Dan, > Huh? I never suggested we should restrict giving out addresses that were > requested, only that a /48 of public IP to my 96yo mother who is quite happy > with her NAT'ed little IP world make no sense. > It will make a lot more sense when her NAT'ed little IPv4 world stops being able to reach a meaningful proportion of new sites that are IPv6 only, she'll probably want at least some form of IPv6 capability. Will she ever adapt to wanting to be able to use her cell phone to query the stock levels in the fridge? Probably not. However, your 90 year old mother is a very small minority of IP consumers. The majority, especially over time, will actually want these kinds of innovations to be available to them and for those people, a /48 makes perfect sense. Owen > -----Original Message----- > From: Dan White [mailto:dwhite at olp.net] > Sent: Monday, September 13, 2010 4:29 PM > To: Mike Lieberman > Cc: arin-discuss at arin.net > Subject: Re: Trying to Understand IPV6 > >> Just because we have the numbers does not mean we should distribute them. > > That actually sounds pretty risky to me, as a business decision, in a > competitive service provider environment. > > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From dwhite at olp.net Mon Sep 13 19:38:25 2010 From: dwhite at olp.net (Dan White) Date: Mon, 13 Sep 2010 18:38:25 -0500 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0b0201cb5397$bb7d9dd0$3278d970$@net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> <20100913222925.GD2625@dan.olp.net> <0b0201cb5397$bb7d9dd0$3278d970$@net> Message-ID: <20100913233825.GF2625@dan.olp.net> >-----Original Message----- >From: Dan White [mailto:dwhite at olp.net] >Sent: Monday, September 13, 2010 4:29 PM >To: Mike Lieberman >Cc: arin-discuss at arin.net >Subject: Re: Trying to Understand IPV6 > >>Just because we have the numbers does not mean we should distribute them. > >That actually sounds pretty risky to me, as a business decision, in a >competitive service provider environment. On 13/09/10?17:02?-0600, Mike Lieberman wrote: >Dan, >Huh? I never suggested we should restrict giving out addresses that were >requested, only that a /48 of public IP to my 96yo mother who is quite happy >with her NAT'ed little IP world make no sense. And I'm not referring to what a customer asks for, the day you turn IPv6 up for them, but rather what's going to break down the road because you may have been short sighted in your address allocation, or encouraged them to use NAT with IPv6 ("I don't know why I would really need that many addresses!"). When your 96yo mother happens to order a service-in-a-box from some remote provider, and it breaks because she's using NAT, or she doesn't have unique addressing, then she's either going to call you and tell you to fix her connection (because the box didn't work on your ISP and that service-in-a-box vendor told her it was your fault), or she's just going to go with another provider because "I have so many problems with your service and I just want it to work." I've actually had a glimpse of this type of response from customers who can't, say, make a VPN connection back to some server in Dallas, and were told their local service provider was at fault. In such a scenario, I feel confident that the problem is not with us, since we don't do port blocking, and don't NAT. We do offer a NAT'd router inside a modem for customers who don't have their own router, but that's not a configuration we recommend, and it's not typical of these types of customers any way. -- Dan White From rs at seastrom.com Mon Sep 13 20:48:59 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 13 Sep 2010 20:48:59 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a8401cb5385$839d48f0$8ad7dad0$@net> (Mike Lieberman's message of "Mon, 13 Sep 2010 14:52:01 -0600") References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> Message-ID: <86hbhtm9ok.fsf@seastrom.com> "Mike Lieberman" writes: > We run VoIP over NAT today and while there is a learning curve it is > manageable. When you run VoIP over public addresses, the learning curve for NAT-related issues is gone. Sure, you still need to open up the proper ports in the firewall. Funny how easy that gets when there is no STUN or uPNP in the fray. Might even be something that you click on, as a common configuration option - the following addresses... oh wait, the following SUBNET (you got 64k of them) is VoIP phones, open the normal ports for them. Almost no configuration necessary. > Make a mistake in NAT'ed network and NAT will save you in-spite of yourself. > Make a mistake in Public IP and you are potentially sunk. See below. > As an advocate for the end user - even when it makes my job > harder.... NAT isn't evil. Network Engineers who expect all > consumers to be knowledgeable are evil. We need to employ > technologies that are safe even when used badly. Public addresses > on residences fails the test. It's funny to see juxtaposition of "VoIP learning curves", "firewall configuration mistakes", and then a justification for NAT to save unsophisticated folks (the unsophisticated folks who are hacking their router to support VoIP and forget "deny ipv6 any any", no doubt). Quite the mental gymnastic there. My mom is gonna click on the "I just installed a Vonage VoIP phone and a Kelvinator SodaProbe V6" buttons, not edit rulesets. And the firewall will default to "no inbound traffic". Just like your NAT router. We agree that the default configurations and likely failure modes for network hardware ought to be maximally safe. NAT creates a nice illusion of improved safety. Doesn't help much against dirty web sites, email, and PDFs... in short, 99% of the issues out there today, but hey, it *looks* safer right? > It's nice that some of you trust public institutions to always behave and do > right. Do I offend you that you are in the aggregate in the extreme minority? Huh? Non-sequiteur there. -r From tlmiller at onlyinternet.net Mon Sep 13 20:57:36 2010 From: tlmiller at onlyinternet.net (Terry Miller) Date: Mon, 13 Sep 2010 20:57:36 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100913233825.GF2625@dan.olp.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net><20100913120150.94bb573c.tim.h@bendtel.com><20100913192745.GA2625@dan.olp.net><0a4e01cb5380$b539e260$1fada720$@net><20100913222925.GD2625@dan.olp.net><0b0201cb5397$bb7d9dd0$3278d970$@net> <20100913233825.GF2625@dan.olp.net> Message-ID: <6599E18629E44E16B2D27CA63028B25C@owner11ed70125> I think NAT should remain an available tool to network administrators. This includes all types of nat. When an organization is allocated a block from us as a provider or if we receive an allocation from one of our up stream providers, what do we do when said customer or we wish to switch from one provider to another? Without nat, the entire organization will have to renumber every host that is allocated a routable ipv6 address. Such an organization could use 1:1 nat to rectify the issue but it still means that said organization must use nat. The same organization could use DNS but there are still the issues with DNS as well, especially when you start changing the IP addresses of your DNS servers as part of the same process. I do not see the need for nat overloading but do not think that such should not be an available tool. Gabriel Selig -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Dan White Sent: Monday, September 13, 2010 7:38 PM To: Mike Lieberman Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] Trying to Understand IPV6 >-----Original Message----- >From: Dan White [mailto:dwhite at olp.net] >Sent: Monday, September 13, 2010 4:29 PM >To: Mike Lieberman >Cc: arin-discuss at arin.net >Subject: Re: Trying to Understand IPV6 > >>Just because we have the numbers does not mean we should distribute them. > >That actually sounds pretty risky to me, as a business decision, in a >competitive service provider environment. On 13/09/10?17:02?-0600, Mike Lieberman wrote: >Dan, >Huh? I never suggested we should restrict giving out addresses that were >requested, only that a /48 of public IP to my 96yo mother who is quite happy >with her NAT'ed little IP world make no sense. And I'm not referring to what a customer asks for, the day you turn IPv6 up for them, but rather what's going to break down the road because you may have been short sighted in your address allocation, or encouraged them to use NAT with IPv6 ("I don't know why I would really need that many addresses!"). When your 96yo mother happens to order a service-in-a-box from some remote provider, and it breaks because she's using NAT, or she doesn't have unique addressing, then she's either going to call you and tell you to fix her connection (because the box didn't work on your ISP and that service-in-a-box vendor told her it was your fault), or she's just going to go with another provider because "I have so many problems with your service and I just want it to work." I've actually had a glimpse of this type of response from customers who can't, say, make a VPN connection back to some server in Dallas, and were told their local service provider was at fault. In such a scenario, I feel confident that the problem is not with us, since we don't do port blocking, and don't NAT. We do offer a NAT'd router inside a modem for customers who don't have their own router, but that's not a configuration we recommend, and it's not typical of these types of customers any way. -- Dan White _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. From alan at peak.org Mon Sep 13 20:59:34 2010 From: alan at peak.org (Alan Batie) Date: Mon, 13 Sep 2010 17:59:34 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0B68D603-5AA8-4834-8426-A52AEAE7144B@delong.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> <20100913222925.GD2625@dan.olp.net> <4C8EAA80.4040300@peak.org> <0B68D603-5AA8-4834-8426-A52AEAE7144B@delong.com> Message-ID: <4C8EC8F6.4050105@peak.org> On 9/13/10 4:23 PM, Owen DeLong wrote: > This is a really horrible approach... Yes, if you give a /48, it's > gone. So what? > > If you need more /48s, then, get another /32 or even a shorter than > /32 prefix. One of the apparent goals is to *avoid* going back to the bar for another block, though I believe the registries are doing the same sort of thing for the same reason: that way it will be *possible* to get a "shorter than /32" > For sparse allocation, allocate your /48s by bisection... same idea, just moving the left edge and doing slightly more complicated math. I should say digits rather than bits though, as it simplifies thinking about it: 1xxx: customers 1000:: 1100:: 1200:: 1300:: ... 1010:: 1020:: ... 1110:: 1120:: From owen at delong.com Mon Sep 13 21:27:20 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Sep 2010 18:27:20 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8EC8F6.4050105@peak.org> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> <20100913222925.GD2625@dan.olp.net> <4C8EAA80.4040300@peak.org> <0B68D603-5AA8-4834-8426-A52AEAE7144B@delong.com> <4C8EC8F6.4050105@peak.org> Message-ID: On Sep 13, 2010, at 5:59 PM, Alan Batie wrote: > On 9/13/10 4:23 PM, Owen DeLong wrote: > >> This is a really horrible approach... Yes, if you give a /48, it's >> gone. So what? >> >> If you need more /48s, then, get another /32 or even a shorter than >> /32 prefix. > > One of the apparent goals is to *avoid* going back to the bar for > another block, though I believe the registries are doing the same sort > of thing for the same reason: that way it will be *possible* to get a > "shorter than /32" > Correct... The RIRs are doing allocation by bisection. >> For sparse allocation, allocate your /48s by bisection... > > same idea, just moving the left edge and doing slightly more complicated > math. > Except it eliminates the whole right-bits/left-bits thinking and becomes pretty straightforward and easy to automate. Also, since you aren't doing variable-length allocations, you don't have to worry about fragmentation. > I should say digits rather than bits though, as it simplifies thinking > about it: > Well, this approach simplifies the human thinking until you start filling things in, but, comes at the disadvantage that you hit higher densities faster. > 1xxx: customers > 1000:: > 1100:: > 1200:: > 1300:: > ... > 1010:: > 1020:: > ... > 1110:: > 1120:: Owen From bicknell at ufp.org Mon Sep 13 21:00:49 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 13 Sep 2010 18:00:49 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <86hbhtm9ok.fsf@seastrom.com> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> Message-ID: <20100914010049.GB96567@ussenterprise.ufp.org> In a message written on Mon, Sep 13, 2010 at 08:48:59PM -0400, Robert E. Seastrom wrote: > proper ports in the firewall. Funny how easy that gets when there is > no STUN or uPNP in the fray. Might even be something that you click I don't think (but I'm not sure) that uPnP requires NAT. That is, I think a stateful firewall could implement uPnP and use it simply to unblock ports on request. I think for most consumers that's a good model. Your PS3 or other appliance like device can request the couple of ports it needs, and if you want to know you can log into your gateway and see waht a device requests, and/or deny a particular device such access. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From owen at delong.com Mon Sep 13 21:43:36 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Sep 2010 18:43:36 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100914010049.GB96567@ussenterprise.ufp.org> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <20100914010049.GB96567@ussenterprise.ufp.org> Message-ID: On Sep 13, 2010, at 6:00 PM, Leo Bicknell wrote: > In a message written on Mon, Sep 13, 2010 at 08:48:59PM -0400, Robert E. Seastrom wrote: >> proper ports in the firewall. Funny how easy that gets when there is >> no STUN or uPNP in the fray. Might even be something that you click > > I don't think (but I'm not sure) that uPnP requires NAT. That is, > I think a stateful firewall could implement uPnP and use it simply > to unblock ports on request. > Yes, that can be done. However, Rob's point was the problems caused by uPNP rather than the features it provides. > I think for most consumers that's a good model. Your PS3 or other > appliance like device can request the couple of ports it needs, and > if you want to know you can log into your gateway and see waht a > device requests, and/or deny a particular device such access. > It really isn't a fantastic model. Better would be to have a way for the firewall to get a request from the device, get user confirmation through some other form of challenge-response and make a quasi-permanent change. Owen From rs at seastrom.com Mon Sep 13 23:10:20 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 13 Sep 2010 23:10:20 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100914010049.GB96567@ussenterprise.ufp.org> (Leo Bicknell's message of "Mon, 13 Sep 2010 18:00:49 -0700") References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <20100914010049.GB96567@ussenterprise.ufp.org> Message-ID: <86bp81m34z.fsf@seastrom.com> Leo Bicknell writes: > In a message written on Mon, Sep 13, 2010 at 08:48:59PM -0400, Robert E. Seastrom wrote: >> proper ports in the firewall. Funny how easy that gets when there is >> no STUN or uPNP in the fray. Might even be something that you click > > I don't think (but I'm not sure) that uPnP requires NAT. That is, > I think a stateful firewall could implement uPnP and use it simply > to unblock ports on request. uPnP does not require NAT. > I think for most consumers that's a good model. Your PS3 or other > appliance like device can request the couple of ports it needs, and > if you want to know you can log into your gateway and see waht a > device requests, and/or deny a particular device such access. That's great if you completely trust your device. Malware on our computer asking for ports to be opened works Just Fine too. If you're running uPnP on your network, your firewall is not really controlling what is traversing it, as you're basically allowing untrusted users on your network to load arbitrary rulesets. -r From michael.dillon at bt.com Tue Sep 14 07:13:14 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 14 Sep 2010 12:13:14 +0100 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100913120150.94bb573c.tim.h@bendtel.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> > > Anyone in this position should simply assign a /48 to every customer > site > > no matter how big or small. A one bedroom apartment gets a /48. A > manufacturing > > plant with 5 buildings including a 4-story office block, gets a /48. > > No exceptions. > > This is slightly different than I have been led to think... It > seems wise, when you know the customer has no intention of having > multiple networks, to provide a /64. That is not wise, it is foolish. If you don't understand IPv6 then assign everyone a /48 and you cannot go wrong. But do take some time to study IPv6 and learn how it is vastly different from IPv4, especially when it comes to addressing architectures. Also, a little humility helps, i.e. how do you *KNOW* that a customer has no intention of having multiple networks within the next 10 years? Fact is that only in extremely special circumstances can you know this, for instance if you provide a wireless service for some sort of handset which you also supply, then perhaps a /64 assignment makes sense. Very, very few ISPs are in this position. > The IPv6 equiv to that would be a /64 connecting > range and another /64 range to use for their LAN. This has been my > plan That is an IPv4 plan, not an IPv6 plan. IPv6 is not just IPv4 with longer addresses, it has a very different idea of how addressing is done, and it intentionally wastes space to make sure that networks can be expanded at several levels without needing to change the addressing architecture. If you don't provide the slack, then you are breaking IPv6 and recreating the problems of IPv4. > Anyone wanting/needing multiple networks (or who even thinks they > might, and knows what a /48 is) can and should have a /48, no problem. > > I am just a small provider with mostly small business accounts > and colo, so maybe my situation isn't typical... It is very typical. /48 to every customer, no exceptions. If a customer wants less, assign them a /48 anyway and only tell them the first part of the prefix. When they get wiser, tell them the /48 that you "reserved" for them. The non-typical case is an ISP with very large numbers of residential customers (something like Comcast for instance) where it makes sense to assign /56 to private residences and /48 to everyone else. > /48 per customer with more than one network (so they can have /64 per > network) > > Is this flawed or no longer the prevailing way of thinking? The flaw is in thinking that a customer has only one network. Most folks these days have two, one wired and one wireless. They may not be using both, but it is there in the gateway router and they could turn on the second network any day now. Maybe Google TV will be what it takes to get them to add a wired network, maybe something else. Don't gamble on this. ARIN expects you to assign a /48 to everyone, and if you use less then you are only punishing yourself by increasing the complexity of your network and your management processes. --Michael Dillon From michael.dillon at bt.com Tue Sep 14 07:25:50 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 14 Sep 2010 12:25:50 +0100 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0a4e01cb5380$b539e260$1fada720$@net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5D0@EMV01-UKBR.domain1.systemhost.net> > Quite frankly what I don't get is why anyone thinks that consumers want > public numbers inside their home/LANs. Once my customers understood > the benefit of hiding behind a NAT, they embraced it quite > emphatically. Why do people want public phone numbers on their phones? So people can call them. Same reason applies for public addressing in their home networks only the devices receiving calls will be many and varied and unlike mere telephones. Security can be provided by firewalls and devices which do not want to receive calls ever, can use ULA addresses, e.g. printers. I fully expect that IPv6 firewalls will be standard on any home gateway device and that they will support a protocol which allows devices to tell the firewall what kind of incoming connections should be allowed. This capability will open the market for a whole series of home network appliances that were not possible before because of NAT. > But > allocating a /48 to a home that today uses an IPv4 /30 with a private > NAT seems beyond humorous. > It just sounds insane. You are 10 years too late for this discussion. And it appears that your IPv6 education could use some updating as well. Check out http://www.getipv6.info for pointers to various tutorials and documents to get your IPv6 knowledge up to date. > Using private addressing that home already > potentially has access thousands of subnets and millions of addresses. Sure, but using private addressing it has no access to the Internet or any network communications outside the local network. Give it a public /48 and it has both boundless addresses, and communication. > Just because we have the numbers does not mean we should distribute > them. You are 100% right on this point. ARIN does not distribute IPv6 addresses in these quantities just because we have them. ARIN distributes the addresses to enable IPv6 network communication in line with the architecture created by the IETF which requires vast numbers of extra addresses at several points in the hierarchy to both allow network expansion without readdressing, and to allow for various types of automatic addressing at the device level. --Michael Dillon From Ron at Cleven.com Tue Sep 14 09:49:04 2010 From: Ron at Cleven.com (Ron Cleven) Date: Tue, 14 Sep 2010 08:49:04 -0500 (CDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> Message-ID: <4C8F7D51.6060106@Cleven.com> I was with you right with you (assign /48 to every customer, no exceptions) up until you came up with the big-isp exception (assign /56 to private residences). Why would Comcast (using your example) customers get "only" a /56? Is there something wrong with the math (are big-isp's going to run out of /48's)? If it is ok for Comcast customers to get /56's, why isn't it ok for all other private residences to get /56's (what are the /56 customers giving up)? As usual, I am horribly confused. michael.dillon at bt.com wrote: > > >It is very typical. /48 to every customer, no exceptions. If a customer >wants less, assign them a /48 anyway and only tell them the first part >of the prefix. When they get wiser, tell them the /48 that you >"reserved" for them. > >The non-typical case is an ISP with very large numbers of residential >customers (something like Comcast for instance) where it makes sense >to assign /56 to private residences and /48 to everyone else. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbourgeois at cablesystem.com Tue Sep 14 10:23:49 2010 From: tbourgeois at cablesystem.com (Tom Bourgeois) Date: Tue, 14 Sep 2010 10:23:49 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8F7D51.6060106@Cleven.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com><0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> Message-ID: <17FF3DE6BB7DAF4D8E26E5F7DD5343BB0A212736@MAIL.buckeyehq.com> ________________________________ From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Ron Cleven Sent: Tuesday, September 14, 2010 9:49 AM To: arin-discuss at arin.net Subject: Re: [arin-discuss] Trying to Understand IPV6 I was with you right with you (assign /48 to every customer, no exceptions) up until you came up with the big-isp exception (assign /56 to private residences). Why would Comcast (using your example) customers get "only" a /56? Is there something wrong with the math (are big-isp's going to run out of /48's)? If it is ok for Comcast customers to get /56's, why isn't it ok for all other private residences to get /56's (what are the /56 customers giving up)? As usual, I am horribly confused. Ditto. We currently have around 115k residential data subs in addition to a few thousand business customers. Compared to the Comcasts, AT&Ts, and Time Warner's of the world we're definitely on the small side but if I give everyone a /48 then I guess I need to go back and get a couple more /32s soon. I guess I don't see the huge problem with aggregation on our local plant. michael.dillon at bt.com wrote: It is very typical. /48 to every customer, no exceptions. If a customer wants less, assign them a /48 anyway and only tell them the first part of the prefix. When they get wiser, tell them the /48 that you "reserved" for them. The non-typical case is an ISP with very large numbers of residential customers (something like Comcast for instance) where it makes sense to assign /56 to private residences and /48 to everyone else. From joelja at bogus.com Tue Sep 14 11:08:07 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Sep 2010 08:08:07 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: References: <0a8401cb5385$839d48f0$8ad7dad0$@net> <968208847.374244.1284411684734.JavaMail.root@zimbra1.crocker.com> <0a9401cb5388$7b848090$728d81b0$@net> Message-ID: <4C8F8FD7.7080600@bogus.com> On 9/13/10 2:51 PM, Owen DeLong wrote: > > On Sep 13, 2010, at 2:13 PM, Mike Lieberman wrote: > >> Matthew! Good heavens, no technology is the panacea. Yes with >> NAT/CiscoASA5500/and AV software my 12 yo daughter does a fine job of making a >> mess on her PC... But to suggest that NATs don't knock down a huge amount of >> unwanted traffic is simply unrealistic. >> >> Stateful firewalls can only knock down what they are looking for. Yes proper >> rules the in/out traffic with internal public IP can work nicely, but they are >> far more susceptible to really bad results if done wrong... >> > Huh? No. > > A properly configured stateful firewall knocks down everything that isn't a > specifically permitted flow. which it should be noted requires only one rule. deny all inbound not established From joelja at bogus.com Tue Sep 14 11:00:25 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Sep 2010 08:00:25 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8E8DC5.1020106@gmail.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <20100913192745.GA2625@dan.olp.net> <0a4e01cb5380$b539e260$1fada720$@net> <4C8E8DC5.1020106@gmail.com> Message-ID: <4C8F8E09.40309@bogus.com> On 9/13/10 1:47 PM, Scott Leibrand wrote: > On Mon 9/13/2010 1:17 PM, Mike Lieberman wrote: >> I have been reading all these discussions (mostly silently) for a long, long >> time. I understand what a /48 is and a /56, /64 and /128. I understand the >> notation. >> >> Quite frankly what I don't get is why anyone thinks that consumers want >> public numbers inside their home/LANs. Once my customers understood the >> benefit of hiding behind a NAT, they embraced it quite emphatically. > > Yes, the stateful firewall aspect of their NAT box is quite useful. I > suspect all IPv6-capable home routers will still run a stateful firewall > with a default-closed policy on incoming traffic. http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-12 >> Put a private residence on public IPv6? Sorry but that makes no sense. > > I'd like to be able to have my phone communicate with my home boxes, at > line rate, regardless of whether I'm on my home wi-fi, or out on someone > else's network. If both devices have public IPv6 addresses, I could > initiate a connection, in either direction, using IPsec to provide > end-to-end security, and ensure that everything is always instantly in > sync between the devices, without having to go through a server. > > Both Apple (with Bonjour) and Microsoft are doing a good job of getting > us back to seamless network device discovery and integration using IPv6 > link-local addresses on the local LAN. There's no reason as we deploy > v6 globally that we shouldn't be able to extend this across the > Internet. But if you implement v6 NAT, that's exactly the kind of > innovation you'd prevent. > >> Yes I agree that I don't know what people will need in 20 years. And YES it >> is nice that we will have address space in 20 years. But allocating a /48 to >> a home that today uses an IPv4 /30 with a private NAT seems beyond humorous. >> It just sounds insane. Using private addressing that home already >> potentially has access thousands of subnets and millions of addresses. >> >> RFC 4193 provides even more addresses for use with firewall/NAT appliances. >> Why does a home or business using RFC 4193 need a /48 or even a /56 or /64. >> >> Just because we have the numbers does not mean we should distribute them. > > Quite a few home networks run two SSIDs, one WPA2-encrypted for private > use, and one open for guests. Each of those should have its own /64. > That means I need at least a /56. > > -Scott > >> >> _________________________ >> Mike Lieberman, President >> Net Wright LLC >> Tel: +1-307-857-4898 >> Fax: +1-307-857-4872 >> >> >> -----Original Message----- >> From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] >> On Behalf Of Dan White >> Sent: Monday, September 13, 2010 1:28 PM >> To: Tim Howe >> Cc: arin-discuss at arin.net >> Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6 >> >> On 13/09/10 12:01 -0700, Tim Howe wrote: >>> On Mon, 13 Sep 2010 19:32:33 +0100 >>> wrote: >>> >>>>> If I assigned a customer say an IPV4 /21 in IPV6 this would translate >>>>> into a /56? If I'm not mistaken a /56 would translate into something >>>>> like 65,000 host addresses? That just seems like a lot of hosts to me, >>>> Anyone in this position should simply assign a /48 to every customer site >>>> no matter how big or small. A one bedroom apartment gets a /48. A >> manufacturing >>>> plant with 5 buildings including a 4-story office block, gets a /48. >>>> No exceptions. >>> This is slightly different than I have been led to think... It >>> seems wise, when you know the customer has no intention of having >>> multiple networks, to provide a /64. Not because you fear wasting >> Consider a long range scenario for that customer. A scenario in which they >> may purchase networking equipment for multiple purposes in 5 or 10, or 20 >> years that performs layer two separation between different functions in >> their network. E.g. Wifi, Bluetooth/USB, appliances, voice, video, visitor >> access, alarm system, automobiles, utilities, etc. >> >> I find it benefitial to consider that I probably don't know what a >> customer's network will look like in 20 years, and a /48 per customer is >> probably wisest until we've gained more operational experience with IPv6 in >> our own network. >> >> >> >> _______________________________________________ >> ARIN-Discuss >> You are receiving this message because you are subscribed to >> the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-discuss >> Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Sep 14 11:18:54 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 08:18:54 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8F7D51.6060106@Cleven.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> Message-ID: <9542ADEA-DC86-4E5F-89C5-C79381624C17@delong.com> FWIW, I don't agree with Michael about assigning /56s. I used to think that /56s for residences made sense. And in reality, most residences will be fine with 256 subnets. However, having now gotten some operational experience with IPv6 and having reviewed the math, I now believe there is no true rationale behind assigning /56s. Very large providers should seek to get larger blocks rather than accepting the default /32. Owen On Sep 14, 2010, at 6:49 AM, Ron Cleven wrote: > I was with you right with you (assign /48 to every customer, no exceptions) up until you came up with the big-isp exception (assign /56 to private residences). > > Why would Comcast (using your example) customers get "only" a /56? > > Is there something wrong with the math (are big-isp's going to run out of /48's)? > > If it is ok for Comcast customers to get /56's, why isn't it ok for all other private residences to get /56's (what are the /56 customers giving up)? > > As usual, I am horribly confused. > > > > michael.dillon at bt.com wrote: >> >> >> It is very typical. /48 to every customer, no exceptions. If a customer >> wants less, assign them a /48 anyway and only tell them the first part >> of the prefix. When they get wiser, tell them the /48 that you >> "reserved" for them. >> >> The non-typical case is an ISP with very large numbers of residential >> customers (something like Comcast for instance) where it makes sense >> to assign /56 to private residences and /48 to everyone else. >> >> > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 14 11:25:29 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 08:25:29 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <17FF3DE6BB7DAF4D8E26E5F7DD5343BB0A212736@MAIL.buckeyehq.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com><0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <17FF3DE6BB7DAF4D8E26E5F7DD5343BB0A212736@MAIL.buckeyehq.com> Message-ID: Tom, If you know you have 115k customers, you should request more than a /32 to begin with. Probably something approaching a 30 or a /29 under current policy. I am soon going to be drafting a policy proposal that supports the notion of rounding up to nibble boundaries in order to provide better guidance to ISPs on right-sizing their requests and also to provide better human factors engineering in the address space overall. Owen On Sep 14, 2010, at 7:23 AM, Tom Bourgeois wrote: > > > ________________________________ > > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Ron Cleven > Sent: Tuesday, September 14, 2010 9:49 AM > To: arin-discuss at arin.net > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > > I was with you right with you (assign /48 to every customer, no > exceptions) up until you came up with the big-isp exception (assign /56 > to private residences). > > Why would Comcast (using your example) customers get "only" a /56? > > Is there something wrong with the math (are big-isp's going to run out > of /48's)? > > If it is ok for Comcast customers to get /56's, why isn't it ok for all > other private residences to get /56's (what are the /56 customers giving > up)? > > As usual, I am horribly confused. > > Ditto. We currently have around 115k residential data subs in addition > to a few thousand business customers. Compared to the Comcasts, AT&Ts, > and Time Warner's of the world we're definitely on the small side but if > I give everyone a /48 then I guess I need to go back and get a couple > more /32s soon. I guess I don't see the huge problem with aggregation > on our local plant. > > michael.dillon at bt.com wrote: > > > > > It is very typical. /48 to every customer, no exceptions. If a > customer > wants less, assign them a /48 anyway and only tell them the > first part > of the prefix. When they get wiser, tell them the /48 that you > "reserved" for them. > > The non-typical case is an ISP with very large numbers of > residential > customers (something like Comcast for instance) where it makes > sense > to assign /56 to private residences and /48 to everyone else. > > > > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From tbourgeois at cablesystem.com Tue Sep 14 11:40:08 2010 From: tbourgeois at cablesystem.com (Tom Bourgeois) Date: Tue, 14 Sep 2010 11:40:08 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com><0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <17FF3DE6BB7DAF4D8E26E5F7DD5343BB0A212736@MAIL.buckeyehq.com> Message-ID: <17FF3DE6BB7DAF4D8E26E5F7DD5343BB0A212737@MAIL.buckeyehq.com> We've already received our first /32 allocation, I was thinking that this would be the last allocation we would ever need. Since we're a cable TV provider we are somewhat at the mercy of DOCSIS and CableLabs as to how v6 addresses will be distributed as well as the companies that create the provisioning software. I guess I need to start that discussion first with the provisioning software developers. Last I heard they were still about 6 months out (their estimate) from having anything to play with. Compared to our cable plant, the metro ethernet customers sound easy... A /64 on the WAN and a /48 on the LAN unless I'm missing something. -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, September 14, 2010 11:25 AM To: Tom Bourgeois Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] Trying to Understand IPV6 Tom, If you know you have 115k customers, you should request more than a /32 to begin with. Probably something approaching a 30 or a /29 under current policy. I am soon going to be drafting a policy proposal that supports the notion of rounding up to nibble boundaries in order to provide better guidance to ISPs on right-sizing their requests and also to provide better human factors engineering in the address space overall. Owen On Sep 14, 2010, at 7:23 AM, Tom Bourgeois wrote: > > > ________________________________ > > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Ron Cleven > Sent: Tuesday, September 14, 2010 9:49 AM > To: arin-discuss at arin.net > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > > I was with you right with you (assign /48 to every customer, no > exceptions) up until you came up with the big-isp exception (assign > /56 to private residences). > > Why would Comcast (using your example) customers get "only" a /56? > > Is there something wrong with the math (are big-isp's going to run out > of /48's)? > > If it is ok for Comcast customers to get /56's, why isn't it ok for > all other private residences to get /56's (what are the /56 customers > giving up)? > > As usual, I am horribly confused. > > Ditto. We currently have around 115k residential data subs in > addition to a few thousand business customers. Compared to the > Comcasts, AT&Ts, and Time Warner's of the world we're definitely on > the small side but if I give everyone a /48 then I guess I need to go > back and get a couple more /32s soon. I guess I don't see the huge > problem with aggregation on our local plant. > > michael.dillon at bt.com wrote: > > > > > It is very typical. /48 to every customer, no exceptions. If a > customer > wants less, assign them a /48 anyway and only tell them the first > part > of the prefix. When they get wiser, tell them the /48 that you > "reserved" for them. > > The non-typical case is an ISP with very large numbers of residential > customers (something like Comcast for instance) where it makes sense > to assign /56 to private residences and /48 to everyone else. > > > > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to the ARIN > Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From Ron at Cleven.com Tue Sep 14 12:22:56 2010 From: Ron at Cleven.com (Ron Cleven) Date: Tue, 14 Sep 2010 11:22:56 -0500 (CDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com><0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <17FF3DE6BB7DAF4D8E26E5F7DD5343BB0A212736@MAIL.buckeyehq.com> Message-ID: <4C8FA15F.5050307@Cleven.com> This was, of course, the point of my question. It would seem that whoever came up with the crazy scheme of 64bit subnets never thought about how many ISP's and customers there are.in the world. We could have accommodated all the ISP's in the universe each of whom could accommodate all the customers in the universe to ensure nobody would ever have to go back for more allocations. Is there a link that would describe "what is the reasoning (if any) behind the math?" More simply, it would seem to have been trivial to accommodate the idea of every ISP only ever needing one allocation, no matter what size they are. There was plenty of bits, which now appear to have been squandered by committee. Even more confused. Perhaps I am the only one. Owen DeLong wrote: >Tom, > >If you know you have 115k customers, you should request more >than a /32 to begin with. Probably something approaching a 30 >or a /29 under current policy. I am soon going to be drafting a policy >proposal that supports the notion of rounding up to nibble boundaries >in order to provide better guidance to ISPs on right-sizing their requests >and also to provide better human factors engineering in the address >space overall. > >Owen > >On Sep 14, 2010, at 7:23 AM, Tom Bourgeois wrote: > > > >>________________________________ >> >>From: arin-discuss-bounces at arin.net >>[mailto:arin-discuss-bounces at arin.net] On Behalf Of Ron Cleven >>Sent: Tuesday, September 14, 2010 9:49 AM >>To: arin-discuss at arin.net >>Subject: Re: [arin-discuss] Trying to Understand IPV6 >> >> >>I was with you right with you (assign /48 to every customer, no >>exceptions) up until you came up with the big-isp exception (assign /56 >>to private residences). >> >>Why would Comcast (using your example) customers get "only" a /56? >> >>Is there something wrong with the math (are big-isp's going to run out >>of /48's)? >> >>If it is ok for Comcast customers to get /56's, why isn't it ok for all >>other private residences to get /56's (what are the /56 customers giving >>up)? >> >>As usual, I am horribly confused. >> >>Ditto. We currently have around 115k residential data subs in addition >>to a few thousand business customers. Compared to the Comcasts, AT&Ts, >>and Time Warner's of the world we're definitely on the small side but if >>I give everyone a /48 then I guess I need to go back and get a couple >>more /32s soon. I guess I don't see the huge problem with aggregation >>on our local plant. >> >>michael.dillon at bt.com wrote: >> >> >> >> >> It is very typical. /48 to every customer, no exceptions. If a >>customer >> wants less, assign them a /48 anyway and only tell them the >>first part >> of the prefix. When they get wiser, tell them the /48 that you >> "reserved" for them. >> >> The non-typical case is an ISP with very large numbers of >>residential >> customers (something like Comcast for instance) where it makes >>sense >> to assign /56 to private residences and /48 to everyone else. >> >> >> >> >>_______________________________________________ >>ARIN-Discuss >>You are receiving this message because you are subscribed to >>the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >>Unsubscribe or manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/arin-discuss >>Please contact info at arin.net if you experience any issues. >> >> > >_______________________________________________ >ARIN-Discuss >You are receiving this message because you are subscribed to >the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-discuss >Please contact info at arin.net if you experience any issues. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spiffnolee at yahoo.com Tue Sep 14 12:16:46 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Tue, 14 Sep 2010 09:16:46 -0700 (PDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> Message-ID: <727349.13443.qm@web63302.mail.re1.yahoo.com> > It is very typical. /48 to every customer, no exceptions. If a customer > wants less, assign them a /48 anyway and only tell them the first part > of the prefix. When they get wiser, tell them the /48 that you > "reserved" for them. Depends on what kind of customers you have. If the bulk of your customers are residential, and you expect to assign them prefixes dynamically, then it is very likely you will only assign them a prefix of whatever length is hinted in their DHCPv6 request. You still have the policy decision of "what is the largest prefix request I will honor?" but that's a different question. If many of your customers are dial-up, you may decide that multiple subnets are unlikely, and default to a /64. For customers with statically-assigned prefixes, do whatever you want. Nibble-boundary prefixes are recommended (so you can delegate reverse DNS), and multiple /64s are encouraged. So, between /48 and /60, but you might make it easier on yourself to pick a prefix length and use the same for everyone. > Don't gamble on this. ARIN expects you to assign a /48 to everyone, and > if you use less then you are only punishing yourself by increasing the > complexity of your network and your management processes. s/expects/allows https://www.arin.net/policy/nrpm.html#six54 The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sitesand Subsequent IPv6 allocations, based on HD-Ratio in units of /56 assignments. Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcarpen at network1.net Tue Sep 14 12:19:57 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Sep 2010 12:19:57 -0400 (EDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <17FF3DE6BB7DAF4D8E26E5F7DD5343BB0A212737@MAIL.buckeyehq.com> Message-ID: <2052823951.5367.1284481197700.JavaMail.root@zimbra.network1.net> What are everyones' thoughts regarding dynamic versus static assignments for residential users? Our current plan is to use DHCPv6 with prefix delegation to auto-assign the WAN and LAN prefixes. In this scenario, we could easily change assignments without anyone having to touch any equipment. The big question is will that wreak havoc with customers' internal network if the addresses ever change? Static assignments for 10,000's of customers does not sound very appealing. Any other considerations? thanks, -Randy ----- Original Message ----- > We've already received our first /32 allocation, I was thinking that > this would be the last allocation we would ever need. Since we're a > cable TV provider we are somewhat at the mercy of DOCSIS and CableLabs > as to how v6 addresses will be distributed as well as the companies > that > create the provisioning software. I guess I need to start that > discussion first with the provisioning software developers. Last I > heard they were still about 6 months out (their estimate) from having > anything to play with. Compared to our cable plant, the metro ethernet > customers sound easy... A /64 on the WAN and a /48 on the LAN unless > I'm > missing something. > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, September 14, 2010 11:25 AM > To: Tom Bourgeois > Cc: arin-discuss at arin.net > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > Tom, > > If you know you have 115k customers, you should request more than a > /32 > to begin with. Probably something approaching a 30 or a /29 under > current policy. I am soon going to be drafting a policy proposal that > supports the notion of rounding up to nibble boundaries in order to > provide better guidance to ISPs on right-sizing their requests and > also > to provide better human factors engineering in the address space > overall. > > Owen > > On Sep 14, 2010, at 7:23 AM, Tom Bourgeois wrote: > > > > > > > ________________________________ > > > > From: arin-discuss-bounces at arin.net > > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Ron Cleven > > Sent: Tuesday, September 14, 2010 9:49 AM > > To: arin-discuss at arin.net > > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > > > > > I was with you right with you (assign /48 to every customer, no > > exceptions) up until you came up with the big-isp exception (assign > > /56 to private residences). > > > > Why would Comcast (using your example) customers get "only" a /56? > > > > Is there something wrong with the math (are big-isp's going to run > > out > > > of /48's)? > > > > If it is ok for Comcast customers to get /56's, why isn't it ok for > > all other private residences to get /56's (what are the /56 > > customers > > giving up)? > > > > As usual, I am horribly confused. > > > > Ditto. We currently have around 115k residential data subs in > > addition to a few thousand business customers. Compared to the > > Comcasts, AT&Ts, and Time Warner's of the world we're definitely on > > the small side but if I give everyone a /48 then I guess I need to > > go > > back and get a couple more /32s soon. I guess I don't see the huge > > problem with aggregation on our local plant. > > > > michael.dillon at bt.com wrote: From owen at delong.com Tue Sep 14 13:11:11 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 10:11:11 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8F8FD7.7080600@bogus.com> References: <0a8401cb5385$839d48f0$8ad7dad0$@net> <968208847.374244.1284411684734.JavaMail.root@zimbra1.crocker.com> <0a9401cb5388$7b848090$728d81b0$@net> <4C8F8FD7.7080600@bogus.com> Message-ID: On Sep 14, 2010, at 8:08 AM, Joel Jaeggli wrote: > On 9/13/10 2:51 PM, Owen DeLong wrote: >> >> On Sep 13, 2010, at 2:13 PM, Mike Lieberman wrote: >> >>> Matthew! Good heavens, no technology is the panacea. Yes with >>> NAT/CiscoASA5500/and AV software my 12 yo daughter does a fine job of making a >>> mess on her PC... But to suggest that NATs don't knock down a huge amount of >>> unwanted traffic is simply unrealistic. >>> >>> Stateful firewalls can only knock down what they are looking for. Yes proper >>> rules the in/out traffic with internal public IP can work nicely, but they are >>> far more susceptible to really bad results if done wrong... >>> >> Huh? No. >> >> A properly configured stateful firewall knocks down everything that isn't a >> specifically permitted flow. > > which it should be noted requires only one rule. > > deny all inbound not established > On a proper stateful firewall, this rule is not required. It is implicit and all other rules implement exceptions to this rule. Owen From tim.h at bendtel.com Tue Sep 14 13:13:49 2010 From: tim.h at bendtel.com (Tim Howe) Date: Tue, 14 Sep 2010 10:13:49 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> Message-ID: <20100914101349.097a8e85.tim.h@bendtel.com> On Tue, 14 Sep 2010 12:13:14 +0100 wrote: > > > Anyone in this position should simply assign a /48 to every customer > > site > > > no matter how big or small. A one bedroom apartment gets a /48. A > > manufacturing > > > plant with 5 buildings including a 4-story office block, gets a /48. > > > No exceptions. > > > > This is slightly different than I have been led to think... It > > seems wise, when you know the customer has no intention of having > > multiple networks, to provide a /64. > > That is not wise, it is foolish. ... > That is an IPv4 plan, not an IPv6 plan. IPv6 is not just IPv4 > with longer addresses, it has a very different idea of how > addressing is done, and it intentionally wastes space to make > sure that networks can be expanded at several levels without > needing to change the addressing architecture. If you don't provide > the slack, then you are breaking IPv6 and recreating the problems > of IPv4. > It is very typical. /48 to every customer, no exceptions. I am now convinced that this is the best policy for end user sites... > The flaw is in thinking that a customer has only one network. Most folks > these days have two, one wired and one wireless. They may not be using > both, but it is there in the gateway router and they could turn on the > second network any day now. I think single colocated servers may be an exception. Today we simply supply a /30 to many of them and they use the one IP and our router is their gateway. I'm not sure these servers need more than a /64 connecting range. Some colo customers have their own routers/firewalls and a /48 is obvious for them, but is there reason to think these one-server folks need more than a /64? -- Tim Howe From jlewis at atlantic.net Tue Sep 14 12:54:29 2010 From: jlewis at atlantic.net (jlewis at atlantic.net) Date: Tue, 14 Sep 2010 12:54:29 -0400 (EDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <727349.13443.qm@web63302.mail.re1.yahoo.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <727349.13443.qm@web63302.mail.re1.yahoo.com> Message-ID: On Tue, 14 Sep 2010, Lee Howard wrote: > The following guidelines may be useful (but they are only guidelines): > * /64 when it is known that one and only one subnet is needed > * /56 for small sites, those expected to need only a few subnets over the next 5 years. > * /48 for larger sitesand > Subsequent IPv6 allocations, based on HD-Ratio in units of /56 assignments. What's recommended for colo/dedi server providers? Our standard dedi server gets a /28 of v4, and this is done by configuring our switch port as the first usable address in their /28. This allows customers to run different services on different IPs, SSL for older browsers, etc. I can't see giving a /48 to every customer. Even a /56 is probably overkill. OTOH, we don't have enough customers that we'd have any concern of using up our /32 even if we did give every customer a /48. Even just configuring a /64 on each customer switch port would give most customers more IPs than they'll ever need. -- ---------------------------------------------------------------------- Jon Lewis | MCP Senior Network Engineer | Atlantic.net | ________ http://www.lewis.org/~jlewis/pgp for PGP public key__________ From owen at delong.com Tue Sep 14 13:33:16 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 10:33:16 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8FA15F.5050307@Cleven.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com><0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <17FF3DE6BB7DAF4D8E26E5F7DD5343BB0A212736@MAIL.buckeyehq.com> <4C8FA15F.5050307@Cleven.com> Message-ID: <0B7D4C9F-3B3A-4F81-866D-71574B175A58@delong.com> On Sep 14, 2010, at 9:22 AM, Ron Cleven wrote: > This was, of course, the point of my question. It would seem that whoever came up with the crazy scheme of 64bit subnets never thought about how many ISP's and customers there are.in the world. We could have accommodated all the ISP's in the universe each of whom could accommodate all the customers in the universe to ensure nobody would ever have to go back for more allocations. Is there a link that would describe "what is the reasoning (if any) behind the math?" > We still can. We just can't do it with /32s to very large ISPs. They'll need larger blocks. In fact, reviewing the math, I think most ISPs will need /28s. > More simply, it would seem to have been trivial to accommodate the idea of every ISP only ever needing one allocation, no matter what size they are. There was plenty of bits, which now appear to have been squandered by committee. > I disagree... There are still plenty of bits. There are actually good reasons for the /64 decision. Consider this... There are probably about 30,000 ISPs worldwide. (~30,000 active ASNs in the global table, yes some are not ISPs, but, not all ISPs are in the table, either. I figure it's about the best approximation available). At that rate, if we gave every one of them 10 /28s (2 from each RIR) we would only consume the first /12 in each region. > Even more confused. Perhaps I am the only one. > There are several good reasons for the idea of a uniform subnet size. Stateless Address Auto-Configuration is the primary reason to make 64 bits that size. There are some pretty good benefits to SLAAC and I think it's a worthwhile use of those bits. Owen > > Owen DeLong wrote: >> >> Tom, >> >> If you know you have 115k customers, you should request more >> than a /32 to begin with. Probably something approaching a 30 >> or a /29 under current policy. I am soon going to be drafting a policy >> proposal that supports the notion of rounding up to nibble boundaries >> in order to provide better guidance to ISPs on right-sizing their requests >> and also to provide better human factors engineering in the address >> space overall. >> >> Owen >> >> On Sep 14, 2010, at 7:23 AM, Tom Bourgeois wrote: >> >> >>> ________________________________ >>> >>> From: arin-discuss-bounces at arin.net >>> [mailto:arin-discuss-bounces at arin.net] On Behalf Of Ron Cleven >>> Sent: Tuesday, September 14, 2010 9:49 AM >>> To: arin-discuss at arin.net >>> Subject: Re: [arin-discuss] Trying to Understand IPV6 >>> >>> >>> I was with you right with you (assign /48 to every customer, no >>> exceptions) up until you came up with the big-isp exception (assign /56 >>> to private residences). >>> >>> Why would Comcast (using your example) customers get "only" a /56? >>> >>> Is there something wrong with the math (are big-isp's going to run out >>> of /48's)? >>> >>> If it is ok for Comcast customers to get /56's, why isn't it ok for all >>> other private residences to get /56's (what are the /56 customers giving >>> up)? >>> >>> As usual, I am horribly confused. >>> >>> Ditto. We currently have around 115k residential data subs in addition >>> to a few thousand business customers. Compared to the Comcasts, AT&Ts, >>> and Time Warner's of the world we're definitely on the small side but if >>> I give everyone a /48 then I guess I need to go back and get a couple >>> more /32s soon. I guess I don't see the huge problem with aggregation >>> on our local plant. >>> >>> michael.dillon at bt.com wrote: >>> >>> >>> >>> >>> It is very typical. /48 to every customer, no exceptions. If a >>> customer >>> wants less, assign them a /48 anyway and only tell them the >>> first part >>> of the prefix. When they get wiser, tell them the /48 that you >>> "reserved" for them. >>> >>> The non-typical case is an ISP with very large numbers of >>> residential >>> customers (something like Comcast for instance) where it makes >>> sense >>> to assign /56 to private residences and /48 to everyone else. >>> >>> >>> >>> >>> _______________________________________________ >>> ARIN-Discuss >>> You are receiving this message because you are subscribed to >>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-discuss >>> Please contact info at arin.net if you experience any issues. >>> >> >> _______________________________________________ >> ARIN-Discuss >> You are receiving this message because you are subscribed to >> the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-discuss >> Please contact info at arin.net if you experience any issues. >> >> > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rs at seastrom.com Tue Sep 14 15:38:46 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 14 Sep 2010 15:38:46 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8FC437.5090900@chl.com> (Joe Maimon's message of "Tue, 14 Sep 2010 14:51:35 -0400") References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <4C8FC437.5090900@chl.com> Message-ID: <86y6b4glo9.fsf@seastrom.com> Joe Maimon writes: > Robert E. Seastrom wrote: > >> And the firewall will default to "no inbound traffic". Just like your >> NAT router. > > In IPv4, SOHO gear defaults to "no inbound traffic" because > > a) its the right thing to do > > b) its what the competitors do > > c) its a byproduct of NAT, which needs to be turned on by default just > to provide basic connectivity in the majority of use cases > > d) It lowers their support costs and lets the device work out of the box > > In IPv6 without NAT66, only A is a given. Disagree. The whole point of a SOHO firewall ("does what it says on the box, keeps bad packets out, makes your network smell minty fresh") guarantees "B" and business case and call center records will dictate "D" even if they get it wrong out of the gate (unlikely). I'm quite willing to listen to countering points of view though - could you please explain why the market forces that push b and d will not be present in IPv6 but would somehow be present if only we added NAT66 to the equation? -r From berger at shout.net Tue Sep 14 16:00:55 2010 From: berger at shout.net (Mike Berger) Date: Tue, 14 Sep 2010 15:00:55 -0500 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <2052823951.5367.1284481197700.JavaMail.root@zimbra.network1.net> References: <2052823951.5367.1284481197700.JavaMail.root@zimbra.network1.net> Message-ID: <4C8FD477.7090605@shout.net> Static assignments sure sound appealing from the customer standpoint. NAT is a kludge that breaks things and customers shouldn't be forced into it, especially when there's no shortage of resources. Yes, you can wreak havoc with the customer's network when you change addresses on them. On 9/14/10 11:19 AM, Randy Carpenter wrote: > What are everyones' thoughts regarding dynamic versus static assignments for residential users? > > Our current plan is to use DHCPv6 with prefix delegation to auto-assign the WAN and LAN prefixes. In this scenario, we could easily change assignments without anyone having to touch any equipment. > > The big question is will that wreak havoc with customers' internal network if the addresses ever change? > > Static assignments for 10,000's of customers does not sound very appealing. > > Any other considerations? > > thanks, > -Randy > > From spiffnolee at yahoo.com Tue Sep 14 17:21:20 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Tue, 14 Sep 2010 14:21:20 -0700 (PDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <2052823951.5367.1284481197700.JavaMail.root@zimbra.network1.net> References: <2052823951.5367.1284481197700.JavaMail.root@zimbra.network1.net> Message-ID: <940648.48531.qm@web63306.mail.re1.yahoo.com> Excellent question. We keep spinning around the question of "what if we groom a customer to a different edge router?" DHCP assignments come from DHCP pools based on the source address of the relay router (i.e., edge router). Even if the home gateway knows to request a new prefix when its link comes up on a new router, the devices in the home don't know that their prefix has changed. Maybe the home gateway should expect to send a DHCP Reconfigure if it acquires a new prefix after a link state change? Assuming the link actually bounces in a groom, that is. How does your edge router know the next hop of the DHCP prefix? Snoop the DHCP packet? I think we should resurrect RAAN, but since it expired I'm not sure there's support. Just MHO, of course. For those playing along at home, this is as hard as the IPv6 questions get. And this probably isn't a question an enterprise network has to handle. Lee ________________________________ From: Randy Carpenter To: arin-discuss at arin.net Sent: Tue, September 14, 2010 12:19:57 PM Subject: Re: [arin-discuss] Trying to Understand IPV6 What are everyones' thoughts regarding dynamic versus static assignments for residential users? Our current plan is to use DHCPv6 with prefix delegation to auto-assign the WAN and LAN prefixes. In this scenario, we could easily change assignments without anyone having to touch any equipment. The big question is will that wreak havoc with customers' internal network if the addresses ever change? Static assignments for 10,000's of customers does not sound very appealing. Any other considerations? thanks, -Randy ----- Original Message ----- > We've already received our first /32 allocation, I was thinking that > this would be the last allocation we would ever need. Since we're a > cable TV provider we are somewhat at the mercy of DOCSIS and CableLabs > as to how v6 addresses will be distributed as well as the companies > that > create the provisioning software. I guess I need to start that > discussion first with the provisioning software developers. Last I > heard they were still about 6 months out (their estimate) from having > anything to play with. Compared to our cable plant, the metro ethernet > customers sound easy... A /64 on the WAN and a /48 on the LAN unless > I'm > missing something. > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, September 14, 2010 11:25 AM > To: Tom Bourgeois > Cc: arin-discuss at arin.net > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > Tom, > > If you know you have 115k customers, you should request more than a > /32 > to begin with. Probably something approaching a 30 or a /29 under > current policy. I am soon going to be drafting a policy proposal that > supports the notion of rounding up to nibble boundaries in order to > provide better guidance to ISPs on right-sizing their requests and > also > to provide better human factors engineering in the address space > overall. > > Owen > > On Sep 14, 2010, at 7:23 AM, Tom Bourgeois wrote: > > > > > > > ________________________________ > > > > From: arin-discuss-bounces at arin.net > > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Ron Cleven > > Sent: Tuesday, September 14, 2010 9:49 AM > > To: arin-discuss at arin.net > > Subject: Re: [arin-discuss] Trying to Understand IPV6 > > > > > > I was with you right with you (assign /48 to every customer, no > > exceptions) up until you came up with the big-isp exception (assign > > /56 to private residences). > > > > Why would Comcast (using your example) customers get "only" a /56? > > > > Is there something wrong with the math (are big-isp's going to run > > out > > > of /48's)? > > > > If it is ok for Comcast customers to get /56's, why isn't it ok for > > all other private residences to get /56's (what are the /56 > > customers > > giving up)? > > > > As usual, I am horribly confused. > > > > Ditto. We currently have around 115k residential data subs in > > addition to a few thousand business customers. Compared to the > > Comcasts, AT&Ts, and Time Warner's of the world we're definitely on > > the small side but if I give everyone a /48 then I guess I need to > > go > > back and get a couple more /32s soon. I guess I don't see the huge > > problem with aggregation on our local plant. > > > > michael.dillon at bt.com wrote: _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelja at bogus.com Tue Sep 14 17:36:05 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Sep 2010 14:36:05 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100914010049.GB96567@ussenterprise.ufp.org> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <20100914010049.GB96567@ussenterprise.ufp.org> Message-ID: <4C8FEAC5.8080907@bogus.com> On 9/13/10 6:00 PM, Leo Bicknell wrote: > In a message written on Mon, Sep 13, 2010 at 08:48:59PM -0400, Robert E. Seastrom wrote: >> proper ports in the firewall. Funny how easy that gets when there is >> no STUN or uPNP in the fray. Might even be something that you click > > I don't think (but I'm not sure) that uPnP requires NAT. That is, > I think a stateful firewall could implement uPnP and use it simply > to unblock ports on request. look up on wikipedia, IGD and SSDP http://upnp.org/sdcps-and-certification/standards/device-architecture-documents/ their approach for v6 is already documented. > I think for most consumers that's a good model. Your PS3 or other > appliance like device can request the couple of ports it needs, and > if you want to know you can log into your gateway and see waht a > device requests, and/or deny a particular device such access. > > > > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From jmaimon at chl.com Tue Sep 14 17:40:10 2010 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 14 Sep 2010 17:40:10 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <86y6b4glo9.fsf@seastrom.com> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <4C8FC437.5090900@chl.com> <86y6b4glo9.fsf@seastrom.com> Message-ID: <4C8FEBBA.1010907@chl.com> Robert E. Seastrom wrote: > Joe Maimon writes: > > >> Robert E. Seastrom wrote: >> >> >>> And the firewall will default to "no inbound traffic". Just like your >>> NAT router. >>> >> In IPv4, SOHO gear defaults to "no inbound traffic" because >> >> a) its the right thing to do >> >> b) its what the competitors do >> >> c) its a byproduct of NAT, which needs to be turned on by default just >> to provide basic connectivity in the majority of use cases >> >> d) It lowers their support costs and lets the device work out of the box >> >> In IPv6 without NAT66, only A is a given. >> > Disagree. The whole point of a SOHO firewall ("does what it says on > the box, keeps bad packets out, makes your network smell minty fresh") > guarantees "B" and business case and call center records will dictate > "D" even if they get it wrong out of the gate (unlikely). > I dont believe we are discussing the same equipment. Set aside gear that specifically markets itself as a security device. I expect those will continue to be secure out of the box. All other residential and SOHO access gear may not. SPI has costs. SPI with default deny has additional costs. In IPv4, these costs are inflicted by the required NAT44 feature, so SPI default deny has no additional cost. Not so in IPv6, with NAT66 not a popular access option, if even ever available at all. > I'm quite willing to listen to countering points of view though - > could you please explain why the market forces that push b and d will > not be present in IPv6 but would somehow be present if only we added > NAT66 to the equation? > > -r > > > I am trying to counter the assumption that the majority of interaction not required devices will continue to deny inbound traffic out of the box with a full blown SPI firewall turned on, with hole punching and other resultant required ALG's and end user conveniences developed, enabled, tuned, tweaked and supported. I believe that the major factor for default deny being ubiquitous is due to NAT44 being similarly ubiquitous. Why would support costs be lower for consumer routers with SPI default deny than for routers without? Most hosts already have adequate host based protection available, there is no reason to expect low cost device makers to continue duplicating the effort for little cause. I support the notion that NAT66 should be available for those who want it without vilification and demonization. I dont support it as a sanctioned solution to any problem better global address management can solve instead. I dont believe anything we do here will have any real effect on NAT66 availability or whether these devices will continue to have default deny. Joe From owen at delong.com Tue Sep 14 17:59:46 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 14:59:46 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <940648.48531.qm@web63306.mail.re1.yahoo.com> References: <2052823951.5367.1284481197700.JavaMail.root@zimbra.network1.net> <940648.48531.qm@web63306.mail.re1.yahoo.com> Message-ID: On Sep 14, 2010, at 2:21 PM, Lee Howard wrote: > Excellent question. > We keep spinning around the question of "what if we groom a customer to a different edge router?" DHCP assignments come from DHCP pools based on the source address of the relay router (i.e., edge router). Even if the home gateway knows to request a new prefix when its link comes up on a new router, the devices in the home don't know that their prefix has changed. > If they're configured by DHCP or SLAAC as they should be in most cases, yes, they do. > Maybe the home gateway should expect to send a DHCP Reconfigure if it acquires a new prefix after a link state change? Assuming the link actually bounces in a groom, that is. > Doesn't DHCPv6 already require a router that receives a new DHCP-PD to notify its existing leasholders? I thought it did, but, I would have to review the RFC to be sure. > How does your edge router know the next hop of the DHCP prefix? Snoop the DHCP packet? I think we should resurrect RAAN, but since it expired I'm not sure there's support. Just MHO, of course. > I'm not sure what you're asking here. The DHCP Prefix Delegation comes after an RA has already been received instructing the router to request addressing via DHCP. The RA covers the next hop information. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 14 19:44:41 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 16:44:41 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8FEBBA.1010907@chl.com> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <4C8FC437.5090900@chl.com> <86y6b4glo9.fsf@seastrom.com> <4C8FEBBA.1010907@chl.com> Message-ID: <276384AF-3287-4CB8-B096-032AC8176D2B@delong.com> > > Set aside gear that specifically markets itself as a security device. I expect those will continue to be secure out of the box. All other residential and SOHO access gear may not. > Maybe, but, I bet SOHO access gear that doesn't will not gain much market share. > SPI has costs. SPI with default deny has additional costs. > SPI costs RAM and CPU. CPU is abundant and cheap compared to residential speeds these days. RAM is relatively cheap. Default deny does not cost anything more than SPI. There has to be code that handles a packet that doesn't match any rule. It doesn't cost any more for that code to drop than it does to forward. > In IPv4, these costs are inflicted by the required NAT44 feature, so SPI default deny has no additional cost. Not so in IPv6, with NAT66 not a popular access option, if even ever available at all. > The additional costs are so small that they are noise vs. the market share and risk of product liability without it, frankly. I would not want to be the person trying to defend the idea that malicious packets coming through my CPE device because I chose not to implement a basic SPI with default deny was not a foreseeable event. If you don't think the law will eventually catch up to the idea that this should be a product liability issue, I think you are sadly mistaken. >> I'm quite willing to listen to countering points of view though - >> could you please explain why the market forces that push b and d will >> not be present in IPv6 but would somehow be present if only we added >> NAT66 to the equation? >> >> -r >> >> >> > > I am trying to counter the assumption that the majority of interaction not required devices will continue to deny inbound traffic out of the box with a full blown SPI firewall turned on, with hole punching and other resultant required ALG's and end user conveniences developed, enabled, tuned, tweaked and supported. > If you don't have NAT and you just use SPI, you mostly don't need ALGs. The hole punching is handled by uPNP (for better or worse) and there are other alternatives as well. I'm not sure why you think any vendor would skip these features just because they don't implement header mangling. > I believe that the major factor for default deny being ubiquitous is due to NAT44 being similarly ubiquitous. > That may have been true when NAT first hit IPv4 because security was still an afterthought at the time. However, in today's environment, I think that would not be the case with any responsible vendor implementing CPE for any significant market share. > Why would support costs be lower for consumer routers with SPI default deny than for routers without? > Because consumers that buy routers without SPI will call the router vendor when their PC gets pwn3d. Even if only 10% blame the router vendor instead of their computer vendor, that's still a large enough support cost to tip the balance. > Most hosts already have adequate host based protection available, there is no reason to expect low cost device makers to continue duplicating the effort for little cause. > You're joking, right? Most hosts doe not have anywhere near adequate protection enabled. Even those that have it available are largely not implemented. > I support the notion that NAT66 should be available for those who want it without vilification and demonization. I dont support it as a sanctioned solution to any problem better global address management can solve instead. I dont believe anything we do here will have any real effect on NAT66 availability or whether these devices will continue to have default deny. > The problem with making NAT66 available without vilification or demonization as you call it is that it will increase costs for everyone, especially those who don't want NAT66 and aren't deploying it. There may be a small cost to SPI, but, there is a HUGE cost to NAT and it is rarely born by those actually using NAT. Owen From jmaimon at chl.com Tue Sep 14 20:56:14 2010 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 14 Sep 2010 20:56:14 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <276384AF-3287-4CB8-B096-032AC8176D2B@delong.com> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <4C8FC437.5090900@chl.com> <86y6b4glo9.fsf@seastrom.com> <4C8FEBBA.1010907@chl.com> <276384AF-3287-4CB8-B096-032AC8176D2B@delong.com> Message-ID: <4C9019AE.9060409@chl.com> Owen DeLong wrote: >> Set aside gear that specifically markets itself as a security device. I expect those will continue to be secure out of the box. All other residential and SOHO access gear may not. >> >> > Maybe, but, I bet SOHO access gear that doesn't will not gain much market share. > My crystal ball is not nearly as clear as yours. >> SPI has costs. SPI with default deny has additional costs. >> >> > SPI costs RAM and CPU. CPU is abundant and cheap compared to residential > speeds these days. RAM is relatively cheap. > SPI costs product development and support. SPI causes state table exhaustion issues for p2p and similar multitude of connections traffic. Port scanning through an SPI isnt any fun, as an example. SPI default deny creates support issues and product perception issues when end users believe or are told that they need to manually tune or turn it off. Is it not possible that "Turn off the firewall on your router" wont become part of the standard support script? > Default deny does not cost anything more than SPI. There has to be code that > handles a packet that doesn't match any rule. It doesn't cost any more for that > code to drop than it does to forward. > There does not need to be any code that implements any rules. That should cost less. Have you not seen access devices that dont even offer the option to turn off NAT44? Why is it so hard to believe that the option of not including any firewall features at all will be attractive to many a maker of low end access devices. > > I would not want to be the person trying to defend the idea that malicious packets > coming through my CPE device because I chose not to implement a basic SPI with > default deny was not a foreseeable event. If you don't think the law will eventually > catch up to the idea that this should be a product liability issue, I think you are > sadly mistaken. > You may be correct that product liability and security expectations will be a growing factor favoring SPI default deny. However, I am unconvinced that it will be great enough to compensate for the removal of NAT, which gives it to you as a by product and is not optional. >> > If you don't have NAT and you just use SPI, you mostly don't need ALGs. I cant accept that on face value. If the protocol embeds the return information in the packet, the SPI firewall will need to know where it is to ensure that return packets are allowed. If this information was discernible from the generic l3 header, why would the protocol feel a need to embed it? If it is discernible from the generic l3 header, why would any special ALG be needed for NAT that would not be needed for SPI? If there is no ALG, without uPNP or similar end node to gateway signalling, which is ugly, embedding return information wont work any better with SPI than it does with NAT+SPI. > The hole punching is > handled by uPNP (for better or worse) and there are other alternatives as well. > Some of which were just discussed in this thread. More product development and support costs. > I'm not sure why you think any vendor would skip these features just because they don't > implement header mangling. > Because if they dont implement header mangling, they now need to justify the effort and cost involved in implementing these features and having them turned on by default. > >> I believe that the major factor for default deny being ubiquitous is due to NAT44 being similarly ubiquitous. >> >> > That may have been true when NAT first hit IPv4 because security was still an afterthought > at the time. However, in today's environment, I think that would not be the case with any > responsible vendor implementing CPE for any significant market share. > At least you acknowledge that there is a question there. We can predict all we want, but we should not be blase about it. Security is still an afterthought, as well as a scapegoat. > >> Why would support costs be lower for consumer routers with SPI default deny than for routers without? >> >> > Because consumers that buy routers without SPI will call the router vendor when their PC gets > pwn3d. Even if only 10% blame the router vendor instead of their computer vendor, that's > still a large enough support cost to tip the balance. > Might those calls be countered by the additional calls from those trying to do their gaming|voip|p2p|cams and claiming that the router is getting in their way with its firewall? I just dont think this is as cut and dried it has been made out to be. > >> Most hosts already have adequate host based protection available, there is no reason to expect low cost device makers to continue duplicating the effort for little cause. >> >> > You're joking, right? > Nope. Linux iptables is actually what powers most of these devices SPI. I cant imagine that a modern distro's iptables is any worse than the embedded ancient kernel. The rest are adequate enough. The bar is not all that high in this device space. > Most hosts doe not have anywhere near adequate protection enabled. Even those that have it available > are largely not implemented. > Is this because they feel they have no compelling reason to turn it on? You have made my case. What makes you think device makers are any better? >> I support the notion that NAT66 should be available for those who want it without vilification and demonization. I dont support it as a sanctioned solution to any problem better global address management can solve instead. I dont believe anything we do here will have any real effect on NAT66 availability or whether these devices will continue to have default deny. >> >> > The problem with making NAT66 available without vilification or demonization as you call it is that > it will increase costs for everyone, especially those who don't want NAT66 and aren't deploying > it. There may be a small cost to SPI, but, there is a HUGE cost to NAT and it is rarely born by those > actually using NAT. > > Owen > > > I appreciate the honesty. You dont want anyone to use NAT66, because it makes it harder (increases costs) for other people who develop and implement independent-stream callback protocols, whether they should be doing so or not, whether they are entitled to lower their costs or not by championing denying users the features that the users claim they want. They always have the option of simply denying nat users the joys and wonder of their protocol and application. Frankly, I think designing protocols in that fashion needs to have its drawbacks just to maintain some balance and those protocols are going to need ALG's anyways. I am also unconvinced that the trade off is as high as you make it to be and that it will not be lowered simply by having a lesser percentage of end nodes with nat on the net. Most things seem to work fairly well on todays net, even with its high density of natted end nodes, especially when they are not designed by anti-nat idealouges. Joe From bicknell at ufp.org Tue Sep 14 21:10:18 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 14 Sep 2010 18:10:18 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C9019AE.9060409@chl.com> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <4C8FC437.5090900@chl.com> <86y6b4glo9.fsf@seastrom.com> <4C8FEBBA.1010907@chl.com> <276384AF-3287-4CB8-B096-032AC8176D2B@delong.com> <4C9019AE.9060409@chl.com> Message-ID: <20100915011018.GA76781@ussenterprise.ufp.org> In a message written on Tue, Sep 14, 2010 at 08:56:14PM -0400, Joe Maimon wrote: > SPI costs product development and support. SPI causes state table > exhaustion issues for p2p and similar multitude of connections traffic. > Port scanning through an SPI isnt any fun, as an example. SPI default > deny creates support issues and product perception issues when end users > believe or are told that they need to manually tune or turn it off. I find this whole SPI stuff rather amusing. Every home box I've ever seen in the past few years has this feature already in big print. For instance, let's look at Netgear's LOWEST end box: http://www.netgear.com/products/home/wirelessouters/simplesharing/WNR1000.aspx "Double firewall protection (SPI and NAT firewall)" SPI is already in nearly all consumer boxes, because some of them are deployed with public IP's today (yes, some providers do that!), and in fact it's probably on by default in millions of home gateways right now with no problems. If it in fact were a support issue it wouldn't already be ubiquitous. Further since the IPv6 code base is new. the choices for the vendors are SPIv6, or SPIv6 + NATv6. There is no choice to leave the users unprotected, and when they have been trumpeting "Double firewall protection" for years in IPv4 they aren't going to do NAT6 only. So in fact SPIv6 only and leaving out NATv6 _reduces_ cost, and support complexity by only having to do one thing rather than two. Folks speak as if residential users have never been deployed with "real" IP's. While it is not the dominate configuration, a number of large regional ISP's deploy residential users with static /29's or simlilar configs. There are millions of users today on public space, protected by SPI firewalls. It's really not a problem, and in many ways good. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From cboyd at gizmopartners.com Tue Sep 14 22:21:20 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 14 Sep 2010 21:21:20 -0500 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C9019AE.9060409@chl.com> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <4C8FC437.5090900@chl.com> <86y6b4glo9.fsf@seastrom.com> <4C8FEBBA.1010907@chl.com> <276384AF-3287-4CB8-B096-032AC8176D2B@delong.com> <4C9019AE.9060409@chl.com> Message-ID: On Sep 14, 2010, at 7:56 PM, Joe Maimon wrote: > SPI costs product development and support. SPI causes state table exhaustion issues for p2p and similar multitude of connections traffic. Port scanning through an SPI isnt any fun, as an example. SPI default deny creates support issues and product perception issues when end users believe or are told that they need to manually tune or turn it off. > > Is it not possible that "Turn off the firewall on your router" wont become part of the standard support script? SPI Default Deny saves frazzled IT staff lots of time and hair follicles when the end user calls software vendor support themselves instead of calling IT, they have local admin, and the support person says "turn off the firewall on your machine." Yes, "turn off your home firewall _will_ become part of the standard support script for application support vendors (especially consumer apps) where the goal typically is to "fix the problem," not worrying about the other problems that it will create for other people down the line. Some clever company will probably even write a little application that the customer can run that will go out and use uPNP or some similar method to do it for them. NAT is ugly, but completely open access will be uglier for the rest of the Internet. Worm writers will find ways to optimize scanning local and remote networks. Phishers will entice people to click on the shiny thing and willingly infect their own box. Default deny in can help mitigate the damage to those around them. --Chris From rcarpen at network1.net Tue Sep 14 23:03:28 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Sep 2010 23:03:28 -0400 (EDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: Message-ID: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> Everyone arguing that NAT is a good thing should have been involved a decade ago when it was decided that IPv6 was not going to have NAT. The NAT argument is over. I wish we would all stop arguing about these issues, and the hardware manufacturers would get some things on the market. We are running dangerously close to needing IPv6 for user expansion, and we have no way to deploy it. -Randy ----- Original Message ----- > On Sep 14, 2010, at 7:56 PM, Joe Maimon wrote: > > > SPI costs product development and support. SPI causes state table > > exhaustion issues for p2p and similar multitude of connections > > traffic. Port scanning through an SPI isnt any fun, as an example. > > SPI default deny creates support issues and product perception > > issues when end users believe or are told that they need to manually > > tune or turn it off. > > > > Is it not possible that "Turn off the firewall on your router" wont > > become part of the standard support script? > > SPI Default Deny saves frazzled IT staff lots of time and hair > follicles when the end user calls software vendor support themselves > instead of calling IT, they have local admin, and the support person > says "turn off the firewall on your machine." Yes, "turn off your home > firewall _will_ become part of the standard support script for > application support vendors (especially consumer apps) where the goal > typically is to "fix the problem," not worrying about the other > problems that it will create for other people down the line. Some > clever company will probably even write a little application that the > customer can run that will go out and use uPNP or some similar method > to do it for them. > > NAT is ugly, but completely open access will be uglier for the rest of > the Internet. Worm writers will find ways to optimize scanning local > and remote networks. Phishers will entice people to click on the shiny > thing and willingly infect their own box. Default deny in can help > mitigate the damage to those around them. > > --Chris > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From joelja at bogus.com Tue Sep 14 23:13:57 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Sep 2010 20:13:57 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> Message-ID: <4C9039F5.7050100@bogus.com> On 9/14/10 8:03 PM, Randy Carpenter wrote: > > Everyone arguing that NAT is a good thing should have been involved a decade ago when it was decided that IPv6 was not going to have NAT. The NAT argument is over. > > I wish we would all stop arguing about these issues, and the hardware manufacturers would get some things on the market. We are running dangerously close to needing IPv6 for user expansion, and we have no way to deploy it. you should look in the wireless router aisle at frys... the cpe you need exists and it doesn't do nat66... > -Randy > > > ----- Original Message ----- >> On Sep 14, 2010, at 7:56 PM, Joe Maimon wrote: >> >>> SPI costs product development and support. SPI causes state table >>> exhaustion issues for p2p and similar multitude of connections >>> traffic. Port scanning through an SPI isnt any fun, as an example. >>> SPI default deny creates support issues and product perception >>> issues when end users believe or are told that they need to manually >>> tune or turn it off. >>> >>> Is it not possible that "Turn off the firewall on your router" wont >>> become part of the standard support script? >> >> SPI Default Deny saves frazzled IT staff lots of time and hair >> follicles when the end user calls software vendor support themselves >> instead of calling IT, they have local admin, and the support person >> says "turn off the firewall on your machine." Yes, "turn off your home >> firewall _will_ become part of the standard support script for >> application support vendors (especially consumer apps) where the goal >> typically is to "fix the problem," not worrying about the other >> problems that it will create for other people down the line. Some >> clever company will probably even write a little application that the >> customer can run that will go out and use uPNP or some similar method >> to do it for them. >> >> NAT is ugly, but completely open access will be uglier for the rest of >> the Internet. Worm writers will find ways to optimize scanning local >> and remote networks. Phishers will entice people to click on the shiny >> thing and willingly infect their own box. Default deny in can help >> mitigate the damage to those around them. >> >> --Chris >> >> _______________________________________________ >> ARIN-Discuss >> You are receiving this message because you are subscribed to >> the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-discuss >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > From rcarpen at network1.net Tue Sep 14 23:40:08 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Sep 2010 23:40:08 -0400 (EDT) Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C9039F5.7050100@bogus.com> Message-ID: <230008014.5610.1284522008943.JavaMail.root@zimbra.network1.net> > > > > I wish we would all stop arguing about these issues, and the > > hardware manufacturers would get some things on the market. We are > > running dangerously close to needing IPv6 for user expansion, and we > > have no way to deploy it. > > you should look in the wireless router aisle at frys... the cpe you > need > exists and it doesn't do nat66... > Do you know of any specific models that will support DHCPv6 including prefix delegation, and also properly hand out DNS servers to the internal devices? Also, will it will plug directly into our existing DSL and CATV deployments? There are a some areas that we can do ethernet-ethernet, but the many of the networks we support have CPE devices that serve as modem and router. -Randy From joelja at bogus.com Wed Sep 15 00:37:53 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Sep 2010 21:37:53 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <230008014.5610.1284522008943.JavaMail.root@zimbra.network1.net> References: <230008014.5610.1284522008943.JavaMail.root@zimbra.network1.net> Message-ID: <4C904DA1.1080807@bogus.com> On 9/14/10 8:40 PM, Randy Carpenter wrote: > >>> >>> I wish we would all stop arguing about these issues, and the >>> hardware manufacturers would get some things on the market. We are >>> running dangerously close to needing IPv6 for user expansion, and we >>> have no way to deploy it. >> >> you should look in the wireless router aisle at frys... the cpe you >> need >> exists and it doesn't do nat66... >> > > Do you know of any specific models that will support DHCPv6 including prefix delegation, and also properly hand out DNS servers to the internal devices? I know d-link dir-825 and dir-615 support pd (or in their manual reservation) > Also, will it will plug directly into our existing DSL and CATV deployments? my docsis 3.0 modem supports v6 (mot 6b6120) given it's a spec requirement I imagine other's do as well. > There are a some areas that we can do ethernet-ethernet, but the many of the networks we support have CPE devices that serve as modem and router. > > -Randy > From jmaimon at chl.com Wed Sep 15 01:05:44 2010 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 15 Sep 2010 01:05:44 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100915011018.GA76781@ussenterprise.ufp.org> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <4C8FC437.5090900@chl.com> <86y6b4glo9.fsf@seastrom.com> <4C8FEBBA.1010907@chl.com> <276384AF-3287-4CB8-B096-032AC8176D2B@delong.com> <4C9019AE.9060409@chl.com> <20100915011018.GA76781@ussenterprise.ufp.org> Message-ID: <4C905428.2080803@chl.com> Leo Bicknell wrote: > In a message written on Tue, Sep 14, 2010 at 08:56:14PM -0400, Joe Maimon wrote: > >> SPI costs product development and support. SPI causes state table >> exhaustion issues for p2p and similar multitude of connections traffic. >> Port scanning through an SPI isnt any fun, as an example. SPI default >> deny creates support issues and product perception issues when end users >> believe or are told that they need to manually tune or turn it off. >> > I find this whole SPI stuff rather amusing. Every home box I've > ever seen in the past few years has this feature already in big > print. For instance, let's look at Netgear's LOWEST end box: > > http://www.netgear.com/products/home/wirelessouters/simplesharing/WNR1000.aspx > > "Double firewall protection (SPI and NAT firewall)" > > SPI is already in nearly all consumer boxes, because some of them > are deployed with public IP's today (yes, some providers do that!), > and in fact it's probably on by default in millions of home gateways > right now with no problems. If it in fact were a support issue it > wouldn't already be ubiquitous. > > Further since the IPv6 code base is new. the choices for the vendors > are SPIv6, or SPIv6 + NATv6. There is no choice to leave the users > unprotected, and when they have been trumpeting "Double firewall > protection" for years in IPv4 they aren't going to do NAT6 only. > So in fact SPIv6 only and leaving out NATv6 _reduces_ cost, and > support complexity by only having to do one thing rather than two. > > Folks speak as if residential users have never been deployed with > "real" IP's. While it is not the dominate configuration, a number > of large regional ISP's deploy residential users with static /29's > or simlilar configs. There are millions of users today on public > space, protected by SPI firewalls. It's really not a problem, and > in many ways good. > > SPI's are in many ways good. Do they owe their ubiquity to NAT44 and how will the lack of NAT66 affect that? I think it is much too early to tell. Joe From michael.dillon at bt.com Wed Sep 15 06:27:09 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 15 Sep 2010 11:27:09 +0100 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <9542ADEA-DC86-4E5F-89C5-C79381624C17@delong.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <9542ADEA-DC86-4E5F-89C5-C79381624C17@delong.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEEAFD@EMV01-UKBR.domain1.systemhost.net> > FWIW, I don't agree with Michael about assigning /56s. I used to think > that /56s for residences made sense. And in reality, most residences > will be fine with 256 subnets. However, having now gotten some > operational experience with IPv6 and having reviewed the math, I now > believe there is no true rationale behind assigning /56s. > > Very large providers should seek to get larger blocks rather than > accepting the default /32. I'm not saying that very large providers SHOULD give /56 assignments to private residences. I am saying that ONLY VERY LARGE providers should consider giving less than a /48 to private residences. Applying for an allocation larger than a /32 is a very good idea for large providers to do. > Is there something wrong with the math (are big-isp's going to > run out of /48's)? For those who REALLY want to study the math, look at this presentation http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf which explains how we might be getting a bit short of addresses in 60 years. This presentation led to policy proposal 2005-8 https://www.arin.net/policy/proposals/2005_8.html and you can see some more background info by following the URLs on the 2005-8 page. > If it is ok for Comcast customers to get /56's, why isn't it ok > for all other private residences to get /56's (what are the /56 > customers giving up)? It is not OK for Comcast to do this, but we have given them the choice. But if you are not Comcast then it would be foolish to do things the way that Comcast does. Just stick to /48 for everyone, and make your projections on that basis. You are not wasting anything because /48 per endsite is the design spec for IPv6. ISPs should not be trying to reinvent IPv6, just deploy it as it is, get your /32 and design your addressing plan based on a /48 per endsite. Internal addressing is a bit more complex, but it is worthwhile to start by assigning a/48 to each of your endsites and projected endsites and only aggregate if really needed. --Michael Dillon From michael.dillon at bt.com Wed Sep 15 06:32:22 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 15 Sep 2010 11:32:22 +0100 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C8FA15F.5050307@Cleven.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com><0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <17FF3DE6BB7DAF4D8E26E5F7DD5343BB0A212736@MAIL.buckeyehq.com> <4C8FA15F.5050307@Cleven.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEEB0F@EMV01-UKBR.domain1.systemhost.net> > This was, of course, the point of my question. It would seem that > whoever came up with the crazy scheme of 64bit subnets never thought > about how many ISP's and customers there are.in the world. We could > have accommodated all the ISP's in the universe each of whom could > accommodate all the customers in the universe to ensure nobody would > ever have to go back for more allocations. Is there a link that would > describe "what is the reasoning (if any) behind the math?" It is indeed math, not arithmetic as you described above. And it is related to the probability of collisions if you use an algorithm that chooses addresses randomly. This is being done to enable auto confifguration of devices. If you want links, start reading the pages at http://www.getipv6.info where you will find dozens of links to other sources. --Michael Dillon From michael.dillon at bt.com Wed Sep 15 06:37:13 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 15 Sep 2010 11:37:13 +0100 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <20100914101349.097a8e85.tim.h@bendtel.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <20100914101349.097a8e85.tim.h@bendtel.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEEB1A@EMV01-UKBR.domain1.systemhost.net> > but is there reason to think these > one-server folks need more than a /64? XEN plus 4 quad-core CPUs in a 1U server equals 48+ virtual servers not to mention virtual routers and virtual switches. If it is one customer, best to just give them a /48. If they add another server, then extend the VLAN to that and let the customer address it out of the existing /48. If they have a full rack, assign them a /48. If they have a room full of racks, assign them a /48. If the customer has two racks in two different cities, then assign them two /48s even if they are somehow bridging their racks together for some kind of DR plan. Keep it simple, assign a /48 --Michael Dillon From owen at delong.com Wed Sep 15 06:47:52 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Sep 2010 03:47:52 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <4C905428.2080803@chl.com> References: <0a4e01cb5380$b539e260$1fada720$@net> <406320703.374005.1284410640074.JavaMail.root@zimbra1.crocker.com> <0a8401cb5385$839d48f0$8ad7dad0$@net> <86hbhtm9ok.fsf@seastrom.com> <4C8FC437.5090900@chl.com> <86y6b4glo9.fsf@seastrom.com> <4C8FEBBA.1010907@chl.com> <276384AF-3287-4CB8-B096-032AC8176D2B@delong.com> <4C9019AE.9060409@chl.com> <20100915011018.GA76781@ussenterprise.ufp.org> <4C905428.2080803@chl.com> Message-ID: >> >> > SPI's are in many ways good. Do they owe their ubiquity to NAT44 and how will the lack of NAT66 affect that? I think it is much too early to tell. > > Joe 1. Agreed. 2. No, they were widely available prior to the existence of NAT44 and would likely have become ubiquitous even if NAT had not caught on. 3. I doubt it will. Owen From owen at delong.com Wed Sep 15 07:01:32 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Sep 2010 04:01:32 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEEAFD@EMV01-UKBR.domain1.systemhost.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <9542ADEA-DC86-4E5F-89C5-C79381624C17@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEEAFD@EMV01-UKBR.domain1.systemhost.net> Message-ID: <82D087F0-778E-498B-B0DF-C79CFABF8AEF@delong.com> > > > Just stick to /48 for everyone, and make your projections on that basis. > You are not wasting anything because /48 per endsite is the design spec > for IPv6. ISPs should not be trying to reinvent IPv6, just deploy it as > it is, get your /32 and design your addressing plan based on a /48 per > endsite. Internal addressing is a bit more complex, but it is worthwhile > to start by assigning a/48 to each of your endsites and projected endsites > and only aggregate if really needed. I am constantly dismayed by this advice. In the alternative I would recommend the following: 1. Design your addressing plan based on a /48 per end site. An end site is a single structure, or, in the case of a multi-tenant structure, a single tenant in that structure. 2. Figure out how many /48s you need in your largest POP. (Ideally, round up to a nibble boundary, but, there is not RIR policy to support this (yet)). 3. Figure out how many POPs you are likely to have in ~5 years. (Ideally you'd round this up to a nibble boundary as well, but, again, RIR policy needs to catch up on this one, it's not quite there yet). 4. The number of bits required for those two things gives you the total number of bits required to describe your network. So, for example, if you need 8 bits to describe <=256 POPs and 12 bits to describe <=4096 end sites per POP, you need 20 bits to describe your network. 48-20 is 28. You would need a /28. Once you have done this calculation, then you should apply for the address space your design requires rather than merely going in blind for a /32. However, if you require less than a /32, then, you should get a /32 minimum allocation. Owen From rs at seastrom.com Wed Sep 15 07:21:37 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 15 Sep 2010 07:21:37 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <82D087F0-778E-498B-B0DF-C79CFABF8AEF@delong.com> (Owen DeLong's message of "Wed, 15 Sep 2010 04:01:32 -0700") References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <9542ADEA-DC86-4E5F-89C5-C79381624C17@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEEAFD@EMV01-UKBR.domain1.systemhost.net> <82D087F0-778E-498B-B0DF-C79CFABF8AEF@delong.com> Message-ID: <86fwxbgsla.fsf@seastrom.com> Owen DeLong writes: > 2. Figure out how many /48s you need in your largest POP. > (Ideally, round up to a nibble boundary, but, there is not RIR > policy to support this (yet)). > > 3. Figure out how many POPs you are likely to have in ~5 years. > (Ideally you'd round this up to a nibble boundary as well, but, > again, RIR policy needs to catch up on this one, it's not quite > there yet). I would support policy proposals for nybble float-up on both of these points. Subnetting or allocating on non-nybble-boundaries is IPv4-austerity-mode thinking, and needs to be supplanted by make-it-easy-on-the-engineers-and-noc-team thinking. -r From michael.dillon at bt.com Wed Sep 15 07:54:23 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 15 Sep 2010 12:54:23 +0100 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <82D087F0-778E-498B-B0DF-C79CFABF8AEF@delong.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <9542ADEA-DC86-4E5F-89C5-C79381624C17@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEEAFD@EMV01-UKBR.domain1.systemhost.net> <82D087F0-778E-498B-B0DF-C79CFABF8AEF@delong.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEEBCD@EMV01-UKBR.domain1.systemhost.net> > I am constantly dismayed by this advice. I don't know why because we are essentially saying the same thing. The difference is that I am oversimplifying assuming that the audience is mainly smaller providers where people haven't taken the time to get up to speed on IPv6. But you are providing fuller and more precise detail because your day job involves teaching providers how to get started with IPv6. I agree with everything that you said, especially this: > Once you have done this calculation, then you should apply for > the address space your design requires rather than merely > going in blind for a /32. However, if you require less than a /32, > then, you should get a /32 minimum allocation. --Michael Dillon From jmaimon at chl.com Wed Sep 15 09:33:14 2010 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 15 Sep 2010 09:33:14 -0400 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <86fwxbgsla.fsf@seastrom.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6DA91@EMV01-UKBR.domain1.systemhost.net> <20100913120150.94bb573c.tim.h@bendtel.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEE5BB@EMV01-UKBR.domain1.systemhost.net> <4C8F7D51.6060106@Cleven.com> <9542ADEA-DC86-4E5F-89C5-C79381624C17@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CEEEAFD@EMV01-UKBR.domain1.systemhost.net> <82D087F0-778E-498B-B0DF-C79CFABF8AEF@delong.com> <86fwxbgsla.fsf@seastrom.com> Message-ID: <4C90CB1A.3080704@chl.com> Robert E. Seastrom wrote: > > Owen DeLong writes: > >> 2. Figure out how many /48s you need in your largest POP. >> (Ideally, round up to a nibble boundary, but, there is not RIR >> policy to support this (yet)). >> >> 3. Figure out how many POPs you are likely to have in ~5 years. >> (Ideally you'd round this up to a nibble boundary as well, but, >> again, RIR policy needs to catch up on this one, it's not quite >> there yet). > > I would support policy proposals for nybble float-up on both of these > points. Subnetting or allocating on non-nybble-boundaries is > IPv4-austerity-mode thinking, and needs to be supplanted by > make-it-easy-on-the-engineers-and-noc-team thinking. > > -r > > I would also support policy that attempts to lessen the divide between end users who will never need more addresses and providers who will likely need more due to the former. Joe From charles at office.tcsn.net Wed Sep 15 14:23:32 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 15 Sep 2010 11:23:32 -0700 Subject: [arin-discuss] Trying to Understand IPV6 In-Reply-To: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> Message-ID: <4C910F24.8000503@office.tcsn.net> On 9/14/10 8:03 PM, Randy Carpenter wrote: > Everyone arguing that NAT is a good thing should have been involved a decade ago when it was decided that IPv6 was not going to have NAT. The NAT argument is over. > Because RFC's are never, ever revised, amended, or depreciated in favor of something newer? IMHO, no matter what one's stance on this topic might be, the discussion itself isn't invalid merely because 'it was decided' in the past. However, the discussion might be better served if on a list that actually has input on the RFC process. > I wish we would all stop arguing about these issues, and the hardware manufacturers would get some things on the market. We are running dangerously close to needing IPv6 for user expansion, and we have no way to deploy it. > The units exist, though you may need to experiment to see which models work best with your EU provisioning. The real trick from my perspective is be convincing the EU's to buy said equipment since they perceive no benefits (yet). > -Randy > > > ----- Original Message ----- >> On Sep 14, 2010, at 7:56 PM, Joe Maimon wrote: >> >>> SPI costs product development and support. SPI causes state table >>> exhaustion issues for p2p and similar multitude of connections >>> traffic. Port scanning through an SPI isnt any fun, as an example. >>> SPI default deny creates support issues and product perception >>> issues when end users believe or are told that they need to manually >>> tune or turn it off. >>> >>> Is it not possible that "Turn off the firewall on your router" wont >>> become part of the standard support script? >> SPI Default Deny saves frazzled IT staff lots of time and hair >> follicles when the end user calls software vendor support themselves >> instead of calling IT, they have local admin, and the support person >> says "turn off the firewall on your machine." Yes, "turn off your home >> firewall _will_ become part of the standard support script for >> application support vendors (especially consumer apps) where the goal >> typically is to "fix the problem," not worrying about the other >> problems that it will create for other people down the line. Some >> clever company will probably even write a little application that the >> customer can run that will go out and use uPNP or some similar method >> to do it for them. >> >> NAT is ugly, but completely open access will be uglier for the rest of >> the Internet. Worm writers will find ways to optimize scanning local >> and remote networks. Phishers will entice people to click on the shiny >> thing and willingly infect their own box. Default deny in can help >> mitigate the damage to those around them. >> >> --Chris >> >> _______________________________________________ >> ARIN-Discuss >> You are receiving this message because you are subscribed to >> the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-discuss >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From jason at jaggartech.com Wed Sep 15 16:15:15 2010 From: jason at jaggartech.com (Jason Hensley) Date: Wed, 15 Sep 2010 15:15:15 -0500 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <4C910F24.8000503@office.tcsn.net> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> Message-ID: <2ec801cb5512$b5914580$20b3d080$@com> Anyone have any idea why Facebook would have a full /20 assigned to them? Seems to me a fine example of the waste that we have out there with IP's. Google is another - they own a /16. Ugh!! Yeah, I know, we all complain about it, but come on! That just doesn't make sense. From owen at delong.com Wed Sep 15 16:35:48 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Sep 2010 13:35:48 -0700 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <2ec801cb5512$b5914580$20b3d080$@com> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> Message-ID: <6895A9A7-4A34-4626-9CCB-E7084B84D3AC@delong.com> On Sep 15, 2010, at 1:15 PM, Jason Hensley wrote: > Anyone have any idea why Facebook would have a full /20 assigned to them? > Seems to me a fine example of the waste that we have out there with IP's. > A /20 is only 4,096 hosts. Do you really think that Facebook, arguably one of the largest volume web sites today, does not have at least 4,096 hosts engaged in providing their service? > Google is another - they own a /16. Ugh!! > Google uses vast quantities of machines doing massively parallel operations. I would be utterly surprised if they do not have at least 50,000 hosts involved in providing their service. > Yeah, I know, we all complain about it, but come on! That just doesn't make > sense. > How does it not make sense? I'm simply not understanding your perceived issue. Owen P.S. The solution to address scarcity is simple. IPv6 is the answer. Fanatical restrictions of the other guy's addressing plan are not. From scottleibrand at gmail.com Wed Sep 15 16:39:55 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 15 Sep 2010 13:39:55 -0700 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <2ec801cb5512$b5914580$20b3d080$@com> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> Message-ID: <4C912F1B.4000508@gmail.com> Do you have an estimate of how many servers it takes to provide the services they provide at the scale they provide them? I suspect it's a lot more than you might intuitively expect, and that they in fact are efficiently utilizing their space. -Scott On Wed 9/15/2010 1:15 PM, Jason Hensley wrote: > Anyone have any idea why Facebook would have a full /20 assigned to them? > Seems to me a fine example of the waste that we have out there with IP's. > > Google is another - they own a /16. Ugh!! > > Yeah, I know, we all complain about it, but come on! That just doesn't make > sense. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From rcarpen at network1.net Wed Sep 15 16:41:34 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 15 Sep 2010 16:41:34 -0400 (EDT) Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <2ec801cb5512$b5914580$20b3d080$@com> Message-ID: <600557916.278.1284583293998.JavaMail.root@zimbra.network1.net> First of all, where are you seeing that? A searched shows Google with an IPv6 allocation /32, and Facebook with a /40. Both seem reasonable considering their size. Unless you are talking about IPv4, in which case both of them have much more than just a /20 and /16 respectively, and are likewise pretty sensible allocations, IMO. Considering Google has in the neighborhood of a million servers (or more), do you expect them do only use a /24 or something? A /8 that was issued to an entity in the '80s, and is no longer used at all is a much bigger waste. It is all moot because of IPv6, of course. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > Anyone have any idea why Facebook would have a full /20 assigned to > them? > Seems to me a fine example of the waste that we have out there with > IP's. > > Google is another - they own a /16. Ugh!! > > Yeah, I know, we all complain about it, but come on! That just doesn't > make > sense. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From joelja at bogus.com Wed Sep 15 16:43:51 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 15 Sep 2010 13:43:51 -0700 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <2ec801cb5512$b5914580$20b3d080$@com> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> Message-ID: <7DCB76D2-8EF6-48A0-954A-F7EC551856C0@bogus.com> Ever tried doing route optimization for dozens of dc locations and markets across hundreds of peers? You don't know what all is behind that and here's a hint it's not all content. Joel's iPad On Sep 15, 2010, at 13:15, "Jason Hensley" wrote: > Anyone have any idea why Facebook would have a full /20 assigned to them? > Seems to me a fine example of the waste that we have out there with IP's. > > Google is another - they own a /16. Ugh!! > > Yeah, I know, we all complain about it, but come on! That just doesn't make > sense. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > From morrowc.lists at gmail.com Wed Sep 15 16:46:06 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 15 Sep 2010 16:46:06 -0400 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <2ec801cb5512$b5914580$20b3d080$@com> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> Message-ID: On Wed, Sep 15, 2010 at 4:15 PM, Jason Hensley wrote: > Anyone have any idea why Facebook would have a full /20 assigned to them? > Seems to me a fine example of the waste that we have out there with IP's. > > Google is another - they own a /16. ?Ugh!! > > Yeah, I know, we all complain about it, but come on! ?That just doesn't make > sense. keeping aside two things: 1) my employer (google) 2) previous emails to this thread How long does a /8 last in global allocations today? (<3months) How many /16's are in a /8? (256) How many hours does it take to allocate a /16 globally today? (8.5hrs) How is this helping the migration to ipv6? -Chris From matthew at crocker.com Wed Sep 15 16:46:45 2010 From: matthew at crocker.com (Matthew S. Crocker) Date: Wed, 15 Sep 2010 16:46:45 -0400 (EDT) Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <889435584.409581.1284583476072.JavaMail.root@zimbra1.crocker.com> Message-ID: <1678075564.409604.1284583605233.JavaMail.root@zimbra1.crocker.com> Recovering underutilized IPv4 space will only delay IPv4 space exhaustion by a couple months. The effort needed to recover the space isn't worth the return. Not saying that Google or Facebook space is under-utilized, just that it doesn't make sense to go after it. Spend your effort ($$) on moving to IPv6 and never have to worry about space again. -Matt ----- Original Message ----- > From: "Matthew S. Crocker" > To: "Jason Hensley" > Cc: arin-discuss at arin.net > Sent: Wednesday, September 15, 2010 4:44:36 PM > Subject: Re: [arin-discuss] Facebook /20, Google /16 > > Recovering underutilized IPv4 space will only delay IPv4 space > exhaustion by a couple months. The effort needed to recover the > space isn't worth the return. Not saying that Google or Facebook > space is under-utilized, just that it doesn't make sense to go after > it. Spend your effort ($$) on moving to IPv6 and never have to worry > about space again. > > -Matt > > > ----- Original Message ----- > > > From: "Jason Hensley" > > To: arin-discuss at arin.net > > Sent: Wednesday, September 15, 2010 4:15:15 PM > > Subject: [arin-discuss] Facebook /20, Google /16 > > > > Anyone have any idea why Facebook would have a full /20 assigned to > > them? > > Seems to me a fine example of the waste that we have out there with > > IP's. > > > > Google is another - they own a /16. Ugh!! > > > > Yeah, I know, we all complain about it, but come on! That just > > doesn't make > > sense. > > > > _______________________________________________ > > ARIN-Discuss > > You are receiving this message because you are subscribed to > > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-discuss > > Please contact info at arin.net if you experience any issues. > > -- > Matthew S. Crocker > President > Crocker Communications, Inc. > PO BOX 710 > Greenfield, MA 01302-0710 > http://www.crocker.com > P: 413-746-2760 From jradel at vantage.com Wed Sep 15 16:47:42 2010 From: jradel at vantage.com (Jon Radel) Date: Wed, 15 Sep 2010 16:47:42 -0400 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <2ec801cb5512$b5914580$20b3d080$@com> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> Message-ID: <4C9130EE.8050808@vantage.com> On 9/15/10 4:15 PM, Jason Hensley wrote: > Anyone have any idea why Facebook would have a full /20 assigned to them? > Seems to me a fine example of the waste that we have out there with IP's. Well, as of October 2009 public information on the topic has that they were running 30,000 servers. Strikes me that doing that with a mere 4,096 address shows significant restraint and thriftiness. Are you sure they don't have more addresses than a mere /20? They are one of the larger destinations on the Internet, you know. -- Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3648 bytes Desc: S/MIME Cryptographic Signature URL: From ipaddressing at atlanticbb.com Wed Sep 15 16:46:17 2010 From: ipaddressing at atlanticbb.com (ipaddressing) Date: Wed, 15 Sep 2010 16:46:17 -0400 Subject: [arin-discuss] Facebook /20, Google /16 References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net><4C910F24.8000503@office.tcsn.net><2ec801cb5512$b5914580$20b3d080$@com> <7DCB76D2-8EF6-48A0-954A-F7EC551856C0@bogus.com> Message-ID: <9EBE4EA352DA4D47AD4AD99A39EAD9CF43200F@ABBEX01.abb.msad> I think the biggest thing that needs said about this entire thread is, yes perhaps there are some frivolous allocations out there (google and facebooks, though, I dont believe fall in this category). However, we'd still be in the same boat we're in now, where IPv6 is necessary. It may have happened at a slightly later date if ARIN and the likes had been a little more stingy with their allocations, but we'd still be at the same point in the end. ________________________________ From: arin-discuss-bounces at arin.net on behalf of Joel Jaeggli Sent: Wed 9/15/2010 4:43 PM To: Jason Hensley Cc: Subject: Re: [arin-discuss] Facebook /20, Google /16 Ever tried doing route optimization for dozens of dc locations and markets across hundreds of peers? You don't know what all is behind that and here's a hint it's not all content. Joel's iPad On Sep 15, 2010, at 13:15, "Jason Hensley" wrote: > Anyone have any idea why Facebook would have a full /20 assigned to them? > Seems to me a fine example of the waste that we have out there with IP's. > > Google is another - they own a /16. Ugh!! > > Yeah, I know, we all complain about it, but come on! That just doesn't make > sense. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.ryu at kdlinc.com Wed Sep 15 16:43:07 2010 From: alex.ryu at kdlinc.com (Alex Ryu) Date: Wed, 15 Sep 2010 15:43:07 -0500 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <2ec801cb5512$b5914580$20b3d080$@com> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> Message-ID: <278B5E4BCD5E654385A9F83C7CA6D517EAD881CE07@MAILBOX-01.qcommcorp.ad> They may have a lot of distributed systems to require their own unique IP addresses. Also, redundant geographic locations for disaster recovery? Do not assume that their service will be served by single or a few hosts. I believe ARIN hostmaters are doing due diligence to check efficient usage of their IP address for justification. Alex -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Jason Hensley Sent: Wednesday, September 15, 2010 3:15 PM To: arin-discuss at arin.net Subject: [arin-discuss] Facebook /20, Google /16 Anyone have any idea why Facebook would have a full /20 assigned to them? Seems to me a fine example of the waste that we have out there with IP's. Google is another - they own a /16. Ugh!! Yeah, I know, we all complain about it, but come on! That just doesn't make sense. _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. From keefe at techwarepc.com Wed Sep 15 16:50:09 2010 From: keefe at techwarepc.com (Keefe John) Date: Wed, 15 Sep 2010 15:50:09 -0500 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <2ec801cb5512$b5914580$20b3d080$@com> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> Message-ID: <02e101cb5517$978f22a0$c6ad67e0$@techwarepc.com> While we're complaining, why does HAM radio have a full /8 that's barely used, if at all? Keefe -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Jason Hensley Sent: Wednesday, September 15, 2010 3:15 PM To: arin-discuss at arin.net Subject: [arin-discuss] Facebook /20, Google /16 Anyone have any idea why Facebook would have a full /20 assigned to them? Seems to me a fine example of the waste that we have out there with IP's. Google is another - they own a /16. Ugh!! Yeah, I know, we all complain about it, but come on! That just doesn't make sense. _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. From berger at shout.net Wed Sep 15 17:04:11 2010 From: berger at shout.net (Mike Berger) Date: Wed, 15 Sep 2010 16:04:11 -0500 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <02e101cb5517$978f22a0$c6ad67e0$@techwarepc.com> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> <02e101cb5517$978f22a0$c6ad67e0$@techwarepc.com> Message-ID: <4C9134CB.1070606@shout.net> I don't know how well utilized it is, but there were a lot of packet radio operators, and each needs a unique address. There are a few hundred thousand licensed amateur radio operators. I think anybody complaining about someone elses' allocation based on conjecture ought to open their own up to scrutiny. On 9/15/10 3:50 PM, Keefe John wrote: > While we're complaining, why does HAM radio have a full /8 that's barely > used, if at all? > > From leland at gandi.net Wed Sep 15 17:23:55 2010 From: leland at gandi.net (Leland Vandervort) Date: Wed, 15 Sep 2010 23:23:55 +0200 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <02e101cb5517$978f22a0$c6ad67e0$@techwarepc.com> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> <02e101cb5517$978f22a0$c6ad67e0$@techwarepc.com> Message-ID: I had actually asked that question last week of ARIN... got a somewhat vague response about it being a legacy network originally for "experimentation and public service attributed directly by IANA so they have no mandate to require or request its return"... The whole 44.0.0.0/8 is in the global BGP tables, but drops into a black hole at UCSD. Apparently there was originally an intention to link the AMPR and internet, hence the globally routed IP space, but the FCC apparently scapped that idea, so the two networks are prohibited from interconnecting directly without the use of a relay-gateway. Leland AA2QX / G0SZP :) Leland Vandervort Director, Technical Operations Gandi SAS 15 Place de la Nation 75011 Paris, France WWW: http://www.gandi.net/ T: +33 1 70 39 37 59 M: +33 6 31 15 15 07 On 15 Sep 2010, at 22:50, Keefe John wrote: > While we're complaining, why does HAM radio have a full /8 that's barely > used, if at all? > > Keefe > > -----Original Message----- > From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] > On Behalf Of Jason Hensley > Sent: Wednesday, September 15, 2010 3:15 PM > To: arin-discuss at arin.net > Subject: [arin-discuss] Facebook /20, Google /16 > > Anyone have any idea why Facebook would have a full /20 assigned to them? > Seems to me a fine example of the waste that we have out there with IP's. > > Google is another - they own a /16. Ugh!! > > Yeah, I know, we all complain about it, but come on! That just doesn't make > sense. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to the ARIN > Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2665 bytes Desc: not available URL: From owen at delong.com Wed Sep 15 17:28:59 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Sep 2010 14:28:59 -0700 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <4C9134CB.1070606@shout.net> References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> <02e101cb5517$978f22a0$c6ad67e0$@techwarepc.com> <4C9134CB.1070606@shout.net> Message-ID: <05BB806C-EA60-4BC9-A137-9C809BB8094D@delong.com> According to http://en.wikipedia.org/wiki/Amateur_radio_operator There are 722,330 licensed amateur radio operators in the US alone. (2007) There are more than 1.2 Million in Japan. (1999) Many of them use TCP/IP over Amateur radio with more than one node. Owen On Sep 15, 2010, at 2:04 PM, Mike Berger wrote: > I don't know how well utilized it is, but there were a lot of packet radio operators, and each needs a unique address. There are a few hundred thousand licensed amateur radio operators. > > I think anybody complaining about someone elses' allocation based on conjecture ought to open their own up to scrutiny. > > On 9/15/10 3:50 PM, Keefe John wrote: >> While we're complaining, why does HAM radio have a full /8 that's barely >> used, if at all? >> >> > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From ptimmins at clearrate.com Wed Sep 15 17:35:08 2010 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Wed, 15 Sep 2010 21:35:08 +0000 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> <02e101cb5517$978f22a0$c6ad67e0$@techwarepc.com>, Message-ID: Furthermore it's also not mandated that all allocations be globally reachable. ANX is a good example of a network that uses public IPv4 space that is globally unique but often completely unreachable from the internet. One can request allocations in 44.x.x.x and there are groups that coordinate it for on-the-air use. Just because it can't directly gateway to the internet does not make it pointless or useless. -Paul (KC8QAY) Paul Timmins Clear Rate Communications Customer Support: (877) 877-4799 24 Hour Repair: (866) 366-4665 www.clearrate.com ________________________________________ From: arin-discuss-bounces at arin.net [arin-discuss-bounces at arin.net] on behalf of Leland Vandervort [leland at gandi.net] Sent: Wednesday, September 15, 2010 5:23 PM To: Keefe John Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] Facebook /20, Google /16 I had actually asked that question last week of ARIN... got a somewhat vague response about it being a legacy network originally for "experimentation and public service attributed directly by IANA so they have no mandate to require or request its return"... The whole 44.0.0.0/8 is in the global BGP tables, but drops into a black hole at UCSD. Apparently there was originally an intention to link the AMPR and internet, hence the globally routed IP space, but the FCC apparently scapped that idea, so the two networks are prohibited from interconnecting directly without the use of a relay-gateway. Leland AA2QX / G0SZP :) Leland Vandervort Director, Technical Operations Gandi SAS 15 Place de la Nation 75011 Paris, France WWW: http://www.gandi.net/ T: +33 1 70 39 37 59 M: +33 6 31 15 15 07 On 15 Sep 2010, at 22:50, Keefe John wrote: > While we're complaining, why does HAM radio have a full /8 that's barely > used, if at all? > > Keefe > > -----Original Message----- > From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] > On Behalf Of Jason Hensley > Sent: Wednesday, September 15, 2010 3:15 PM > To: arin-discuss at arin.net > Subject: [arin-discuss] Facebook /20, Google /16 > > Anyone have any idea why Facebook would have a full /20 assigned to them? > Seems to me a fine example of the waste that we have out there with IP's. > > Google is another - they own a /16. Ugh!! > > Yeah, I know, we all complain about it, but come on! That just doesn't make > sense. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to the ARIN > Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From nate.lyon at nfldwifi.net Wed Sep 15 17:47:39 2010 From: nate.lyon at nfldwifi.net (Nathaniel B. Lyon) Date: Wed, 15 Sep 2010 16:47:39 -0500 Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: References: <945604348.5604.1284519808278.JavaMail.root@zimbra.network1.net> <4C910F24.8000503@office.tcsn.net> <2ec801cb5512$b5914580$20b3d080$@com> <02e101cb5517$978f22a0$c6ad67e0$@techwarepc.com>, , Message-ID: <24F349B8030E5A47A8BDC2FE0E13D13E03F9912E7D@nfldnet6.NFLDWIFI.LOCAL> I am really surprised Ted Middlestad (spelling?) hasn't chimed in on this conversation. I always enjoy his views on such topics. :) Ted you out there? Nathaniel B. Lyon Owner, NorthfieldWiFi (612) 991-4260 www.northfieldwifi.com nate.lyon at nfldwifi.net The information in this e-mail is intended for the use of the individual or entity to which it is addressed, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, use of, or reliance on, the contents of this e-mail is prohibited. If you have received this e-mail in error, please notify us immediately by replying back to the sending e-mail address, and delete this e-mail message from your computer. ________________________________________ From: arin-discuss-bounces at arin.net [arin-discuss-bounces at arin.net] On Behalf Of Paul G. Timmins [ptimmins at clearrate.com] Sent: Wednesday, September 15, 2010 4:35 PM To: Leland Vandervort; Keefe John Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] Facebook /20, Google /16 Furthermore it's also not mandated that all allocations be globally reachable. ANX is a good example of a network that uses public IPv4 space that is globally unique but often completely unreachable from the internet. One can request allocations in 44.x.x.x and there are groups that coordinate it for on-the-air use. Just because it can't directly gateway to the internet does not make it pointless or useless. -Paul (KC8QAY) Paul Timmins Clear Rate Communications Customer Support: (877) 877-4799 24 Hour Repair: (866) 366-4665 www.clearrate.com ________________________________________ From: arin-discuss-bounces at arin.net [arin-discuss-bounces at arin.net] on behalf of Leland Vandervort [leland at gandi.net] Sent: Wednesday, September 15, 2010 5:23 PM To: Keefe John Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] Facebook /20, Google /16 I had actually asked that question last week of ARIN... got a somewhat vague response about it being a legacy network originally for "experimentation and public service attributed directly by IANA so they have no mandate to require or request its return"... The whole 44.0.0.0/8 is in the global BGP tables, but drops into a black hole at UCSD. Apparently there was originally an intention to link the AMPR and internet, hence the globally routed IP space, but the FCC apparently scapped that idea, so the two networks are prohibited from interconnecting directly without the use of a relay-gateway. Leland AA2QX / G0SZP :) Leland Vandervort Director, Technical Operations Gandi SAS 15 Place de la Nation 75011 Paris, France WWW: http://www.gandi.net/ T: +33 1 70 39 37 59 M: +33 6 31 15 15 07 On 15 Sep 2010, at 22:50, Keefe John wrote: > While we're complaining, why does HAM radio have a full /8 that's barely > used, if at all? > > Keefe > > -----Original Message----- > From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] > On Behalf Of Jason Hensley > Sent: Wednesday, September 15, 2010 3:15 PM > To: arin-discuss at arin.net > Subject: [arin-discuss] Facebook /20, Google /16 > > Anyone have any idea why Facebook would have a full /20 assigned to them? > Seems to me a fine example of the waste that we have out there with IP's. > > Google is another - they own a /16. Ugh!! > > Yeah, I know, we all complain about it, but come on! That just doesn't make > sense. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to the ARIN > Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Thu Sep 16 22:56:33 2010 From: tedm at ipinc.net (tedm at ipinc.net) Date: Thu, 16 Sep 2010 19:56:33 -0700 (PDT) Subject: [arin-discuss] Facebook /20, Google /16 In-Reply-To: <24F349B8030E5A47A8BDC2FE0E13D13E03F9912E7D@nfldnet6.NFLDWIFI.LOCAL> Message-ID: I've chimed in on these sorts of things before. At one time I was a huge proponent of IPv4 recovery. And I am still very much in favor of ARIN retrieving abandonded IPv4 blocks and putting them into use. But over the years it's become very clear that there is a balance between putting effort into reclamation of IPv4 and into deployment of IPv6. It is fine for the RIR's to go after abandonded IPv4 blocks. All of them have internal mechanisms to deal with this kind of thing and the legacy holders are the biggest culprits of abandonding IPv4. In short, even if the abandonded block is a /24 it really does not take skin off anyone's nose for the RIR to get off it's duff and take it over. But when your talking about blocks like the 44.0.0.0/8 which anyone with a quarter of a brain can see is far too large for it's defined use, there's a morass of politics for the RIR to wade through to prod the block holder to subnet. And the block holder isn't going to be able to subnet and sell-off parts of the 44.0.0.0/8 block through the transfer market because the basis of the original assignment was for the public good and the block holder is entrusted to administer it for the public. So the holder has no incentive to spend time on doing it. If you want to complain check out what DoD has allocated, it dwarfs most of these. And there's no possible way you can argue that DoD IP addresses ever need to be reachable from the Internet. There will be need for IPv4 for years - but as soon as the larger holders (Comcast, the cell carriers, etc.) start getting partially filled requests, the IPv4 party will be over. The large networks will move to IPv6 and start returning their IPv4 allocations and the market will be flooded with IPv4 nobody wants. There will be maybe 2-3 years where it will be tight, but that's going to be it. I predict that the time will come that anyone who wants to could cobble together a bunch of baloney and obtain without challenge a /8 of IPv4 from the RIRs. But nobody will want to because doing it would be like announcing you have reserved the Arcnet numbers 1-128 for a new series of PCI ArcnetPlus cards your going to produce. Ted On Wed, 15 Sep 2010, Nathaniel B. Lyon wrote: > I am really surprised Ted Middlestad (spelling?) hasn't chimed in on this conversation. I always enjoy his views on such topics. :) Ted you out there? > > Nathaniel B. Lyon > Owner, NorthfieldWiFi > (612) 991-4260 > www.northfieldwifi.com > nate.lyon at nfldwifi.net > > The information in this e-mail is intended for the use of the individual or entity to which it is addressed, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, use of, or reliance on, the contents of this e-mail is prohibited. If you have received this e-mail in error, please notify us immediately by replying back to the sending e-mail address, and delete this e-mail message from your computer. > ________________________________________ > From: arin-discuss-bounces at arin.net [arin-discuss-bounces at arin.net] On Behalf Of Paul G. Timmins [ptimmins at clearrate.com] > Sent: Wednesday, September 15, 2010 4:35 PM > To: Leland Vandervort; Keefe John > Cc: arin-discuss at arin.net > Subject: Re: [arin-discuss] Facebook /20, Google /16 > > Furthermore it's also not mandated that all allocations be globally reachable. ANX is a good example of a network that uses public IPv4 space that is globally unique but often completely unreachable from the internet. > > One can request allocations in 44.x.x.x and there are groups that coordinate it for on-the-air use. Just because it can't directly gateway to the internet does not make it pointless or useless. > > -Paul (KC8QAY) > > > Paul Timmins > Clear Rate Communications > Customer Support: (877) 877-4799 > 24 Hour Repair: (866) 366-4665 > www.clearrate.com > > > ________________________________________ > From: arin-discuss-bounces at arin.net [arin-discuss-bounces at arin.net] on behalf of Leland Vandervort [leland at gandi.net] > Sent: Wednesday, September 15, 2010 5:23 PM > To: Keefe John > Cc: arin-discuss at arin.net > Subject: Re: [arin-discuss] Facebook /20, Google /16 > > I had actually asked that question last week of ARIN... got a somewhat vague response about it being a legacy network originally for "experimentation and public service attributed directly by IANA so they have no mandate to require or request its return"... > > The whole 44.0.0.0/8 is in the global BGP tables, but drops into a black hole at UCSD. > > Apparently there was originally an intention to link the AMPR and internet, hence the globally routed IP space, but the FCC apparently scapped that idea, so the two networks are prohibited from interconnecting directly without the use of a relay-gateway. > > Leland > AA2QX / G0SZP > > :) > > > > Leland Vandervort > Director, Technical Operations > Gandi SAS > 15 Place de la Nation > 75011 Paris, France > > WWW: http://www.gandi.net/ > > T: +33 1 70 39 37 59 > M: +33 6 31 15 15 07 > > > > On 15 Sep 2010, at 22:50, Keefe John wrote: > >> While we're complaining, why does HAM radio have a full /8 that's barely >> used, if at all? >> >> Keefe >> >> -----Original Message----- >> From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] >> On Behalf Of Jason Hensley >> Sent: Wednesday, September 15, 2010 3:15 PM >> To: arin-discuss at arin.net >> Subject: [arin-discuss] Facebook /20, Google /16 >> >> Anyone have any idea why Facebook would have a full /20 assigned to them? >> Seems to me a fine example of the waste that we have out there with IP's. >> >> Google is another - they own a /16. Ugh!! >> >> Yeah, I know, we all complain about it, but come on! That just doesn't make >> sense. >> >> _______________________________________________ >> ARIN-Discuss >> You are receiving this message because you are subscribed to the ARIN >> Discussion Mailing List (ARIN-discuss at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-discuss >> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> ARIN-Discuss >> You are receiving this message because you are subscribed to >> the ARIN Discussion Mailing List (ARIN-discuss at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-discuss >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > From michael.dillon at bt.com Wed Sep 15 06:27:09 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 15 Sep 2010 11:27:09 +0100 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921045547.2CA0412E29BE@sa.esc7.net> An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Wed Sep 15 06:37:13 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 15 Sep 2010 11:37:13 +0100 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921045606.B7F1C12E2C25@sa.esc7.net> An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Wed Sep 15 06:37:13 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 15 Sep 2010 11:37:13 +0100 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921045606.B02A512E2C23@sa.esc7.net> An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Wed Sep 15 16:39:55 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 15 Sep 2010 13:39:55 -0700 Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062414.052861E053E8@sa.esc7.net> An HTML attachment was scrubbed... URL: From matthew at crocker.com Wed Sep 15 16:46:45 2010 From: matthew at crocker.com (Matthew S. Crocker) Date: Wed, 15 Sep 2010 16:46:45 -0400 (EDT) Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062451.D48BA1E033DF@sa.esc7.net> An HTML attachment was scrubbed... URL: From berger at shout.net Tue Sep 14 16:00:55 2010 From: berger at shout.net (Mike Berger) Date: Tue, 14 Sep 2010 15:00:55 -0500 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921064828.98F8385A8F5@sa.esc7.net> An HTML attachment was scrubbed... URL: From rcarpen at network1.net Tue Sep 21 07:22:12 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 21 Sep 2010 07:22:12 -0400 (EDT) Subject: [arin-discuss] repeated messages? Message-ID: <1577411264.1314.1285068131973.JavaMail.root@zimbra.network1.net> Is there an echo in here? I have been getting repeats of messages that are many days old. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- From cboyd at gizmopartners.com Tue Sep 14 22:21:20 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 14 Sep 2010 21:21:20 -0500 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921081255.A03AC1298C8E@sa.esc7.net> An HTML attachment was scrubbed... URL: From cboyd at gizmopartners.com Tue Sep 14 22:21:20 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 14 Sep 2010 21:21:20 -0500 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921081255.AF0001298C90@sa.esc7.net> An HTML attachment was scrubbed... URL: From rcarpen at network1.net Tue Sep 14 23:03:28 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Sep 2010 23:03:28 -0400 (EDT) Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921081321.26F4D1298D76@sa.esc7.net> An HTML attachment was scrubbed... URL: From cboyd at gizmopartners.com Tue Sep 14 22:21:20 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 14 Sep 2010 21:21:20 -0500 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921081251.BE0251298AB0@sa.esc7.net> An HTML attachment was scrubbed... URL: From rcarpen at network1.net Tue Sep 14 23:03:28 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Sep 2010 23:03:28 -0400 (EDT) Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921081314.EE3641298B9A@sa.esc7.net> An HTML attachment was scrubbed... URL: From rcarpen at network1.net Tue Sep 14 23:03:28 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Sep 2010 23:03:28 -0400 (EDT) Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921081315.02AC01298B9E@sa.esc7.net> An HTML attachment was scrubbed... URL: From rcarpen at network1.net Tue Sep 14 17:21:20 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Sep 2010 14:21:20 -0700 (PDT) Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921070831.6A68E1F5A175@sa.esc7.net> An HTML attachment was scrubbed... URL: From rcarpen at network1.net Tue Sep 14 17:21:20 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Sep 2010 14:21:20 -0700 (PDT) Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921070825.2E9431F5A10A@sa.esc7.net> An HTML attachment was scrubbed... URL: From rcarpen at network1.net Tue Sep 14 17:21:20 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Sep 2010 14:21:20 -0700 (PDT) Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921070831.5EEB01F5A173@sa.esc7.net> An HTML attachment was scrubbed... URL: From berger at shout.net Tue Sep 14 16:00:55 2010 From: berger at shout.net (Mike Berger) Date: Tue, 14 Sep 2010 15:00:55 -0500 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921064836.5BE8285A9C7@sa.esc7.net> An HTML attachment was scrubbed... URL: From berger at shout.net Tue Sep 14 16:00:55 2010 From: berger at shout.net (Mike Berger) Date: Tue, 14 Sep 2010 15:00:55 -0500 Subject: [arin-discuss] Trying to Understand IPV6 Message-ID: <20100921064836.52EAE85A99E@sa.esc7.net> An HTML attachment was scrubbed... URL: From berger at shout.net Wed Sep 15 17:04:11 2010 From: berger at shout.net (Mike Berger) Date: Wed, 15 Sep 2010 16:04:11 -0500 Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062638.315C81E05DCE@sa.esc7.net> An HTML attachment was scrubbed... URL: From berger at shout.net Wed Sep 15 17:04:11 2010 From: berger at shout.net (Mike Berger) Date: Wed, 15 Sep 2010 16:04:11 -0500 Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062635.AFD211E05DDF@sa.esc7.net> An HTML attachment was scrubbed... URL: From berger at shout.net Wed Sep 15 17:04:11 2010 From: berger at shout.net (Mike Berger) Date: Wed, 15 Sep 2010 16:04:11 -0500 Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062638.2C3491E05DC5@sa.esc7.net> An HTML attachment was scrubbed... URL: From jradel at vantage.com Wed Sep 15 16:47:42 2010 From: jradel at vantage.com (Jon Radel) Date: Wed, 15 Sep 2010 16:47:42 -0400 Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062501.848011E05809@sa.esc7.net> An HTML attachment was scrubbed... URL: From jradel at vantage.com Wed Sep 15 16:47:42 2010 From: jradel at vantage.com (Jon Radel) Date: Wed, 15 Sep 2010 16:47:42 -0400 Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062501.7969A1E05807@sa.esc7.net> An HTML attachment was scrubbed... URL: From jradel at vantage.com Wed Sep 15 16:47:42 2010 From: jradel at vantage.com (Jon Radel) Date: Wed, 15 Sep 2010 16:47:42 -0400 Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062457.230721E05773@sa.esc7.net> An HTML attachment was scrubbed... URL: From matthew at crocker.com Wed Sep 15 16:46:45 2010 From: matthew at crocker.com (Matthew S. Crocker) Date: Wed, 15 Sep 2010 16:46:45 -0400 (EDT) Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062455.BE0751E05780@sa.esc7.net> An HTML attachment was scrubbed... URL: From matthew at crocker.com Wed Sep 15 16:46:45 2010 From: matthew at crocker.com (Matthew S. Crocker) Date: Wed, 15 Sep 2010 16:46:45 -0400 (EDT) Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062455.D640E1E041BA@sa.esc7.net> An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Wed Sep 15 16:39:55 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 15 Sep 2010 13:39:55 -0700 Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062419.0AAD71E0547E@sa.esc7.net> An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Wed Sep 15 16:39:55 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 15 Sep 2010 13:39:55 -0700 Subject: [arin-discuss] Facebook /20, Google /16 Message-ID: <20100921062419.03BC81E0547C@sa.esc7.net> An HTML attachment was scrubbed... URL: From jradel at vantage.com Tue Sep 21 13:26:14 2010 From: jradel at vantage.com (Jon Radel) Date: Tue, 21 Sep 2010 13:26:14 -0400 Subject: [arin-discuss] repeated messages? In-Reply-To: <1577411264.1314.1285068131973.JavaMail.root@zimbra.network1.net> References: <1577411264.1314.1285068131973.JavaMail.root@zimbra.network1.net> Message-ID: <4C98EAB6.8010301@vantage.com> On 9/21/10 7:22 AM, Randy Carpenter wrote: > Is there an echo in here? I have been getting repeats of messages that are many days old. > > In honor of my mail of 9/15 being one of the first that they've sent out 3 copies of, via 3 different mx hosts on their network, I've called the ESC Region 7 help desk to grumble at them. I didn't bother grumbling about the fact that both their contact e-mail in whois and postmaster@ are rejected, there's only so much that one can achieve in a single day. The help desk claims the issue is being worked on. You can reach them at 903-988-6940. -- Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3648 bytes Desc: S/MIME Cryptographic Signature URL: From info at arin.net Tue Sep 21 15:25:20 2010 From: info at arin.net (ARIN) Date: Tue, 21 Sep 2010 15:25:20 -0400 Subject: [arin-discuss] Message Reposting Issue Resolved Message-ID: <4C9906A0.6060105@arin.net> Good Afternoon, We have received a number of emails about a recent issue on the arin-discuss mailing list. We have isolated the source of the problem, a misconfigured subscriber mailserver was reposting old messages to the list, and we have corrected the issue. We apologize for any inconvenience and look forward to your continued participation. If you have any further questions or concerns regarding this event, please email postmaster at arin.net Regards, Communications and Member Services American Registry for Internet Numbers (ARIN)