Re: IPv6 deployment excuses
On Mon, 4 Jul 2016, Baldur Norddahl wrote: The two other technologies mentioned do the same as MAP more or less, but both requires carrier NAT, which is expensive for the ISP and has a lack of control as seen from the end user point of view (no port forwarding etc). What it does however, is make things like GRE work. Some are surprised that there is actually non A+P protocols being used by customers. For instance legacy PPTP uses this, so some business VPNs run into problem with MAP or LW4o6. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 deployment excuses
valdis.kletni...@vt.edu wrote: A large ISP should just set up usual NAT. In addition, Thus almost guaranteeing a call to the support desk for each and every single game console, because the PS3 and PS4 doesn't have a configuration interface for that, and the XBox probably doesn't either (and if it does, it's probably something that Joe Sixpack can't do without help). With usual NAT? That is not my problem. But, if you want to run a server at fixed IP address and port, port forwarding must be static. A laudable network design for my competitors. Feel free to deploy it at a realistic sized ISP and let us know how it works out. Are you saying there is no realistic sized ISP offering fixed IP addresses without NAT? If not, additional setup of static port forwarding on NAT boxes can not be a problem. Masataka Ohta
Re: IPv6 deployment excuses
On Tue, 05 Jul 2016 11:16:31 +0900, Masataka Ohta said: > A large ISP should just set up usual NAT. In addition, the ISP > tells its subscriber a global IP address, a private IP address > and a small range of port numbers the subscriber can use and > set up *static* bi-directional port forwarding. Thus almost guaranteeing a call to the support desk for each and every single game console, because the PS3 and PS4 doesn't have a configuration interface for that, and the XBox probably doesn't either (and if it does, it's probably something that Joe Sixpack can't do without help). > It is merely because you think you must do it dynamically. > > But, if you want to run a server at fixed IP address > and port, port forwarding must be static. A laudable network design for my competitors. Feel free to deploy it at a realistic sized ISP and let us know how it works out. pgpLoOOtUmlD0.pgp Description: PGP signature
Re: IPv6 deployment excuses
> On Jul 4, 2016, at 10:32 PM, Matt Hoppes > wrote: > > Jared, > The issue I have with the whole DNS IPv6 thing is IPs are static (on > infrastructure), DNS can get munged up and is another database we have to > maintain. I’m not sure I understand your point. DNS is DNS. It’s not the 1990s anymore and people should not be doing this without automation. > So now rather than just maintaining an IP database we have to maintain a > database for DNS to IP and the IP. This should be done at the same time. There’s plenty of people who have done this, so you shouldn’t have to build it yourself either, but you may want to. > And Ina subscriber network things like cpe12232.domain.com are worthless for > identifying the end user so I'm referencing the Ip back to something else > anyway. Your central unit should be the subscriber and they should have the relevant attributes associated with them, be it IP history as well as account history. You can have the DNS system sign on the fly if you have DNSSEC and that’s your concern. IPv6 hosts still leave something to be desired for dynamic DNS entries, but looking at what happens behind Comcast as an example, there are no PTR records, eg: 2601:401:4:3000:71d1:cf8e:a951: -> x.x.x.x.1.5.9.a.e.8.f.c.1.d.1.7.0.0.0.3.4.0.0.0.1.0.4.0.1.0.6.2.ip6.arpa not found: 3(NXDOMAIN) If you want to make it more user friendly, you can overload it like this: openresolverproject.org has address 204.42.254.206 openresolverproject.org has IPv6 address 2001:418::7011:204:42:254:206 - Jared
Re: IPv6 deployment excuses
Jared Mauch wrote: Are you saying, without NAT or something like that to restrict reachable ports, the Internet, regardless of whether it is with IPv4 or IPv6, is not very secure? I'm saying two things: 1) UPnP is a security nightmare and nobody (at scale) will let you register ports with their CGN/edge. Don't do that. Just have static port forwarding. UPnP may be used as a channel to advertise the forwarding information but you can also do it manually (for reverse translation, configuring a global IP address and a range of port numbers is enough). 2) We are an industry in transition. Internet connectivity will soon be defined by v6 + v4, not v4+ sometimes v6. Yeah, we have been so for these 20 years. Our services need to work for the broadest set of users. Many people are now used to the non-e2e results of a NAT/CGN environment. Exactly. And, as e2e transparency over NAT can be offered to exceptional people, we can live with IPv4 forever. Masataka Ohta
Re: IPv6 deployment excuses
Jared, The issue I have with the whole DNS IPv6 thing is IPs are static (on infrastructure), DNS can get munged up and is another database we have to maintain. So now rather than just maintaining an IP database we have to maintain a database for DNS to IP and the IP. And Ina subscriber network things like cpe12232.domain.com are worthless for identifying the end user so I'm referencing the Ip back to something else anyway.
Re: IPv6 deployment excuses
Or how about we just avoid anything that uses the terms like "Mappings" and "NAT" and speed the adoption of IPv6 everywhere which already solves all of these problems. *Spencer Ryan* | Senior Systems Administrator | sr...@arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Mon, Jul 4, 2016 at 10:16 PM, Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Baldur Norddahl wrote: > > With end to end NAT, you can still configure your UPnP capable NAT >>> boxes to restrict port forwarding. >>> >> > Only if you by NAT mean "home network NAT". No large ISP has or will deploy >> a carrier NAT router that will respect UPnP. >> > > A large ISP should just set up usual NAT. In addition, the ISP > tells its subscriber a global IP address, a private IP address > and a small range of port numbers the subscriber can use and > set up *static* bi-directional port forwarding. > > If each subscriber is allocated 64 ports, effective address > space is 1000 times more than that of IPv4, which should be > large enough. > > Then, if a subscriber want transparency, he can set up his > home router make use of the bi-directional port forwarding > and his host reverse translation by nested port forwarding. > > That does not scale and is a >> security nightmare besides. >> > > It is merely because you think you must do it dynamically. > > But, if you want to run a server at fixed IP address > and port, port forwarding must be static. > > Masataka Ohta >
Re: IPv6 deployment excuses
Baldur Norddahl wrote: With end to end NAT, you can still configure your UPnP capable NAT boxes to restrict port forwarding. Only if you by NAT mean "home network NAT". No large ISP has or will deploy a carrier NAT router that will respect UPnP. A large ISP should just set up usual NAT. In addition, the ISP tells its subscriber a global IP address, a private IP address and a small range of port numbers the subscriber can use and set up *static* bi-directional port forwarding. If each subscriber is allocated 64 ports, effective address space is 1000 times more than that of IPv4, which should be large enough. Then, if a subscriber want transparency, he can set up his home router make use of the bi-directional port forwarding and his host reverse translation by nested port forwarding. That does not scale and is a security nightmare besides. It is merely because you think you must do it dynamically. But, if you want to run a server at fixed IP address and port, port forwarding must be static. Masataka Ohta
Re: IPv6 deployment excuses
On Mon, Jul 04, 2016 at 06:41:00PM +0900, Masataka Ohta wrote: > Jared Mauch wrote: > > > Actually they are not that great. Look at the DDoS mess that UPnP has > > created and problems for IoT (I call it Internet of trash, as most > > devices are poorly implemented without safety in mind) folks on all > > sides. > > Are you saying, without NAT or something like that to restrict > reachable ports, the Internet, regardless of whether it is with > IPv4 or IPv6, is not very secure? I'm saying two things: 1) UPnP is a security nightmare and nobody (at scale) will let you register ports with their CGN/edge. 2) We are an industry in transition. Internet connectivity will soon be defined by v6 + v4, not v4+ sometimes v6. There are challenges still, AWS, UBNT UniFi and things like the CableWifi/xfinitywifi don't do V6 currently. I've heard most of these are coming. There are still a lot of self-proclaimed "IT Experts" that say stuff like "why use DNS", or the well meaning "Cybermoon CEO Amitay Dan" who says you should use an IP address to manage your home router. Of course when people see that, I'm sure they all are thinking IPv4 vs using a .local domain name. Much of this is because we're technical people and most users are non-technical, they just want their stuff(tm) to work. We must make it seamless, and this will mean providing them a method to have their technology work. Take how most people copy files between devices today. I may go and SFTP or SCP files around, know the paths, set my prompt but others? USB or a service like Dropbox. It's about the technology as a tool. If you fail to see IPv6 as part of that tool to fix things and think that everyone will do the right thing, you will face hurdles. Our services need to work for the broadest set of users. Many people are now used to the non-e2e results of a NAT/CGN environment. They work around it with other solutions. Soon? IPv4AAS will be abundant to bridge those who lack full internet access. - 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: IPv6 deployment excuses
On Monday, July 4, 2016, Baldur Norddahl wrote: > On 2016-07-04 20:50, Ca By wrote: > > > Always so funny how people love talking how great MAP scales, yet it has > never been deployed at scale. 464XLAT and ds-lite have been deployed at > real scale, so has 6RD. > > MAP is like beta max. Technically great, but reality is poor. > > > The two MAP RFCs are dated July 2015 just one year old. The world does not > move that fast and especially not "large deployments". > > 6RD is dated August 2010 > DS-LITE is dated August 2011 > 464XLAT is dated April 2013 > > Funny thing about that is that 464XLAT IETF work started after MAP and finshed before MAP, despite MAP being the path of the true believers. Seems MAP running code has been around for 3 years https://ripe67.ripe.net/presentations/136-ripe_20_dollar_cgn.pdf > Someone from Comcast just said at the recent RIPE conference in Copenhagen > that they are considering MAP. Now Comcast were also one the larger 6RD > deployments. Why the switch? Because those technologies do not solve the > same problem. > > No, comcast never did a production deployment of 6RD. I was on their beta 6RD many moons ago. Not good. > 6RD is a short term technology fix to get some IPv6 out to the customers > quickly in a network that is otherwise pure IPv4. > > MAP is a long term solution to deliver some IPv4 in a world where IPv4 is > deprecated and IPv6 is the main protocol. It is meant to deployed in a > network that is otherwise pure IPv6, the exact opposite to 6RD. > > The two other technologies mentioned do the same as MAP more or less, but > both requires carrier NAT, which is expensive for the ISP and has a lack of > control as seen from the end user point of view (no port forwarding etc). > > I for one is going to continue to demand that my vendors implement MAP, so > I do not have to pay for a carrier NAT solution that always is going to be > in need of upgrade, will be under DDoS attack every tuesday and just > plainly is not a necessary element in the network. MAP on the other hand is > stateless and it is very simple to tack on an encapsulating header. Any > router that can do GRE should also be able to do MAP. > > Regards, > > Baldur > I look forward to your deployment report. Sometimes folks underestimate the complexity of the dhcpv6 coordination to assign ports (state) or overstate the IPv4 efficiency in MAP, but i am sure you have that figured out and accounted. My point , which i believe is a statement of fact, is that there are MAP fans, and no deployments at scale to demonstrate real world success. I am sure that will change, someone will deploy MAP at scale CB
Re: IPv6 deployment excuses
On 2016-07-04 20:50, Ca By wrote: Always so funny how people love talking how great MAP scales, yet it has never been deployed at scale. 464XLAT and ds-lite have been deployed at real scale, so has 6RD. MAP is like beta max. Technically great, but reality is poor. The two MAP RFCs are dated July 2015 just one year old. The world does not move that fast and especially not "large deployments". 6RD is dated August 2010 DS-LITE is dated August 2011 464XLAT is dated April 2013 Someone from Comcast just said at the recent RIPE conference in Copenhagen that they are considering MAP. Now Comcast were also one the larger 6RD deployments. Why the switch? Because those technologies do not solve the same problem. 6RD is a short term technology fix to get some IPv6 out to the customers quickly in a network that is otherwise pure IPv4. MAP is a long term solution to deliver some IPv4 in a world where IPv4 is deprecated and IPv6 is the main protocol. It is meant to deployed in a network that is otherwise pure IPv6, the exact opposite to 6RD. The two other technologies mentioned do the same as MAP more or less, but both requires carrier NAT, which is expensive for the ISP and has a lack of control as seen from the end user point of view (no port forwarding etc). I for one is going to continue to demand that my vendors implement MAP, so I do not have to pay for a carrier NAT solution that always is going to be in need of upgrade, will be under DDoS attack every tuesday and just plainly is not a necessary element in the network. MAP on the other hand is stateless and it is very simple to tack on an encapsulating header. Any router that can do GRE should also be able to do MAP. Regards, Baldur
Re: IPv6 deployment excuses
On 4/Jul/16 18:28, Matt Hoppes wrote: > Except the lady will eventually downsize. The college student will want more > and lease the space. > > Also, the 49,000 Sq ft office space that has been leased for 10 years and > never occupied will be taken back and released to someone who will actually > develop it. Can we trade worlds :-)? Mark.
Re: IPv6 deployment excuses
On 4/Jul/16 16:33, Matt Hoppes wrote: > Except that IPv4 is not exhausted. That's the doomsday message that was > preached over and over. > > The simple fact that there is/are IP broker exchanges now simply proves there > are surplus IPs to go around. > > We have an efficiency utilization issue - not an exhaustion issue. As a global Internet community, which is easier to do? Going around looking for inefficiencies in holders' allocations, or getting on with the job of deploying IPv6? Mark.
Re: IPv6 deployment excuses
On 4/Jul/16 14:44, Matt Hoppes wrote: > I disagree. Any data center or hosting provider is going to continue to offer > IPv4 lest they island themselves from subscribers who have IPv4 only - which > no data center is going to do. But that's what I said... Mark.
Re: New ICANN registrant change process
Seems to me that the proper thing to be done would have been for Registries to deauthorize registrars on the grounds of continuous streams of complaints. On July 4, 2016 2:35:37 PM EDT, Mel Beckman wrote: >I've worked behind the scenes for more than one of these outfits. I can >tell you that domain registrars are basically printing money. On the >other hand, I've also been the victim of domain hijacking. I can tell >you that the domain registrars involved were less than useless in >reversing the obviously fraudulent transactions. They basically said >"Not our problem. Deal with it." > >That's on top of the other obviously unethical practices by registrars, >such as seizing nonexistent domain names following a prospective >buyer's whois search, sluggardly unlocking of domains, etc. > >Something had to be done. Now it has been. > >To the registers whining about this change: > > Not my problem. Deal with it. > > -mel beckman > >> On Jul 4, 2016, at 10:55 AM, Jay R. Ashworth wrote: >> >> I'll go ahead and assume I wasn't the last person to get this memo >(courtesy >> Lauren Weinstein's PRIVACY Digest): >> >> >https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/ >> >> It does seem that this is going to make life difficult for a bunch of >pretty >> normal business processes. >> >> If you didn't know about it either... ask yourself why not. >> >> Cheers, >> -- jra >> >> -- >> Jay R. Ashworth Baylink >j...@baylink.com >> Designer The Things I Think >RFC 2100 >> Ashworth & Associates http://www.bcp38.info 2000 Land >Rover DII >> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 >647 1274 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
IPv6 deployment excuses
On Monday, July 4, 2016, Baldur Norddahl > wrote: > On 4 July 2016 at 11:41, Masataka Ohta > wrote: > > > With end to end NAT, you can still configure your UPnP capable NAT > > boxes to restrict port forwarding. > > > > Only if you by NAT mean "home network NAT". No large ISP has or will deploy > a carrier NAT router that will respect UPnP. That does not scale and is a > security nightmare besides. > > We could deploy MAP > https://en.wikipedia.org/wiki/Mapping_of_Address_and_Port (which scales) > and the user could then use the belowed "end to end NAT" method on that. > But why would they? MAP requires IPv6 so they already have end to end > transparency using IPv6. > > Regards, > > Baldur > Always so funny how people love talking how great MAP scales, yet it has never been deployed at scale. 464XLAT and ds-lite have been deployed at real scale, so has 6RD. MAP is like beta max. Technically great, but reality is poor.
Re: New ICANN registrant change process
On Mon, Jul 4, 2016 at 2:54 PM, Jay R. Ashworth wrote: > I'll go ahead and assume I wasn't the last person to get this memo > (courtesy > Lauren Weinstein's PRIVACY Digest): > > > https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/ > > It does seem that this is going to make life difficult for a bunch of > pretty > normal business processes. > > If you didn't know about it either... ask yourself why not. > Although I'm not a member of the WG that defined such policy, having seen the many occasions where domain hijacks occurred, I'm totally fine with the outcome. I only see real impact for "wholesale" registrars, like OpenSRS, eNom and Endurance, since they have to figure out a way to be compliant with policy without actually having contact with the registrants, and this kind of problem will continue to haunt them as they just operate a way for companies to operate in the gTLD market outside of its framework. Rubens
Re: New ICANN registrant change process
I've worked behind the scenes for more than one of these outfits. I can tell you that domain registrars are basically printing money. On the other hand, I've also been the victim of domain hijacking. I can tell you that the domain registrars involved were less than useless in reversing the obviously fraudulent transactions. They basically said "Not our problem. Deal with it." That's on top of the other obviously unethical practices by registrars, such as seizing nonexistent domain names following a prospective buyer's whois search, sluggardly unlocking of domains, etc. Something had to be done. Now it has been. To the registers whining about this change: Not my problem. Deal with it. -mel beckman > On Jul 4, 2016, at 10:55 AM, Jay R. Ashworth wrote: > > I'll go ahead and assume I wasn't the last person to get this memo (courtesy > Lauren Weinstein's PRIVACY Digest): > > https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/ > > It does seem that this is going to make life difficult for a bunch of pretty > normal business processes. > > If you didn't know about it either... ask yourself why not. > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: IPv6 deployment excuses
On 4 July 2016 at 11:41, Masataka Ohta wrote: > With end to end NAT, you can still configure your UPnP capable NAT > boxes to restrict port forwarding. > Only if you by NAT mean "home network NAT". No large ISP has or will deploy a carrier NAT router that will respect UPnP. That does not scale and is a security nightmare besides. We could deploy MAP https://en.wikipedia.org/wiki/Mapping_of_Address_and_Port (which scales) and the user could then use the belowed "end to end NAT" method on that. But why would they? MAP requires IPv6 so they already have end to end transparency using IPv6. Regards, Baldur
New ICANN registrant change process
I'll go ahead and assume I wasn't the last person to get this memo (courtesy Lauren Weinstein's PRIVACY Digest): https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/ It does seem that this is going to make life difficult for a bunch of pretty normal business processes. If you didn't know about it either... ask yourself why not. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: IPv6 deployment excuses - IPv6 only resources
On Mon, Jul 4, 2016 at 11:55 AM, Jacques Latour wrote: > > Is there a list of IPv6 only ISP or services? I'd be curious to trend > that somehow, by geography, service type, etc... if any. > Since "IPv6 only" right now is primarily about those portions of the network that are under a single organization's control, the rest of us will only know about them, for the most part, from reports from those organizations. As such, I doubt there's a list, per se, though somebody may be collecting one. Off the top of my head, Facebook has reported moving to IPv6 only below their edge. T-Mobile's cellular data is IPv6 only for newer handset and will become fully IPv6-only when the older handsets age off. IPv4 Internet access is provided through some combination of NAT64/DNS64/464xlat. Comcast isn't (to the best of my knowledge) hasn't yet made any moves in that direction, but have presented on moving to IPv6 only offering IPv4 as a service on top of it. Starting this past June 1 (from what I've heard) Apple is requiring all apps submitted to their app store to support IPv6 only networks. The US Federal CIO is expanding IPv6 transition focus to government enterprise networks from the previous, more Internet-based focus. Again, those are just a handful of the large-scale efforts I've personally heard about. But those are all some pretty significant players on the Internet. And there are likely to be many more who aren't publicizing their efforts. Of course, I happen to mostly pay attention to activity in the US, so there's that selection bias in play as well. Scott
Re: IPv6 deployment excuses
Filip Hruska wrote: Without firewalls, internet is not very secure, regardless of protocol used. Irrelevant. The point of the Internet with end to end transparency is that if end users want to have the end to end transparency, they can have it. If they don't, they don't have to. Masataka Ohta On 07/04/2016 11:41 AM, Masataka Ohta wrote: Jared Mauch wrote: Actually they are not that great. Look at the DDoS mess that UPnP has created and problems for IoT (I call it Internet of trash, as most devices are poorly implemented without safety in mind) folks on all sides. Are you saying, without NAT or something like that to restrict reachable ports, the Internet, regardless of whether it is with IPv4 or IPv6, is not very secure? With end to end NAT, you can still configure your UPnP capable NAT boxes to restrict port forwarding. The fact that I go to a hotel and that AT&T mobility have limited internet reach is a technology problem that we all must work to fix. Want to run a server at the hotel? IP mobility helps you, if you have a home agent at your home and you can use IP over UDP/TCP over IP as mobility tunnel. Masataka Ohta Jared Mauch On Jul 1, 2016, at 11:49 PM, Masataka Ohta wrote: And, to applications running over TCP/UDP, UPnP capable legacy NATs are transparent, if host TCP/UDP are modified to perform reverse NAT, information to do so is provided by UPnP.
RE: IPv6 deployment excuses - IPv6 only resources
Is there a list of IPv6 only ISP or services? I'd be curious to trend that somehow, by geography, service type, etc... if any. >-Original Message- >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Andrews >Sent: July-04-16 9:49 AM >To: Matt Hoppes >Cc: Tore Anderson; nanog@nanog.org >Subject: Re: IPv6 deployment excuses > > >In message c2ae05bcc...@rivervalleyinternet.net>, Matt Hoppes writes: >> I disagree. Any data center or hosting provider is going to continue >> to offer IPv4 lest they island themselves from subscribers who have >> IPv4 only - which no data center is going to do. >> >> One can not run IPv6 only because there are sites that are only IPv4. >> >> Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be >> going away for at least ten years or more - if ever. >> >> I'm not saying don't be ready for IPv6. I'm not saying don't >> understand how it works. But doomsday isn't here. > >There are ISP's that are essentially IPv6 only today as they do not have enough >IPv4 addresses to give all their customers a public >IPv4 address. > >Once you need to run a GGN you may as well run DS-Lite, MAP* or >(shudder) DNS64/NAT64 as NAT444. There is no need to talk IPv4 to your >customers today. You still need a small number of IPv4 address to talk to >legacy IPv4 servers on the internet. Just because there owners don't know they >are legacy servers doesn't mean they aren't. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 deployment excuses
On Mon, Jul 4, 2016 at 11:28 AM, Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: > Except the lady will eventually downsize. The college student will want > more and lease the space. > > Also, the 49,000 Sq ft office space that has been leased for 10 years and > never occupied will be taken back and released to someone who will actually > develop it. > I'm not particularly fond of metaphors using physical resources like land because physical changes do tend to happen slowly and carry substantial inertia. As a result such metaphors break down pretty quickly. Internet numbers are an abstraction with no physical component. As such, their utility depends on how all the different players on the Internet behave. Given that, it becomes a classic game theory problem. It makes little practical difference if there are "enough" IPv4 numbers theoretically available to serve the demand if only better allocated or not. I agree with those who believe there aren't given the demands on the infrastructure and the rate of growth, but that's largely irrelevant. Even if there theoretically were 'enough' legacy numbers to fit some definition of 'enough', do you actually believe the many and varied players on the Internet will converge on that optimal utilization? I certainly don't. Nor is that the behavior we're seeing. We see players who have 'more than enough' by some theoretical optimum utilization scheme conserving the resources they have for transition. We see large players, who have the most influence on the direction software and hardware makers move, somewhere in transition to IPv6. Some are very advanced in their deployment, others are earlier in it, but pretty much all of them are moving in that direction. Given that reality and the way the Internet works, at some point in the not too distant future we're more likely to see the Internet tip toward IPv6 than not. Nothing's certain, but that seems to be where the game is headed. Once that happens, those caught behind the curve are more likely to suffer loss than not. The safe bet is to be prepared beforehand, especially since it's neither particularly difficult nor expensive to deploy IPv6. It's a comparatively low cost hedge. Of course, as more people hedge their bets that way, the likelihood that IPv6 will also turn out to be the 'winning' bet increases, so it starts to become a self-fulfilling prophecy. But some people prefer risky bets. It's not clear to me what you actually gain if you bet the farm on IPv4 and its utility remains more or less the same for a decade. Any cost-savings over deploying IPv6 are likely going to be more than consumed in renumbering efforts, purchasing IPv4 number resources, and deploying/administering CGN equipment. So it actually looks like a lose/lose scenario to me. But if you see some hypothetical advantage you wish to pursue, go for it. But if that hypothetical advantage depends on getting everyone on the Internet to play along with your scheme for optimal IPv4 number utilization? Well, good luck with that one. Scott
Re: IPv6 deployment excuses
On Mon 2016-Jul-04 12:42:33 -0400, Christopher Morrow wrote: On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: Except the lady will eventually downsize. The college student will want more and lease the space. Also, the 49,000 Sq ft office space that has been leased for 10 years and never occupied will be taken back and released to someone who will actually develop it. and as has been covered numerous times here and other places the lifetime of a /8 in the global pool is ~1month. so.. you bought essentially nothing. The math that matters is: 7b people - 3b ips == 4b lost connections. ...and even that is generous as it assumes 1 device per person and strictly peer-to-peer traffic with no servers or even any addresses on routers and their interfaces. Reference to NAT as a saviour in 3...2...1... -- Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com pgp key: B178313E | also on Signal signature.asc Description: Digital signature
Re: IPv6 deployment excuses
On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: > Except the lady will eventually downsize. The college student will want > more and lease the space. > > Also, the 49,000 Sq ft office space that has been leased for 10 years and > never occupied will be taken back and released to someone who will actually > develop it. > and as has been covered numerous times here and other places the lifetime of a /8 in the global pool is ~1month. so.. you bought essentially nothing. The math that matters is: 7b people - 3b ips == 4b lost connections.
Re: IPv6 deployment excuses
Except the lady will eventually downsize. The college student will want more and lease the space. Also, the 49,000 Sq ft office space that has been leased for 10 years and never occupied will be taken back and released to someone who will actually develop it. > On Jul 4, 2016, at 11:58, Mikael Abrahamsson wrote: > >> On Mon, 4 Jul 2016, Matt Hoppes wrote: >> >> My point is there are more than enough IPv4 addresses. The issue is not >> resources. It is hoarding and inappropriate use. > > I tend to make the analogy of land use and/or houses/apartments. Yes, there > is that old lady down the street who lives in 300 square meters (~3000 sq > feet for those who are !metric), and then there is the student who shares a > 30sq meter studio with another student. > > Now what? Yes, this is not fair and it's inefficient utilization of > resources, but how are you going to rectify this? Forcibly take away the > apartment from the old lady and tell her to go live somewhere else just > because it isn't fair that she has 10 times the apartment size as the student? > > IPv6 is the answer, because it doesn't have shortcoming when it comes to > available "land". Everybody can get plenty. No need to try to take away > resources from someone holding them (legitimately) as per the rules of > yestercentury.
Re: IPv6 deployment excuses
On Mon, 4 Jul 2016, Matt Hoppes wrote: My point is there are more than enough IPv4 addresses. The issue is not resources. It is hoarding and inappropriate use. I tend to make the analogy of land use and/or houses/apartments. Yes, there is that old lady down the street who lives in 300 square meters (~3000 sq feet for those who are !metric), and then there is the student who shares a 30sq meter studio with another student. Now what? Yes, this is not fair and it's inefficient utilization of resources, but how are you going to rectify this? Forcibly take away the apartment from the old lady and tell her to go live somewhere else just because it isn't fair that she has 10 times the apartment size as the student? IPv6 is the answer, because it doesn't have shortcoming when it comes to available "land". Everybody can get plenty. No need to try to take away resources from someone holding them (legitimately) as per the rules of yestercentury.
Re: IPv6 deployment excuses
On 4 July 2016 at 17:33, Matt Hoppes wrote: > The simple fact that there is/are IP broker exchanges now simply proves there > are surplus IPs to go around. I'm unsure of the message. Is the statement that if commodity is tradable, there is surplus to go around? Is converse true? If I can't buy it, there is no surplus? I don't think either statement is correct. Lot of things exist in exactly 1 copy, and there is market for them, so market does not imply 'surplus to go around'. And lack of market does not imply 'surplus to go around', merely lack of demand. Yes, US has more IP addresses allocated to them than there are people, several times over. This is not true for earth. We need more addresses, IPv4 addresses are scarce. Just because I can throw money at the problem, does not mean problem does not exist. I am privileged, but people shouldn't need to have my privileges to have access to Internet. -- ++ytti
Re: IPv6 deployment excuses
Except that IPv4 is not exhausted. That's the doomsday message that was preached over and over. The simple fact that there is/are IP broker exchanges now simply proves there are surplus IPs to go around. We have an efficiency utilization issue - not an exhaustion issue.
Re: IPv6 deployment excuses
There are 7 billion people world wide that want Internet and only approximately 3 billion usable IPv4 addresses. It wont do. Den 4. jul. 2016 16.03 skrev "Matt Hoppes" < mattli...@rivervalleyinternet.net>: > My point is there are more than enough IPv4 addresses. The issue is not > resources. It is hoarding and inappropriate use. > > The large ISPs have enough IPs to service every household in the US > several times over. And yet, we have an IP shortage. > > There are universities holding onto /8s and not using them. > > IPv6 just feels like a knee jerk reaction.
Re: IPv6 deployment excuses
On Mon, Jul 4, 2016 at 7:44 AM, Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: > I disagree. Any data center or hosting provider is going to continue to > offer IPv4 lest they island themselves from subscribers who have IPv4 only > - which no data center is going to do. > > Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be going > away for at least ten years or more - if ever. > That's an interesting "bet the business" decision for an ISP to make. It's not one a large ISP can make simply because they want to continue growing their subscriber base and that's a losing proposition as far as profits go. That's why all the big ISPs are either implementing IPv6 or actively working to deploy it. So it seems you're saying that a small to medium sized ISP can delay 10 or more years because all the content their customers want will be available over IPv4. And that's pretty much betting the entire business on what is basically nothing more than a crystal ball. I don't know about you, but I think back to the mid to late 80s and most ideas I saw about where technology would be by the mid to late 90s were pretty inaccurate. Jump to the mid 2000s and past projections were pretty off-base again. Shortly after that, mobile computing really hit and the world today looks very little like it did then. Do you really think someone should bet their entire business on your ability to make Internet forecasts 10 years into the future? Now, that's not to say I expect IPv4 to necessarily be mostly gone (from the Internet, not private networks) in 10 years, though it wouldn't particularly shock me either if things did work out that way. But I do expect a tipping point will be reached well before then that reduces the utility of IPv4. Technology changes on the Internet have not traditionally been steady, gradual processes. Rather, they've had some sort of fairly long lead time, a rapid spike of uptake, and then a flip from a 'new' technology to something expected. There's then often something of a long tail, but it can be pretty unpleasant to be forced to exist in that tail. The attitude quickly switches to one of, "Oh, you're still using 'x'? You should use 'y' instead. It's working fine." And issues with 'x' get lower priority attention. And that 'flip', when it happens, tends to happy relatively quickly. Often, it can be difficult to predict if a new technology will overtake and supplant an older one. The IPv6 transition, however, is being forced by IPv4 exhaustion. That's putting a lot of technological and financial pressure on most of the parties involved. As someone who works at an enterprise that sees a lot of traffic, primarily from the US, we were seeing a steady increase in IPv6 traffic from end users from practically nothing in 2012 to around 15% in 2015. This year we've seen it spike to 25%-30%. So in the US, we may very well reach that tipping point within the next couple of years. If we do, the utility of IPv4 will probably start to degrade pretty rapidly as more attention and focus is placed on IPv6 connectivity. If that happens and you're still an IPv4 only edge/access network that hasn't even begun planning an IPv6 deployment? That's apt to be an uncomfortable experience. But again, I'm not a prognosticator. I wouldn't have correctly guessed the timing for any of the transitions I've seen in the past, though I did sometimes come close to guessing the outcome. (That's one of the reasons I started a small scale production deployment of Linux at my place of employment back in the mid-90s, something we now have running on platforms all the way up to our mainframes.) It looks to me like, in the US at least, we're on the 'rapid uptake' slope of adoption. If that's the case, then that tipping point is probably coming a lot sooner than 10 years out. You could be right and everything will be fine for IPv4-only customers and networks in 10 years. But that is most definitely a high stakes bet to make. I certainly wouldn't be willing to make such a gamble. I also want to note that enterprise or data center networks moving to IPv6 only does not necessarily involve NAT64 or any sort of translation. For any large internet service, inbound connections are typically terminated at the edge. A new connection is then established from the point of termination to the data center resources. So Facebook, for instance, only needs to dual-stack its edge. And if you use a 3rd part CDN for the edge, you don't even have to do that. That's what other posters were pointing out. Depending on its security profile, a large enterprise network might also 'proxy' outbound Internet traffic (primarily web, mail, DNS) already for its internal users. If that's the case (as it is where I work) very little outbound translation is required as well and only the outbound perimeter services need to be dual-stacked long-term. So if an enterprise or data center network operator isn't already thinking in terms of where they can go IPv6
Re: IPv6 deployment excuses
My point is there are more than enough IPv4 addresses. The issue is not resources. It is hoarding and inappropriate use. The large ISPs have enough IPs to service every household in the US several times over. And yet, we have an IP shortage. There are universities holding onto /8s and not using them. IPv6 just feels like a knee jerk reaction.
Re: IPv6 deployment excuses
In message , Matt Hoppes writes: > I disagree. Any data center or hosting provider is going to continue to > offer IPv4 lest they island themselves from subscribers who have IPv4 > only - which no data center is going to do. > > One can not run IPv6 only because there are sites that are only IPv4. > > Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be going > away for at least ten years or more - if ever. > > I'm not saying don't be ready for IPv6. I'm not saying don't understand > how it works. But doomsday isn't here. There are ISP's that are essentially IPv6 only today as they do not have enough IPv4 addresses to give all their customers a public IPv4 address. Once you need to run a GGN you may as well run DS-Lite, MAP* or (shudder) DNS64/NAT64 as NAT444. There is no need to talk IPv4 to your customers today. You still need a small number of IPv4 address to talk to legacy IPv4 servers on the internet. Just because there owners don't know they are legacy servers doesn't mean they aren't. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 deployment excuses
I disagree. Any data center or hosting provider is going to continue to offer IPv4 lest they island themselves from subscribers who have IPv4 only - which no data center is going to do. One can not run IPv6 only because there are sites that are only IPv4. Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be going away for at least ten years or more - if ever. I'm not saying don't be ready for IPv6. I'm not saying don't understand how it works. But doomsday isn't here. > On Jul 4, 2016, at 04:01, Mark Tinka wrote: > > > >> On 3/Jul/16 15:34, Tore Anderson wrote: >> >> We've found that it is. IPv6-only greatly reduces complexity compared to >> dual stack. This means higher reliability, lower OpEx, shorter recovery >> time when something does go wrong anyway, fewer SLA violations, happier >> customers, and so on - the list goes on and on. Single stack is >> essentially the KISS option. > > What I was trying to get to is that, yes, running a single-stack is > cheaper (depending on what "cheaper" means to you) than running dual-stack. > > That said, running IPv4-only means you put yourself at a disadvantage as > IPv6 is now where the world is going. > > Similarly, running IPv6-only means you still need to support access to > the IPv4-only Internet anyway, if you want to have paying customers or > happy users. > > So the bottom line is that for better or worse, any progressive network > in 2016 is going to have to run dual-stack in some form or other for the > foreseeable future. So the argument on whether it is cheaper or more > costly to run single- or dual-stack does not change that fact if you are > interested in remaining a going concern. > > Mark.
Looking for a Seabone / Telecom Italia Sparkle rep
Hi guys, Does anyone have any good Seabone / Telecom Italia Sparkle representatives whose contacts they don't mind passing along? Looking for service in Asia, particularly Singapore and Hong Kong markets. Having absolutely no luck with the standard sales channels, no one has gotten back to us. We've been trying for a while. Thanks in advance!
Re: IPv6 deployment excuses
Without firewalls, internet is not very secure, regardless of protocol used. On 07/04/2016 11:41 AM, Masataka Ohta wrote: > Jared Mauch wrote: > >> Actually they are not that great. Look at the DDoS mess that UPnP has >> created and problems for IoT (I call it Internet of trash, as most >> devices are poorly implemented without safety in mind) folks on all >> sides. > > Are you saying, without NAT or something like that to restrict > reachable ports, the Internet, regardless of whether it is with > IPv4 or IPv6, is not very secure? > > With end to end NAT, you can still configure your UPnP capable NAT > boxes to restrict port forwarding. > >> The fact that I go to a hotel and that AT&T mobility have limited >> internet reach is a technology problem that we all must work to fix. > > Want to run a server at the hotel? > > IP mobility helps you, if you have a home agent at your home and > you can use IP over UDP/TCP over IP as mobility tunnel. > > Masataka Ohta >> >> >> Jared Mauch >> >>> On Jul 1, 2016, at 11:49 PM, Masataka Ohta >>> wrote: >>> >>> And, to applications running over TCP/UDP, UPnP capable legacy NATs >>> are transparent, if host TCP/UDP are modified to perform reverse >>> NAT, information to do so is provided by UPnP. >> >> >> >
Re: IPv6 deployment excuses
Jared Mauch wrote: Actually they are not that great. Look at the DDoS mess that UPnP has created and problems for IoT (I call it Internet of trash, as most devices are poorly implemented without safety in mind) folks on all sides. Are you saying, without NAT or something like that to restrict reachable ports, the Internet, regardless of whether it is with IPv4 or IPv6, is not very secure? With end to end NAT, you can still configure your UPnP capable NAT boxes to restrict port forwarding. The fact that I go to a hotel and that AT&T mobility have limited internet reach is a technology problem that we all must work to fix. Want to run a server at the hotel? IP mobility helps you, if you have a home agent at your home and you can use IP over UDP/TCP over IP as mobility tunnel. Masataka Ohta Jared Mauch On Jul 1, 2016, at 11:49 PM, Masataka Ohta wrote: And, to applications running over TCP/UDP, UPnP capable legacy NATs are transparent, if host TCP/UDP are modified to perform reverse NAT, information to do so is provided by UPnP.
Re: IPv6 deployment excuses
On 4/Jul/16 11:04, Tore Anderson wrote: > My point is that as a content provider, I only need dual-stacked > façade. That can easily be achieved using, e.g., protocol translation > at the outer border of my network. > > The inside of my network, where 99.99% of all the complexity, devices, > applications and so on reside, can be single stack IPv6-only today. > > Thus I get all the benefits of running a single stack network, minus a > some fraction of a percent needed to operate the translation system. > (I could in theory get rid of that too by outsourcing it somewhere.) The NAT64 translation still requires a dual-stack deployment. Of course, it is a smaller % of your overall single-stack IPv6 network, but still there nonetheless. The advantage with NAT64, as you say, is that it easier to rip it out when the IPv4 Internet dies a happy death, than it would be if one were keeping IPv4 primary and sticking IPv6 duct tape on top. Mark.
Re: IPv6 deployment excuses
* Mark Tinka > What I was trying to get to is that, yes, running a single-stack is > cheaper (depending on what "cheaper" means to you) than running > dual-stack. Wholeheartedly agreed. > That said, running IPv4-only means you put yourself at a disadvantage > as IPv6 is now where the world is going. Also wholeheartedly agreed. > Similarly, running IPv6-only means you still need to support access to > the IPv4-only Internet anyway, if you want to have paying customers or > happy users. > > So the bottom line is that for better or worse, any progressive > network in 2016 is going to have to run dual-stack in some form or > other for the foreseeable future. So the argument on whether it is > cheaper or more costly to run single- or dual-stack does not change > that fact if you are interested in remaining a going concern. My point is that as a content provider, I only need dual-stacked façade. That can easily be achieved using, e.g., protocol translation at the outer border of my network. The inside of my network, where 99.99% of all the complexity, devices, applications and so on reside, can be single stack IPv6-only today. Thus I get all the benefits of running a single stack network, minus a some fraction of a percent needed to operate the translation system. (I could in theory get rid of that too by outsourcing it somewhere.) Tore
Re: IPv6 deployment excuses
On 3/Jul/16 15:34, Tore Anderson wrote: > We've found that it is. IPv6-only greatly reduces complexity compared to > dual stack. This means higher reliability, lower OpEx, shorter recovery > time when something does go wrong anyway, fewer SLA violations, happier > customers, and so on - the list goes on and on. Single stack is > essentially the KISS option. What I was trying to get to is that, yes, running a single-stack is cheaper (depending on what "cheaper" means to you) than running dual-stack. That said, running IPv4-only means you put yourself at a disadvantage as IPv6 is now where the world is going. Similarly, running IPv6-only means you still need to support access to the IPv4-only Internet anyway, if you want to have paying customers or happy users. So the bottom line is that for better or worse, any progressive network in 2016 is going to have to run dual-stack in some form or other for the foreseeable future. So the argument on whether it is cheaper or more costly to run single- or dual-stack does not change that fact if you are interested in remaining a going concern. Mark.
