Re: Possible Sudden Uptick in ASA DOS?
you would think a researcher would stop once he realised effect being caused ? Colin On 9 Jul 2015, at 14:08, Jared Mauch ja...@puck.nether.net wrote: My guess is a researcher. We saw the same issue in the past with a Cisco microcode bug and people doing ping record route. When it went across a LC with a very specific set of software it would crash. If you crashed just upgrade your code, don't hide behind blocking an IP as people now know what to send/do. It won't be long. Jared Mauch On Jul 9, 2015, at 7:44 AM, Colin Johnston col...@gt86car.org.uk wrote: Hi Jared, thanks for update do you know provider/source ip of the source of the attack ? Colin On 9 Jul 2015, at 12:27, Jared Mauch ja...@puck.nether.net wrote: Really just people not patching their software after warnings more than six months ago: July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. Jared Mauch On Jul 8, 2015, at 1:15 PM, Michel Luczak fr...@shrd.fr wrote: On 08 Jul 2015, at 18:58, Mark Mayfield mark.mayfi...@cityofroseville.com wrote: Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. Not sure it’s related but I’ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. Regards, Michel
Re: Dual stack IPv6 for IPv4 depletion
Probably because he got good advise from his father :) On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch c...@pobox.com wrote: On 9 July 2015 at 09:11, Mike Hammett na...@ics-il.net wrote: I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. My son (who is not a tech guy but is a gamer) has four subnets in his (rented) house already: private LAN, guest network, home control network, and a separate LAN for the tenant downstairs who is sharing their broadband connection. And he's just getting started. The common man is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need. -- Harald
Re: Hotels/Airports with IPv6
We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either. On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman m...@beckman.org wrote: I working on a large airport WiFi deployment right now. IPv6 is allowed for in the future but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. -mel beckman On Jul 9, 2015, at 7:53 AM, Jared Mauch ja...@puck.nether.net wrote: It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. I’m wondering what people who deploy captive portals are doing with these things? https://tools.ietf.org/html/draft-wkumari-dhc-capport seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6. Thanks, - Jared -- :o@
Re: Possible Sudden Uptick in ASA DOS?
I’m sure they did. It could also have been any number of other things. I’m just guessing. It could have been someone trying to scan their enterprise too and went a bit rogue. Not everyone reads NANOG believe it or not :) Either way, if you haven’t upgraded for a 9 month old security advisory, shame on you. I don’t care what your change management process looks like, it’s bordering on network malpractice IMHO. - Jared On Jul 9, 2015, at 10:09 AM, Colin Johnston col...@gt86car.org.uk wrote: you would think a researcher would stop once he realised effect being caused ? Colin On 9 Jul 2015, at 14:08, Jared Mauch ja...@puck.nether.net wrote: My guess is a researcher. We saw the same issue in the past with a Cisco microcode bug and people doing ping record route. When it went across a LC with a very specific set of software it would crash. If you crashed just upgrade your code, don't hide behind blocking an IP as people now know what to send/do. It won't be long. Jared Mauch On Jul 9, 2015, at 7:44 AM, Colin Johnston col...@gt86car.org.uk wrote: Hi Jared, thanks for update do you know provider/source ip of the source of the attack ? Colin On 9 Jul 2015, at 12:27, Jared Mauch ja...@puck.nether.net wrote: Really just people not patching their software after warnings more than six months ago: July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. Jared Mauch On Jul 8, 2015, at 1:15 PM, Michel Luczak fr...@shrd.fr wrote: On 08 Jul 2015, at 18:58, Mark Mayfield mark.mayfi...@cityofroseville.com wrote: Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. Not sure it’s related but I’ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. Regards, Michel
Re: Possible Sudden Uptick in ASA DOS?
On Thu, Jul 9, 2015 at 10:09 AM, Colin Johnston col...@gt86car.org.uk wrote: you would think a researcher would stop once he realised effect being caused ? how would he/she know?
Re: Hotels/Airports with IPv6
On Jul 9, 2015, at 9:53 AM, Jared Mauch ja...@puck.nether.net wrote: It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. I’m wondering what people who deploy captive portals are doing with these things? https://tools.ietf.org/html/draft-wkumari-dhc-capport seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6. Thanks, - Jared We use the HotSpot feature on a Mikrotik box as a captive portal. It does not re-direct IPv6 web traffic but it does redirect all IPv4 DNS traffic to a DNS resolver that only answers with A records. Once a device has been authenticated IPv4 DNS traffic goes to a DNS server that will answer with records also. --- Bruce Curtis bruce.cur...@ndsu.edu Certified NetAnalyst II701-231-8527 North Dakota State University
Re: Dual stack IPv6 for IPv4 depletion
On 9 July 2015 at 09:11, Mike Hammett na...@ics-il.net wrote: I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. My son (who is not a tech guy but is a gamer) has four subnets in his (rented) house already: private LAN, guest network, home control network, and a separate LAN for the tenant downstairs who is sharing their broadband connection. And he's just getting started. The common man is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need. -- Harald
RE: Hotels/Airports with IPv6
Most hotels etc, are perfectly happy doing NAT. Dennis Burgess, CTO, Link Technologies, Inc. den...@linktechs.net – 314-735-0270 – www.linktechs.net -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Oliver O'Boyle Sent: Thursday, July 09, 2015 10:20 AM To: Mel Beckman Cc: North American Network Operators' Group Subject: Re: Hotels/Airports with IPv6 We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either. On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman m...@beckman.org wrote: I working on a large airport WiFi deployment right now. IPv6 is allowed for in the future but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. -mel beckman On Jul 9, 2015, at 7:53 AM, Jared Mauch ja...@puck.nether.net wrote: It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. I’m wondering what people who deploy captive portals are doing with these things? https://tools.ietf.org/html/draft-wkumari-dhc-capport seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6. Thanks, - Jared -- :o@
Re: Hotels/Airports with IPv6
I working on a large airport WiFi deployment right now. IPv6 is allowed for in the future but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. -mel beckman On Jul 9, 2015, at 7:53 AM, Jared Mauch ja...@puck.nether.net wrote: It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. I’m wondering what people who deploy captive portals are doing with these things? https://tools.ietf.org/html/draft-wkumari-dhc-capport seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6. Thanks, - Jared
Re: Hotels/Airports with IPv6
On Thursday, July 9, 2015, Mel Beckman m...@beckman.org wrote: I working on a large airport WiFi deployment right now. IPv6 is allowed for in the future but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. 1. Users will never demand ipv6. They demand google and facebook. So that road goes nowhere 2. What data do you have that most devices and apps are not default-on / ready for ipv6. My guess is most devices carried by airport users will accept and use ipv6 address, and most used destinations (google, fb, netflix, wikipedia, ) use ipv6 CB -mel beckman On Jul 9, 2015, at 7:53 AM, Jared Mauch ja...@puck.nether.net javascript:; wrote: It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. I’m wondering what people who deploy captive portals are doing with these things? https://tools.ietf.org/html/draft-wkumari-dhc-capport seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6. Thanks, - Jared
Re: Hotels/Airports with IPv6
Yep, because most don't even know what NAT is! On Thu, Jul 9, 2015 at 11:33 AM, Dennis Burgess dmburg...@linktechs.net wrote: Most hotels etc, are perfectly happy doing NAT. Dennis Burgess, CTO, Link Technologies, Inc. den...@linktechs.net – 314-735-0270 – www.linktechs.net -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Oliver O'Boyle Sent: Thursday, July 09, 2015 10:20 AM To: Mel Beckman Cc: North American Network Operators' Group Subject: Re: Hotels/Airports with IPv6 We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either. On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman m...@beckman.org wrote: I working on a large airport WiFi deployment right now. IPv6 is allowed for in the future but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. -mel beckman On Jul 9, 2015, at 7:53 AM, Jared Mauch ja...@puck.nether.net wrote: It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. I’m wondering what people who deploy captive portals are doing with these things? https://tools.ietf.org/html/draft-wkumari-dhc-capport seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6. Thanks, - Jared -- :o@ -- :o@
Hotels/Airports with IPv6
It’s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. I’m wondering what people who deploy captive portals are doing with these things? https://tools.ietf.org/html/draft-wkumari-dhc-capport seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn’t work well what works for IPv6. Thanks, - Jared
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 08:42 , Matthew Huff mh...@ox.com wrote: What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? It’s the need for a large enough bitfield to do more flexible things with auto-delegation in a dynamic self-organizing topology. 8 is 2x2x2 and there’s really no other way you can break it down. (2x4, 4x2, 2x2x2 is it.) 16 is 2x2x2x2 and allows many more possible topologies (4x4, 2x4x2, 2x2x4, 2x8, 8x2, etc.) With /56 you are giving each residential customer: 256 subnets x 18,446,744,073,709,551,616 hosts per subnet. The host count is irrelevant to the discussion. I would expect at least 95.0% of residential customers are using 1 subnet, and 99.9% are using less than 4. I can understand people complaining when some ISPs were deciding to only give out a /64, but even with new ideas, new protocols and new applications, do people really think residential customers will need more than 256 subnets? When such a magical new system is developed, and people start to want it, can't ISPs start new /48 delegations? Since DHCP-PD and their infrastructure will already be setup for /56, it may not be easy, but it shouldn't be that difficult. I would expect that basing decisions about limits on tomorrows network on the inadequacy of today’s solutions is unlikely to yield good results. Further, I’m not so sure you are right in your belief. I suspect that there are many more networks in most households that you are not counting. Sure, those networks are currently usually disjoint, but do you really think it will always be that way in the future? Every phone is a router. Ever tablet is a router. Cars are becoming routers and in some cases, collections of routers. Set top boxes are becoming routers. Utility meters are becoming routers. Laptops and desktops are capable of being routers. I know the saying build it and they will come, but seriously I'd rather ISPs stop discussing deploying IPv6, and start doing it… I’m all for that, but do you have a valid reason not to give out /48s per end site? Just because /56 might be enough doesn’t cut it… I’m asking if you can point to any tangible benefit obtained from handing out /56s instead? Is there any problem solved, labor saved, or any other benefit whatsoever to giving out /56s instead of /48s? If not, then let’s hand out /48s until we discover one. Owen
RE: Dual stack IPv6 for IPv4 depletion
What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? With /56 you are giving each residential customer: 256 subnets x 18,446,744,073,709,551,616 hosts per subnet. I would expect at least 95.0% of residential customers are using 1 subnet, and 99.9% are using less than 4. I can understand people complaining when some ISPs were deciding to only give out a /64, but even with new ideas, new protocols and new applications, do people really think residential customers will need more than 256 subnets? When such a magical new system is developed, and people start to want it, can't ISPs start new /48 delegations? Since DHCP-PD and their infrastructure will already be setup for /56, it may not be easy, but it shouldn't be that difficult. I know the saying build it and they will come, but seriously I'd rather ISPs stop discussing deploying IPv6, and start doing it... Verizon: The upgrades will start in 2013 and the first phase will include Verizon FiOS customers who have a dynamic IP address.. I'm still waiting...(at least I have a 6in4 tunnel with he.net). Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Marco Teixeira Sent: Thursday, July 9, 2015 11:09 AM To: Harald Koch Cc: NANOG list Subject: Re: Dual stack IPv6 for IPv4 depletion Probably because he got good advise from his father :) On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch c...@pobox.com wrote: On 9 July 2015 at 09:11, Mike Hammett na...@ics-il.net wrote: I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. My son (who is not a tech guy but is a gamer) has four subnets in his (rented) house already: private LAN, guest network, home control network, and a separate LAN for the tenant downstairs who is sharing their broadband connection. And he's just getting started. The common man is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need. -- Harald
Re: Dual stack IPv6 for IPv4 depletion
On 9 July 2015 at 11:42, Matthew Huff mh...@ox.com wrote: What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not here's a subnet for the car, it's here's a /56 for the car to break into smaller pieces as required. A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for the car network to make the routing and security easier to manage, and leave room for expansion (or for my guests...) One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the remaining space left to do something different. -- Harald
RE: Dual stack IPv6 for IPv4 depletion
When I see a car that needs a /56 subnet then I’ll take your use case seriously. Otherwise, it’s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work using jetpacks. We have prefix delegation already via DHCP-PD, but some in the IPv6 world don’t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don’t let the prefect be the enemy of the good. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff| Fax: 914-694-5669 From: Harald Koch [mailto:c...@pobox.com] Sent: Thursday, July 9, 2015 12:01 PM To: Matthew Huff Cc: Marco Teixeira; NANOG list Subject: Re: Dual stack IPv6 for IPv4 depletion On 9 July 2015 at 11:42, Matthew Huff mh...@ox.commailto:mh...@ox.com wrote: What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not here's a subnet for the car, it's here's a /56 for the car to break into smaller pieces as required. A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for the car network to make the routing and security easier to manage, and leave room for expansion (or for my guests...) One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the remaining space left to do something different. -- Harald
RE: Dual stack IPv6 for IPv4 depletion
It seems like there might be several incorrect assumptions here leading to over thinking the issue. 1. Over a long period of time, will the size or number of subnets be significantly different than today. Even today a bunch of our assumptions on why subnets are created the way they are might be obsolete or close to it. For example, broadcast domain size becomes less of an issue as broadcasts are used less (presumably by better targeted multicast and smarter protocols) and device performance increases. Maybe networks get smart enough to reorganize themselves and their subnets to optimize performance or maybe there will not be the need to do so. 2. Am I wrong or are we making some bad assumptions about routability of subnets? It seems like we might be too concerned about the minimum routable sized subnet when in reality that is just a policy decision open to change over time. Also, the routing I do inside my home does not need to be routable to the Internet at large. Summarization can occur in my home and at the service provider level. 3. If a couple of users required an inordinate amount of subnets, why not assign them an additional netblock? In the V4 world Fortune 500 global networks are not treated the same as your grandma's cell phone. It's nice to have the comfort of doing it with V6 but no real compelling reason not to have more than one type of customer assignment. Why not size things for the usual use case and add another allocation as needed? Seems really wasteful to do anything else. The NICs don't give a global carriers the same assignments they give a simple dual homed user why should you think all of your sub-assignments would be identical? 4. This is not the last time in history that you might get to reorganize your address space so don't try to plan for crazy edge cases. Given the widespread use of DHCP (or any other automatic addressing technology) in the V6 world it is archaic to think that an address change will be a big inconvenience. If my device receives an address and auto updates DNS records then I really do not care what that address is. Feel free to reorganize the network whenever you want. 5. The car example does not work because I am assuming you don't drive in your home. You probably roam all around the area and will be getting dynamic assignments from whomever the provider is. Do you statically address your iPhone when it is on the 3G/4G/LTE network? Steven Naslund Chicago IL Subject: Re: Dual stack IPv6 for IPv4 depletion On 9 July 2015 at 11:42, Matthew Huff mh...@ox.commailto:mh...@ox.com wrote: What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not here's a subnet for the car, it's here's a /56 for the car to break into smaller pieces as required. A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for the car network to make the routing and security easier to manage, and leave room for expansion (or for my guests...) One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the remaining space left to do something different.
Re: Dual stack IPv6 for IPv4 depletion
On Thu, Jul 9, 2015 at 9:01 AM, Harald Koch c...@pobox.com wrote: On 9 July 2015 at 11:42, Matthew Huff mh...@ox.com wrote: What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? It is wasting that /64 on each separate media, lan type, or security model. One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not here's a subnet for the car, it's here's a /56 for the car to break into smaller pieces as required. A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for the car network to make the routing and security easier to manage, and leave room for expansion (or for my guests...) One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the remaining space left to do something different. And the colonists of Alpha Centauri will curse our shortsightedness. -- Harald -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 09:16 , Matthew Huff mh...@ox.com wrote: When I see a car that needs a /56 subnet then I’ll take your use case seriously. Otherwise, it’s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work using jetpacks. When I see a reason not to give out /48s, I might start taking your argument seriously. We have prefix delegation already via DHCP-PD, but some in the IPv6 world don’t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. Clearly the quality of IPv6 in embedded devices needs to improve. There’s clearly work being done on LWIP IPv6, but I don’t think it’s ready for prime time yet. (LWIP is one of the most popular embedded IP stacks. You’ll find it in a wide range of devices, including, but not limited to the ESP8266). Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don’t let the prefect be the enemy of the good. /48s for end sites are NOT new… They have been part of the IPv6 design criteria from about the same time 128-bit addresses were decided. It is these silly IPv4-think notions of /56 and /60 that are new changes to the protocol. The good news is that it’s very easy to deploy /48s and if it turns out we were wrong, virtually everyone currently advocating /48s will happily help you get more restrictive allocation policies when 2000::/3 runs out. (assuming any of us are still alive when that happens). Owen
Re: Dual stack IPv6 for IPv4 depletion
Den 09/07/2015 18.08 skrev Owen DeLong o...@delong.com: That will never happen. If you offer me $1000 per IPv4, then I will happily terminate some user contracts and sell their IP space to you… Eventually, you run out of user contracts to terminate. At $1000 per contract I do not care. I will retire and be happy. Seriously ISPs are often valued by number of active contracts. A typical value might be $100 to $200. The value of an IPv4 address can not go any higher than this because at that point you can buy another company just to get the addresses. In fact it will never become even that expensive. With a marked price of $10 I am buying IP space for customers as needed and I will include free space in the contracts. If the price went to $100 I would tell all users that they need to pay monthly rent for their IP or alternative, the user would have to accept carrier NAT in some form. And then I would proceed to buy a new house for the money I make by selling address space. Sure, but aren’t your customers going to start demanding IPv6 instead of that at some point? My customers have been demanding IPv6 for some time already. Aren’t they going to start insisting on a service that doesn’t charge per address? They will have their free IPv6 and will care less about a non shared IPv4. This will cause the valuation of IPv4 to crash at some point because the demand will disappear. There is a ton of address space that is inefficient used. We will be able to buy excess from companies that create space by optimizing their existing space. There is a reason we have not seen any rise in the price even after multiple years with depletion in large parts of the world. Yes… It’s called “soft landing”… ARIN will be the first region to deplete without significant austerity policies for newcomers to get address space. RIPE gives you 1k addresses. This is not enough even for two guys and a router. But yes it is a nice token. The big companies have now gone without new space for a while. Just a few months ago I bought 2k addresses at $6 per address. I do not observe any rising tendency in IPv4 pricing. Regards Baldur
Re: Dual stack IPv6 for IPv4 depletion
My parents are non-technical. Other than a little help connecting her airport to the cable modem, I had nothing to do with the design and implementation of their networks. They have at least 7 distinct subnets in their house that I know of. Some of them are routed together. Some of them are isolated. I suspect my parents don’t even realize what a subnet is or how a router connects them. It is unlikely, IMHO, that said topology will likely get flattened in the future. I expect, rather, that it will grow both vertical and horizontal. I think that’s about as common person as it gets. So I’m not talking about the 15-30 subnets in my house, depending on the day, nor the subnets outside of my house used to support the networking in my house (point to point circuits and the like). I’m well aware that the common person does not have an ASN for their home and the average home thinks BGP is probably an airport code. Owen On Jul 9, 2015, at 06:11 , Mike Hammett na...@ics-il.net wrote: I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com - Original Message - From: Tony Finch d...@dotat.at To: Ricky Beam jfb...@gmail.com Cc: nanog@nanog.org Sent: Thursday, July 9, 2015 6:17:17 AM Subject: Re: Dual stack IPv6 for IPv4 depletion Ricky Beam jfb...@gmail.com wrote: Talking about IPv6, we aren't carving a limit in granite. 99.9% of home networks currently have no need for multiple networks, and thus, don't ask for anything more; they get a single /64 prefix. Personal-area networks already exist. Phone/watch/laptop etc. Virtual machines are common, e.g. for running multiple different operating systems on your computer. And automotive networks need connectivity. There are often separate VLANs for VOIP and IP TV and smart meters. Separate wifi networks tuned for low-latency synchronized audio. So it's very common to have multiple networks in a home with multiple layers of routing. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Shannon, Rockall: South or southeast 5 or 6, increasing 6 or 7 later. Moderate, occasionally rough. Rain, fog patches. Moderate, occasionally very poor.
Re: Hotels/Airports with IPv6
Absolutely agree. It's not their job to even know to ask for a specific protocol version in the first place. Their experience should be as seamless and consistent as possible at all times. What we should be be concerned about is that the hospitality industry is so far behind the game on technology. Hotels and restaurants will be some of the last to drop IPv4 unless they don't realize they're doing it in the first place. On Thu, Jul 9, 2015 at 1:45 PM, Jacques Latour jacques.lat...@cira.ca wrote: Just turn IPv6 on when you can. We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either. I would argue customers never asked an IPv4 connection either, they asked for an Internet connection. The Internet is IPv4 and IPv6. I working on a large airport WiFi deployment right now. IPv6 is allowed for in the future but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. End users will never demand IPv6, turn it on :-) -- :o@
RE: Hotels/Airports with IPv6
Just turn IPv6 on when you can. We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either. I would argue customers never asked an IPv4 connection either, they asked for an Internet connection. The Internet is IPv4 and IPv6. I working on a large airport WiFi deployment right now. IPv6 is allowed for in the future but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. End users will never demand IPv6, turn it on :-)
Re: Hotels/Airports with IPv6
On Thu, 9 Jul 2015, Ca By wrote: On Thursday, July 9, 2015, Mel Beckman m...@beckman.org wrote: I working on a large airport WiFi deployment right now. IPv6 is allowed for in the future but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. 1. Users will never demand ipv6. They demand google and facebook. So that road goes nowhere I wonder if the front desk ever understood and forwarded my complaints about filtered ports (like 22) and other issues with NAT and firewalls. How do we know what customers demand if they don't bother reporting or are unable to produce a sophisticated report going beyond it does not work for me? What if Microsoft releases a portable IPv6-only game console one day? ~Marcin
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 4:07 PM, Owen DeLong o...@delong.com wrote: On Jul 9, 2015, at 15:45 , Ricky Beam jfb...@gmail.com wrote: On Thu, 09 Jul 2015 18:05:00 -0400, Owen DeLong o...@delong.com wrote: Look again… IPv6 is already more than 20% of Google traffic in the US. 20% of *1* site's traffic does not equal 20% DEPLOYMENT. (read: 20% of internet DEVICES (CPE) connected by IPv6) You are correct… In order for 20% of Google’s traffic to come from IPv6 connected devices, there would generally need to be more than 20% of all devices connected over IPv6. Owen That doesn't follow at all. One guy who has v6 and really loves youtube can account for most of it. Matthew Kaufman (Sent from my iPhone)
Re: Dual stack IPv6 for IPv4 depletion
On Thu, 2015-07-09 at 19:06 -0500, Mike Hammett wrote: Solutions looking for problems. I get a few subnets (though don't foresee it being likely). Someone here was mentioning dozens or hundreds of subnets for a residential customer. Um, no. Actually I was mentioning thousands. What you personally don't foresee is pretty much irrelevant to what will actually happen - unless you are in a position to make things impossible. If we build a world where only 256 in-home subnets are possible, then future homes will have no more than 256 in-home subnets, no-one will be building systems that need more than 256 subnets, and no doubt you will be saying see, I told you so. Like pretty much the entire current generation of net techs, your imagination is limited by your past. But there are kids in school right now who do not suffer from the same limitations - and they will build wonders. If we let them. Regards, K. PS: People keep dissing home users saying how they are incapable of understanding stuff and installing all these complex networks. Twenty years ago getting online at home took lots of know-how; getting more than one device online in the home took even more. Now you can just buy a $50 bit of kit, plug it in and your desktops, laptops, smartphones, tablets, televisions, digital radios and wireless sound systems just work. With main and guest networks, multiple wifi protocols, and in many cases basic IPv6 as well. There is no reason to think that the complexity of future networks will not be equally well packaged for the home. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 9:02 PM, Matthew Kaufman matt...@matthew.atmailto:matt...@matthew.at wrote: On Jul 9, 2015, at 4:07 PM, Owen DeLong o...@delong.commailto:o...@delong.com wrote: ... You are correct… In order for 20% of Google’s traffic to come from IPv6 connected devices, there would generally need to be more than 20% of all devices connected over IPv6. That doesn't follow at all. One guy who has v6 and really loves youtube can account for most of it. Matthew - That would be the case if the measurements of “IPv6 users” were based on traffic or packet counts, but Google’s measurements are based on specific pairs of HTTP connection attempts (one IPv4, and one IPv6) and the ratio of those which are IPv6 capable. The measurement methodology is documented in the Google research paper - http://research.google.com/pubs/pub36240.html I’ll also observe that APNIC has been conducting its own research via a different approach but achieved a rather similar measurement results for of IPv6 enabled users in the US - http://labs.apnic.net/dists/v6dcc.html. You can find more details on the approach used here http://www.circleid.com/posts/20120625_measuring_ipv6_country_by_country Both techniques indicate more than 20% of the US Internet users are connecting via IPv6. FYI, /John John Curran President and CEO ARIN
Re: Also Facebook (was: Re: Dual stack IPv6 for IPv4 depletion)
On Thu, 09 Jul 2015 21:48:06 -0400, John Curran jcur...@arin.net wrote: Both techniques indicate more than 20% of the US Internet users are connecting via IPv6. Interesting method that's full of holes (and they know it), but it's data nonetheless. Globally, it's still ~4.5%. Within my own pool of providers, I'm ZERO for 5. (I've not pinged TWC-BC lately, 'tho. And no one has gotten back to me that Earthlink has provided TWC with any prefixes, so us Earthlink cable internet customers are still dark.) (They’ve also observing a significant performance improvement with IPv6 connected users over IPv4 connected... IPv4 tends to be NAT'd and aggressively proxied. I also wouldn't rule out v6 taking a different path, but that wouldn't explain the magnitude of difference those slides would suggest. (not really readable via youtube)
RE: Possible Sudden Uptick in ASA DOS?
-Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jared Mauch Sent: Thursday, July 09, 2015 9:08 AM To: Colin Johnston Cc: nanog@nanog.org Subject: Re: Possible Sudden Uptick in ASA DOS? My guess is a researcher. I wouldn't classify someone sending known malicious traffic towards someone else's network device attempting to crash it as a 'researcher'. Criminal is a better term. Chuck
Also Facebook (was: Re: Dual stack IPv6 for IPv4 depletion)
On Jul 9, 2015, at 9:31 PM, John Curran jcur...@arin.netmailto:jcur...@arin.net wrote: ... Both techniques indicate more than 20% of the US Internet users are connecting via IPv6. You might also want to review Paul Saab’s presentation regarding what Facebook actually sees for IPv6 traffic and performance (given in March 2015 at the World IPv6 Congress) - https://www.youtube.com/watch?v=An7s25FSK0U They are seeing 9% of their traffic via IPv6 and doubling each year. This is likely because US mobile providers strong support for IPv6, with more than 80% of mobile devices on a some mobile providers supporting IPv6… (They’ve also observing a significant performance improvement with IPv6 connected users over IPv4 connected, but they admit to still looking into the reason behind the performance lift) FYI, /John John Curran President and CEO ARIN
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 16:28 , Ricky Beam jfb...@gmail.com wrote: On Thu, 09 Jul 2015 19:08:56 -0400, Owen DeLong o...@delong.com wrote: the reality I’m trying to point out is that application developers make assumptions based on the commonly deployed environment that they expect in the world. Partially. It's also a matter of the software guys not having any clue what-so-ever w.r.t. networking. In this case, APPLE designed Bonjour to not cross network boundaries. Idiotic, but it allows them to sell servers that do the cross-network routing. Actually it’s not a design problem in IPv6. A simple tweak to the software to send to ff05::group instead of ff02::group or better yet, allow the user to edit the scope in System Preferences is all that is really needed. However, in IPv4, mDNS/Bonjour (and mDNS is uPNP’s fault, not Apple’s to the best of my knowledge) use broadcast packets and that’s a design flaw. However, hard to argue with the choice since multicast, especially cross-router multicast is pretty much busted in any sort of home gateway in IPv4 anyway. If we create a limited environment, then that is what they will code to. They will code to what they understand, what works for them, and what their users report works for me. We will always end up with substandard quality because they have little (or no) understanding of how networking does it's thing. (And then marketing, and legal will step in and pooh on it even more.) OK… Clearly you are determined to let cynicism and avoidance drive your ideas here. I can’t help that. Hopefully enough others will try to make the internet more useful as we move forward and hand out larger end-site prefixes. Owen
Re: Dual stack IPv6 for IPv4 depletion
In message d51a9dbc-03a7-4ce9-88ec-17d7d7570...@matthew.at, Matthew Kaufman w rites: On Jul 9, 2015, at 4:07 PM, Owen DeLong o...@delong.com wrote: On Jul 9, 2015, at 15:45 , Ricky Beam jfb...@gmail.com wrote: On Thu, 09 Jul 2015 18:05:00 -0400, Owen DeLong o...@delong.com wrote: Look again⦠IPv6 is already more than 20% of Google traffic in the US. 20% of *1* site's traffic does not equal 20% DEPLOYMENT. (read: 20% of internet DEVICES (CPE) connected by IPv6) You are correct⦠In order for 20% of Googleâs traffic to come from IPv6 connected devices, there would generally need to be more than 2 0% of all devices connected over IPv6. Owen That doesn't follow at all. One guy who has v6 and really loves youtube can account for most of it. Matthew Kaufman (Sent from my iPhone) Doesn't pass the laugh test. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 11:08 PM, Owen DeLong o...@delong.com wrote: On Jul 9, 2015, at 15:55 , Ricky Beam jfb...@gmail.com wrote: On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve snasl...@medline.com wrote: That would be Tivo's fault wouldn't it. Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work over the internet. (It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.) Correct… It _IS_ TiVO’s fault. However, the reality I’m trying to point out is that application developers make assumptions based on the commonly deployed environment that they expect in the world. If we create a limited environment, then that is what they will code to. If we deliver /48s, then they will come up with innovative ways to make use of those deployments. If we deliver /56s, then innovation will be constrained to what can be delivered to /56s, even for sites that have /48s. Owen I would love to see things go Owen's way.. /48s everywhere, everyone agrees it's a good idea, and we can just assume that it will work. We can move on, this is one less thing to stress about. On the other hand, I do wonder how this will work, even if most people are getting /48s. Perhaps in a few years we'll be past all this, and there will be a well accepted standard way. Maybe it will be RIPng. Maybe some thing that we haven't seen yet. Or maybe there will be 800 ways of doing it, because the protocol spec allows that, and so we should complicate our lives further by requiring everyone to support every possibility of combinations. This is the worst possible outcome because it means unnecessary complexity, more work for everyone involved, and less reliability. If you're writing an application, do you bother supporting /48, /56, RA, DHCP, etc, while also supporting an https polling mechanism for the times when none of that stuff works? We can pretend that it doesn't matter and that software should 'just work' with any network, but that's simply not possible for many applications. I think as an application developer, you're much better off aiming for the least common denominator, accepting the limitations of that, and just moving on. This means polling, reflectors, NAT, proxyarp, etc. Things that you can control, to make your app work. Supporting a bunch of different ways is a waste of everyone's time and just makes your application less reliable and harder to test. Unless your specific application benefits greatly from a more capable network, it's probably not worth even thinking about, as long as you know that you will still have to support the 'bad' ones. A music streaming application can use a hardcoded well known server name to access a centralized service. It can even communicate with other users by using that central server as a database or reflector. It would be 'nice' if it could ask the network for a prefix and use a different address for each peer it talks to, but what's the point in developing that, if you still have to support the other case? A wifi hotspot device would benefit from prefix delegation, but it could of course use NAT or proxying without the cooperation of the network. This is one application where it might be worth supporting all the different combinations, but it means that all those different methods need to be tested, and they can break in different ways, and there's no way to be sure it's right. Choice is good, you can run your own network any way you want, etc, but it's not good when people are making choices just for the sake of being different and incompatible. After all, the point of the internet is to communicate with everyone else, which means we all need to agree on how we will communicate. How can we expect everyone to embrace IPv6 if we can't even provide a straightforward procedure to get connected to it? -Laszlo
Re: Possible Sudden Uptick in ASA DOS?
On Jul 9, 2015, at 9:43 PM, Chuck Church chuckchu...@gmail.com wrote: -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jared Mauch Sent: Thursday, July 09, 2015 9:08 AM To: Colin Johnston Cc: nanog@nanog.org Subject: Re: Possible Sudden Uptick in ASA DOS? My guess is a researcher. I wouldn't classify someone sending known malicious traffic towards someone else's network device attempting to crash it as a 'researcher'. Criminal is a better term. There are other terms for people who don’t maintain their equipment, it’s usually described as negligent. If my hardware were rebooting, I would be red-faced first about not having done something and not blaming someone outside. I don’t know if it was a researcher or something buggy sending packets or anything else. (I have no unique direct insight). What I do know is the ASAs under my control and purview had no issues. Take the free upgrade and move on folks. - Jared
Re: Possible Sudden Uptick in ASA DOS?
In message 011d01d0bab1$e7890a00$b69b1e00$@gmail.com, Chuck Church writes: -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jared Mauch Sent: Thursday, July 09, 2015 9:08 AM To: Colin Johnston Cc: nanog@nanog.org Subject: Re: Possible Sudden Uptick in ASA DOS? My guess is a researcher. I wouldn't classify someone sending known malicious traffic towards someone else's network device attempting to crash it as a 'researcher'. Criminal is a better term. Chuck At what point does a well formed but bug triggering packet go from malicious to expected? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 18:19 , Laszlo Hanyecz las...@heliacal.net wrote: On Jul 9, 2015, at 11:08 PM, Owen DeLong o...@delong.com wrote: On Jul 9, 2015, at 15:55 , Ricky Beam jfb...@gmail.com wrote: On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve snasl...@medline.com wrote: That would be Tivo's fault wouldn't it. Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work over the internet. (It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.) Correct… It _IS_ TiVO’s fault. However, the reality I’m trying to point out is that application developers make assumptions based on the commonly deployed environment that they expect in the world. If we create a limited environment, then that is what they will code to. If we deliver /48s, then they will come up with innovative ways to make use of those deployments. If we deliver /56s, then innovation will be constrained to what can be delivered to /56s, even for sites that have /48s. Owen I would love to see things go Owen's way.. /48s everywhere, everyone agrees it's a good idea, and we can just assume that it will work. We can move on, this is one less thing to stress about. On the other hand, I do wonder how this will work, even if most people are getting /48s. Perhaps in a few years we'll be past all this, and there will be a well accepted standard way. Maybe it will be RIPng. Maybe some thing that we haven't seen yet. Or maybe there will be 800 ways of doing it, because the protocol spec allows that, and so we should complicate our lives further by requiring everyone to support every possibility of combinations. This is the worst possible outcome because it means unnecessary complexity, more work for everyone involved, and less reliability. If you're writing an application, do you bother supporting /48, /56, RA, DHCP, etc, while also supporting an https polling mechanism for the times when none of that stuff works? We can pretend that it doesn't matter and that software should 'just work' with any network, but that's simply not possible for many applications. I think as an application developer, you're much better off aiming for the least common denominator, accepting the limitations of that, and just moving on. This means polling, reflectors, NAT, proxyarp, etc. Things that you can control, to make your app work. Supporting a bunch of different ways is a waste of everyone's time and just makes your application less reliable and harder to test. Unless your specific application benefits greatly from a more capable network, it's probably not worth even thinking about, as long as you know that you will still have to support the 'bad' ones. Which is why I’m arguing that we should try not to implement the bad ones in IPv6. A music streaming application can use a hardcoded well known server name to access a centralized service. It can even communicate with other users by using that central server as a database or reflector. It would be 'nice' if it could ask the network for a prefix and use a different address for each peer it talks to, but what's the point in developing that, if you still have to support the other case? Will you always have to support that case? Do you really want to say that the current state of IPv4 should drive all development decisions for all future products? A wifi hotspot device would benefit from prefix delegation, but it could of course use NAT or proxying without the cooperation of the network. This is one application where it might be worth supporting all the different combinations, but it means that all those different methods need to be tested, and they can break in different ways, and there's no way to be sure it's right. Choice is good, you can run your own network any way you want, etc, but it's not good when people are making choices just for the sake of being different and incompatible. After all, the point of the internet is to communicate with everyone else, which means we all need to agree on how we will communicate. How can we expect everyone to embrace IPv6 if we can't even provide a straightforward procedure to get connected to it? This is all true. Seems to me DHCP-PD receiving a /48 from upstream is a pretty straightforward approach. Dynamic topologies inside the home still require some development work, but any router ought to be able to accept a /48 and assign /64s to the local-facing port(s) fairly easily. Owen
Re: Dual stack IPv6 for IPv4 depletion
hum.. let me postulate. my lan, my kids, my guests, the drive-bys, … the LG stuff, the Apple stuff, the whitebox stuff, appliances … smart meters, switches, thermostats, toilets, water flow controls, … Microsoft can talk to the x-box, but i have no desire for them t see/know anything else on the entertainment lan at the house…. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 9July2015Thursday, at 13:00, Naslund, Steve snasl...@medline.com wrote: Yes, and that is a problem. Usually because it is not granular enough and there are a lot of ways to get onto another VLAN (physical access and packet trickery). It is a pretty weak form of security policy. Now, if we assume that VLAN based security is weak and that most homes do not generate enough broadcast traffic to be an issue, what exactly is the reason that a residential customer needs a lot of VLANs? Answer, they probably don't. A lot of residential users have a CPE device that does wireless, routing, and DHCP assignments all in one. No need to create a guest VLAN on that type of device. You simply assign an ACL that keeps the guest from reaching any internal IP. Why would your refrigerator (or car, toaster, TV, whatever) need to be on a separate subnet when the whole point is to create a network where all of your stuff communicates? Us engineers need to make sure we don't generalize that a lot of residential users do to their networks what we do to ours. We MIGHT have a reason for several subnets to simulate different stuff. I am still waiting for a valid example of a residential situation where VLANs are a useful addition. Oh, and don't even try the QoS argument. I will tell you that LLDP identification of the device and applying QoS policy based on the identification is much more effective and transparent to the end user. Steven Naslund Chicago IL -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tyler Applebaum Sent: Thursday, July 9, 2015 3:38 PM To: Naslund, Steve Cc: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation.
Re: Dual stack IPv6 for IPv4 depletion
On Jul 8, 2015, at 19:22 , Israel G. Lugo israel.l...@lugosys.com wrote: On 07/09/2015 02:31 AM, Owen DeLong wrote: Here’s the problem… You started at the wrong end and worked in the wrong direction in your planning. [...get larger allocation...] We are now left with only 1,041,888 /20s remaining. You still haven’t put a dent in it. I am aware of the math, and how it can fit. I will concede that a /20 is sufficient. Note, however, the difference in orders of magnitude for typical allocations. I realize in ARIN side you've got e.g. Comcast with multiple /20s, but in RIPE that is not so common. My home ISP has 3x /32s. As I said, default ISP/LIR allocation here is from /32 to /29. Yes, shorter prefixes can be justified and obtained, but it's not the norm. Poor allocation practice and/or policy in RIPE is something that should be solved through education and policy change where needed. The fact that such is apparently commonplace in RIPE is probably an artifact of the RIPE region having deployed IPv6 a bit ahead of much of the world. In part, it’s probably cultural artifact. In any case, since there’s still a lot of networks that haven’t really deployed IPv6, let’s stop teaching bad ways to do things and focus on doing better going forward. It’s not… It’s a great example of how not to plan your address space in IPv6. However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don’t make a dent in the IPv6 free pool. Everyone wins. You basically just said get a larger allocation... Which was my point all along. /32 is not enough, and even /24 could be made much roomier. Sure… And if you need larger allocations, they should be very easy to get. I haven’t yet built anything that needed more than a /24. However, I have now obtained 3 /24s from ARIN for 3 different networks and not had significant difficulty with any of the 3. Speaking of IPv6's full potential: we're considering 32 subscriptions per client. I've read people thinking of things like IPv6-aware soda cans. Refrigerators. Wearables. Cars and their internal components... You could have the on-board computer talking to the suspension via IPv6, and reporting back to the manufacturer or whatnot. Yes, but each of those wouldn’t require its own subscription/network. Most of those things would aggregate into one or more of your wireless networks. By subscriptions, I was literally talking about different ISP connections. 32 is massive overkill… Very few people today have more than 5. Each cellular device is essentially one since there’s no real local aggregation available. However, everything on the wired and wireless networks in your home would probably share a single attachment. Your car might be its own attachment or might use one or more of your cellular attachments. Your soda cans, refrigerators, wearables, etc. would most likely use one of your fixed or mobile attachments. Personally, I'm not particularly fond of the whole refrigerators ordering milk bottles craze, but hey, it may very well become a thing. And other stuff we haven't thought of yet. What I think will become more common than refrigerators ordering things is refrigerators providing inventory management capabilities (including load cells in the shelves that work with positional RFID sensors so that you not only know that you have 3 bottles of milk in the fridge, but can tell where in the fridge and how much in each bottle). Zap a QR-Code for a recipe with your cell phone, and the fridge checks in with the cabinets and sends back a list of what you need to buy vs. what you already have in inventory. My point is: we're changing to a brand new protocol, and only now beginning to scratch its full potential. Yes, everything seems very big right now. Yes, 128 bits can be enough. Even 64 bits could be more than enough. But why limit ourselves? Someone decided (corretly) that 64 would be too limiting. The additional consumptions you’re talking about all fit within the model I described. You’re either expanding the number of things in the house that are hosts or you’re expanding the number of hosts attached to one of the mobile attach points. I used 32 attach points per person on the planet with the full population of planet earth to be deliberately conservative in the potential number of ISP connections required. Please don't fall into the usual you've got more addresses than atoms... I've heard that, and am not disputing it. I'm not just talking about individual addresses (or /48's). I don’t think I did. Nor did I talk about individual /48s. What I am proposing here, as food for thought, is: what if we had e.g. 192 bits, or 256? For one, we could have much sparser allocations. Heck, we could even go as far as having a bit
Re: Dual stack IPv6 for IPv4 depletion
Ricky Beam jfb...@gmail.com wrote: Talking about IPv6, we aren't carving a limit in granite. 99.9% of home networks currently have no need for multiple networks, and thus, don't ask for anything more; they get a single /64 prefix. Personal-area networks already exist. Phone/watch/laptop etc. Virtual machines are common, e.g. for running multiple different operating systems on your computer. And automotive networks need connectivity. There are often separate VLANs for VOIP and IP TV and smart meters. Separate wifi networks tuned for low-latency synchronized audio. So it's very common to have multiple networks in a home with multiple layers of routing. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Shannon, Rockall: South or southeast 5 or 6, increasing 6 or 7 later. Moderate, occasionally rough. Rain, fog patches. Moderate, occasionally very poor.
Re: Dual stack IPv6 for IPv4 depletion
On 8/Jul/15 21:32, Owen DeLong wrote: I think the “THING” that people are starting to worry about is how to deploy a network when you can’t get IPv4 space for it at a reasonable price. I suppose the issue will become more real when you can't get any IPv4 space period. Mark.
Re: Possible Sudden Uptick in ASA DOS?
Really just people not patching their software after warnings more than six months ago: July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. Jared Mauch On Jul 8, 2015, at 1:15 PM, Michel Luczak fr...@shrd.fr wrote: On 08 Jul 2015, at 18:58, Mark Mayfield mark.mayfi...@cityofroseville.com wrote: Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. Not sure it’s related but I’ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. Regards, Michel
Re: Dual stack IPv6 for IPv4 depletion
Hi, With RIPE you can get a /29 with no justification, so if you have any less it is because you did not bother logging in to ripe.net and hit the get more button. ARIN gives you the option to make a network scheme based on nibbles but RIPE does not, so do not go there. Why try to allocate by the bit at all? We all use internal routing protocols instead of static routing. The only concern is to avoid an excess amount of internal routes in your IGP. You do that by using an allocation size per site, so your local routers can do route aggregation before redistributing the routes. We have an allocation size of /42 per site. A site can have and usually have multiple /42 allocated. This size was chosen because we allocate a /26 of IPv4 per site (=6 bits per allocation or blocks of 64). We are a residual ISP and it is expected that each customer needs one /32 IPv4 and one /48 IPv6 prefix. Our allocation of /32 IPv4 and /48 IPv6 is approximately the same utilization. In fact we made an algorithm that can convert your IPv4 /32 to your IPv6 /48, so we avoid tracking two allocations per user. Our smallest access routers can handle about 30k routes. But long before we hit that, I expect we would add another layer of aggregation. The case of using a bit based allocation scheme is so you can avoid that database (or spreadsheet) keeping track of your allocations. But I found that you need that either way or you will go crazy. The ability to look at an allocation and say hmm digit 10 is between 8 and f, so that must be somewhere in [insert big city here]... well it does just not seem that useful. Check our reverse DNS if you want to know. Regards, Baldur
Re: Dual stack IPv6 for IPv4 depletion
Residential users just buy another router for wifi coverage at the local wall mart. They have no clue about anything internet. That is why isp CPE devices should always perform dhcp-pd on their own to provide a prefix to the downstream devices so those have globally routed ipv6 too. For that to work you need concepts like route aggregation in the form of a /48 for the CPE so it can hand out a /56 to the customer bought CPE. Seth Oorspronkelijk bericht Van: Mike Hammett na...@ics-il.net Datum: 09-07-2015 04:03 (GMT+01:00) Aan: nanog@nanog.org Onderwerp: Re: Dual stack IPv6 for IPv4 depletion I wasn't aware that residential users had (intentionally) multiple layers of routing within the home. I'm also not sure what address length has to do with routability, other than networks filtering prefix lengths. If that's an issue, that customer is covered by the ISP's larger allocation, or they get their own PI space if they're BGPing. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com - Original Message - From: Karl Auer ka...@biplane.com.au To: nanog@nanog.org Sent: Wednesday, July 8, 2015 8:36:41 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, 2015-07-08 at 19:57 -0500, Mike Hammett wrote: Isn't /56 the standard end-user allocation? No - it's just a common one. And a bad one. /48s for all opens up a whole different world of end-user reachability, routability and flexibility that a mere /56 does not. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
Re: Dual stack IPv6 for IPv4 depletion
On Jul 8, 2015, at 21:55 , Ricky Beam jfb...@gmail.com wrote: On Wed, 08 Jul 2015 22:49:17 -0400, Karl Auer ka...@biplane.com.au wrote: You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE. What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples. Talking about IPv6, we aren't carving a limit in granite. 99.9% of home networks currently have no need for multiple networks, and thus, don't ask for anything more; they get a single /64 prefix. If tomorrow they need more, set the hint to 60 and they get a /60. Need more, ask for 56... CURRENTLY, providers have their DHCP server(s) set to a limit of 56. But that's simply a number in a config file; it can be changed as easily as it was set the first time. (source pool size and other infrastructure aside.) It's just like the escalation of speeds: as the need for it rises, it becomes available. (in general, at least) But we are carving a limit in stone without realizing it. Changing the network to give out larger prefixes is easy. However, developers consistently develop to the lowest common denominator. Don’t believe me? Try to use any of a variety of mobile apps to control a non-NAT device in your home from your cell phone when you’re not in the same broadcast domain as the device you want to control. The developers have assumed that: 1. Every household is behind NAT 2. Every household is a single broadcast domain 3. There’s never any need to talk to a device that isn’t within the same broadcast domain as the handset. 4. Nobody would ever want to use their cell phone to control their $PRODUCT without putting it on the wifi network and the $PRODUCT wired network interface will always be bridged to the wifi on the same subnet, right? Given how baked in these bad assumptions have become, I shudder at the thought of how long after ISPs start issuing /48s it will take before we start to see useful products designed with that expectation in mind. Owen
Re: How to build an IPv6-only internal network?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8/Jul/15 22:23, Fred Baker (fred) wrote: (2) they use NAT64 (RFC 6146/6147) translation The only issue with NAT64 is that you still need some IPv4 space. If you can't get any anymore, despite all the millions of $$ in your bank, then we'll see massively overlayed NAT, and perhaps service providers selling Quadruple Overlay NAT as a Service :-\. Mark. -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJVnltZAAoJEGcZuYTeKm+GtyIP/3Eo9pPRW2dRYt67s2xx2fMI 2Oia8efH3ZEBrFOgSHBsBmmxeewP+CGcmosQ8uSFSXCKLLKDCl996wVPu9dmKTGO WORwzoy8EmUeuAKLsxd/CGHes1ExUijfFBf27hz0CA+qmRcINdh45RhQKLUb2EWs iNj6yF8OSRe9tZAk+caNbLJA5EDpq7XAYGIBv3z4wtW/Dr+DGbUJMsrTjzVEEFCS N81cXQep4risY58JLBmBlY7RuiK9xRqTtmwlK0KQeEPF05NK8xo5Nxi02fjF7TSF ZsMvHaLKFWtjwC5L+MJwVswgOEKaleFyi1QsICdEQnXdW6MObA/COdnI3VIOgJ1c bhjBmTN8PuXc3zrV+iIBctg241it7NPbf+dlRzQ5xm+pn6M3AymoLk+i6xpj/NSx D3nIpGmuZSiXs+PkpYXYU4C9SKib6sKOLX9/Nu5fo4oY4t/mJtpon439NAFpxPAI I5fEYFpXdIRop6KelT3b91auqwjVNUbqZxq9HbF7Sq/PJ0xkT0ivsKem/6xBdsNK dQeo8sqkmo97pQ+6qLjaGEw3C0XT1y8skXq0Y1hZZvGHvouVWgqLg+xwthu2qKfi JOLk7GWIkYj9gwMYUmKXFmOayjBCh/fWPXLxiVpSDss23asIARFRfSvG4XhjVUfI JplyKrXhqK4MTxK3wLz4 =1mCX -END PGP SIGNATURE-
Re: Possible Sudden Uptick in ASA DOS?
Hi Jared, thanks for update do you know provider/source ip of the source of the attack ? Colin On 9 Jul 2015, at 12:27, Jared Mauch ja...@puck.nether.net wrote: Really just people not patching their software after warnings more than six months ago: July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. Jared Mauch On Jul 8, 2015, at 1:15 PM, Michel Luczak fr...@shrd.fr wrote: On 08 Jul 2015, at 18:58, Mark Mayfield mark.mayfi...@cityofroseville.com wrote: Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. Not sure it’s related but I’ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. Regards, Michel
Re: Dual stack IPv6 for IPv4 depletion
Using one-byte buffers, one hopes. :) -mel via cell On Jul 8, 2015, at 8:49 PM, Dave Taht dave.t...@gmail.com wrote: On Wed, Jul 8, 2015 at 7:49 PM, Karl Auer ka...@biplane.com.au wrote: On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote: I wasn't aware that residential users had (intentionally) multiple layers of routing within the home. No, what they often have is multiple layers of nat. I was at a hotel once that had plugged in 12 APs, serially, wan, to lan, to wan, to lan, to wan ports... because the Internet is a series of tubes, right? You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE. What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples. Multiple layers of routing might not be what is now in the home, but it doesn't take that much imagination to envision a future where there are hundreds, or even thousands of separate networks in the average home, some permanent, some ephemeral, and quite possibly all requiring end-to-end connectivity into the wider Internet. Taking into account just a few current technologies (virtual machines, car networks, personal networks, guest networks, entertainment systems) and fast-forwarding just a few years it's easy to imagine tens of subnets being needed - so it's not much of a leap to hundreds. And if we can already dimly see a future where hundreds might be needed, history tells us that there will probably be applications that need thousands. Unless of course we decide now that we don't WANT that. Then we should make it hard for it to happen by applying entirely arbitrary brakes like /48 sounds too big to me, let's make it 1/256th of that. In my case I have completely abandoned much of the debris of ipv4 and ipv6 - using self assigned /128s and a mesh routing protocol everywhere, giving up on multicast as we knew it, and all I need is one /64 to route my (almost entirely wireless) world. Somehow I doubt this will become a common option for others, but it sure is easier than navigating the slew of standards, configuring centralized services, and casting and configuring limited and highly dynamic ipv6 subnets around. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast
Re: Dual stack IPv6 for IPv4 depletion
On 9 July 2015 at 13:25, Mark Tinka mark.ti...@seacom.mu wrote: I suppose the issue will become more real when you can't get any IPv4 space period. Mark. That will never happen. If you offer me $1000 per IPv4, then I will happily terminate some user contracts and sell their IP space to you... In fact it will never become even that expensive. With a marked price of $10 I am buying IP space for customers as needed and I will include free space in the contracts. If the price went to $100 I would tell all users that they need to pay monthly rent for their IP or alternative, the user would have to accept carrier NAT in some form. And then I would proceed to buy a new house for the money I make by selling address space. There is a ton of address space that is inefficient used. We will be able to buy excess from companies that create space by optimizing their existing space. There is a reason we have not seen any rise in the price even after multiple years with depletion in large parts of the world. Regards, Baldur
Re: Dual stack IPv6 for IPv4 depletion
On 9/Jul/15 14:53, Baldur Norddahl wrote: That will never happen. If you offer me $1000 per IPv4, then I will happily terminate some user contracts and sell their IP space to you... In fact it will never become even that expensive. With a marked price of $10 I am buying IP space for customers as needed and I will include free space in the contracts. If the price went to $100 I would tell all users that they need to pay monthly rent for their IP or alternative, the user would have to accept carrier NAT in some form. And then I would proceed to buy a new house for the money I make by selling address space. There is a ton of address space that is inefficient used. We will be able to buy excess from companies that create space by optimizing their existing space. There is a reason we have not seen any rise in the price even after multiple years with depletion in large parts of the world. In this particular case, I'm not concerned about the next ten years. Predicting what happens between now and then could have a fair degree of accuracy. I'm more concerned about what happens beyond that. I'm not sure I can accurately (even with large error margins) predict what happens then. All that said, I'm not trying to paint myself into that kind of corner. It is 2015, after all... Just don't tell my competitors... Mark.
Re: Dual stack IPv6 for IPv4 depletion
I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com - Original Message - From: Tony Finch d...@dotat.at To: Ricky Beam jfb...@gmail.com Cc: nanog@nanog.org Sent: Thursday, July 9, 2015 6:17:17 AM Subject: Re: Dual stack IPv6 for IPv4 depletion Ricky Beam jfb...@gmail.com wrote: Talking about IPv6, we aren't carving a limit in granite. 99.9% of home networks currently have no need for multiple networks, and thus, don't ask for anything more; they get a single /64 prefix. Personal-area networks already exist. Phone/watch/laptop etc. Virtual machines are common, e.g. for running multiple different operating systems on your computer. And automotive networks need connectivity. There are often separate VLANs for VOIP and IP TV and smart meters. Separate wifi networks tuned for low-latency synchronized audio. So it's very common to have multiple networks in a home with multiple layers of routing. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Shannon, Rockall: South or southeast 5 or 6, increasing 6 or 7 later. Moderate, occasionally rough. Rain, fog patches. Moderate, occasionally very poor.
Re: Dual stack IPv6 for IPv4 depletion
Sounds like someone's getting caught up in the hype of a few buzzwords. I can't imagine where more than a couple bits of separately isolated networks in a home would be required. Most of those things you mentioned have no need to be isolated and are just being used to support a decision that was already made than evidence that lead to a decision. I'm not advocating anyone do anything other than what best practices dictate, just that whomever came up with best practices got a little caught up in the moment. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com - Original Message - From: Karl Auer ka...@biplane.com.au To: nanog@nanog.org Sent: Wednesday, July 8, 2015 9:49:17 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote: I wasn't aware that residential users had (intentionally) multiple layers of routing within the home. You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE. What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples. Multiple layers of routing might not be what is now in the home, but it doesn't take that much imagination to envision a future where there are hundreds, or even thousands of separate networks in the average home, some permanent, some ephemeral, and quite possibly all requiring end-to-end connectivity into the wider Internet. Taking into account just a few current technologies (virtual machines, car networks, personal networks, guest networks, entertainment systems) and fast-forwarding just a few years it's easy to imagine tens of subnets being needed - so it's not much of a leap to hundreds. And if we can already dimly see a future where hundreds might be needed, history tells us that there will probably be applications that need thousands. Unless of course we decide now that we don't WANT that. Then we should make it hard for it to happen by applying entirely arbitrary brakes like /48 sounds too big to me, let's make it 1/256th of that. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
Re: Dual stack IPv6 for IPv4 depletion
Don't confuse someone's poor design with design goals. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com - Original Message - From: Dave Taht dave.t...@gmail.com To: Karl Auer ka...@biplane.com.au Cc: NANOG nanog@nanog.org Sent: Wednesday, July 8, 2015 10:48:26 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, Jul 8, 2015 at 7:49 PM, Karl Auer ka...@biplane.com.au wrote: On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote: I wasn't aware that residential users had (intentionally) multiple layers of routing within the home. No, what they often have is multiple layers of nat. I was at a hotel once that had plugged in 12 APs, serially, wan, to lan, to wan, to lan, to wan ports... because the Internet is a series of tubes, right? You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE. What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples. Multiple layers of routing might not be what is now in the home, but it doesn't take that much imagination to envision a future where there are hundreds, or even thousands of separate networks in the average home, some permanent, some ephemeral, and quite possibly all requiring end-to-end connectivity into the wider Internet. Taking into account just a few current technologies (virtual machines, car networks, personal networks, guest networks, entertainment systems) and fast-forwarding just a few years it's easy to imagine tens of subnets being needed - so it's not much of a leap to hundreds. And if we can already dimly see a future where hundreds might be needed, history tells us that there will probably be applications that need thousands. Unless of course we decide now that we don't WANT that. Then we should make it hard for it to happen by applying entirely arbitrary brakes like /48 sounds too big to me, let's make it 1/256th of that. In my case I have completely abandoned much of the debris of ipv4 and ipv6 - using self assigned /128s and a mesh routing protocol everywhere, giving up on multicast as we knew it, and all I need is one /64 to route my (almost entirely wireless) world. Somehow I doubt this will become a common option for others, but it sure is easier than navigating the slew of standards, configuring centralized services, and casting and configuring limited and highly dynamic ipv6 subnets around. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast
Telia Globalcrossing ASH peering issue
Hello, is someone from GBLX/Level 3/Telia around? It looks like there's a problem with one of your peerings/LAGs. The problem exists since 00:36 UTC working path: traceroute from 71.80.34.222 to 151.248.24.61 (151.248.24.61), 30 hops max, 40 byte packets 1 192.168.30.1 (192.168.30.1) 0.416 ms 0.917 ms 1.085 ms 2 192.168.1.2 (192.168.1.2) 0.620 ms 0.520 ms 0.468 ms 3 71-80-34-193.static.kgpt.tn.charter.com (71.80.34.193) 1.342 ms 1.538 ms 2.180 ms 4 71-80-34-152.static.kgpt.tn.charter.com (71.80.34.152) 1.835 ms 2.001 ms 2.061 ms 5 dtr02lncytn-tge-0-6-1-2.lncy.tn.charter.com (96.34.68.84) 1.774 ms 1.787 ms 1.860 ms 6 crr02kgpttn-tge-0-7-0-4.kgpt.tn.charter.com (96.34.69.27) 5.485 ms crr02kgpttn-tge-0-7-0-6.kgpt.tn.charter.com (96.34.71.100) 5.222 ms crr02kgpttn-tge-0- -0-5.kgpt.tn.charter.com (96.34.69.29) 5.257 ms 7 crr12spbgsc-bue-100.spbg.sc.charter.com (96.34.93.200) 11.958 ms 11.962 ms 11.988 ms 8 bbr01spbgsc-bue-4.spbg.sc.charter.com (96.34.2.50) 11.864 ms 12.505 ms 14.984 ms 9 cha-b1-link.telia.net (62.115.12.125) 11.356 ms 11.370 ms 11.391 ms 10 ash-bb3-link.telia.net (80.91.252.100) 19.172 ms 19.211 ms 19.210 ms 11 ash-b1-link.telia.net (62.115.113.207) 19.439 ms 21.042 ms 20.627 ms 12 globalcrossing-ic-150675-ash-bb1.c.telia.net (213.248.90.122) 19.593 ms 19.223 ms 19.291 ms 13 lag9.csr1.dca3.gblx.net (67.16.146.25) 28.340 ms 19.095 ms 19.117 ms 14 ae3.scr4.wdc2.gblx.net (67.16.166.229) 19.894 ms 19.936 ms 19.929 ms 15 xe10-1-0-10g.scr4.lon3.gblx.net (67.16.166.81) 94.114 ms 94.124 ms 94.428 ms 16 lag2.ar9.lon3.gblx.net (67.17.106.149) 95.592 ms 93.098 ms 93.086 ms 17 avanti-hylas-2-cyprus-ltd.ethernet23-1.ar9.lon3.gblx.net (159.63.52.6) 95.534 ms 92.612 ms 92.568 ms 18 88.210.183.37 (88.210.183.37) 168.082 ms 181.644 ms 181.669 ms 19 88.210.186.77 (88.210.186.77) 169.436 ms 168.871 ms 168.895 ms 20 static-151-248-24-61.nynex.de (151.248.24.61) 169.285 ms 169.200 ms 169.151 ms Broken path to a neighboring IP using another interconnect: traceroute from 71.80.34.222 to 151.248.24.62 (151.248.24.62), 30 hops max, 40 byte packets 1 192.168.30.1 (192.168.30.1) 0.409 ms 0.903 ms 1.073 ms 2 192.168.1.2 (192.168.1.2) 0.488 ms 0.581 ms 0.529 ms 3 71-80-34-193.static.kgpt.tn.charter.com (71.80.34.193) 1.512 ms 2.005 ms 2.305 ms 4 71-80-34-152.static.kgpt.tn.charter.com (71.80.34.152) 2.807 ms 2.753 ms 3.027 ms 5 dtr02lncytn-tge-0-6-1-2.lncy.tn.charter.com (96.34.68.84) 1.809 ms 1.814 ms 1.815 ms 6 crr02kgpttn-tge-0-7-0-4.kgpt.tn.charter.com (96.34.69.27) 5.551 ms crr02kgpttn-tge-0-7-0-6.kgpt.tn.charter.com (96.34.71.100) 4.802 ms 4.837 ms 7 crr12spbgsc-bue-100.spbg.sc.charter.com (96.34.93.200) 10.341 ms 10.681 ms 10.593 ms 8 bbr01spbgsc-bue-4.spbg.sc.charter.com (96.34.2.50) 16.036 ms 10.018 ms 10.780 ms 9 cha-b1-link.telia.net (213.248.86.173) 21.081 ms 21.124 ms 21.121 ms 10 ash-bb4-link.telia.net (213.155.132.178) 19.049 ms 19.051 ms 19.041 ms 11 ash-b1-link.telia.net (213.155.130.73) 19.414 ms 19.434 ms 19.545 ms 12 globalcrossing-ic-130167-ash-bb1.c.telia.net (213.248.84.154) 19.239 ms 19.182 ms 19.279 ms 13* 14* 15* 16* 17* 18* 19* 20* 21* 22* 23* 24* 25* 26* 27* 28* 29*
Re: Possible Sudden Uptick in ASA DOS?
My guess is a researcher. We saw the same issue in the past with a Cisco microcode bug and people doing ping record route. When it went across a LC with a very specific set of software it would crash. If you crashed just upgrade your code, don't hide behind blocking an IP as people now know what to send/do. It won't be long. Jared Mauch On Jul 9, 2015, at 7:44 AM, Colin Johnston col...@gt86car.org.uk wrote: Hi Jared, thanks for update do you know provider/source ip of the source of the attack ? Colin On 9 Jul 2015, at 12:27, Jared Mauch ja...@puck.nether.net wrote: Really just people not patching their software after warnings more than six months ago: July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. Jared Mauch On Jul 8, 2015, at 1:15 PM, Michel Luczak fr...@shrd.fr wrote: On 08 Jul 2015, at 18:58, Mark Mayfield mark.mayfi...@cityofroseville.com wrote: Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. Not sure it’s related but I’ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. Regards, Michel
RE: Dual stack IPv6 for IPv4 depletion
I've seen VLAN/subnet security used frequently in the financial world, even to the point of having full firewalls between vlans/subnets. Mostly for regulator purposes (Chinese firewall and all that). It's also common to allow outbound requests or redirect to different proxies based on source addresses within a corporate network. In residential networks, it's mostly used for guest networks that can route out to the internet, but not to other local devices. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tyler Applebaum Sent: Thursday, July 9, 2015 3:38 PM To: Naslund, Steve Cc: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Naslund, Steve Sent: Thursday, July 09, 2015 12:24 PM To: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment. When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device. The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP. Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a full table view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two). The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that accounting and their server are on one VLAN and engineering and their server are on another VLAN and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the Internet of things we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks. In the future it would seem
Re: Dual stack IPv6 for IPv4 depletion
And I’m saying you’re ignoring an important part of reality. Whatever ISPs default to deploying now will become the standard to which application developers develop. Changing the ISP later is easy. Changing the applications is hard. Let’s not bake unnecessary limitations into applications by assuming that tomorrow’s networks in homes will necessarily be as simple as today’s. Owen On Jul 9, 2015, at 13:07 , Naslund, Steve snasl...@medline.com wrote: In short, I'm saying that you should set your default so it is easily changed on the fly and then it won't matter if you are wrong. Steven Naslund Chicago IL In short, much of what you say below has been discussed before and with the general conclusion “geography != topology and no, geographic allocation would not improve summarization”. I’m not saying that assignments need to be static, but I am saying that we need to put the default size somewhere that doesn’t inhibit future development and close off options at the application level. That’s why I’m arguing for a default /48. Owen
Re: Dual stack IPv6 for IPv4 depletion
one word.RFC 1918. Here is an perpetual well of IPv4, packed down, overflowing. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 9July2015Thursday, at 6:02, Mark Tinka mark.ti...@seacom.mu wrote: On 9/Jul/15 14:53, Baldur Norddahl wrote: That will never happen. If you offer me $1000 per IPv4, then I will happily terminate some user contracts and sell their IP space to you... In fact it will never become even that expensive. With a marked price of $10 I am buying IP space for customers as needed and I will include free space in the contracts. If the price went to $100 I would tell all users that they need to pay monthly rent for their IP or alternative, the user would have to accept carrier NAT in some form. And then I would proceed to buy a new house for the money I make by selling address space. There is a ton of address space that is inefficient used. We will be able to buy excess from companies that create space by optimizing their existing space. There is a reason we have not seen any rise in the price even after multiple years with depletion in large parts of the world. In this particular case, I'm not concerned about the next ten years. Predicting what happens between now and then could have a fair degree of accuracy. I'm more concerned about what happens beyond that. I'm not sure I can accurately (even with large error margins) predict what happens then. All that said, I'm not trying to paint myself into that kind of corner. It is 2015, after all... Just don't tell my competitors... Mark.
RE: Dual stack IPv6 for IPv4 depletion
Huh, since when does ANY application care about what size address allocation you have? A V6 address is a 128 bit address period. Any IPv6 aware application will handle addresses as a 128 bit variable. Does any application running on IPv4 care if you have a /28 or a /29? In fact the application should not even be aware of what the net mask is because that is an OS function to handle the IP stack. This argument makes no sense at all since every application will be able to handle any allocation size since it is not even aware what that is. Any IPv6 compatible OS will not care either because they would be able to handle any number of masked bits. No app developer has ever been tied into the size of a subnet since CIDR was invented. Steven Naslund Chicago IL Subject: Re: Dual stack IPv6 for IPv4 depletion And I’m saying you’re ignoring an important part of reality. Whatever ISPs default to deploying now will become the standard to which application developers develop. Changing the ISP later is easy. Changing the applications is hard. Let’s not bake unnecessary limitations into applications by assuming that tomorrow’s networks in homes will necessarily be as simple as today’s. Owen
Re: Hotels/Airports with IPv6
Oliver O'Boyle wrote: It's not their job to even know to ask for a specific protocol version in the first place No. They should just ask, with the best geek intonation, whether this place still is stuck with 32-bit Internet. Grüße, Carsten
Re: Dual stack IPv6 for IPv4 depletion
- On Jul 9, 2015, at 4:56 PM, Naslund, Steve snasl...@medline.com wrote: Huh, since when does ANY application care about what size address allocation you have? A V6 address is a 128 bit address period. Any IPv6 aware application will handle addresses as a 128 bit variable. The DHCPv6-PD server application on your router(s) might care. Does any application running on IPv4 care if you have a /28 or a /29? In fact the application should not even be aware of what the net mask is because that is an OS function to handle the IP stack. This argument makes no sense at all since every application will be able to handle any allocation size since it is not even aware what that is. Any IPv6 compatible OS will not care either because they would be able to handle any number of masked bits. No app developer has ever been tied into the size of a subnet since CIDR was invented. For an application that doesn't do anything with IP addresses (allocating, etc.), it shouldn't matter, but that does not mean that there aren't applications for which it does. -Randy
Re: Hotels/Airports with IPv6
Unfortunately, the hotel staff wouldn't be able to answer that question. But they might give them free internet in exchange and hope the guest doesn't ask any more questions! On Thu, Jul 9, 2015 at 5:01 PM, Carsten Bormann c...@tzi.org wrote: Oliver O'Boyle wrote: It's not their job to even know to ask for a specific protocol version in the first place No. They should just ask, with the best geek intonation, whether this place still is stuck with 32-bit Internet. Grüße, Carsten -- :o@
Re: Dual stack IPv6 for IPv4 depletion
Sigh… Home gateways are an application in this context. How the firmware gets written in those things will be affected. Further, applications do care about things like “Can I assume that every home is reachable in its entirety via a packet to ff02::group?” which is, for example, already baked into many products as the current mDNS default scope. SSDPv6 also seems to default to ff02:: scoping. Whether or not applications come into existence that can take advantage of diverse topology in the home will depend entirely on whether or not we make diverse topology possible going forward. /56 will enable some development in this area, but it will hinder several potential areas of exploration. /48 is a reasonable end-site boundary. It allows enough flexibility for dynamic topologies while still leaving enough prefix space to have lots of extra room for sparse allocations and everything else. So, instead of focusing on the narrowest possible definition of “application” by todays terms, try opening your mind just a little bit and recognize that anything that requires software and interacts with the network in any way is a better definition of application in this context. Owen On Jul 9, 2015, at 13:56 , Naslund, Steve snasl...@medline.com wrote: Huh, since when does ANY application care about what size address allocation you have? A V6 address is a 128 bit address period. Any IPv6 aware application will handle addresses as a 128 bit variable. Does any application running on IPv4 care if you have a /28 or a /29? In fact the application should not even be aware of what the net mask is because that is an OS function to handle the IP stack. This argument makes no sense at all since every application will be able to handle any allocation size since it is not even aware what that is. Any IPv6 compatible OS will not care either because they would be able to handle any number of masked bits. No app developer has ever been tied into the size of a subnet since CIDR was invented. Steven Naslund Chicago IL Subject: Re: Dual stack IPv6 for IPv4 depletion And I’m saying you’re ignoring an important part of reality. Whatever ISPs default to deploying now will become the standard to which application developers develop. Changing the ISP later is easy. Changing the applications is hard. Let’s not bake unnecessary limitations into applications by assuming that tomorrow’s networks in homes will necessarily be as simple as today’s. Owen
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 3:38 PM, Tyler Applebaum appleba...@ochin.org wrote: Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation. I would generally say yes. For example, if you are a wireless access point you may have an internal SSID and a Guest SSID on the same radio and hence same physical ethernet cable. - Jared
Re: Dual stack IPv6 for IPv4 depletion
On Thu, Jul 09, 2015 at 08:02:40AM -0500, Mike Hammett wrote: Sounds like someone's getting caught up in the hype of a few buzzwords. I can't imagine where more than a couple bits of separately isolated networks in a home would be required. Most of those things you mentioned have no need to be isolated and are just being used to support a decision that was already made than evidence that lead to a decision. I'm not advocating anyone do anything other than what best practices dictate, just that whomever came up with best practices got a little caught up in the moment. You quickly run into religion here. I run my home as a big broadcast domain, but there's no reason I wouldn't perhaps segment things differently. There are a lot of people who just extend their wifi by plugging in a 2nd router with a long cable and don't realize they now have a new layer of nat, they just know the wifi by the $newRouter got better. Should I have a lan party VLAN/SSID? Perhaps, but for ease of use I let my AppleTV be on the same network as my iPhone so I can control them with the Remote app. Otherwise you quickly get into kinky broadcast relay or similar issues with multicast groups :) - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: Dual stack IPv6 for IPv4 depletion
I don't have a problem with that use case IF there is a real firewall between VLANs. I was mostly referring to residential networks however. As far as guest access, a lot of today's CPE does that with its internal firewall creating an ACL for anyone on the guest network. The VLAN barrier is not really needed there and there are lots of techniques for dodging a VLAN barrier anyway. Steven Naslund Chicago IL I've seen VLAN/subnet security used frequently in the financial world, even to the point of having full firewalls between vlans/subnets. Mostly for regulator purposes (Chinese firewall and all that). It's also common to allow outbound requests or redirect to different proxies based on source addresses within a corporate network. In residential networks, it's mostly used for guest networks that can route out to the internet, but not to other local devices. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669
RE: Dual stack IPv6 for IPv4 depletion
In short, I'm saying that you should set your default so it is easily changed on the fly and then it won't matter if you are wrong. Steven Naslund Chicago IL In short, much of what you say below has been discussed before and with the general conclusion “geography != topology and no, geographic allocation would not improve summarization”. I’m not saying that assignments need to be static, but I am saying that we need to put the default size somewhere that doesn’t inhibit future development and close off options at the application level. That’s why I’m arguing for a default /48. Owen
RE: Dual stack IPv6 for IPv4 depletion
You quickly run into religion here. I run my home as a big broadcast domain, but there's no reason I wouldn't perhaps segment things differently. There are a lot of people who just extend their wifi by plugging in a 2nd router with a long cable and don't realize they now have a new layer of nat, they just know the wifi by the $newRouter got better. More VLANs (or no VLANs) won't help with multiple layers of NAT but we are talking here about IPV6 allocations so NAT on the home CPE should not be an issue. Should I have a lan party VLAN/SSID? I would say that additional SSID ?= VLAN and would suggest that your LAN party try to use wired connections for better performance. If you don't want to reveal your wifi password by all means set up another SSID but it does not need to necessarily be in a different VLAN. Perhaps, but for ease of use I let my AppleTV be on the same network as my iPhone so I can control them with the Remote app. Otherwise you quickly get into kinky broadcast relay or similar issues with multicast groups :) -Jared Isn't the whole idea of this Internet of Things is that everything communicates to everything. Assuming that is the goal, what does VLANing do for you? Steven Naslund Chicago IL
RE: Dual stack IPv6 for IPv4 depletion
Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment. When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device. The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP. Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a full table view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two). The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that accounting and their server are on one VLAN and engineering and their server are on another VLAN and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the Internet of things we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks. In the future it would seem that systems would create their own little networks ad-hoc as needed for the best efficiency. I know this is not all out there today but planning address allocation 10 years down the road might be an exercise in futility. I would suggest plan for today and build it so you can easily change it when your prediction invariably prove wrong or short-sighted. Steven Naslund Chicago IL On Jul 9, 2015, at 09:16 , Matthew Huff mh...@ox.com wrote: When I see a car that needs a /56 subnet then I’ll take your use case seriously. Otherwise, it’s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work using jetpacks. When I see a reason not to give out /48s, I might start taking your argument seriously. We have prefix delegation already via DHCP-PD, but some in the IPv6 world don’t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. Clearly the quality of IPv6 in embedded devices needs to improve. There’s clearly work being done on LWIP
RE: Dual stack IPv6 for IPv4 depletion
Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Naslund, Steve Sent: Thursday, July 09, 2015 12:24 PM To: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment. When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device. The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP. Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a full table view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two). The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that accounting and their server are on one VLAN and engineering and their server are on another VLAN and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the Internet of things we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks. In the future it would seem that systems would create their own little networks ad-hoc as needed for the best efficiency. I know this is not all out there today but planning address allocation 10 years down the road might be an exercise in futility. I would suggest plan for today and build it so you can easily change it when your prediction invariably prove wrong or short-sighted. Steven Naslund Chicago IL On Jul 9, 2015, at 09:16 , Matthew Huff mh...@ox.com wrote: When I see a car that needs a /56 subnet then I’ll take your use case seriously. Otherwise, it’s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work using jetpacks. When I see a reason not to give out /48s, I might start taking your argument seriously. We have prefix delegation already via DHCP-PD, but some in the IPv6 world don’t even want to
RE: Dual stack IPv6 for IPv4 depletion
Yes, and that is a problem. Usually because it is not granular enough and there are a lot of ways to get onto another VLAN (physical access and packet trickery). It is a pretty weak form of security policy. Now, if we assume that VLAN based security is weak and that most homes do not generate enough broadcast traffic to be an issue, what exactly is the reason that a residential customer needs a lot of VLANs? Answer, they probably don't. A lot of residential users have a CPE device that does wireless, routing, and DHCP assignments all in one. No need to create a guest VLAN on that type of device. You simply assign an ACL that keeps the guest from reaching any internal IP. Why would your refrigerator (or car, toaster, TV, whatever) need to be on a separate subnet when the whole point is to create a network where all of your stuff communicates? Us engineers need to make sure we don't generalize that a lot of residential users do to their networks what we do to ours. We MIGHT have a reason for several subnets to simulate different stuff. I am still waiting for a valid example of a residential situation where VLANs are a useful addition. Oh, and don't even try the QoS argument. I will tell you that LLDP identification of the device and applying QoS policy based on the identification is much more effective and transparent to the end user. Steven Naslund Chicago IL -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tyler Applebaum Sent: Thursday, July 9, 2015 3:38 PM To: Naslund, Steve Cc: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation.
Re: Dual stack IPv6 for IPv4 depletion
In short, much of what you say below has been discussed before and with the general conclusion “geography != topology and no, geographic allocation would not improve summarization”. I’m not saying that assignments need to be static, but I am saying that we need to put the default size somewhere that doesn’t inhibit future development and close off options at the application level. That’s why I’m arguing for a default /48. Owen On Jul 9, 2015, at 12:24 , Naslund, Steve snasl...@medline.com wrote: Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment. When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device. The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP. Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a full table view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two). The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that accounting and their server are on one VLAN and engineering and their server are on another VLAN and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the Internet of things we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks. In the future it would seem that systems would create their own little networks ad-hoc as needed for the best efficiency. I know this is not all out there today but planning address allocation 10 years down the road might be an exercise in futility. I would suggest plan for today and build it so you can easily change it when your prediction invariably prove wrong or short-sighted. Steven Naslund Chicago IL On Jul 9, 2015, at 09:16 , Matthew Huff mh...@ox.com wrote: When I see a car that needs a /56 subnet then I’ll take your use case seriously. Otherwise, it’s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that
Re: Dual stack IPv6 for IPv4 depletion
- On Jul 9, 2015, at 4:07 PM, Naslund, Steve snasl...@medline.com wrote: In short, I'm saying that you should set your default so it is easily changed on the fly and then it won't matter if you are wrong. Absolutely. Also, since it won't matter if we are wrong, let's use /48 as the default, since it is much easier to deal with and is much less likely to be a case of oops, too small than /56 or, particularly, /60 or longer. -Randy
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 05:53 , Baldur Norddahl baldur.nordd...@gmail.com wrote: On 9 July 2015 at 13:25, Mark Tinka mark.ti...@seacom.mu wrote: I suppose the issue will become more real when you can't get any IPv4 space period. Mark. That will never happen. If you offer me $1000 per IPv4, then I will happily terminate some user contracts and sell their IP space to you… Eventually, you run out of user contracts to terminate. In fact it will never become even that expensive. With a marked price of $10 I am buying IP space for customers as needed and I will include free space in the contracts. If the price went to $100 I would tell all users that they need to pay monthly rent for their IP or alternative, the user would have to accept carrier NAT in some form. And then I would proceed to buy a new house for the money I make by selling address space. Sure, but aren’t your customers going to start demanding IPv6 instead of that at some point? Aren’t they going to start insisting on a service that doesn’t charge per address? There is a ton of address space that is inefficient used. We will be able to buy excess from companies that create space by optimizing their existing space. There is a reason we have not seen any rise in the price even after multiple years with depletion in large parts of the world. Yes… It’s called “soft landing”… ARIN will be the first region to deplete without significant austerity policies for newcomers to get address space. Owen
RE: Dual stack IPv6 for IPv4 depletion
Matthew Huff mh...@ox.com wrote: When I see a car that needs a /56 subnet then I’ll take your use case seriously. Cars need partitions between their automotive network, their entertainment network, and their passenger wifi. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southeast Fitzroy: Northeasterly becoming cyclonic 5 to 7, occasionally gale 8 at first. Moderate or rough. Fair. Moderate or good.
RE: Dual stack IPv6 for IPv4 depletion
Sure, they may be 100,000+ networks like that in non-technical households. Maybe. I doubt it, but still that would be like 0.01%. Many consumer systems have trouble with L3 hops (mDNS/Bonjour, etc...). First thing tech support will suggest it to put them on the same network. People have been taught this. My experience is that most people that even have a second network, it's their AP that sets up a Guest network, and even then, it doesn't route between the networks (that's sort of the whole idea). If an ISP wants to give out a /48, great for them. If they want to give out only a /56, I say that's fine. What's more important to me is that they implement IPv6. Arguing about prefix size and SLAAC vs DHCP rather than just go ahead and implement things, to me is just silly. When IP was first deployed, we didn't have DHCP (bootp was still in it's infancy), no mDNS, etc...Lots of things grew up after the fact. I agree that we can't foresee what will happen in the future, but that to me just proves my point. Worrying about the ability to create complex topologies in home networks that may or may not ever be needed or wanted just seems absurd to me. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Thursday, July 9, 2015 12:36 PM To: Matthew Huff Cc: Marco Teixeira; Harald Koch; NANOG list Subject: Re: Dual stack IPv6 for IPv4 depletion On Jul 9, 2015, at 08:42 , Matthew Huff mh...@ox.com wrote: What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? It's the need for a large enough bitfield to do more flexible things with auto-delegation in a dynamic self-organizing topology. 8 is 2x2x2 and there's really no other way you can break it down. (2x4, 4x2, 2x2x2 is it.) 16 is 2x2x2x2 and allows many more possible topologies (4x4, 2x4x2, 2x2x4, 2x8, 8x2, etc.) With /56 you are giving each residential customer: 256 subnets x 18,446,744,073,709,551,616 hosts per subnet. The host count is irrelevant to the discussion. I would expect at least 95.0% of residential customers are using 1 subnet, and 99.9% are using less than 4. I can understand people complaining when some ISPs were deciding to only give out a /64, but even with new ideas, new protocols and new applications, do people really think residential customers will need more than 256 subnets? When such a magical new system is developed, and people start to want it, can't ISPs start new /48 delegations? Since DHCP-PD and their infrastructure will already be setup for /56, it may not be easy, but it shouldn't be that difficult. I would expect that basing decisions about limits on tomorrows network on the inadequacy of today's solutions is unlikely to yield good results. Further, I'm not so sure you are right in your belief. I suspect that there are many more networks in most households that you are not counting. Sure, those networks are currently usually disjoint, but do you really think it will always be that way in the future? Every phone is a router. Ever tablet is a router. Cars are becoming routers and in some cases, collections of routers. Set top boxes are becoming routers. Utility meters are becoming routers. Laptops and desktops are capable of being routers. I know the saying build it and they will come, but seriously I'd rather ISPs stop discussing deploying IPv6, and start doing it. I'm all for that, but do you have a valid reason not to give out /48s per end site? Just because /56 might be enough doesn't cut it. I'm asking if you can point to any tangible benefit obtained from handing out /56s instead? Is there any problem solved, labor saved, or any other benefit whatsoever to giving out /56s instead of /48s? If not, then let's hand out /48s until we discover one. Owen
Re: Hotels/Airports with IPv6
Unfortunately, there are still some that would report 2mbit via dsl and think that was ahead of their competition (and it might be in some cases...)... On Jul 9, 2015 5:51 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: No. They should just ask, with the best geek intonation, whether this place still is stuck with 32-bit Internet I'm sure they'd gladly report that their Internet is 24 mbit and not just 32 bit ;) alan
Re: Dual stack IPv6 for IPv4 depletion
On Thu, 09 Jul 2015 18:05:00 -0400, Owen DeLong o...@delong.com wrote: Look again… IPv6 is already more than 20% of Google traffic in the US. 20% of *1* site's traffic does not equal 20% DEPLOYMENT. (read: 20% of internet DEVICES (CPE) connected by IPv6)
Re: Dual stack IPv6 for IPv4 depletion
On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve snasl...@medline.com wrote: That would be Tivo's fault wouldn't it. Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work over the internet. (It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.)
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 15:45 , Ricky Beam jfb...@gmail.com wrote: On Thu, 09 Jul 2015 18:05:00 -0400, Owen DeLong o...@delong.com wrote: Look again… IPv6 is already more than 20% of Google traffic in the US. 20% of *1* site's traffic does not equal 20% DEPLOYMENT. (read: 20% of internet DEVICES (CPE) connected by IPv6) You are correct… In order for 20% of Google’s traffic to come from IPv6 connected devices, there would generally need to be more than 20% of all devices connected over IPv6. Owen
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 15:55 , Ricky Beam jfb...@gmail.com wrote: On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve snasl...@medline.com wrote: That would be Tivo's fault wouldn't it. Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work over the internet. (It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.) Correct… It _IS_ TiVO’s fault. However, the reality I’m trying to point out is that application developers make assumptions based on the commonly deployed environment that they expect in the world. If we create a limited environment, then that is what they will code to. If we deliver /48s, then they will come up with innovative ways to make use of those deployments. If we deliver /56s, then innovation will be constrained to what can be delivered to /56s, even for sites that have /48s. Owen
Re: Dual stack IPv6 for IPv4 depletion
In message 9578293ae169674f9a048b2bc9a081b401c7097...@munprdmbxa1.medline.com , Naslund, Steve writes: Subject: Re: Dual stack IPv6 for IPv4 depletion Because vendor pressure depends on a userbase that knows enough to demand fixes. No vendor pressure is dependent on people buying their stuff. Don't send that CPE to your user if it does not meet your standards. If their stuff breaks because of shortsighted coding to bad for them. I am not going to be the guy to build in stupid limitations today to save a few minutes of coding for some lazy hardware vendor. Simple fact is that if most ISPs deploy degraded services, vendors will code to the lowest common denominator of that degraded service and well all be forced to live within those limitations in the products we receive. Why would you think so? Did your IPv4 router not accept a /8 netmask even though there was very little chance you would get one? I know most of my programmers are trained to anticipate all of the possible options for an input. Sometimes this is hard to define but with IPv6 it is clearly in the specification. Would you consider an ISP that hands out /56s to be degraded? Most users wouldn't know the difference and if you offered the /48 on request (or even better automatically on depletion of the /56) what would be degraded? Because ISP's have a track record of not listening to user requests. Getting IPv6 delivered is a prime example. Some of us have been requesting it from our ISP's for well over a decade now and they are still yet to deliver. Some of us have requested that SUBMIT be enabled on their outgoing mail server for just as long, a simple 1 line fix in the mail server config. No, webmail is not a acceptable alternative. It's likely to take as long to get them to increase the allocation from a /56 to a /48 despite it being a 1 word fix in a config. Getting that one word change will not be as easy as ring up customer support and saying Can you please increase the number of subnets returned to a prefix delegation request? and getting Yes as the answer. This is already evident in the IPv4 world. Even though my TiVO is 100% reachable from the internet, I cant use any of TiVOs applications to access it directly, I have to work through their proxy servers that depend on periodic polling from my devices to work because they assume everyone is stuck behind NAT. That would be Tivo's fault wouldn't it. It would be trivially simple for them to know if they were behind a NAT so I am guessing they force you through their proxy for other purposes. Should we re-engineer the way IP works so that Tivo can write crap code? Should we limit all future v6 users today so that crap CPE works now? No. It is ISP's and CPE vendors faults for stalling on IPv6 for well over a decade. If we all had IPv6 in the home a decade ago Tivo could have designed for a reachable device rather than one that had to polled due to there being no IPv6 in the home and IPv4 addresses changing all the time due to there not being enouhg of them and ISP's having to juggle them. Tivo added IP support in 2006. Windows XP already had IPv6 support when Tivo shipped their 2nd gen box. A Tivo box is a in-home server. That requires stable addressability which IPv6 (RFC 2460) can deliver, using address blocks assigned from the ISP using PD (RFC 3633). With IPv6 it could register its address in the global DNS using a TSIG (RFC 2845) signed UPDATE (RFC 2136) requests just the way your Mac can do today. All of these RFC's existed when the 2nd Gen Tivo was designed. What didn't exist was ISP's delivering IPv6 to the home customer. What Tivo had to work with was 99.9% of the user base behind a NAT with no address stablility. How would you design your Tivo? Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever? I never said that there was a valid reason not to use /48s or /56s or whatever prefix you like. What I am saying is don't force that decision on anyone today. IPv6 does not force the use of any particular prefix length for an end user, why should you? Why do we all have to use the same length anyways? Owen Steven Naslund Chicago IL -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Dual stack IPv6 for IPv4 depletion
Yes, the reason is that we'd never had ARIN turn down a request due to space exhaustion before. In 12 months we'll see the prices will go up significantly. Don't underestimate the demand, which is easily measured via ARIN space allocation reports. That demand rate has very little flexibility, and the businesses asking for /21 and above are willing to pay for the space. It's not the two guys and a router startups asking for a mere /23 or /24. These are generally pre-existing businesses or well-funded startups. -mel beckman On Jul 9, 2015, at 5:53 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote: There is a reason we have not seen any rise in the price even after multiple years with depletion in large parts of the world.
Re: Possible Sudden Uptick in ASA DOS?
On Thu, 09 Jul 2015 07:27:16 -0400, Jared Mauch ja...@puck.nether.net wrote: Really just people not patching their software after warnings more than six months ago: A lot goes into updates. Not the least of which is *knowing* about the issue. Then getting the patched code, then lab testing, then regulatory approval(s), then maintenance window(s)... Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. Free if you have a support contract. (the clause 3 contact TAC method is all too often a serious pain in the ass.) --Ricky
Re: Possible Sudden Uptick in ASA DOS?
On Jul 9, 2015, at 5:35 PM, Ricky Beam jfb...@gmail.com wrote: On Thu, 09 Jul 2015 07:27:16 -0400, Jared Mauch ja...@puck.nether.net wrote: Really just people not patching their software after warnings more than six months ago: A lot goes into updates. Not the least of which is *knowing* about the issue. Then getting the patched code, then lab testing, then regulatory approval(s), then maintenance window(s)… Not my first rodeo. Once again, it’s been since October 2014. If you failed to pay your credit card bill from October 2014 you can’t expect it to work either. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. Free if you have a support contract. (the clause 3 contact TAC method is all too often a serious pain in the ass.) I’ve never had issues getting them to open a case for this hardware. You can either operate responsibly or not. I wouldn’t be surprised if the situation gets worse. Either way, upgrade/patch/silo as necessary. - Jared
Re: Dual stack IPv6 for IPv4 depletion
On Thu, 09 Jul 2015 11:08:53 -0400, Marco Teixeira ad...@marcoteixeira.com wrote: On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch c...@pobox.com wrote: The common man is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need. Probably because he got good advise from his father :) Indeed. Either someone else set it up, or he took the time to learn how to set it up himself. (kudos if the latter) THIS definitely makes him parsecs from the common man (there being 7billion people in the world, and all.) Will a dozen networks be common (ie. out-of-the-box default) tomorrow? (NO) Next year? (NO) A decade from now? (maybe, and IPv6 deployment *might* be up to 20% by then)
Re: Hotels/Airports with IPv6
No. They should just ask, with the best geek intonation, whether this place still is stuck with 32-bit Internet I'm sure they'd gladly report that their Internet is 24 mbit and not just 32 bit ;) alan
Re: Possible Sudden Uptick in ASA DOS?
On 09/07/2015 22:35, Ricky Beam wrote: Free if you have a support contract. No, free-as-in-beer. You register a guest CCO account, email t...@cisco.com, provide the device serial number (or output of show hardware) and the bugid + Cisco PSIRT URL reference. Cisco TAC will then provide you with a download link with fixed software, at no cost to you. It's not a pain in the ass - it works fine. Nick
RE: Dual stack IPv6 for IPv4 depletion
Huh, since when does ANY application care about what size address allocation you have? A V6 address is a 128 bit address period. Any IPv6 aware application will handle addresses as a 128 bit variable. The DHCPv6-PD server application on your router(s) might care. Do you know of a DHCPv6-PD or router code that will accept a /56 and not a /48? If you do, I suggest you open a bug with that vendor and tell them that either is a legal prefix length. Does any application running on IPv4 care if you have a /28 or a /29? In fact the application should not even be aware of what the net mask is because that is an OS function to handle the IP stack. This argument makes no sense at all since every application will be able to handle any allocation size since it is not even aware what that is. Any IPv6 compatible OS will not care either because they would be able to handle any number of masked bits. No app developer has ever been tied into the size of a subnet since CIDR was invented. For an application that doesn't do anything with IP addresses (allocating, etc.), it shouldn't matter, but that does not mean that there aren't applications for which it does. -Randy One should demand that application that care about allocation size, routing, etc would not be IPv6 compatible if they cannot handle all mask length legal under the protocol specification. The reason there is a v6 standard is to define what is allowable or not, that is what a protocol IS. We do not need to decide by committee to limit those options. Steven Naslund Chicago IL
Re: Dual stack IPv6 for IPv4 depletion
On Jul 9, 2015, at 14:50 , Ricky Beam jfb...@gmail.com wrote: On Thu, 09 Jul 2015 11:08:53 -0400, Marco Teixeira ad...@marcoteixeira.com wrote: On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch c...@pobox.com wrote: The common man is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need. Probably because he got good advise from his father :) Indeed. Either someone else set it up, or he took the time to learn how to set it up himself. (kudos if the latter) THIS definitely makes him parsecs from the common man (there being 7billion people in the world, and all.) Will a dozen networks be common (ie. out-of-the-box default) tomorrow? (NO) Next year? (NO) A decade from now? (maybe, and IPv6 deployment *might* be up to 20% by then) Look again… IPv6 is already more than 20% of Google traffic in the US. Owen
Re: Dual stack IPv6 for IPv4 depletion
Because vendor pressure depends on a userbase that knows enough to demand fixes. Simple fact is that if most ISPs deploy degraded services, vendors will code to the lowest common denominator of that degraded service and we’ll all be forced to live within those limitations in the products we receive. This is already evident in the IPv4 world. Even though my TiVO is 100% reachable from the internet, I can’t use any of TiVO’s applications to access it directly, I have to work through their proxy servers that depend on periodic polling from my devices to work because they assume everyone is stuck behind NAT. Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever? Owen On Jul 9, 2015, at 14:51 , Naslund, Steve snasl...@medline.com wrote: So, why not demand that firmware accepts ANY mask length just like VLSM v4. I don't see what possible difference it will make if it is a /56 or /48 and I don't think you should make ANY assumption based on either of those being correct for any particular application. An assumption you make today is only applicable to your network not mine, it has no certainty of permanence at all. If one of my software engineers came to me and asked I would tell them they need to handle all possible mask lengths...period. Even if they are not in common use today, if its legal under the v6 spec then you should expect to support it. Not engineering for change is how we end up with software that won't handle a 2xxx year or a leap second. If a vendor decides to code something like the ff02:: scoping into their systems in a way that can't easily change then it is at their own risk. Would it be very difficult to change that depending on the DHCP-PD response you got? Why do you want to be the guy to make the bad assumption instead of them? That's what you are doing in the /56 vs /48 argument is it not? A little early in the IPv6 game to be making permanent rules on allocation sizes for future generations and hard coding them don't you think? All of statements you make regarding enable some development and reasonable end-site boundary are the network equivalents of the no one will need more that 640k of RAM and 32 bits will be more addresses than we ever need As far as opening up my mind a bit how about opening your mind and demanding that IPv6 compatibility means accepting ALL possible allocation lengths. Steven Naslund Chicago IL Sigh… Home gateways are an application in this context. How the firmware gets written in those things will be affected. Further, applications do care about things like “Can I assume that every home is reachable in its entirety via a packet to ff02::group?” which is, for example, already baked into many products as the current mDNS default scope. SSDPv6 also seems to default to ff02:: scoping. Whether or not applications come into existence that can take advantage of diverse topology in the home will depend entirely on whether or not we make diverse topology possible going forward. /56 will enable some development in this area, but it will hinder several potential areas of exploration. /48 is a reasonable end-site boundary. It allows enough flexibility for dynamic topologies while still leaving enough prefix space to have lots of extra room for sparse allocations and everything else. So, instead of focusing on the narrowest possible definition of “application” by todays terms, try opening your mind just a little bit and recognize that anything that requires software and interacts with the network in any way is a better definition of application in this context. Owen
RE: Dual stack IPv6 for IPv4 depletion
Subject: Re: Dual stack IPv6 for IPv4 depletion Because vendor pressure depends on a userbase that knows enough to demand fixes. No vendor pressure is dependent on people buying their stuff. Don't send that CPE to your user if it does not meet your standards. If their stuff breaks because of shortsighted coding to bad for them. I am not going to be the guy to build in stupid limitations today to save a few minutes of coding for some lazy hardware vendor. Simple fact is that if most ISPs deploy degraded services, vendors will code to the lowest common denominator of that degraded service and we’ll all be forced to live within those limitations in the products we receive. Why would you think so? Did your IPv4 router not accept a /8 netmask even though there was very little chance you would get one? I know most of my programmers are trained to anticipate all of the possible options for an input. Sometimes this is hard to define but with IPv6 it is clearly in the specification. Would you consider an ISP that hands out /56s to be degraded? Most users wouldn't know the difference and if you offered the /48 on request (or even better automatically on depletion of the /56) what would be degraded? This is already evident in the IPv4 world. Even though my TiVO is 100% reachable from the internet, I can’t use any of TiVO’s applications to access it directly, I have to work through their proxy servers that depend on periodic polling from my devices to work because they assume everyone is stuck behind NAT. That would be Tivo's fault wouldn't it. It would be trivially simple for them to know if they were behind a NAT so I am guessing they force you through their proxy for other purposes. Should we re-engineer the way IP works so that Tivo can write crap code? Should we limit all future v6 users today so that crap CPE works now? Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever? I never said that there was a valid reason not to use /48s or /56s or whatever prefix you like. What I am saying is don't force that decision on anyone today. IPv6 does not force the use of any particular prefix length for an end user, why should you? Why do we all have to use the same length anyways? Owen Steven Naslund Chicago IL
RE: Dual stack IPv6 for IPv4 depletion
So, why not demand that firmware accepts ANY mask length just like VLSM v4. I don't see what possible difference it will make if it is a /56 or /48 and I don't think you should make ANY assumption based on either of those being correct for any particular application. An assumption you make today is only applicable to your network not mine, it has no certainty of permanence at all. If one of my software engineers came to me and asked I would tell them they need to handle all possible mask lengths...period. Even if they are not in common use today, if its legal under the v6 spec then you should expect to support it. Not engineering for change is how we end up with software that won't handle a 2xxx year or a leap second. If a vendor decides to code something like the ff02:: scoping into their systems in a way that can't easily change then it is at their own risk. Would it be very difficult to change that depending on the DHCP-PD response you got? Why do you want to be the guy to make the bad assumption instead of them? That's what you are doing in the /56 vs /48 argument is it not? A little early in the IPv6 game to be making permanent rules on allocation sizes for future generations and hard coding them don't you think? All of statements you make regarding enable some development and reasonable end-site boundary are the network equivalents of the no one will need more that 640k of RAM and 32 bits will be more addresses than we ever need As far as opening up my mind a bit how about opening your mind and demanding that IPv6 compatibility means accepting ALL possible allocation lengths. Steven Naslund Chicago IL Sigh… Home gateways are an application in this context. How the firmware gets written in those things will be affected. Further, applications do care about things like “Can I assume that every home is reachable in its entirety via a packet to ff02::group?” which is, for example, already baked into many products as the current mDNS default scope. SSDPv6 also seems to default to ff02:: scoping. Whether or not applications come into existence that can take advantage of diverse topology in the home will depend entirely on whether or not we make diverse topology possible going forward. /56 will enable some development in this area, but it will hinder several potential areas of exploration. /48 is a reasonable end-site boundary. It allows enough flexibility for dynamic topologies while still leaving enough prefix space to have lots of extra room for sparse allocations and everything else. So, instead of focusing on the narrowest possible definition of “application” by todays terms, try opening your mind just a little bit and recognize that anything that requires software and interacts with the network in any way is a better definition of application in this context. Owen
RE: Dual stack IPv6 for IPv4 depletion
On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch c...@pobox.com wrote: The common man is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need. Probably because he got good advise from his father :) Agreed, we need to not add any limits or conventions to the v6 protocol. Why commit to a /48 or /56 if the protocol offers many more options? Just write software to deal with all the possibilities. While the common man has become much more sophisticated in network REQUIREMENTS. They have probably become less KNOWLEDGEABLE about what those requirement are because they are getting used to just plugging it in and it works. Used to be that most Internet users knew if that had public/private or dynamic/static addresses because they had to. Today the most likely answer would be who knows, I plugged in my Apple TV and it just worked Steven Naslund
Re: Dual stack IPv6 for IPv4 depletion
On Thu, 09 Jul 2015 16:00:35 -0400, Naslund, Steve snasl...@medline.com wrote: Now, if we assume that VLAN based security is weak and that most homes do not generate enough broadcast traffic to be an issue, what exactly is the reason that a residential customer needs a lot of VLANs? Answer, they probably don't. ... I am still waiting for a valid example of a residential situation where VLANs are a useful addition. Voice, Video, Data, and Guest VLANs. And even that is generally overkill, but does provide a measurable, if marginal, improvement. --Ricky
Re: Dual stack IPv6 for IPv4 depletion
On Thu, 09 Jul 2015 19:08:56 -0400, Owen DeLong o...@delong.com wrote: the reality I’m trying to point out is that application developers make assumptions based on the commonly deployed environment that they expect in the world. Partially. It's also a matter of the software guys not having any clue what-so-ever w.r.t. networking. In this case, APPLE designed Bonjour to not cross network boundaries. Idiotic, but it allows them to sell servers that do the cross-network routing. If we create a limited environment, then that is what they will code to. They will code to what they understand, what works for them, and what their users report works for me. We will always end up with substandard quality because they have little (or no) understanding of how networking does it's thing. (And then marketing, and legal will step in and pooh on it even more.)
Re: Dual stack IPv6 for IPv4 depletion
On Thu, 2015-07-09 at 08:02 -0500, Mike Hammett wrote: I can't imagine [...] And that, right there, is the problem. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
Re: Dual stack IPv6 for IPv4 depletion
Solutions looking for problems. I get a few subnets (though don't foresee it being likely). Someone here was mentioning dozens or hundreds of subnets for a residential customer. Um, no. If you feel the need to segment private wire and private wireless, okay. Then there's guest... um, and M2M? yeah, that's about it for a single residence. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com - Original Message - From: Harald Koch c...@pobox.com To: Mike Hammett na...@ics-il.net Cc: NANOG list nanog@nanog.org Sent: Thursday, July 9, 2015 9:46:41 AM Subject: Re: Dual stack IPv6 for IPv4 depletion On 9 July 2015 at 09:11, Mike Hammett na...@ics-il.net wrote: I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. My son (who is not a tech guy but is a gamer) has four subnets in his (rented) house already: private LAN, guest network, home control network, and a separate LAN for the tenant downstairs who is sharing their broadband connection. And he's just getting started. The common man is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need. -- Harald
