[Nanog-futures] Update on NANOG Marketing Working Group
Everyone, The NANOG Marketing Working Group has been working hard to help NANOG find new profitable revenue to ensure the meetings keep getting better without raising prices. The group's most active members are: Betty Burke (Merit, SC) Carol Wadsworth (Merit) Greg Dendy Dave Tempkin Martin Levy Martin Hannigan Sylvie Laperriere Steve Feldman (SC) Patrick Gilmore (Chair, SC) The group is making some progress on finding new, innovative sponsorship opportunities for the NANOG meeting which we believe will not interfere with the spirit of the meeting. These include: * Vendor Collaboration Suite Where vendors can allow hands-on experience with their equipment, one- to-one (or few), probably by appointment. This is our highest value sponsorship opportunity as it grants the vendor exclusive access to the NANOG attendees. $15,000/day * Lanyards A sponsor can have their name interleaved with the NANOG logo on the name badge lanyards. $4,000 * Water Bottles Get your logo on water bottles people will carry around during the conference! $ TBD * Break Slides Sponsor name logo will be put up on the projectors during the break. Included in break sponsorship $ TBD * Party Promotion Sponsor's social activity is put onto the official NANOG agenda, announced at the mic at the end of the day it is occurring, and sponsor even has the option of providing tickets which will be handed out with NANOG collateral pack during check-in. $2,000 And more! We encourage feedback from the community on both our ideas and the implementation thereof. And, of course, anyone who wants to help out is encouraged to join the Marketing WG. We are in especially desperate need of a competent chairperson. :) -- TTFN, patrick ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
Exactly correct. The number one priority, which trumps all others, is making the abuse stop. Yes, there are many other things that can and should be done, but that's the first one. Stopping the abuse is fine, but cutting service to the point that a family using VOIP only for their phone service can't call 911 and several children burn to death could bring all sorts of undesirable regulation let alone the bad press and legal expenses. As far as the Ducth situation with one of the largest providers (KPN) goes this is solved by using a seperate VLAN for VOIP traffic. Only the data VLAN is being blocked or actually policy routed towards a walled garden in which users are able to clean themselves up. -- Nils Kolstein SSCPlus
Re: Minimum IPv6 size
On 04/10/2009 4:49, Kevin Oberman ober...@es.net wrote: [...] So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges. I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn. I don't think so. I believe the statement is not in regard to separate, discrete networks bu to a network with a national footprint which must deaggregate to do traffic engineering by region. Item 2 clearly makes 2009-5 non-applicable to this case. I thought that Geographic distance and diversity between networks covered the case above but I could well be wrong. This issue will be discussed in a Mark Kosters moderated panel at NANOG in Dearborn. Hey, why not attend both meetings? I won't be there in person but look forward to watching the video feed. Regards, Leo
RE: Dutch ISPs to collaborate and take responsibility for botted clients
-Original Message- From: Christopher Morrow [mailto:morrowc.li...@gmail.com] Sent: Sunday, October 04, 2009 4:04 PM To: Peter Beckman Cc: NANOG Subject: Re: Dutch ISPs to collaborate and take responsibility for botted clients On Sun, Oct 4, 2009 at 2:55 PM, Peter Beckman beck...@angryox.com wrote: service being cut off. However it is ignorance and lack of maintenance that makes viruses and botnets so prevelant that it may just be time to bite the bullet and force users to learn how to maintain their machines. because this works so well with: 1) cars 2) home-security 3) personal security wandering around cities/towns I note that I'm not particularly against any of the proposal, just the 'people need a drivers license to get on the interwebz'... it's been tried many times before, always without success. I'm trying to understand your analogy, but it's hidden in the sarcasm. Your assertion is that education (and you've decided to include licensing, for some reason) of drivers and the rest is ineffective? You're not opposed to user education, you just believe it's useless because it will only reduce, not eliminate, badness? Lee
Re: Dutch ISPs to collaborate and take responsibility for botted clients
Gadi Evron wrote: Apparently, marketing departments like the idea of being able to send customers that need to pay them to a walled garden. It also saves on tech support costs. Security being the main winner isn't the main supporter of the idea at some places. I would love to do this both for non-pays and security incidents. I'd like to do something similar to let customers update their provisioning information for static IP changes so cable source verify doesn't freak out. Unfortunately I haven't been able to find any open source tools to do this. I can't even think of commercial ones off the top of my head. It's a relatively simple concept. Some measure of integration into the DHCP provisioning system(s) would be needed to properly route the customer's traffic to the walled garden and only to the walled garden. Once the problem is resolved the walled garden fixes the DHCP so the customer can once again pull a public IP and possibly flushes ARP caches if your access medium makes that a problem to be dealt with. I would think that the walled garden portion could be handled well-enough with Squid and some custom web programming to perform tasks to reverse the provisioning issues. I'm sure people have written internal solutions for SPs before but I haven't found anyone that has made that into an OSS project and put it on the Web. I'd love to make this a project but there is little financial gain to my small SP so if it costs much money it won't get management support. Justin
Re: Dutch ISPs to collaborate and take responsibility for botted clients
Justin Shore wrote: Gadi Evron wrote: Apparently, marketing departments like the idea of being able to send customers that need to pay them to a walled garden. It also saves on tech support costs. Security being the main winner isn't the main supporter of the idea at some places. I would love to do this both for non-pays and security incidents. I'd like to do something similar to let customers update their provisioning information for static IP changes so cable source verify doesn't freak out. Unfortunately I haven't been able to find any open source tools to do this. I can't even think of commercial ones off the top of my head. It's a relatively simple concept. Some measure of integration into the DHCP provisioning system(s) would be needed to properly route the customer's traffic to the walled garden and only to the walled garden. Once the problem is resolved the walled garden fixes the DHCP so the customer can once again pull a public IP and possibly flushes ARP caches if your access medium makes that a problem to be dealt with. I would think that the walled garden portion could be handled well-enough with Squid and some custom web programming to perform tasks to reverse the provisioning issues. I'm sure people have written internal solutions for SPs before but I haven't found anyone that has made that into an OSS project and put it on the Web. I'd love to make this a project but there is little financial gain to my small SP so if it costs much money it won't get management support. Justin There is all sorts of kit that will do this for you, Ellacoya, Redback etc. They all have APIs and all work well. The customer keeps their public IP address, but you can then make it belong to another virtual router instance, or you can apply certain firewall/ACL/policy rules to it. For example, my Ellacoyas will, for a walled customer, deny traffic to anything but the walled garden hosts and will then route any port 80 traffic to my proxy server that re-directs it all to a walled garden web server. Then soon as they hand over their payment details and we take payment, a request is sent to the Ellacoya to remove the restrictions. Lovaly. -- Leigh
operations contact @ facebook?
Hi All, Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Thanks in advance. Leland Vandervort Director, Technical Operations Gandi SAS Paris t: +33 1 70 39 37 59 m: +33 6 31 15 15 07
Re: operations contact @ facebook?
On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. -- TTFN, patrick [*] No, I do not work for FB.
Re: operations contact @ facebook?
Patrick W. Gilmore wrote: On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. The original poster is from Paris. Do consider the possibility that there are different jurisdictional rules or service terms in force from your own. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: operations contact @ facebook?
We have had issues with a FB application basically doing a DOS against a network. This was not on our servers but somewhere out there on the Internet. It was an application that was going rogue. It was talking to several of our user¹s using this application. FaceBook caught it and made the developer fix the App. I am sure we were not the only ones seeing the issue. Justin From: Patrick W. Gilmore patr...@ianai.net Date: Mon, 5 Oct 2009 10:57:28 -0400 To: NANOG list nanog@nanog.org Subject: Re: operations contact @ facebook? On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. -- TTFN, patrick [*] No, I do not work for FB.
Re: operations contact @ facebook?
On Mon, 5 Oct 2009, Patrick W. Gilmore wrote: On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. Sounds like it's an app on facebook that's causing unexpected access to something on their systems...perhaps kind of like being /.'d ? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: operations contact @ facebook?
On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. That's far from the only possibility. The ability of a site such as FB to generate an inadvertent but effective DDoS against a smaller site in a variety of ways is quite significant, and depending on the specifics, failure to mitigate such damage once being made aware of it could even open one up to penalties under regional computer crime laws... of course, that's making a bit of a jump and some assumptions, but it is certainly a different possibility from the one you suggest. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: operations contact @ facebook?
The application is not being hosted on the VPS servers, but rather on the mutualised blog platform and is impacting on other customers of this platform. We have VPS services available for the app developer in question to host his application on should he desire to do so. Leland On Mon, 2009-10-05 at 10:57 -0400, Patrick W. Gilmore wrote: On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front.
Re: operations contact @ facebook?
I guess the facebook app allows any FB user to check availability of domain names or to request Gandi's whois database. From what I saw, FB people do not check every applications neither before or after publication. And that could create some issues out there. Patrick W. Gilmore a écrit : On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front.
Re: operations contact @ facebook?
On Mon, 5 Oct 2009, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. You might be able to reach the right people at o...@facebook.com jms
ISP customer assignments
From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? Thank you. - Brian
Re: Verizon Southeast Network Map
On Mon, 5 Oct 2009, Jason Bertoch wrote: We're considering adding a Verizon connection to our network in Florida, so I've been looking unsuccessfully for a map of Verizon's fiber network in the southeast to verify that I'll have diverse paths with my other providers. Does anyone know if such a map exists in a public location? I haven't seen one, but I'd imagine they have a route that parallels I-95 through Jacksonville to Miami and maybe one that runs up the gulf side via Tampa. Not sure about route diversity in the panhandle but I'd bet there would be at least some for Tallahassee and Pensacola. That might be something that a VZB account manager could provide after the execution of an appropriately flavored NDA. jms
Re: operations contact @ facebook?
Thanks Justin... will give it a shot; hopefully they're relatively rapid :) Leland On Mon, 2009-10-05 at 11:31 -0400, Justin M. Streiner wrote: On Mon, 5 Oct 2009, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. You might be able to reach the right people at o...@facebook.com jms
Re: ISP customer assignments
Brian Johnson wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. ~Seth
Re: operations contact @ facebook?
This is a classic case of one of the problems of the increasingly numerous and powerful Web dev platforms - as you let other people either control your app through an API, or even write code that executes on the server-side, you're increasing the cycles available to an attacker. It's similar to the dns reflector attack. signature.asc Description: This is a digitally signed message part.
RE: ISP customer assignments
So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device! Am I still seeing/reading/understanding this correctly? - Brian -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Monday, October 05, 2009 10:38 AM To: nanog@nanog.org Subject: Re: ISP customer assignments Brian Johnson wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. ~Seth
Re: ISP customer assignments
On Oct 5, 2009, at 17:38, Seth Mattinen wrote: The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. Brrzt, wrong. Neither the end user nor you know the answer to that question! So the only sensible thing is to always give them a /56. (Actually, the IPv6 address architecture design was to give them a / 48. Think about it: We will run out of MAC addresses before we run out of those. But some people can't manage the cognitive dissonance coming from an address starving IPv4 world and then wasting all these 2^80 addresses. My parents, who grew up around WW2, were that way, too, and never could unlearn their saving habits. So the current wise thing is to allocate a /56, wasting only 2^72 addresses per customer. The only way back to a connected Internet.) Gruesse, Carsten
Re: ISP customer assignments
Yes, each and every network segment (especially multi-access ones) should be /64s. Regardless of the types of machines, speed of link, etc. It is an entirely different model of addressing, whose name just happens to start with IP ... /TJ On Mon, Oct 5, 2009 at 12:08 PM, Brian Johnson bjohn...@drtel.com wrote: So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device! Am I still seeing/reading/understanding this correctly? - Brian -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Monday, October 05, 2009 10:38 AM To: nanog@nanog.org Subject: Re: ISP customer assignments Brian Johnson wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. ~Seth -- /TJ
Re: ISP customer assignments
Carsten Bormann wrote: On Oct 5, 2009, at 17:38, Seth Mattinen wrote: The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. Brrzt, wrong. Neither the end user nor you know the answer to that question! So the only sensible thing is to always give them a /56. I'm just relating what's common *right now*, not what I would do personally. ~Seth
IPv6 peering between Internet2 and Hurricane Electric
It seems to be down, based on http://routerproxy.grnoc.iu.edu/internet2/ and trying to get a traceroute to he.net/2001:470:0:76::2 from the SEAT location. BGP seems to be up, though. Shouldn't this cause quite a few problems for Internet2 downstreams? (We received a report from an academic site in Brazil that some security.debian.org IPv6 instances are inaccessible, that's why I looked.) What's the best way to help the SPs involved to get this resolved?
Re: ISP customer assignments
On Mon, Oct 5, 2009 at 11:27 AM, Brian Johnson bjohn...@drtel.com wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? No. A /64 is one *subnet*. Essentially the standard, static size for any Ethernet LAN. For a customer, the following values are more appropriate: /128 - connecting exactly one computer. Probably only useful for your dynamic dialup customers. Any always-on or static-IP customer should probably have a CIDR block. /48 - current ARIN/IETF recommendation for a downstream customer connecting more than one computer unless that customer is large enough to need more than 65k LANs. /56 - in some folks opinion, slightly more sane than assigning a 65k subnets and bazillions of addresses to a home hobbyist with half a dozen PC's. /60 - the smallest amount you should allocate to a downstream customer with more than one computer. Anything smaller will cost you extra management overhead from not matching the nibble boundary for RDNS delegation, handling multiple routes when the customer grows, not matching the standard /64 subnet size and a myriad other obscure issues. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ISP customer assignments
more-or-less. Can I suggest you read: http://en.wikipedia.org/wiki/IPv6 Think of ipv6 not as 128 bits of address space, but more as a addressing system with a globally unique host part and 2^64 possible subnets. In this respect it's substantially different to ipv4. And after reading Wikipedia, follow it up with ARIN's http://www.getipv6.info wiki site. --Michael Dillon
Re: operations contact @ facebook?
Patrick W. Gilmore wrote: On Oct 5, 2009, at 11:10 AM, Alex Balashov wrote: Patrick W. Gilmore wrote: On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. The original poster is from Paris. Do consider the possibility that there are different jurisdictional rules or service terms in force from your own. I certainly did not. And I would suggest we refuse to do so as an industry. The UN lists 192 countries, and there are several others (e.g. Vatican City, Scotland, etc.) which others may count. Many of these have provinces or states or whatever, and almost all have cities, towns, counties, etc., each of which may have its own laws regulations. Operationally speaking (see, this is on-topic :), trying to consider every single one of those possible laws, rules, social norms, preferences, political slants, religious authorities, and whatever else may come into the mix when putting an object or code onto the Internet is simply not possible. Giving in to it, even a little bit, leads to ridiculous restrictions and stifling of many things on the 'Net. We should all push back HARD whenever someone over here tries to tell someone over there what to do. The OP responded with a quite reasonable answer (shared infrastructure) that had nothing to do with local jurisdiction. That is an operational issue. What laws your country, province, county, town, or church has set up for you should have zero operational impact on me if my gear is not in the same place. And maybe someday we can even get away from that whole in the same place idea. (Hey, one can dream.) That is a very fair point. I cannot come up with any appealing counterarguments. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
RE: ISP customer assignments
What would be wrong with using a /64 for a customer who only has a local network? Most home users won't understand what a subnet is. - Brian -Original Message- From: wher...@gmail.com [mailto:wher...@gmail.com] On Behalf Of William Herrin Sent: Monday, October 05, 2009 11:58 AM To: Brian Johnson Cc: nanog@nanog.org Subject: Re: ISP customer assignments On Mon, Oct 5, 2009 at 11:27 AM, Brian Johnson bjohn...@drtel.com wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? No. A /64 is one *subnet*. Essentially the standard, static size for any Ethernet LAN. For a customer, the following values are more appropriate: /128 - connecting exactly one computer. Probably only useful for your dynamic dialup customers. Any always-on or static-IP customer should probably have a CIDR block. /48 - current ARIN/IETF recommendation for a downstream customer connecting more than one computer unless that customer is large enough to need more than 65k LANs. /56 - in some folks opinion, slightly more sane than assigning a 65k subnets and bazillions of addresses to a home hobbyist with half a dozen PC's. /60 - the smallest amount you should allocate to a downstream customer with more than one computer. Anything smaller will cost you extra management overhead from not matching the nibble boundary for RDNS delegation, handling multiple routes when the customer grows, not matching the standard /64 subnet size and a myriad other obscure issues. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ISP customer assignments
On Mon, Oct 05, 2009 at 01:10:15PM -0500, Brian Johnson wrote: What would be wrong with using a /64 for a customer who only has a local network? Most home users won't understand what a subnet is. IPv6 CPE's may be designed to get one subnet per physical media via DHCPv6-PD, so for example wireless and wired may be different subnets. Really, /56 is the way to go for residential assignments.
Re: ISP customer assignments
Brian Johnson bjohn...@drtel.com writes: So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device! Most people will have more than one device. And there is no NAT as you know it from IPv4 (and hopefully there never will be. I had to troubleshoot a NAT related problem today and it wasn't fun.[1]) And I want more than one network I want to have a firewall between my fridge and my file server. Am I still seeing/reading/understanding this correctly? RFC 3177 suggest a /48. Forget about IPv4 when assigning IPv6 Networks to customers. Think big an take a one size fits all(most) customers approach. Assign a /48 or /56 to your customers and they will never ask you about additional IPs again. This make Documentation relay easy. ;-) cheers Jens [1] Everybody who claims that NAT is easy should have his or her head examined. -- - | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jensl...@guug.de | -
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
Perhaps someone has said this but a potential implementation problem in the US are anti-trust regulations. Sure, they may come around to seeing it your way since the intent is so good but then again we all decided to get together and blacklist customers who... is not a great elevator pitch to an attorney-general no matter how good the intent. Obviously there are ways around that (e.g., it's ok to do credit checks) but one has to be up-front and get approval. I'm just sayin': a) consult with legal counsel before doing anything in collusion with competitors. b) this is probably not for smaller ISPs until the legal way is cleared by those with plenty of money for lawyering and lobbying. (I did say IN THE USA, right?) -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: ISP customer assignments
So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! Thatâs the IPv4 Internet^2 for a single device! Am I still seeing/reading/understanding this correctly? The fact that you could use it for a single device is irrelevant. We have learned the problems imposed by the shortsightedness of IPv4. You're already given 65536 ports for your IPv4 device. OMG, you do not /really/ need that many for a single device! This issue has been hashed over many times. Stop thinking IPv4, where bits are in sufficiently short supply that we feel assignment of any extra space is waste. Start thinking IPv6, where bits are in such great supply that it makes sense to think about stuff like making sure delegations are sufficiently large that your typical ASN isn't having to advertise a hundred prefixes of cobbled-together-over-the-years space, that NAT can be purged from the face of the earth, etc. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: ISP customer assignments
On Mon, Oct 05, 2009 at 08:18:23PM +0200, Jens Link wrote: Brian Johnson bjohn...@drtel.com writes: So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That?s the IPv4 Internet^2 for a single device! Most people will have more than one device. And there is no NAT as you know it from IPv4 (and hopefully there never will be. I had to troubleshoot a NAT related problem today and it wasn't fun.[1]) And I want more than one network I want to have a firewall between my fridge and my file server. Am I still seeing/reading/understanding this correctly? RFC 3177 suggest a /48. Forget about IPv4 when assigning IPv6 Networks to customers. Think big an take a one size fits all(most) customers approach. Assign a /48 or /56 to your customers and they will never ask you about additional IPs again. This make Documentation relay easy. ;-) cheers Jens Am I the only one that finds this problematic? I mean, the whole point of moving to a 128 bit address was to ensure that we would never again have a problem of address depletion. Now I'm not saying that this puts us anywhere in that boat (yet) but isn't saying oh, lets just put a /64 on every interface pretty well ignoring the lessons of the last 20 years? Surely a /96 or even a /112 would have been just as good. Lets think longer term... IPv4 is several decades old now and still in use. If IPv6 lasts another 50 years before someone decides that it needs a redo, with current practices, what will things look like? Consider the population at that point and consider the number of interfaces as more and more devices become IP enabled. wireless devices have their own issues to content with (spectrum being perhaps the biggest limiter) so wired devices will always be around. That means physical interfaces and probably multiple LANs in each residence. I can see where each device may want its own LAN and will talk to components of itself using IP internally, perhaps even having a valid reason for having these individual components publically addressable. Like I said, I'm not necessarily saying we're going to find ourselves in that boat again but it does seem as though more thought is required. (And yes, I fully realize the magnitude of 2^64. I also fully realize how quickly inexhaustable resources become rationable.) -Wayne --- Wayne Bouchard w...@typo.org Network Dude http://www.typo.org/~web/
Re: ISP customer assignments
On Mon, Oct 5, 2009 at 2:10 PM, Brian Johnson bjohn...@drtel.com wrote: What would be wrong with using a /64 for a customer who only has a local network? Most home users won't understand what a subnet is. It's a question of convenience... your customers', but more importantly yours. Every time you have to deviate from your default, whatever default you pick, that's an extra overhead cost you have to bear. Absent a compelling reason not to, you should structure your default choice so that it accommodates as many customers as possible. There are too many good reasons why someone might want to use two subnets with two different security policies and not enough reasons (zero in fact) why it would help you to give them less subnets than the 16 in a /60. So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device! Some clever guy figured out that if you use 64 bits you can write algorithms that automatically assign an interface's IP address based on its MAC address without having to arp for it. Since the details of IPv6 were not yet firmly fixed at that point and ram is cheap, why not add an extra 64 bits for that very convenient improvement? This is called stateless autoconfiguration. Some even more clever guy figured out that if the first clever guy's strategy is used, it becomes a trivial matter to track someone online... based on the last 64 bits of their IP address which will remain static for the life of the hardware they use regardless of where they connect to the 'net. Given this rather blatent weakness and given that you still need DHCP to assign DNS resolvers and the like, stateless autoconfiguration will probably end up being a waste. That's unfortunate, but look at it this way: the important part is not how many addresses are wasted, it's how many addresses are usable. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ISP customer assignments
On Oct 5, 2009, at 2:10 PM, Brian Johnson wrote: What would be wrong with using a /64 for a customer who only has a local network? Most home users won't understand what a subnet is. They probably don't -- but some appliance they buy might. Maybe some home family-oriented box will put the kids' machines on a separate VLAN, to permit rate-limiting, port- and destination-filtering, time- of-day limits, etc. In the past, I had to do similar things -- no AIM during homework hours, no file-sharing -- to the point that I had four subnets in my house (wireless, teen-net, workVPN, and backbone/ parents). I don't expect the average consumer to set up something like that, but I sure wouldn't be surprised at appliances that did. --Steve Bellovin, http://www.cs.columbia.edu/~smb
FairPoint New England Internet Access issues.
Oct 2, 2009: Verizon identified it largest CORE Juniper router was creating issues for all of it peering points to New York and Boston having said that all of FairPoint's DIA, DSL, Fast customer had intermittent issues accessing the internet partial service was restored after Verizon reroute part of FairPoint traffic. Verizon was able to replace the Juniper router and restore full service around 1:45 PM EDT October 3rd 2009. Bill Davis William P. Davis - Director IT Network FairPoint Communications | 900 Elm St., Manchester, NH 03101 | bda...@fairpoint.com mailto:acout...@fairpoint.com 620-339-4786 office | 309-696-0299 Cell ___ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media.
Re: ISP customer assignments
Am I the only one that finds this problematic? No, but most of the people who find this problematic haven't done any looking into the matter. I mean, the whole point of moving to a 128 bit address was to ensure that we would never again have a problem of address depletion. Now I'm not saying that this puts us anywhere in that boat (yet) but isn't saying oh, lets just put a /64 on every interface pretty well ignoring the lessons of the last 20 years? Surely a /96 or even a /112 would have been just as good. No, it wouldn't have been. The sheer usefulness of having things like stateless autoconfig for many trivial applications should not be underestimated. Lets think longer term... IPv4 is several decades old now and still in use. If IPv6 lasts another 50 years before someone decides that it needs a redo, with current practices, what will things look like? Consider the population at that point and consider the number of interfaces as more and more devices become IP enabled. wireless devices have their own issues to content with (spectrum being perhaps the biggest limiter) so wired devices will always be around. That means physical interfaces and probably multiple LANs in each residence. I can see where each device may want its own LAN and will talk to components of itself using IP internally, perhaps even having a valid reason for having these individual components publically addressable. Do some math, then. A /64 handles a single network. An essentially infinite number of devices can live within that space, though there are practical limits. You might realistically have a network for your light switches and a network for your A/V gear. You seem to anticipate that, so let's just say we agree, but I'm going to make a big whopper claim and say that we should delegate /48 to end users. This means each user could have up to 65,536 /64's. While I can daydream about scenarios that would eat up a significant fraction of those subnets, I have to also concede that consolidation is probably possible. Population today is about 7 billion. A fairly aggressive long range report by the UN puts population in 2300 as high as maybe 40 billion, or about six times our current population. Let's just pretend we had the 40 billion today. To come up with 40 billion unique /48 allocations, we'd need almost 36 bits. Of course, this assumes that you can sequentially allocate them. More realistic scenarios suggest that you'd have several bits worth of sparseness. Maybe 40 bits. Okay, 40 bits is close to 48 bits. But we're not delegating /48's to everyone (yet) and we don't have 40 billion people on the planet. Like I said, I'm not necessarily saying we're going to find ourselves in that boat again but it does seem as though more thought is required. (And yes, I fully realize the magnitude of 2^64. I also fully realize how quickly inexhaustable resources become rationable.) People HAVE done the thought. They've thought about it and argued it back and forth for years. This isn't a good place to continue to beat the discolored spot where the dead horse formerly lay; there are some discussions in the NANOG archives as it stands. It's mostly only those who are steeped in the IPv4 thinking and who haven't done the math are concerned about /64's. And note that you're *free* to go allocate a /96 or a /112 to your devices if you really want to do the manual configuration. What's required is for you to do the thinking as to whether or not it is worth it to paddle furiously against the current to save a resource that is in no short supply. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: ISP customer assignments
[here we go again] On Mon, 05 Oct 2009 14:37:49 -0400, William Herrin herrin-na...@dirtside.com wrote: Some clever guy figured out that ... why not add an extra 64 bits for that very convenient improvement? This is called stateless autoconfiguration. Except that clever guy was in fact an idiot blinded by idealism. Not only did he fail to see the security implications of having a fixed address, but he'd apparently spent his entire life under a rock, on an island, on another planet... he completely ignored the fact that people were using DHCP [formerly known as BOOTP] (and have been now for over a decade) to provide machines with FAR MORE than just an address. A machine needs more than just an address to be useful -- something IPv6 users learn very quickly after turning off IPv4 and it's DHCP learned info. Some even more clever guy figured out that if the first clever guy's strategy is used, it becomes a trivial matter to track someone online... ... stateless autoconfiguration will probably end up being a waste. It's ALWAYS been a waste. All these supposed clever guys failed to learn from the mistakes that preceded them and have doomed us to repeat them... ICMP router discovery (technology abandoned so long ago, I'd forgotten about it), RARP, bootp, dhcp. SLAAC loops us back around to the beginning. Only this time, it's inescapable: I still have to have something on the network spewing RAs for the sole purpose of telling everything to use DHCP instead; there's a hard class boundary smack in the middle of a classless network because these clever guys were lazy and didn't want to figure out ways to avoid address collisions. (something modern IPv6 stacks do by default for privacy -- randomly generated addresses have to be tested for uniqueness.) --Ricky
Re: ISP customer assignments
On Mon, Oct 05, 2009 at 11:34:51AM -0700, Wayne E. Bouchard wrote: Am I the only one that finds this problematic? I mean, the whole point of moving to a 128 bit address was to ensure that we would never again have a problem of address depletion. Now I'm not saying that this puts us anywhere in that boat (yet) but isn't saying oh, lets just put a /64 on every interface pretty well ignoring the lessons of the last 20 years? Surely a /96 or even a /112 would have been just as good. The current guidance applies only to one /3 out of eight. Different rules could be applied to the others. Like I said, I'm not necessarily saying we're going to find ourselves in that boat again but it does seem as though more thought is required. (And yes, I fully realize the magnitude of 2^64. I also fully realize how quickly inexhaustable resources become rationable.) As it happens, Windows boxes now generate random interface IDs (not based on MACs), which could have easily been 32 bits with the default subnet 96 bits long, rather than 64 bits. But we are where we are and we do have interesting ideas like CGAs as a result. -- Tim
Re: ISP customer assignments
On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: Whenever you declare something to be inexhasutable all you do is increase demand. Eventually you reach a point where you realize that there is, in fact, a limit to the inexhaustable resource. This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it. 2^128 is enough space for every man, woman and child on the planet to have around 4 billion /64s to themselves. Even if we assume everyone might possibly need say 10 /64s per person that still means we are covered until the population hits around 2,600,000,000,000,000,000. Chris - Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 -A stupidity tax Hubris Communications Inc www.hubris.net -
Re: ISP customer assignments
On 05/10/09 16:20 -0500, Chris Owen wrote: On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: Whenever you declare something to be inexhasutable all you do is increase demand. Eventually you reach a point where you realize that there is, in fact, a limit to the inexhaustable resource. This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it. I think another disconnect is our understanding and expectations of addressing needs with IPv6. The challenge of IPv6 address assignment is to predict what home and enterprise networks will look like in 10, 20 or more years. Do we want to implement an assignment method of conservation based on what we know and understand today, that maximizes the lifetime of IPv6? Or do we want to use an approach that maximizes its usefulness (and the utility of the internet) over the next 50 years? -- Dan White BTC Broadband
Re: ISP customer assignments
considered top posting to irritate a few folks, decided not to. On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: Whenever you declare something to be inexhasutable all you do is increase demand. Eventually you reach a point where you realize that there is, in fact, a limit to the inexhaustable resource. This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it. 2^128 is enough space for every man, woman and child on the planet to have around 4 billion /64s to themselves. Even if we assume everyone might possibly need say 10 /64s per person that still means we are covered until the population hits around 2,600,000,000,000,000,000. Chris here, you expose a hidebound bias to 20th century networking. please remember that - with few exceptions - people network at a very different level than machines. people don't need IP addresses - computing nodes that want to communicate do. Just for grins, put a unique IPv6 address in every active RFID tag. ... and remember that there are RFID printers that can put 18 tags on a single A4 sheet. Numbers will become disposible, like starbucks coffee cups and MCD's bigmac containers. --bill
Re: ISP customer assignments
The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a little less than 6x10^24Kg. 2^128 is around 3.4x10^38. So in a flat address space we have about one IPV6 address for every 20,000Kg in the galaxy or for every 20 picograms in the earth... One would hope it would last for a while :) On Mon, Oct 5, 2009 at 5:32 PM, bmann...@vacation.karoshi.com wrote: considered top posting to irritate a few folks, decided not to. On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: Whenever you declare something to be inexhasutable all you do is increase demand. Eventually you reach a point where you realize that there is, in fact, a limit to the inexhaustable resource. This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it. 2^128 is enough space for every man, woman and child on the planet to have around 4 billion /64s to themselves. Even if we assume everyone might possibly need say 10 /64s per person that still means we are covered until the population hits around 2,600,000,000,000,000,000. Chris here, you expose a hidebound bias to 20th century networking. please remember that - with few exceptions - people network at a very different level than machines. people don't need IP addresses - computing nodes that want to communicate do. Just for grins, put a unique IPv6 address in every active RFID tag. ... and remember that there are RFID printers that can put 18 tags on a single A4 sheet. Numbers will become disposible, like starbucks coffee cups and MCD's bigmac containers. --bill
Re: ISP customer assignments
Brian Johnson wrote: So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? No, that's a single subnet, typically they should be assigned more than that. I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device! Am I still seeing/reading/understanding this correctly? - Brian -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Monday, October 05, 2009 10:38 AM To: nanog@nanog.org Subject: Re: ISP customer assignments Brian Johnson wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. ~Seth
Re: ISP customer assignments
This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it. Why bother wrapping your head around it? Do you count how many computers are in your house? Did you remember to count the CPU inside the PC keyboards? Does it matter? IPv6 addresses are not for you, they are not for your house, and they are not for your network. IPv6 addresses are for network interfaces, physical and virtual, and these interfaces are free to use multiple IPv6 addresses at the same time for various reasons. Why even try to count that unless you are a protocol designer? Fact is that IPv6 is dead simple. You, the ISP, get a /32 from ARIN unless you are really big. You give your customers a /48. If you have a really, really big number of really small (consumer) customers, then you can add another level of complexity and give them a /56. Every time you set up a new network segment (broadcast domain) you assign it a /64. All /64s in one building should really be out of the same /48 unless you are segregating internal use networks from transit service networks, in which case there would be two /48s for the building. Forget counting bits except between /32 and /48 for your ISP business and between /48 and /64 for your network building business. --Michael Dillon
Re: ISP customer assignments
well - if we are presuming a -FLAT- space, then IPv4 will last a great deal longer than 2011. and tell your vendors to pump up the CAM/ARP table sizes ... and bring back the ARP storms of the 1980s. (who owns the vitalink codes base anyway?) --bill On Mon, Oct 05, 2009 at 05:47:12PM -0400, Dorn Hetzel wrote: The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a little less than 6x10^24Kg. 2^128 is around 3.4x10^38. So in a flat address space we have about one IPV6 address for every 20,000Kg in the galaxy or for every 20 picograms in the earth... One would hope it would last for a while :) On Mon, Oct 5, 2009 at 5:32 PM, bmann...@vacation.karoshi.com wrote: considered top posting to irritate a few folks, decided not to. On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: Whenever you declare something to be inexhasutable all you do is increase demand. Eventually you reach a point where you realize that there is, in fact, a limit to the inexhaustable resource. This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it. 2^128 is enough space for every man, woman and child on the planet to have around 4 billion /64s to themselves. Even if we assume everyone might possibly need say 10 /64s per person that still means we are covered until the population hits around 2,600,000,000,000,000,000. Chris here, you expose a hidebound bias to 20th century networking. please remember that - with few exceptions - people network at a very different level than machines. people don't need IP addresses - computing nodes that want to communicate do. Just for grins, put a unique IPv6 address in every active RFID tag. ... and remember that there are RFID printers that can put 18 tags on a single A4 sheet. Numbers will become disposible, like starbucks coffee cups and MCD's bigmac containers. --bill
Re: ISP customer assignments
On Mon, 05 Oct 2009 16:13:37 CDT, Dan White said: a publicly routeable stateless auto configured address is no less secure than a publicly routeable address assigned by DHCP. Security is, and should be, handled by other means. The problem is user tracking and privacy. RFC4941's problem statement: Addresses generated using stateless address autoconfiguration [ADDRCONF] contain an embedded interface identifier, which remains constant over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier. The correlation can be performed by o An attacker who is in the path between the node in question and the peer(s) to which it is communicating, and who can view the IPv6 addresses present in the datagrams. o An attacker who can access the communication logs of the peers with which the node has communicated. Since the identifier is embedded within the IPv6 address, which is a fundamental requirement of communication, it cannot be easily hidden. This document proposes a solution to this issue by generating interface identifiers that vary over time. Note that an attacker, who is on path, may be able to perform significant correlation based on o The payload contents of the packets on the wire o The characteristics of the packets such as packet size and timing Use of temporary addresses will not prevent such payload-based correlation. (end quote) Or phrased differently - if I DCHP my laptop in a Starbuck's, on Comcast, at work, at a hotel, and a few other places, you'll get a whole raft of answers which will be very hard to cross-corrolate. But if all those places did IPv6 autoconfig, the correlation would be easy, because my address would always end in 215:c5ff:fec8:334e - and no other users should have those last 64 bits. Amazingly enough, some people think making it too easy to Big-Brother you is a security issue... pgpadHp4B4941.pgp Description: PGP signature
Re: ISP customer assignments
It's very likely that they won't understand, won't have to, and will still need them. Let's face it, most customer's don't know what an IP address is, really, but, they still need them and they still use them all the time. It is, as someone else stated, very likely that there will be home routers that have multiple zones on multiple interfaces each of which gets a different /64 from a /56 or /48 handed to it by the upstream DHCP-PD box. Owen On Oct 5, 2009, at 11:10 AM, Brian Johnson wrote: What would be wrong with using a /64 for a customer who only has a local network? Most home users won't understand what a subnet is. - Brian -Original Message- From: wher...@gmail.com [mailto:wher...@gmail.com] On Behalf Of William Herrin Sent: Monday, October 05, 2009 11:58 AM To: Brian Johnson Cc: nanog@nanog.org Subject: Re: ISP customer assignments On Mon, Oct 5, 2009 at 11:27 AM, Brian Johnson bjohn...@drtel.com wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? No. A /64 is one *subnet*. Essentially the standard, static size for any Ethernet LAN. For a customer, the following values are more appropriate: /128 - connecting exactly one computer. Probably only useful for your dynamic dialup customers. Any always-on or static-IP customer should probably have a CIDR block. /48 - current ARIN/IETF recommendation for a downstream customer connecting more than one computer unless that customer is large enough to need more than 65k LANs. /56 - in some folks opinion, slightly more sane than assigning a 65k subnets and bazillions of addresses to a home hobbyist with half a dozen PC's. /60 - the smallest amount you should allocate to a downstream customer with more than one computer. Anything smaller will cost you extra management overhead from not matching the nibble boundary for RDNS delegation, handling multiple routes when the customer grows, not matching the standard /64 subnet size and a myriad other obscure issues. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ISP customer assignments
On 05/10/09 18:35 -0400, valdis.kletni...@vt.edu wrote: On Mon, 05 Oct 2009 16:13:37 CDT, Dan White said: a publicly routeable stateless auto configured address is no less secure than a publicly routeable address assigned by DHCP. Security is, and should be, handled by other means. The problem is user tracking and privacy. cut Or phrased differently - if I DCHP my laptop in a Starbuck's, on Comcast, at work, at a hotel, and a few other places, you'll get a whole raft of answers which will be very hard to cross-corrolate. But if all those places did IPv6 autoconfig, the correlation would be easy, because my address would always end in 215:c5ff:fec8:334e - and no other users should have those last 64 bits. All of the items in the above list are true of DHCP. The only difference is how long that correlation will be taking place. You're likely to keep using the same addresses at each site (unless the DHCP server is configured not to). DHCP servers themselves tend to re-hand out addresses based on seeing the same MAC address. Is it really a secure approach to depend on how often you go mobile? Random address assignment *is* auto configuration (well, a modified form of it). That seems to be much better. -- Dan White BTC Broadband
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
On Oct 5, 2009, at 11:23 AM, Barry Shein wrote: Perhaps someone has said this but a potential implementation problem in the US are anti-trust regulations. Sure, they may come around to seeing it your way since the intent is so good but then again we all decided to get together and blacklist customers who... is not a great elevator pitch to an attorney-general no matter how good the intent. That's not what is being discussed from my understanding. From my understanding, the intent is to share names of known abusers and data necessary to help in tracking DDOS. I don't believe that any ISP is expected to necessarily take any particular action determined by the group with respect to the list of names they are given. I do think that it is reasonable to have an agreement among an industry organization or collaboration which states that ISPs which determine that abuse is being sourced from one of their customers (either through their own processes or by notification from another participant) should be expected to take the necessary steps to mitigate that abuse from exiting said ISPs autonomous system. Obviously there are ways around that (e.g., it's ok to do credit checks) but one has to be up-front and get approval. I don't think that's true. I think that as long as your privacy policy and terms of service state that you will share certain information with other operators regarding abuse complaints and (possibly) abusive activities, you are free to share that information. Having a coalition rule that says any member must refuse to service any party on the list would be an anti-trust violation. Having a list, alone, without any rules about how the list is used, is not an anti-trust violation. Just like agreeing ahead of time on the price of gas amongst multiple competitors is an anti-trust violation, posting the price of gas at your service stations is not. Modifying your price to match the price across the street also is not. I'm just sayin': a) consult with legal counsel before doing anything in collusion with competitors. Definitely. b) this is probably not for smaller ISPs until the legal way is cleared by those with plenty of money for lawyering and lobbying. I'm not so sure that is true, but, they should seek good legal counsel about whatever they plan to do regardless of size. Owen
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
On Mon, Oct 05, 2009 at 03:55:02PM -0700, Owen DeLong wrote: On Oct 5, 2009, at 11:23 AM, Barry Shein wrote: Perhaps someone has said this but a potential implementation problem in the US are anti-trust regulations. Sure, they may come around to seeing it your way since the intent is so good but then again we all decided to get together and blacklist customers who... is not a great elevator pitch to an attorney-general no matter how good the intent. That's not what is being discussed from my understanding. From my understanding, the intent is to share names of known abusers and data necessary to help in tracking DDOS. I don't believe that any ISP is expected to necessarily take any particular action determined by the group with respect to the list of names they are given. I do think that it is reasonable to have an agreement among an industry organization or collaboration which states that ISPs which determine that abuse is being sourced from one of their customers (either through their own processes or by notification from another participant) should be expected to take the necessary steps to mitigate that abuse from exiting said ISPs autonomous system. In a way, this is kind of like stores keeping a list of bad check writers. The whole information sharing thing can get more than a little touchy from a legal perspective. Then again, an independant database could also be viewed as a sort of internet credit agency. Stuff in a name, get a score back and certain flags and make your judgement based on that. I'm sorry, I can't give you an email account. Your internet-karma rating came back below our minimum levels. -Wayne --- Wayne Bouchard w...@typo.org Network Dude http://www.typo.org/~web/
Re: ISP customer assignments
On Oct 5, 2009, at 11:34 AM, Wayne E. Bouchard wrote: On Mon, Oct 05, 2009 at 08:18:23PM +0200, Jens Link wrote: Brian Johnson bjohn...@drtel.com writes: So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That?s the IPv4 Internet^2 for a single device! Most people will have more than one device. And there is no NAT as you know it from IPv4 (and hopefully there never will be. I had to troubleshoot a NAT related problem today and it wasn't fun.[1]) And I want more than one network I want to have a firewall between my fridge and my file server. Am I still seeing/reading/understanding this correctly? RFC 3177 suggest a /48. Forget about IPv4 when assigning IPv6 Networks to customers. Think big an take a one size fits all(most) customers approach. Assign a /48 or / 56 to your customers and they will never ask you about additional IPs again. This make Documentation relay easy. ;-) cheers Jens Am I the only one that finds this problematic? I mean, the whole point of moving to a 128 bit address was to ensure that we would never again have a problem of address depletion. Now I'm not saying that this puts us anywhere in that boat (yet) but isn't saying oh, lets just put a /64 on every interface pretty well ignoring the lessons of the last 20 years? Surely a /96 or even a /112 would have been just as good. Nope It really isn't. If we wanted to do that, then, IPv6 would probably have 64-bit addressing, instead of 128-bit, and, you'd have 32 bits of carrier, 16 bits of end- site, 8 bits of subnet and 8 bits of host (or something approximating that). Part of the reason that 128 bits was chosen (64 bits is FAR more than enough) was that it allowed for 64 bits of stateless auto-configuration (IEEE was already pushing EUI-64) within each network and still provided more than enough network numbers. Lets think longer term... IPv4 is several decades old now and still in use. If IPv6 lasts another 50 years before someone decides that it needs a redo, with current practices, what will things look like? OK. Consider the population at that point and consider the number of interfaces as more and more devices become IP enabled. wireless devices have their own issues to content with (spectrum being perhaps the biggest limiter) so wired devices will always be around. That The planet's sustainable population is not likely to exceed 10 billion. (However, current growth is approximately 80 million per year, so, our current 6 billion + 80 million * 50 = 4 billion still puts us at around 10 billion, so, it should be a safe number even if we throw sustainability out the window). IPv6 offers us 32 bits of provider units == 4 billion providers. Each provider can serve 65,536 customer units which gives us the ability to support 281,474,976,710,656, or, about 281 trillion customers. Each customer unit gets 65,536 subnets to do with as they like and they still have 64 bits on each subnet. means physical interfaces and probably multiple LANs in each residence. I can see where each device may want its own LAN and will talk to components of itself using IP internally, perhaps even having a valid reason for having these individual components publically addressable. It's OK. We can do it. We will still have addresses to spare even in 50 years, even with that. Like I said, I'm not necessarily saying we're going to find ourselves in that boat again but it does seem as though more thought is required. (And yes, I fully realize the magnitude of 2^64. I also fully realize how quickly inexhaustable resources become rationable.) Well... There is a safety valve. We are only issuing from 1/8th of the current address space at this time. If we run that out before we expect to and it becomes clear that there is a need to allocate differently, we can begin doing that from the next 1/8th without any real changes to the protocol or router software. Really, it's OK. Owen
Re: ISP customer assignments
On 10/05/2009 04:41 PM, robert.e.vanor...@frb.gov wrote: The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each. Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste. I'm perplexed. At what size address would people stop worrying about the finite address space? 256 bits? 1024 bits? I just don't get it. It's not like people get stressed out about running out of name space in English which is probably more finite than ipv6. Mike
Re: ISP customer assignments
On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote: I'm perplexed. At what size address would people stop worrying about the finite address space? 256 bits? 1024 bits? I just don't get it. It's not like people get stressed out about running out of name space in English which is probably more finite than ipv6. Unless you're trying to find a nice, catchy, short domain name. ;-) But seriously: Many people don't seem to have good intuition about really big numbers. Say, on the order of 2^128. The same thing comes up in discussions about hash collisions in, e.g., content based naming with a 160-bit namespace. I think it's because the numbers are so astronomically big, that without some amount of math and having thought about it with paper and pencil, people automatically scale the #s into terms they can think of as really big (like, # of people on earth). So when they think about the 128-bit namespace, they apply intuition that works for a 35-bit namespace... -Dave
Re: ISP customer assignments
On Mon, Oct 05, 2009, Antonio Querubin wrote: On Mon, 5 Oct 2009, robert.e.vanor...@frb.gov wrote: The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space. .. address aggregation? .. convergence time? I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their local internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it better. adrian
Re: ISP customer assignments
If people start getting /32s because some ISPs are refusing to route / 48s, then, the RIRs are not doing their stewardship job correctly and we should resolve that issue. If addresses are handed out according to policies, there is more than enough space for every individual to have a /48. I think that /56s for residential customers are probably a good idea and I agree that /48s are usually excessive for residential. (a /64 is far more than a billion addresses since 32 bits if 4 billion and a /64 is whatever number 4 billion^2 works out to, basically 16 followed by lots more digits). As a residential customer, if you get a /64, then, your ISP is really limiting you in ways they should not. You should get at least a /56 in most cases. I think that comparing this to class Bs is kind of absurd, and, I think that the people talking about lessons learned haven't really analyzed the lessons very well. The argument of lessons learned usually centers around the idea that we should regard address space as finite and seek ways to maximize its use. The reality is that is not the best lesson. That is what you do when address space is finite and insufficient and you can't make use of extra bits to do other optimizations. Therefore, the best lesson to learn is simply that the IPv4 space was simply not large enough and that we need a much much much larger space with bits available to do other forms of optimization. IPv6 does appear to contain that lesson rather well. We have TONS of bits available on each network for host addressing. So much so that complicated bizarre subnet address calculations and DNS reverse delegation difficulties become a thing of the past (look at the hacks necessary to delegate reverse DNS to 16 different /28 customers in a /24 block, for example). In essence, a class B was equivalent to a /56 in its original form, you could carve it up into 256 /24s. In IPv6, we have plenty of space to issue /56 and even /48 networks to every small to medium business, home, etc. and still have lots left over. Large organizations and IPSs easily get /32s which each contain 65,536 /48s, so, you can divide your multi-national mega-corp into as many as 65,536 regions and give each region a /48 and still be OK. IPv6 offers so much address space that we could give every existing IPv4 user an entire IPv6 ISP allocation (no, I'm not recommending this) and still have enough /32s left over in IPv6 to give one to each ISP and large mega-corp. Lesson learned... The original address was far too small. The new address space is actually large enough that this is a pretty good guess at how to generate addresses that will be fine for decades to come and still have space left over. In fact, so much so, that, to test the theory, we're issuing 1/8th of it this way, and, if it doesn't work out as planned, we can change the allocation policies for the other 7/8ths of the space. So... Lesson learned... If we had tossed classful addressing overboard in IPv4 when we allocated 1/8th of the address space, most of the legacy /8s wouldn't be. Owen On Oct 5, 2009, at 4:41 PM, robert.e.vanor...@frb.gov wrote: The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each. Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste. Food for thought... Message: 3 Date: Mon, 5 Oct 2009 17:47:12 -0400 From: Dorn Hetzel dhet...@gmail.com Subject: Re: ISP customer assignments To: bmann...@vacation.karoshi.com Cc: NANOG list nanog@nanog.org Message-ID: 7db2dcf90910051447r5bd7e42fja0b750dceb8d...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a little less than 6x10^24Kg. 2^128 is around 3.4x10^38. So in a flat address space we have about one IPV6 address for every 20,000Kg in the galaxy or for every 20 picograms in the earth... One would hope it would last for a while :) On Mon, Oct 5, 2009 at 5:32 PM, bmann...@vacation.karoshi.com wrote: considered top posting to irritate a few folks, decided not to. On Mon,
Re: ISP customer assignments
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. That's probably because IPv4 was a technology where the expected host address allocation strategy was (last+1) and IPv6 is a technology where the default host address allocation strategy involves shooting into an extremely extra-sparse 64-bit address space. These are incredibly different things. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each. Um, no. Unless by roughly we use a definition where 1 is roughly equal to 18 billion. Yes, that's right, a /64 is 18 billion *billion*. Generally speaking, we shouldn't *want* end users to be provided with a single /64. The number of addresses is not the point. The idea of getting rid of the horribleness that is CIDR is the point. For example, consider the network 206.55.76.0/23. If I assign that to an Ethernet interface, I have a problem because two addresses in the middle of the network, 206.55.76.255 and 206.55.77.0, are less-than- fully-usable because stupid idiot retards out on the Internet will see that last octet and will firewall it. And by stupid idiot retards, I don't necessarily mean end users, I mean *VENDORS*. (You know who you are.) The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc. And here's the kicker. If it /really/ bothers you, just bear in mind that having another whole 64 bits as the host space means that if ever the V6Internet is in crisis and is running out of IP space, unlike IPv4, we can fix that problem by changing the addressing strategy within the local AS. Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... Oh puhleeeze. Where do we get these newbies from. Part of the reason for forming a group such as NANOG was that there were lots of routing issues; we still see requests for help for that sort of stuff today on the IPv4 Internet. Anyone who remembers the fun days of the early commercial Internet would likely say that we've got it easy today. so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste. Not likely to happen in this century. One of the lessons that *was* learned was that it's better to go too big than too small. People just have a rough time visualizing how massively immense 2^128 actually is. But this discussion is really not relevant to NANOG; if you wish to fight this battle, the people with the clue-by-fours are over on the IPv6 lists. Food for thought... Only if by food you mean I went down to Lardburger and ate until I had a heart attack and died. You're not bringing anything new to the table, least of all in the fact department, which is about the only way you could manage to convince people that there's a problem. And the very thing you're complaining about would actually be the obvious safety valve if there's a problem. That immense, extremely sparse space that forms the host portion of an IPv6 address... that is where we dip into in the extremely unlikely event there's a problem. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: ISP customer assignments
On 10/05/2009 04:59 PM, David Andersen wrote: On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote: I'm perplexed. At what size address would people stop worrying about the finite address space? 256 bits? 1024 bits? I just don't get it. It's not like people get stressed out about running out of name space in English which is probably more finite than ipv6. Unless you're trying to find a nice, catchy, short domain name. ;-) But seriously: Many people don't seem to have good intuition about really big numbers. Say, on the order of 2^128. The same thing comes up in discussions about hash collisions in, e.g., content based naming with a 160-bit namespace. I think it's because the numbers are so astronomically big, that without some amount of math and having thought about it with paper and pencil, people automatically scale the #s into terms they can think of as really big (like, # of people on earth). So when they think about the 128-bit namespace, they apply intuition that works for a 35-bit namespace... Hey, that's are why logarithms are our friends :) Seriously though, when i was at that big ol' networking company, the size of the address space was so ridiculously large that hardware and software people charged with implementing it certainly had no love for it. So it's not like vendors were cheaping out or something -- it makes their life quite a bit more, uh, interesting. Ipv6 *is* what what was learned about ipv4 addresses: make the address space so astronomically large that nobody could possibly worry. Curse those logarithms on second thought. Mike
Re: ISP customer assignments
I've been trying to stay out of this discussion because it is pointless, however as I can't help picking at scratching mosquito bites either... On Oct 5, 2009, at 4:50 PM, Michael Thomas wrote: I'm perplexed. At what size address would people stop worrying about the finite address space? 256 bits? 1024 bits? The issue is that given it is a _finite_ space, its longevity depends exclusively on allocation policy. Since allocation policy is determined by human decision, it is possible (albeit unlikely) that decisions will be made that will result in runout of IPv6 far sooner than one would predict given the vast size of the address space. To wit, we have already had allocations of a /13, /16s, /19s, /20s, etc., irrespective of the fact that the organizations that obtained those prefixes would likely be unable to make a dent in their allocations by the time the sun burned out (assuming they allocate in a rational fashion). Now, as an exercise to the reader, compare how many of those prefixes exist in IPv6 to how many there are in IPv4... Regards, -drc
Re: ISP customer assignments
On Mon, Oct 05, 2009, Antonio Querubin wrote: On Mon, 5 Oct 2009, robert.e.vanor...@frb.gov wrote: The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space. .. address aggregation? .. convergence time? I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their local internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it better. That would seem to be an IX administrative problem. As it stands, there are lots and lots and lots of AS's that advertise multiple blocks of space. Ideally, one would rather see a large ISP get a single delegation, rather than advertising 50 or 500. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: ISP customer assignments
Owen, On Oct 5, 2009, at 5:05 PM, Owen DeLong wrote: If people start getting /32s because some ISPs are refusing to route /48s, then, the RIRs are not doing their stewardship job correctly and we should resolve that issue. Since when do RIRs, good stewards or not, control routing policy of ISPs? IPv6 offers so much address space that we could give every existing IPv4 user an entire IPv6 ISP allocation (no, I'm not recommending this) and still have enough /32s left over in IPv6 to give one to each ISP and large mega-corp. Um. How many /32s are their in IPv4? How many /32s are their in IPv6? Regards, -drc
Re: ISP customer assignments
The fallacy here is the idea that IPv6 has a 128-bit namespace. It does not. It has two 64 bit namespaces, where one is expected to be globally unique and flat, While the other is hierarchical. IPv6 has a lot more room than v4 does, but it is worth noting Than in v4, a customer would typically use a single /32. In v6-speak, a /48 is a smaller percentage of the overall space, but it would not be prudent to view the v6-space as infinite. Remember, the value of a network increases with the number of interconnections, and those interconnections are what get numbered. All of the comparisons to atoms in the galaxy or human population are ignoring the hierarchical element of the 64-bit space. The nature of hierarchical allocations requires a Significant quot;burnquot; in terms of wasted, unusable addresses. All that said, the /64-based v6 addressing approaches are going to be with us for quite a while, so they#39;re worth getting used to. -David Barak David Andersen wrote: On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote: I'm perplexed. At what size address would people stop worrying about the finite address space? 256 bits? 1024 bits? I just don't get it. It's not like people get stressed out about running out of name space in English which is probably more finite than ipv6. Unless you're trying to find a nice, catchy, short domain name. ;-) But seriously: Many people don't seem to have good intuition about really big numbers. Say, on the order of 2^128. The same thing comes up in discussions about hash collisions in, e.g., content based naming with a 160-bit namespace. I think it's because the numbers are so astronomically big, that without some amount of math and having thought about it with paper and pencil, people automatically scale the #s into terms they can think of as really big (like, # of people on earth). So when they think about the 128-bit namespace, they apply intuition that works for a 35-bit namespace... -Dave
Re: ISP customer assignments
On 10/05/2009 05:09 PM, Adrian Chadd wrote: On Mon, Oct 05, 2009, Antonio Querubin wrote: On Mon, 5 Oct 2009, robert.e.vanor...@frb.gov wrote: The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space. .. address aggregation? .. convergence time? I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their local internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it better. There's a good reason for that: ipv6 isn't intended to do anything about disaggregation. Which as you rightly point out is a problem in ipv4 too. IIRC, there was a contingent who thought that address space and aggregation needed to be considered as a single problem. They lost the argument and hence ipv6 as it is today and the previously unsolved aggregation problem... still unsolved. Mike
(Spelling embarrassment, ignorable except for spelling pedants) Re: ISP customer assignments
On Oct 5, 2009, at 5:20 PM, David Conrad wrote: Um. How many /32s are their in IPv4? How many /32s are their in IPv6? Of course, that should be there in both cases. Wow. Regards, -drc
Re: ISP customer assignments
On Mon, Oct 05, 2009, Joe Greco wrote: I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their local internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it better. That would seem to be an IX administrative problem. Sure, if you don't want to see those local networks. But since the cost of getting from Perth to ! Perth is (was?) a lot higher than what you guys even pay for international transit at non-Cogent rates, we have some sort of desire to keep as much traffic local as possible. Hence Local only announcements. As it stands, there are lots and lots and lots of AS's that advertise multiple blocks of space. Ideally, one would rather see a large ISP get a single delegation, rather than advertising 50 or 500. .. and what about their customers with portable address space? What if every single customer decides they now want to multihome, dynamic endpoint resolution stuff (LISA?) isn't ready, and companies simply join the RIR and buy their own IP space? :) Adrian
RE: ISP customer assignments
Just for grins, put a unique IPv6 address in every active RFID tag. ... and remember that there are RFID printers that can put 18 tags on a single A4 sheet. Numbers will become disposible, like starbucks coffee cups and MCD's bigmac containers. --bill Ignoring the difference between a globally unique identifier and a network-connected, routeable, globally-unique identifier for just a moment ... OK, so we can print 18 tags per A4 sheet. And a single /64 gives us 18BillionBillion of these - start printing, if you so desire. Let me know when you need your next /64 :) (even assuming no reuse / overlap between different solution sets). /TJ
RE: ISP customer assignments
On Mon, 05 Oct 2009 16:13:37 CDT, Dan White said: a publicly routeable stateless auto configured address is no less secure than a publicly routeable address assigned by DHCP. Security is, and should be, handled by other means. The problem is user tracking and privacy. RFC4941's problem statement: Addresses generated using stateless address autoconfiguration [ADDRCONF] contain an embedded interface identifier, which remains constant over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier. The correlation can be performed by o An attacker who is in the path between the node in question and the peer(s) to which it is communicating, and who can view the IPv6 addresses present in the datagrams. o An attacker who can access the communication logs of the peers with which the node has communicated. Since the identifier is embedded within the IPv6 address, which is a fundamental requirement of communication, it cannot be easily hidden. This document proposes a solution to this issue by generating interface identifiers that vary over time. Note that an attacker, who is on path, may be able to perform significant correlation based on o The payload contents of the packets on the wire o The characteristics of the packets such as packet size and timing Use of temporary addresses will not prevent such payload-based correlation. (end quote) Or phrased differently - if I DCHP my laptop in a Starbuck's, on Comcast, at work, at a hotel, and a few other places, you'll get a whole raft of answers which will be very hard to cross-corrolate. But if all those places did IPv6 autoconfig, the correlation would be easy, because my address would always end in 215:c5ff:fec8:334e - and no other users should have those last 64 bits. Amazingly enough, some people think making it too easy to Big-Brother you is a security issue... Isn't this really a security by obscurity argument? Making it a bit harder for the attacker, relying on 'Eve' just not realizing who I am? Most of those concerns are in fact mitigated by a well implemented Privacy implementation ... and many of the remaining concerns do in fact apply to IPv4. Not to mention the 'higher layer' aspects. Bottom line - if you are doing something that warrants some level of privacy or protection, you should do something to ensure that level of privacy or protection - never assume you are private/secure by default. /TJ
RE: ISP customer assignments
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space. .. address aggregation? .. convergence time? I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their local internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it better. Is someone not making sensible use of their IPv6 allocation? Another one of the goals is to enable organization (and the Internet, prior to PI space) to be far more aggregatable. Real example: Instead of one enterprise network having 31 dis-contiguous IPv4 /16s they could get one (large) IPv6 allocation. ... With room to grow and still aggregate. PI space changes that conversation on the DFZ side back to a bit of a swamp until we get that fixed in one fashion or another ... /TJ
Re: ISP customer assignments
On Mon, Oct 5, 2009 at 7:41 PM, robert.e.vanor...@frb.gov wrote: The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Robert, I would suggest that some of the lessons we learned are faulty. Maladaptive. CIDR for instance. In a classful world, folks who needed a class A got a class A and were able to announce a class A. They couldn't announce 4200 little divisions of their addresses like Bell South on last Friday's CIDR report. CIDR made today's BGP mess possible. With a larger address space, let's say 128 bits, things *could* have been partitioned in a such a way that there were enough class B's for everyone who needed more than a class C and plenty of class-A's for everyone who needed more than a class B. There's no doubt that CIDR saved the Internet. There -weren't- enough IPv4 class B's for everyone who needed more than a class C. CIDR made it possible to express ranges of class C's as a single route and that's just the start. But CIDR also created today's problems where it isn't possible to tell the difference between a route that represents a unique multihomed endpoint and routes which reflect nothing more than a bad actor making you pay his traffic engineering cost. So now Verizon is in open revolt against ARIN. They positively refuse to carry /48's from legitimately multihomed users. Eff 'em. Perhaps Verizon would sooner see IPv6 go down in flames than see their TCAMs fill up again. Who knows their reasoning? Agree or disagree, it is indeed food for thought. One thing I can say with confidence: as a community we truly haven't grasped the major implications of an address space that isn't scarce coupled with a routing table that is. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ISP customer assignments
So now Verizon is in open revolt against ARIN. They positively refuse to carry /48's from legitimately multihomed users. Eff 'em. Perhaps Verizon would sooner see IPv6 go down in flames than see their TCAMs fill up again. Who knows their reasoning? Agree or disagree, it is indeed food for thought. One thing I can say with confidence: as a community we truly haven't grasped the major implications of an address space that isn't scarce coupled with a routing table that is. Thing is, I'm an end user site. I need more that a /48, but probably less than a /32. Seeing as how we have an AS and PI, PA isn't going to cut it. What am I supposed to do? ARIN suggested creative subnetting. We pushed back and got a /41. If IPv6 doesn't scratch an itch, why bother? There are plenty of high-profile end user sites in 2620::/23. Some government (CIA), some popular (Facebook.) I don't think Verizon's stand is going to last. Tim:
Re: ISP customer assignments
On Mon, 05 Oct 2009 18:55:35 -0400, Dan White dwh...@olp.net wrote: All of the items in the above list are true of DHCP. ... In an IPv4 world (which is where DHCP lives), it's much MUCH harder to track assignments -- I don't share my DHCP logs with anyone, nor does anyone send theirs to me. From the perspective of remote systems (ie. not on the same network), there is about a 100% chance NAT is involved making it near impossible to individually identify a specific machine, even if it gets the same address every Tuesday when you're at Starbucks for coffee. IPv6 does away with NAT (or it's supposed to); in doing so, the veil is removed and everything that had been hidden from site is now openly displayed. If the host part of your address never changes, then you are instantly identifiable everywhere you go, with zero effort, forever. --Ricky
Re: ISP customer assignments
Tim Durack wrote: Thing is, I'm an end user site. I need more that a /48, but probably less than a /32. Seeing as how we have an AS and PI, PA isn't going to cut it. What am I supposed to do? ARIN suggested creative subnetting. We pushed back and got a /41. If IPv6 doesn't scratch an itch, why bother? We were assigned a /43. insofar as I can tell that's Arin policy working just fine. There are plenty of high-profile end user sites in 2620::/23. Some government (CIA), some popular (Facebook.) I don't think Verizon's stand is going to last. Tim:
Practical numbers for IPv6 allocations
[ I normally don't say this, but please reply to the list only, thanks. ] I've been a member of the let's not assume the IPv6 space is infinite school from day 1, even though I feel like I have a pretty solid grasp of the math. Others have alluded to some of the reasons why I have concerns about this, but they mostly revolve around the concepts that the address space is not actually flat (i.e., it's going to be carved up and handed out to RIRs, LIRs, companies, individuals, etc.) and that both the people making the requests and the people doing the allocations have a WIDE (pardon the pun) variety of motivations, not all of which are centered around the greater good. I'm also concerned that the two main pillars of what I semi-jokingly refer to as the profligate school of IPv6 allocation actually conflict with one another (even if they both had valid major premises, which I don't think they do). On the one hand people say, The address space is so huge, we should allocate and assign with a 50-100 year time horizon and on the other they say, The address space is so huge, even if we screw up 2000::/3 we have 7 more bites at the apple. I DO believe that the space is large enough to make allocation policies with a long time horizon, but relying on trying again if we screw up the first time has a lot of costs that are currently undefined, and should not be assumed to be trivial. It also ignores the fact that if we reduce the pool of /3s because we do something stupid with the first one we allocate from it reduces our opportunities to do cool things with the other 7 that we haven't even thought of yet. In regards to the first of the profligate arguments, the idea that we can do anything now that will actually have even a 25 year horizon is naively optimistic at best. It ignores the day-to-day realities of corporate mergers and acquisitions, residential customers changing residences and/or ISPs, the need for PI space, etc. IPv6 is not a set it and forget it tool any more than IPv4 is because a lot of the same realities apply to it. You also have to keep in mind that even if we could come up with a theoretically perfect address allocation scheme at minimum the existing space is going to be carved up 5 ways for each of the RIRs to implement. (When I was at IANA I actually proposed dividing it along the 8 /6 boundaries, which is sort of what has happened subsequently if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to LACNIC and 2c00::/12 to AfriNIC.) Since it's not germane to NANOG I will avoid rehashing the why RA and 64-bit host IDs were bad ideas from the start argument. :) In the following I'm assuming that you're familiar with the fact that staying on the 4-byte boundaries makes sense because it makes reverse DNS delegation easier. It also makes the math easier. As a practical matter we're stuck with /64 as the smallest possible network we can reliably assign. A /60 contains 16 /64s, which personally I think is more than enough for a residential customer, even taking a long view into consideration. The last time I looked into this there were several ISPs in Japan who were assigning /60s to their residential users with good success. OTOH, a /56 contains 256 /64s, which is way WAY more than enough for a residential user. The idea that a residential user needs a full /48 (65,536 /64s) is absurd. OTOH, assigning a /48 to even a fairly large commercial customer is perfectly reasonable. This would give them 256 /56 networks (which would in turn have 256 /64 networks) which should be plenty to handle the problems of multiple campuses with multiple subnets, etc. So let's assume that we'll take /56 as the standard unit of assignment to residential customers, and /48 as the standard unit of assignment to commercial customers. A /32 has 65,536 /48s in it. If your business was focused mainly on commercial customers that's not a very big pool. OTOH if your business was focused primarily on residential customers you'd have 16,777,216 /56s to work with. That's enough for even a very large regional ISP. One could also easily imagine a model where out of a /32 you carve out one /34 for /56 assignments (4,194,304) and use the other 3/4ths of the space for /48s (49,152). A really large (national or even global) ISP would obviously need more space if they were going to intelligently divide up addresses on a regional basis. A /28 would have 16 /32s which should be enough for even a very large ISP, but let's really make sure that we cover the bases and go /24 (256 /32s). Even if you assume splitting that address space in half, that's 2.147483e+09 (approximately 2,147,483,000) /56s, and 8,388,608 /48s. There are roughly 2,097,152 /24s in 2000::/3 (I say roughly because I'm ignoring space that's already been carved out, like 6to4, etc.), or 262,144 /24s per /6, or 67,108,864 /32s per /6. Which means that yes, we really do have a lot of space to work with. I also think it means that even with a lot of space there
Re: ISP customer assignments
On Mon, 05 Oct 2009 20:40:28 EDT, TJ said: Isn't this really a security by obscurity argument? No - security through obscurity is security measures that only seem to work because you hope the attacker doesn't know how they are implemented. In this case, making sure somebody else can't aggregate data about you is more akin to making sure somebody else can't obtain your password. In this case, you're making it harder for the attacker because they *do* know how the security measure works - if you're IP-address hopping or using RFC4191 privacy, then they know they have to find other means to do the tracking. Making it a bit harder for the attacker, relying on 'Eve' just not realizing who I am? Actually, yes. If you're the type of person that is careful not to accept website cookies to prevent cross-session and even cross-website tracking, you probably don't want to make it easy for Multi-click or whoever to do their tracking by having an IP address that shouts Hey I'm the same laptop that was in the Starbuck's in Chicago last Tuesday. That isn't making it a little harder, it's making it a *lot* harder. And there's something to be said for Eve just not realizing who I am - the only reason my father's family made it to the US was because a Soviet border guard didn't realize my grandfather was on a take in the forest and shoot on sight list. So sometimes being able to keep Eve from making that correlation is literally a life-or-death issue. Most of those concerns are in fact mitigated by a well implemented Privacy implementation Which is why I started off by mentioning RFC4191. ;) pgpyHEigCz3JV.pgp Description: PGP signature
Re: ISP customer assignments
joel jaeggli wrote: Tim Durack wrote: Thing is, I'm an end user site. I need more that a /48, but probably less than a /32. Seeing as how we have an AS and PI, PA isn't going to cut it. What am I supposed to do? ARIN suggested creative subnetting. We pushed back and got a /41. If IPv6 doesn't scratch an itch, why bother? We were assigned a /43. insofar as I can tell that's Arin policy working just fine. Mind if I ask what is is so I can see if it's in my Verizon table? Offlist is fine, I can just post yea/nea to the list. ~Seth
Re: Practical numbers for IPv6 allocations
On Mon, Oct 5, 2009 at 11:39 PM, Doug Barton do...@dougbarton.us wrote: As a practical matter we're stuck with /64 as the smallest possible network we can reliably assign. A /60 contains 16 /64s, which personally I think is more than enough for a residential customer, even taking a long view into consideration. The last time I looked into this there were several ISPs in Japan who were assigning /60s to their residential users with good success. OTOH, a /56 contains 256 /64s, which is way WAY more than enough for a residential user. The idea that a residential user needs a full /48 (65,536 /64s) is absurd. OTOH, assigning a /48 to even a fairly large commercial customer is perfectly reasonable. This would give them 256 /56 networks (which would in turn have 256 /64 networks) which should be plenty to handle the problems of multiple campuses with multiple subnets, etc. Keep in mind that not all 'fairly large enterprises' are willing to sit at a single ISP, they may have diverse offices on diverse network provider connections. They may want the easy of saying: 'All my address blocks are in 1.2.0.0/16' and not understand (or like) that they now have to deal with wierd routing and addressing problems because they can't get a /32 and break it up into /48's all over creation (different ISP's/links/etc) or deal with the split of address space they'd get from ISP /48 PA assignments. the enterprise world has changed quite a bit from IPNG's early days... Someone who runs a large Enterprise with global office locations and who's actually deploying ipv6 internally/externally ought to give a presentation at NANOG and/or IETF. I don't disagree with the math I snipped, I do appreciate you laying it out, and I don't think that there are a super large number of folks in the scenario I layed out above. I've seen quite a few at previous employers though... -Chris
