Re: Dutch ISPs to collaborate and take responsibility for bottedclients
Eugeniu Patrascu wrote: Gadi Evron wrote: Barton F Bruce wrote: 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. While a legitimate concern it's also a red herring, as it's a technical problem looking for a technical solution. Gadi. I think the need for someone being able to call 911 from their VoIP outweighs your right to claim that they should be disconnected from the Internet. Again, I don't disagree, but I see it as a technical issue which is solvable. I don't see why this is THE issue. It's really just changing the subject of the discussion. Besides, if that provider wants to help out, he might setup a captive portal or something with information regarding tools to clean their computer. -- Gadi Evron, g...@linuxbox.org. Blog: http://gevron.livejournal.com/
Re: ISP customer assignments
Joe Greco jgr...@ns.sol.net writes: the people with the clue-by-fours are over on the IPv6 lists. They've upgraded to clue-by-six's. Not as handy, but will last longer. Bjørn
RE: ISP customer assignments
-Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Snip - good points all Most of those concerns are in fact mitigated by a well implemented Privacy implementation Which is why I started off by mentioning RFC4191. ;) -End Original Message- And Vista/Win7/etc. make it even more interesting by not doing EUI64 at all. ... Hopefully they have more entropic 'random' values as well ... /TJ
Re: Practical numbers for IPv6 allocations
FWIW - I don't believe the two arguments are in opposition/conflict ... But totally agree with your end result of /56s and /48s, with add'l bits held in reserve ... /TJ On Mon, Oct 5, 2009 at 11:39 PM, Doug Barton do...@dougbarton.us wrote: [ 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
Re: ISP customer assignments
On 05/10/09 22:28 -0400, Ricky Beam wrote: On Mon, 05 Oct 2009 17:13:37 -0400, Dan White dwh...@olp.net wrote: I don't understand. You're saying you have overlapping class boundaries in your network? No. What I'm saying is IPv6 is supposed to be the new, ground-breaking, unimaginably huge *classless* network. Yet, 2 hours into day one, a classful boundary has already been woven into it's DNA. Saying it's I would disagree. IPv6 is designed around class boundaries which, in my understanding, are: A layer two network gets assigned a /64 A customer gets assigned a /48 An ISP gets assigned a /32 (unless they need more) classless because routing logic doesn't care is pure bull. In order for the most basic, fundamental, part (the magic -- holy grail -- address autoconfig) to function, the network has to be a minimum of /64. Even when the reason for that limit -- using one's MAC to form a (supposedly) unique address without having to consult with anything or fire off a single packet -- has long bit the dust; privacy extensions generate addresses at random and have to take steps to avoid address collisions, so continuing to cling to it has to be 64bits is infuriating. IPv6 provides you the opportunity to design your network around your layer two needs, not limited by restrictive layer 3 subnetting needs. If your complaint is that all devices in a /64 are going to see IPv6 broadcast/multicast packets from the rest of the devices in that subnet, then don't assign 2^64 devices to that subnet. I still don't understand why its infuriating to you, but I can certainly tell that it is. -- Dan White BTC Broadband
Re: ISP customer assignments
On 05/10/09 22:53 -0400, Ricky Beam wrote: 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. Use random addresses, and change as often as you like. Why depend on someone else's DHCP server to provide you the addressing uniqueness you desire? -- Dan White BTC Broadband
RE: Dutch ISPs to collaborate and take responsibility for bottedclients
-Original Message- From: Eugeniu Patrascu [mailto:eu...@imacandi.net] Sent: Tuesday, October 06, 2009 4:20 AM To: Gadi Evron Cc: NANOG Subject: Re: Dutch ISPs to collaborate and take responsibility for bottedclients . I think the need for someone being able to call 911 from their VoIP outweighs your right to claim that they should be disconnected from the Internet. I believe the FCC requires even deactivated phones to be able to reach 911. Can't confirm, fcc.gov is down. Don't know about CRTC. And I don't know how this could apply to an over-the-top VoIP service--how would an ISP know you're trying to call 911 on Skype? Besides, if that provider wants to help out, he might setup a captive portal or something with information regarding tools to clean their computer. Many providers already do that. Lee
RE: ISP customer assignments
-Original Message- From: William Herrin [mailto:herrin-na...@dirtside.com] Sent: Monday, October 05, 2009 12:58 PM To: Brian Johnson Cc: nanog@nanog.org Subject: Re: ISP customer assignments /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, I have a lack of imagination, I guess. I can't imagine anyone larger than a small residential user being assigned a /60 or less. Therefore, nybble boundary for rDNS delegation only matters if you delegate rDNS for that block. handling multiple routes when the customer grows, not Any customer getting a /60 or less will be dynamically numbered (RA, DHCPv6, whatever), and if more space is needed, should be easily renumbered into a larger prefix. matching the standard /64 subnet size and a myriad other obscure issues. I don't know about myriad but I agree that /64 is the standard subnet size. I am *not* advocating assignments of /60 or less, just pointing out that if you do it, it doesn't have to break. Lee
Re: ISP customer assignments
On 05/10/09 23:23 -0400, Ricky Beam wrote: You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible. That has not been my (limited) experience. If you are aware of any ISPs which are not handing out a reasonable address space to customers, please call them out. 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 it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules. You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days... The assumption that IPv6 addresses are harder has not been my experience. A server address of 2610:b8:5::1 is just as easy for me to remember as 67.217.144.1. Granted, auto configured addresses are much harder to remember. And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP. Anything I put in DNS is a server/router, and gets a static address, just like with IPv4. -- Dan White BTC Broadband
RE: ISP customer assignments
-Original Message- From: robert.e.vanor...@frb.gov [mailto:robert.e.vanor...@frb.gov] Sent: Monday, October 05, 2009 7:41 PM To: nanog@nanog.org Subject: Re: ISP customer assignments 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... Most organizations will still be assigned a /48 (or whatever) from their ISP. Provider-aggregable addressing has no routing scalability problems. I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... I have to agree, here. Moving between letters and numbers, and having to hit shift to use the colon wastes valuable keystrokes compared to the keypad. However, compare IPv6 vs IPv4-like numbering: 2001:db8:f1::1 81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 Did I type the right number of zeroes? Lee
RE: Practical numbers for IPv6 allocations
Doug Barton wrote: [ 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. I agree with the point about undefined costs, but the biggest one that is easy to see is that 100-300 years from now when someone thinks about moving on to the second /3, this entire discussion will have been lost and there will be an embedded-for-generations expectation that the model is cast in stone for all of the /3's. 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. www.tndh.net/~tony/ietf/draft-hain-ipv6-geo-addr-00.txt shows a different way to allocate space, using only 1/16 the total space to achieve a /48 globally on a 6m grid. Other ideas will emerge, so you are correct that we can't assume we have 8 shots at this, but if the first pass is really bad the second will be so draconian in restrictions that you will never get to the third. 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. Well mostly. It is not set forget, but a lot of the day-to-day in IPv4 is wrapped up in managing subnet sizes to 'avoid waste'. In an IPv6 environment the only concern is the total number of subnets needed to meet routing/access policy, avoiding the nonsense of continually shifting the subnet size to align with the number of endpoints over time. 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. :) People need to get over it... the original design was 64 bits for both hosts and routing exceeding the design goal by 10^3, then routing wanted more so it was given the whole 64 bits. The fact that 64 more bits was added is not routing's concern, but the IPv4-conservation mindset can't seem to let it go despite having 10^6 more space to work with than the target. It could have been 32 bits (resulting in a 96 bit address), but given that 64 bit processors were expected to be widespread, it makes no sense to use less than that. 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. I assume you meant 4-bit. ;) ^^^ 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. Stop looking backward. To achieve the home network of the last millennium a small number of subnets was appropriate. Constraining the world to that through allocation is a self-fulfilling way to
RE: ISP customer assignments
Rick et al, I work at an ISP, and I know staff at several other ISPs, we are all trying to do this right. If a /56 makes sense and is supported by the IPv6 technology and we won't have issues supplying these to customers (technically speaking), then we will most likely do this or something similar. The issue is more of a nuanced issue. There seems to be a variance between It's OK to just give out a /64 to You better be thinking about giving out a /48. I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound? This wasn't suppose to digress to this level of vitriol. - Brian -Original Message- From: Ricky Beam [mailto:jfb...@gmail.com] Sent: Monday, October 05, 2009 10:23 PM To: Joe Greco; robert.e.vanor...@frb.gov Cc: nanog@nanog.org Subject: Re: ISP customer assignments On Mon, 05 Oct 2009 20:14:01 -0400, Joe Greco jgr...@ns.sol.net wrote: 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. You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible. 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 it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules. You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days... And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP. --Ricky
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
On Oct 6, 2009, at 1:20 AM, Eugeniu Patrascu wrote: Gadi Evron wrote: Barton F Bruce wrote: 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. While a legitimate concern it's also a red herring, as it's a technical problem looking for a technical solution. Gadi. I think the need for someone being able to call 911 from their VoIP outweighs your right to claim that they should be disconnected from the Internet. Besides, if that provider wants to help out, he might setup a captive portal or something with information regarding tools to clean their computer. I disagree... Distributed Denials of Service have gotten to the point where they can actually endanger lives. Think about this... In order to be able to make your 911 VOIP call, the VOIP provider has to be able to process your call. The system that is getting disconnected because it is an active source of abuse may be one of many participating in a DOS against someone elses 911 VOIP provider. Removing them from the internet could be saving more lives than it risks. Someone else pointed out that if the system in question has been botted/owned/pwn3d/whatever you want to call it, then, you can't guarantee it would make the 911 call correctly anyway. Owen
Re: ISP customer assignments
On Oct 6, 2009, at 7:29 AM, Lee Howard wrote: -Original Message- From: robert.e.vanor...@frb.gov [mailto:robert.e.vanor...@frb.gov] Sent: Monday, October 05, 2009 7:41 PM To: nanog@nanog.org Subject: Re: ISP customer assignments 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... Most organizations will still be assigned a /48 (or whatever) from their ISP. Provider-aggregable addressing has no routing scalability problems. I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... I have to agree, here. Moving between letters and numbers, and having to hit shift to use the colon wastes valuable keystrokes compared to the keypad. However, compare IPv6 vs IPv4-like numbering: 2001:db8:f1::1 81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 Did I type the right number of zeroes? I don't know, but, it's not 81.93.35.12... It's: 32.1.13.184.241.0.0.0.0.0.0.0.0.0.0.1 And that is the correct number of zeroes for 2001:db8:f1::1. Also, there's no reason the syntax couldn't be made 32.1.13.184.241..1 although that isn't the case today. However, I believe that 90.1 is supposed to be parsed equivalent to 90.0.0.1 and 90.5.1 is supposed to be treated as 90.5.0.1, so, 32.1.13.184.241.1 should also work for the above if you expanded todays IPv4 notation to accept IPv6 length addresses. Owen Lee
Re: IPv6 peering between Internet2 and Hurricane Electric
* Florian Weimer: 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. I've been told that the looking glass needs some knowledge about Internet2's routing architecture to use properly, and that I had misinterpreted its output. Sorry about that. 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.) That site hasn't got global IPv6 transit, and it's likely that this is causing the reachability issue (d'oh).
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
Re: VOIP, 911, bots Shape their bandwidth down to the minimum required to make a 911 call, around 64Kbps, and capture their web accesses. -- -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: Practical numbers for IPv6 allocations
Tony Hain wrote: Doug Barton wrote: 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. I assume you meant 4-bit. ;) Grrr, I hate when I do that. I spent quite a bit of time on this post, and the one time I remembered that I needed to go back and double-check what I wrote there I wasn't at the keyboard. Thanks for keeping me honest. There was one other thing you wrote that I wanted to clarify, you indicated that I was arguing for ISPs to only get one shot at an IPv6 allocation. Since my post was already really long I chose to leave out the bit about how (TMK, which could be outdated) the RIRs are reserving a bit or two for their allocations to ISPs so going back and expanding should be an easy thing to do. On a personal note, I hope that we DO need to expand IPv6 allocations to ISPs as this thing finally gets deployed. I'm not responding to the rest of your post because you and I have already had those discussions in person on more than one occasion and I know I'm not going to change your mind. I do think it's extremely gracious of you to say that my post was well reasoned though. :) Thanks to the others who had nice things to say as well. Regards, Doug
Re: ISP customer assignments
On Tue, 06 Oct 2009 09:34:28 PDT, Owen DeLong said: although that isn't the case today. However, I believe that 90.1 is supposed to be parsed equivalent to 90.0.0.1 and 90.5.1 is supposed to be treated as 90.5.0.1, so, 32.1.13.184.241.1 should also work for the above if you expanded todays IPv4 notation to accept IPv6 length addresses. So if you expand the notation like that, is 32.1.13.7 a 32 bit IPv4 address, or a 128 bit IPv6 address with lots of zeros between 13 and 7? They chose the : instead of overloading '.' for a *reason*... pgpckqTyuip4k.pgp Description: PGP signature
Up Next: Quarantine Phishing (Was: Dutch ISPs to collaborate and take responsibility for bottedclients)
mark [at] edgewire wrote: The end problem is still users and really, these users will click on anything that has a bright and shiny button which says, Ok. Really, does setting up a portal help? Perhaps a sandboxed area which has some information on securing their machine and keeping it clean may be the way to go but how much more of a resource will it chew up? And then the nice phisher people come in and they replicate the quarantine website of various providers (just check IP address, you know the ISP and present the appropriate page) after having lured them to some site they control. Then they simply have a nice big Install this cool tool to update your computer link et voila. The problem with all of that boils down to what people have to believe... and how to properly inform them of that... Yes, I think the sandbox/quarantine style things is the way to go for the time being, but there are other more important things that need fixing. (afaik) Most people will get infected by clicking on something at one point in time on some weird website, even after having googled it etc. The problem is that it is really hard to show to the user that a site is 'trustworty' or not, especially as everyone can just get an SSL certificate for faceb0ok.com and m1crosoft.com and soon also for all the nice variants in the IDN space, thus SSL doesn't state anything, it just makes the connection secure (aka unsniffable unless there is a 3 letter acronym doing so, or they have access to either end). And that would not help much either as even Facebook and other such sites have been used to distribute worms, thus it becomes really hard to do it on a domain basis, as what is on a domain at point X in time, will be different at point Y, thus distributing lists becomes problematic too. The company that can come up with a proper universal solution to that problem (and patent it so they can actually get the moneyz) will probly end up doing quite well. Most likely though it means restricting user freedom, which is the counter problem as that is something one doesn't want, and when there is an option to disable it, then people will just disable it. Greets, Jeroen signature.asc Description: OpenPGP digital signature
RE: Dutch ISPs to collaborate and take responsibility for bottedclients
-Original Message- From: Eugeniu Patrascu [mailto:eu...@imacandi.net] Sent: Tuesday, October 06, 2009 4:20 AM To: Gadi Evron Cc: NANOG Subject: Re: Dutch ISPs to collaborate and take responsibility for bottedclients . I think the need for someone being able to call 911 from their VoIP outweighs your right to claim that they should be disconnected from the Internet. I believe the FCC requires even deactivated phones to be able to reach 911. Can't confirm, fcc.gov is down. Authoritatively *NOT* true for hard-wire landlines in the U.S. Cellular may, and I believe _is_, be a different story.
Re: ISP customer assignments
On Tue, 6 Oct 2009 09:25:44 -0500 Dan White dwh...@olp.net wrote: On 05/10/09 23:23 -0400, Ricky Beam wrote: You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible. That has not been my (limited) experience. If you are aware of any ISPs which are not handing out a reasonable address space to customers, please call them out. Once one of them actually realises how much address space they've been given, and that giving more perceived value to a customer will win them the business, I think they will e.g. same price, same quota/bandwidth, one ISP giving you 64K more address space. I think customers will say, I fully understand what it's for, and I don't really know what I'll use it for .. but I'll have it if I ever need it. 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 it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules. I think it is both classless and classfull (although it's different enough that we probably should stop using loaded IPv4 terms ...) Forwarding is purely classless - the best route is the one with the longest matching prefix length, regardless of where that prefix length lands within the 128 bits. For 1/8th of the address space, it's classful. It's been shown that humans work best with simplicity, so introducing fixed operational (but not forwarding) boundaries between node, subnet and global prefixes makes IPv6 much more operationally simple than dealing with IPv4 classes, subnets or classless addressing. I think anybody who has dealt operationally with IPX, Appletalk, XNS, DECnet or even Ethernet with it's single OUI/Node ID boundary would agree. If the plan for the classful 1/8th ends up being wrong, the classless forwarding means that we don't have to deploy new routing code or hardware to change to a different addressing model, be it classless or something else. You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days... The assumption that IPv6 addresses are harder has not been my experience. A server address of 2610:b8:5::1 is just as easy for me to remember as 67.217.144.1. Granted, auto configured addresses are much harder to remember. And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP. Anything I put in DNS is a server/router, and gets a static address, just like with IPv4. -- Dan White BTC Broadband
Re: Dutch ISPs to collaborate and take responsibility
Someone else pointed out that if the system in question has been botted/owned/pwn3d/whatever you want to call it, then, you can't guarantee it would make the 911 call correctly anyway. I realize that many NANOG'ers don't actually use the technologies that we talk about, so I'm just going to correct this: You seem to be under the mistaken assumption that most people using VoIP do so using their computer. While it kind of started out that way years ago, it simply isn't so anymore. Most VoIP services can be configured to work with an analog telephony adapter, providing a POTS jack. Most VoIP services even provide one as part of the subscription, sometimes for a fee. There's also a growing number of phones that support Skype or generic VoIP, sometimes alongside a regular POTS line, sometimes not. It is perfectly possible to have an infected PC sitting right next to a nice VoIP-capable DECT cordless phone system, both hooked to the same NAT router. This is, of course, problematic, and would be a useful problem to contemplate how to cause one to break while keeping the other operational. Assuming that the existence of an infected PC in the mix translates to some sort of inability to make a 911 call correctly is, however, simply irresponsible, and at some point, is probably asking for trouble. ... 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
unimaginably huge *classless* network. Yet, 2 hours into day one, a classful boundary has already been woven into it's DNA. Saying it's No bit patterns in a V6 address indicate total size of a network. v6 doesn't bring classful addressing back or get rid of CIDR.. v6 dispenses with something much older: common use of VLSM on the local LAN and sizing subnets based on the number of hosts. Instead a form of FLSM is recommended, a fixed standard subnet size of /64 that essentially all IPv6 networks use for the subnets that have hosts on them. This restores consistency to LAN addressing. In V4 there is a valid reason for choosing VLSM and sizing every subnet: IP addresses are scarce. V6 removes that scarcity problem. No more unanticipated growth necessitating an addressing re-design, or at least error-prone adjustment of netmasks on all hosts. No more hodgepodge of different netmask settings for different sized LANs. No more LAN address ranges starting or ending with a different trailing string of digits than other LANs. /64 is the standard. V6 leaves the operator able to pick something different, but in most cases it would be a very poor design practice, and ISPs should think long and hard before ignoring the standard and trying to issue a customer subnet a /128, instead of /48 or /56. However... none of the network protocol documents were ever able to prevent determined people from coming up with bad designs, or ignoring recommendations due to politics or preconceived notion(s); don't hold your breath on that one... -- -J
Re: ISP customer assignments
On Tue, 06 Oct 2009 17:40:40 -0400, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: I think it is both classless and classfull (although it's different enough that we probably should stop using loaded IPv4 terms ...) It's _classless_. There's none of this Class A, B, C, D, or E nonsense. The word everyone is dancing around is, hierarchical. How the bits get divided up depends on what you want to do with it. SLAAC, in it's current form, requires a 64-bit prefix, but there are other ways to assign addresses that do not have that requirement. --Ricky
Re: Practical numbers for IPv6 allocations
On 7/10/2009, at 6:10 AM, Doug Barton wrote: Tony Hain wrote: Doug Barton wrote: 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. I assume you meant 4-bit. ;) Grrr, I hate when I do that. I spent quite a bit of time on this post, and the one time I remembered that I needed to go back and double-check what I wrote there I wasn't at the keyboard. Thanks for keeping me honest. There was one other thing you wrote that I wanted to clarify, you indicated that I was arguing for ISPs to only get one shot at an IPv6 allocation. Since my post was already really long I chose to leave out the bit about how (TMK, which could be outdated) the RIRs are reserving a bit or two for their allocations to ISPs so going back and expanding should be an easy thing to do. On a personal note, I hope that we DO need to expand IPv6 allocations to ISPs as this thing finally gets deployed. My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong. -- Nathan Ward
Re: Practical numbers for IPv6 allocations
On Oct 6, 2009, at 6:13 PM, Nathan Ward wrote: My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong. Last I heard, with the exception of APNIC and contrary to what they indicated they'd do prior to IANA allocating the /12s, you are indeed wrong. I'd be happy to hear things have changed. Regards, -drc
Re: Practical numbers for IPv6 allocations
On Oct 6, 2009, at 6:17 PM, David Conrad wrote: On Oct 6, 2009, at 6:13 PM, Nathan Ward wrote: My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong. Last I heard, with the exception of APNIC and contrary to what they indicated they'd do prior to IANA allocating the /12s, you are indeed wrong. I'd be happy to hear things have changed. Sigh. Seem to have troubles posting coherent English to the Nanog list recently. The they in the above sentence references the RIRs except for APNIC (last I heard). Regards, -drc
Does Internet Speed Vary by Season?
http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion -Hank
