IPv6 deployment excuses
Hi, I am in contact with a couple of network operators trying to prod them to deploy IPv6, I figured that 10 minutes to send a couple of emails was worth the effort to make them "see a customer demand" (now none of them can use the excuse that nobody has asked for it!), but the replies I got were less than impressive to say the least. I was wondering if you guys could summarise your experiences with people who make excuses for not deploying IPv6? I regularly see a specific person saying "we can't deploy it because X" followed by you guys "correcting them" and telling them how to deploy it without the problems they claim they will have, but that is only a small snapshot of the people who bother to post about their ignorance in public. I suspect there is also a lot of selection-bias in the NANOG membership base but you deal with a lot of enterprise networks off of this list so probably have broader experience than the NANOG archives. Can we have a thread summarising the most common excuses you've heard, and if they are actual problems blocking IPv6 deployment or just down to ignorance? Perhaps this could be the basis for an FAQ type page that I can point people to when they say they don't know how to deploy IPv6 on their networks? :) - Mike Jones
On Fri, 1 Jul 2016, Mike Jones wrote:
Hi,
I am in contact with a couple of network operators trying to prod them to deploy IPv6, I figured that 10 minutes to send a couple of emails was worth the effort to make them "see a customer demand" (now none of them can use the excuse that nobody has asked for it!), but the replies I got were less than impressive to say the least.
When I talked to one European residential cable provider ca. 2008 they used a similar argument. Fast forward to 2016 and IPv6 (and dual stack lite) is *the* way they provide Internet access those days. The reason is simple: their growth rate is way too high to provide IPv4 to everyone at this point. If the provider is still using the "see a customer demand" argument this could mean their IPv4 demand may not be growing fast enough. Depending on the market they operate on this an be an indication that their market growth rate may not be fast enough. Maybe their customer demand for IP(v4) leaves something to be desired? Or they sit on some almost empty /8s. Marcin
---- From: Mike Jones <mike@mikejones.in> -- Sent: 2016-07-01 - 12:52 ----
Hi,
I am in contact with a couple of network operators trying to prod them to deploy IPv6, I figured that 10 minutes to send a couple of emails was worth the effort to make them "see a customer demand" (now none of them can use the excuse that nobody has asked for it!), but the replies I got were less than impressive to say the least.
I was wondering if you guys could summarise your experiences with people who make excuses for not deploying IPv6?
http://ipv6excuses.com/ https://twitter.com/ipv6excuses
- Mike Jones
-- Hugo
https://youtu.be/v26BAlfWBm8 Is always good for a reminder and laughs on a holiday weekend. Jared Mauch
On Jul 1, 2016, at 5:00 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
Jared Mauch wrote:
Is always good for a reminder and laughs on a holiday weekend.
But, end to end NATs are actually good: https://tools.ietf.org/html/draft-ohta-e2e-nat-00 fully transparent to all the transport and application layer protocols. 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. Masataka Ohta
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. 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. Jared Mauch
On Jul 1, 2016, at 11:49 PM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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.
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 <mohta@necom830.hpcl.titech.ac.jp> 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.
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 <mohta@necom830.hpcl.titech.ac.jp> 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.
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 <mohta@necom830.hpcl.titech.ac.jp> 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.
On 4 July 2016 at 11:41, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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
On Monday, July 4, 2016, Baldur Norddahl <baldur.norddahl@gmail.com <javascript:_e(%7B%7D,'cvml','baldur.norddahl@gmail.com');>> wrote:
On 4 July 2016 at 11:41, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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.
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
On Monday, July 4, 2016, Baldur Norddahl <baldur.norddahl@gmail.com> 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
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 Abrahamsson email: swmike@swm.pp.se
On 5 July 2016 at 07:27, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
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.
We will tell you to use IPv6 for that or make you pay extra for a dedicated IPv4 address. Everyone else do not need to help pay for a CGN solution just because you did not move ahead with IPv6. To clarify, right now at this moment we are pure dual stack with everyone have both their own IPv4 and a /48 IPv6 prefix. But I can see some time in the not too distant future where there will be market acceptance of a solution with crippled IPv4 MAP style NAT plus full connectivity using IPv6. In fact I believe we are already there as most people really do not care as long their gmail and Facebook works. The only thing that stops me from deploying MAP is lack of vendor support. I am working on that. Regards, Baldur
On Tue, 5 Jul 2016, Baldur Norddahl wrote:
We will tell you to use IPv6 for that or make you pay extra for a dedicated IPv4 address.
That is a good solution to that problem. I hope all ISPs implementing A+P protocols does that. It also puts a monthly cost that teleworkers have to pay (or their employers have to pay) for not supporting IPv6 on their enterprise solutions. Hopefully that'll drive IPv6 interest in the enterprise space as well. -- Mikael Abrahamsson email: swmike@swm.pp.se
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
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 | sryan@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 < mohta@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
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.
Valdis.Kletnieks@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
Are you saying that functional game consoles aren't your problem? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> To: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu> Cc: nanog@nanog.org Sent: Monday, July 4, 2016 11:22:59 PM Subject: Re: IPv6 deployment excuses Valdis.Kletnieks@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
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 jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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.
On Jul 4, 2016, at 10:32 PM, Matt Hoppes <mattlists@rivervalleyinternet.net> 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:xxxx -> 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
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
On Fri Jul 1 17:43:21 2016, Gary Wardell wrote:
That website only supports IPv4.
It’s on your side. alarig@pikachu ~ % telnet ipv6excuses.com http Trying 2403:7000:8000:500::26... Connected to ipv6excuses.com. Escape character is '^]'. ^] telnet> quit Connection closed. -- alarig
---- From: Alarig Le Lay <alarig@swordarmor.fr> -- Sent: 2016-07-01 - 14:53 ----
On Fri Jul 1 17:43:21 2016, Gary Wardell wrote:
That website only supports IPv4.
It’s on your side.
alarig@pikachu ~ % telnet ipv6excuses.com http Trying 2403:7000:8000:500::26... Connected to ipv6excuses.com. Escape character is '^]'. ^] telnet> quit Connection closed.
-- alarig
twitter.com, OTOH... -- Hugo
Ok, I didn't dig. Evidently it's because not all of the content could be delivered over v6.
-----Original Message-----
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Alarig Le
Lay
Sent: Friday, July 01, 2016 5:53 PM
To: nanog@nanog.org
Subject: Re: IPv6 deployment excuses
On Fri Jul 1 17:43:21 2016, Gary Wardell wrote:
That website only supports IPv4.
It’s on your side.
alarig@pikachu ~ % telnet ipv6excuses.com http Trying
2403:7000:8000:500::26...
Connected to ipv6excuses.com.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
--
alarig
Thanks guys, this is what I have come up with so far. Next week i'll put together a web page or something with slightly better write-ups, but these are my initial ideas for responses to each point. Better answers would be welcome. "We have NAT, therefore we don't need IPv6." "We still have plenty of IPv4 addresses" "IPv4 works so we don't need IPv6." They said similar things about IPX, DECNET, Appletalk........ but they eventually realised it was easier to move to IP than to keep making excuses for why their network can't connect to anything. "we want NAT for IPv6 for security reasons" NAT does not provide any security, typically a NAT will also include a stateful firewall which provides the security. You can deploy a stateful firewall for your IPv6 network if you like, however it isn't required as much as you probably think it is - see below. "IPv6 is just another way for hackers to get in." There is no difference between IPv4 and IPv6 when it comes to firewalls and reachability. It is worth noting that hosts which support IPv6 are typically a lot more secure than older IPv4-only hosts. As an example every version of Windows that ships with IPv6 support also ships with the firewall turned on by default. "End users don't care about IPv6" Are you saying this in response to someone asking for IPv6? because that would be contradictory. I am an end user and I care about IPv6! "But it isn't a priority and we have other stuff to do" Reconfiguring every router on your network is not something you want to rush when you realise you needed IPv6 yesterday, early adopters have the advantage that they can gain experience with running IPv6 and test their infrastructure without worrying about critical traffic being IPv6-only. "None of the software vendors support IPv6." If your software vendors were following best practices and writing decent code then this would not be a problem, I suggest pushing your vendors to fix their code. If you only have 1 of two systems that are IPv4-only then you can always "special case" them. See NAT64 for information about one way of reaching IPv4 hosts from an IPv6 network. If you dual stack then it doesn't matter and you can just use IPv4 for those few services than require it until you get a fix from the vendor. "None of our staff understand IPv6." Do your staff understand IPv4? because it's not that different... "IPv6 addresses are too long to remember" You shouldn't need to remember IP addresses, that's what DNS is for. However I will say that in my experience and many other peoples having the extra bits to structure your network in a logical fasion can make addresses more obvious and easier to remember. You have a single prefix to remember, then can address hosts within that subnet however you like. In IPv4 you rarely have the luxury of being able to number your DNS server 192.0.2.53 and your web server 192.0.2.80 to make them easier to remember, whereas in IPv6 you can easily assign hosts easy to remember addresses. "Having to dual stack means I still have to manage a 4 and 6 network." Good point, however if you want to ease your network management and run an IPv6-only network with IPv4-only services still reachable over the top of it then there are several ways to do it, the most obvious being NAT64. "Our DNS provider won't let us as add AAAA records" Seriously? who is your DNS provider? You need to ask them why they don't support standard record types. If they refuse to add standard records to your zone, get a new provider there are plenty out there. "We'll deploy IPv6 right after we finish deploying DNSSEC" The 2 are not mutually exclusive - at a large organisation where this sort of project would be major work, you probably have different teams dealing with IP and DNS so there's no reason one would stop the other. "But Android doesn't support stateful DHCPv6." I will admit that the specifications were written a little loosely so you have 2 ways of configuring hosts, however if you configure both RA and DHCP then you will cover 100% of IPv6-capible hosts. "Our legal intercept setup does not work with IPv6" If your lawful intercept equipment can't see traffic just because they used an "unknown" protocol then it has a major flaw! - Mike Jones
Issues I've faced in the past with v6 deployments, from the point of view of stub networks. Feel free to pick/choose as you wish: - Badly understood (By the team) methods to assign addressing to servers. - Poor tooling in regards to log processing/external providers. - Unknown cost in dev time to debug badly written applications (ie: cheaper to buy v4 space than assign dev time, which is inherently expensive) - PMTUD issues (Mostly around PTB handling) - ECMP issues (Mostly around flow labels and vendor support for that, also feeds back into PMTUD issues) - Cogent/HE "spat" causes legitimate concerns about reachability (ie: why should I buy an extra transit because someone else is playing silly buggers) - Lack of backbone forces stubs to de-aggregate to much annoyance (but 0 choice) of everyone else - Maintaining 2x IP stacks is inherently expensive Vs 1 Of course, you can say "v4 has these issues too" to some of these, and call bullshit on others. That's not the point, I'm just airing some issues that can be deal breakers. I would imagine that as v4 becomes more expensive, most of the list will no longer be an issue. /Ruairi On 2 July 2016 at 13:44, Mike Jones <mike@mikejones.in> wrote:
Thanks guys, this is what I have come up with so far. Next week i'll put together a web page or something with slightly better write-ups, but these are my initial ideas for responses to each point. Better answers would be welcome.
"We have NAT, therefore we don't need IPv6." "We still have plenty of IPv4 addresses" "IPv4 works so we don't need IPv6."
They said similar things about IPX, DECNET, Appletalk........ but they eventually realised it was easier to move to IP than to keep making excuses for why their network can't connect to anything.
"we want NAT for IPv6 for security reasons"
NAT does not provide any security, typically a NAT will also include a stateful firewall which provides the security. You can deploy a stateful firewall for your IPv6 network if you like, however it isn't required as much as you probably think it is - see below.
"IPv6 is just another way for hackers to get in."
There is no difference between IPv4 and IPv6 when it comes to firewalls and reachability. It is worth noting that hosts which support IPv6 are typically a lot more secure than older IPv4-only hosts. As an example every version of Windows that ships with IPv6 support also ships with the firewall turned on by default.
"End users don't care about IPv6"
Are you saying this in response to someone asking for IPv6? because that would be contradictory. I am an end user and I care about IPv6!
"But it isn't a priority and we have other stuff to do"
Reconfiguring every router on your network is not something you want to rush when you realise you needed IPv6 yesterday, early adopters have the advantage that they can gain experience with running IPv6 and test their infrastructure without worrying about critical traffic being IPv6-only.
"None of the software vendors support IPv6."
If your software vendors were following best practices and writing decent code then this would not be a problem, I suggest pushing your vendors to fix their code. If you only have 1 of two systems that are IPv4-only then you can always "special case" them. See NAT64 for information about one way of reaching IPv4 hosts from an IPv6 network. If you dual stack then it doesn't matter and you can just use IPv4 for those few services than require it until you get a fix from the vendor.
"None of our staff understand IPv6."
Do your staff understand IPv4? because it's not that different...
"IPv6 addresses are too long to remember"
You shouldn't need to remember IP addresses, that's what DNS is for. However I will say that in my experience and many other peoples having the extra bits to structure your network in a logical fasion can make addresses more obvious and easier to remember. You have a single prefix to remember, then can address hosts within that subnet however you like. In IPv4 you rarely have the luxury of being able to number your DNS server 192.0.2.53 and your web server 192.0.2.80 to make them easier to remember, whereas in IPv6 you can easily assign hosts easy to remember addresses.
"Having to dual stack means I still have to manage a 4 and 6 network."
Good point, however if you want to ease your network management and run an IPv6-only network with IPv4-only services still reachable over the top of it then there are several ways to do it, the most obvious being NAT64.
"Our DNS provider won't let us as add AAAA records"
Seriously? who is your DNS provider? You need to ask them why they don't support standard record types. If they refuse to add standard records to your zone, get a new provider there are plenty out there.
"We'll deploy IPv6 right after we finish deploying DNSSEC"
The 2 are not mutually exclusive - at a large organisation where this sort of project would be major work, you probably have different teams dealing with IP and DNS so there's no reason one would stop the other.
"But Android doesn't support stateful DHCPv6."
I will admit that the specifications were written a little loosely so you have 2 ways of configuring hosts, however if you configure both RA and DHCP then you will cover 100% of IPv6-capible hosts.
"Our legal intercept setup does not work with IPv6"
If your lawful intercept equipment can't see traffic just because they used an "unknown" protocol then it has a major flaw!
- Mike Jones
There's one other major issue faced by stub networks which I have encountered at $DAYJOB: - My upstream(s) refuse(s) to support IPv6 This *is* a deal breaker. The pat response of "get new upstreams" is not helpful and shows the distinct bias among this community to the large players who actually have budgets to work with. It's not always possible to change to a better upstream and even when it is, it is often prohibitively expensive. This is particularly the case with colocation where the cost of changing providers is huge as it requires physically relocating equipment. That either requires doubling up (very expensive) or non-trivial downtime (also likely very expensive). This is an especially sad state of affairs given that at least one very large network (AS701) has pulled this refusal at some data centres on their network. Their specific excuse du jour changes every few months but it usually boils down to "we don't want to put any effort or resources into updating anything". On 16-07-02 09:35 AM, Ruairi Carroll wrote:
Issues I've faced in the past with v6 deployments, from the point of view of stub networks. Feel free to pick/choose as you wish:
- Badly understood (By the team) methods to assign addressing to servers. - Poor tooling in regards to log processing/external providers. - Unknown cost in dev time to debug badly written applications (ie: cheaper to buy v4 space than assign dev time, which is inherently expensive) - PMTUD issues (Mostly around PTB handling) - ECMP issues (Mostly around flow labels and vendor support for that, also feeds back into PMTUD issues) - Cogent/HE "spat" causes legitimate concerns about reachability (ie: why should I buy an extra transit because someone else is playing silly buggers) - Lack of backbone forces stubs to de-aggregate to much annoyance (but 0 choice) of everyone else - Maintaining 2x IP stacks is inherently expensive Vs 1
Of course, you can say "v4 has these issues too" to some of these, and call bullshit on others. That's not the point, I'm just airing some issues that can be deal breakers.
I would imagine that as v4 becomes more expensive, most of the list will no longer be an issue.
/Ruairi
On 2 July 2016 at 13:44, Mike Jones <mike@mikejones.in> wrote:
Thanks guys, this is what I have come up with so far. Next week i'll put together a web page or something with slightly better write-ups, but these are my initial ideas for responses to each point. Better answers would be welcome.
"We have NAT, therefore we don't need IPv6." "We still have plenty of IPv4 addresses" "IPv4 works so we don't need IPv6."
They said similar things about IPX, DECNET, Appletalk........ but they eventually realised it was easier to move to IP than to keep making excuses for why their network can't connect to anything.
"we want NAT for IPv6 for security reasons"
NAT does not provide any security, typically a NAT will also include a stateful firewall which provides the security. You can deploy a stateful firewall for your IPv6 network if you like, however it isn't required as much as you probably think it is - see below.
"IPv6 is just another way for hackers to get in."
There is no difference between IPv4 and IPv6 when it comes to firewalls and reachability. It is worth noting that hosts which support IPv6 are typically a lot more secure than older IPv4-only hosts. As an example every version of Windows that ships with IPv6 support also ships with the firewall turned on by default.
"End users don't care about IPv6"
Are you saying this in response to someone asking for IPv6? because that would be contradictory. I am an end user and I care about IPv6!
"But it isn't a priority and we have other stuff to do"
Reconfiguring every router on your network is not something you want to rush when you realise you needed IPv6 yesterday, early adopters have the advantage that they can gain experience with running IPv6 and test their infrastructure without worrying about critical traffic being IPv6-only.
"None of the software vendors support IPv6."
If your software vendors were following best practices and writing decent code then this would not be a problem, I suggest pushing your vendors to fix their code. If you only have 1 of two systems that are IPv4-only then you can always "special case" them. See NAT64 for information about one way of reaching IPv4 hosts from an IPv6 network. If you dual stack then it doesn't matter and you can just use IPv4 for those few services than require it until you get a fix from the vendor.
"None of our staff understand IPv6."
Do your staff understand IPv4? because it's not that different...
"IPv6 addresses are too long to remember"
You shouldn't need to remember IP addresses, that's what DNS is for. However I will say that in my experience and many other peoples having the extra bits to structure your network in a logical fasion can make addresses more obvious and easier to remember. You have a single prefix to remember, then can address hosts within that subnet however you like. In IPv4 you rarely have the luxury of being able to number your DNS server 192.0.2.53 and your web server 192.0.2.80 to make them easier to remember, whereas in IPv6 you can easily assign hosts easy to remember addresses.
"Having to dual stack means I still have to manage a 4 and 6 network."
Good point, however if you want to ease your network management and run an IPv6-only network with IPv4-only services still reachable over the top of it then there are several ways to do it, the most obvious being NAT64.
"Our DNS provider won't let us as add AAAA records"
Seriously? who is your DNS provider? You need to ask them why they don't support standard record types. If they refuse to add standard records to your zone, get a new provider there are plenty out there.
"We'll deploy IPv6 right after we finish deploying DNSSEC"
The 2 are not mutually exclusive - at a large organisation where this sort of project would be major work, you probably have different teams dealing with IP and DNS so there's no reason one would stop the other.
"But Android doesn't support stateful DHCPv6."
I will admit that the specifications were written a little loosely so you have 2 ways of configuring hosts, however if you configure both RA and DHCP then you will cover 100% of IPv6-capible hosts.
"Our legal intercept setup does not work with IPv6"
If your lawful intercept equipment can't see traffic just because they used an "unknown" protocol then it has a major flaw!
- Mike Jones
Living in an area where we have a dense pocket without broadband available is a key problem. The two incumbents fail to service the area despite one having fiber 1200' away at the entry to our street. One area incumbent can do native v6, the other does 6rd but they don't serve the area so it's even moot. I'm in the process of building my own fiber now due to this problem. The service will likely look like native v6 and 100.64 for v4 w/ nat. This penalty for v4 will become more apparent over time is my guess. Jared Mauch
On Jul 2, 2016, at 12:49 PM, William Astle <lost@l-w.ca> wrote:
My upstream(s) refuse(s) to support IPv6
This *is* a deal breaker. The pat response of "get new upstreams" is not helpful
On 2/Jul/16 18:49, William Astle wrote:
Their specific excuse du jour changes every few months but it usually boils down to "we don't want to put any effort or resources into updating anything".
If you keep asking your girlfriend out on a date each week, and she refuses to go out with you, each week, at some point, painful as it might be, you have to cut your losses and move on. Continuing to keep her as your girlfriend does not change the fact that she does not want go out with you anymore, and only further incentivizes her not to change her ways, as she knows you don't have the will or strength to walk regardless of the bad treatment. Mark.
On 3 July 2016 at 11:42, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 2/Jul/16 17:35, Ruairi Carroll wrote:
- ECMP issues (Mostly around flow labels and vendor support for that, also feeds back into PMTUD issues)
Do you rely on the ToS field in IPv4 for ECMP?
Nope. I use l4 tuple for flow hashing to make TCP happy. I was referring to two things: - https://www.nanog.org/sites/default/files/wednesday.general.lotfi.mtu.6.pdf - https://tools.ietf.org/html/rfc7098 Core of the issue is that we _need_ to get an ICMP message back to the original "real server" who sent it. It's a non-issue in the SP space, but imagine if your ECMP groups were stateful in both directions...
- Maintaining 2x IP stacks is inherently expensive Vs 1
How so?
Think about it in layers, with each little piece adding up to the overall cost: Implementation: - Numerous bugs in control plane features with v6 handling. - Numerous platform quirks which need time to be understood. Operational: - Need dev time to ensure applications are v6 ready. - Need SysAdmin time to evaluate kernel/userspace support and functionality - Need to maintain two sets of templates for config purposes - Need to maintain two sets of addressing policies Design: - Some switches are not suitable for v6 because of their multicast handling - Need extra time to validate designs will be v6 ready - Need engineers who understand v6 sufficiently to think in terms of Anycast and ECMP (Those who do it in v4 space are already thin on the ground) - Need engineers who understand v6 sufficiently to describe a good ACL/Firewall filtering. - Need engineers who understand v6 sufficiently to understand the peering/transit landscape (Which IS different from v4). I'll be the first one to say it sucks, but this is the reality of being a stub. My past implementation failures were all torpedo'd by lack of dev time/priority. /Ruairi
Mark.
On 3/Jul/16 12:01, Ruairi Carroll wrote:
Core of the issue is that we _need_ to get an ICMP message back to the original "real server" who sent it. It's a non-issue in the SP space, but imagine if your ECMP groups were stateful in both directions...
Okay.
Think about it in layers, with each little piece adding up to the overall cost:
I understand your points - to your comment, my question is around whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and IPv4. Mark.
On 3 July 2016 at 12:15, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 3/Jul/16 12:01, Ruairi Carroll wrote:
Core of the issue is that we _need_ to get an ICMP message back to the original "real server" who sent it. It's a non-issue in the SP space, but imagine if your ECMP groups were stateful in both directions...
Okay.
Think about it in layers, with each little piece adding up to the overall cost:
I understand your points - to your comment, my question is around whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and IPv4.
Probably equal cost (ha ha) to pick one or the other. However since this conversation was started about people using excuses to not deploy....and being a stub/content provider, your main goal is reachability, to which v4 is still king. So you have your hand forced to pick v4 for now. /Ruairi
Mark.
* Mark Tinka
I understand your points - to your comment, my question is around whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and IPv4.
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. It also means that we'll essentially never have to perform IPv4 renumbering exercises in order to accomodate for growth. Those tend to be very costly due to the man-hours required for planning and implementation. Besides, it means we don't need IPv4 to number customer infrastructure. As you probably know, IPv4 numbers have a real cost these days. My point of view is ASP/MSP/data centre stuff. I know I'm not alone in going down the IPv6 road here, though. Facebook is another prominent example. Other operators in different market segments are also doing IPv6-only. Kabel Deutschland and T-Mobile US, for example. I'm guessing they have similar motivations. Tore
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.
* Mark Tinka <mark.tinka@seacom.mu>
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
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.
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 <mark.tinka@seacom.mu> 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.
In message <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@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: marka@isc.org
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.
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" < mattlists@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.
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.
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 <swmike@swm.pp.se> 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.
On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes < mattlists@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.
On Mon 2016-Jul-04 12:42:33 -0400, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes < mattlists@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: hugo@slabnet.com pgp key: B178313E | also on Signal
On Mon, Jul 4, 2016 at 11:28 AM, Matt Hoppes < mattlists@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
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.
On Mon, Jul 4, 2016 at 7:44 AM, Matt Hoppes < mattlists@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 only rather than dual-stacked, now is probably when you want to start thinking that way. There is a definite cost to trying to operate what is essentially two networks over the long haul. The more places you can move from dual-stacked to single-stacked IPv6 in your network, the better off you'll be. And even ISP access networks are moving more toward offering IPv4 as a service on top of a native IPv6 network. T-Mobile is already doing that.
From what I've seen, others are exploring ways to do it. Especially given all the constraints on IPv4, that approach just makes sense.
So again, the safe bet today looks like IPv6 to me. Wagering that the rest of the Internet will be fully supporting IPv4 at the same level of utility as IPv6 in a decade looks like a high-risk gamble. Scott
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.
On 4 July 2016 at 17:33, Matt Hoppes <mattlists@rivervalleyinternet.net> 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
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.
There is no difference between IPv4 and IPv6 when it comes to firewalls and reachability. It is worth noting that hosts which support IPv6 are typically a lot more secure than older IPv4-only hosts. As an example every version of Windows that ships with IPv6 support also ships with the firewall turned on by default.
Just because the firewall is turned on does not mean that it is configured properly. Every version of Windows that ships with IPv6 support also ships with the Firewall configured in such a fashion that you may as well have it turned off. This is especially true in Windows 8 and later where the firewall is reconfigured without your permission by Microsoft every time you install any update whatsoever back to the "totally insecure" default state -- and there is absolutely no way to fix this other than to check, every single minute, that the firewall is still configured as you configured it, and not as Microsoft (and their NSA partners) choose to configure it. All versions of Windows 8 and later whether using IPv4 or IPv6 are completely unsuitable for use on a network attached to the Internet by any means (whether using NAT or not) that does not include an external (to Windows) -- ie, in network -- statefull firewall over which Windows, Microsoft, (and their NSA partners) have no automatic means of control. If you allow UPnP control of the external statefull firewall from Windows version 8 or later, you may as well not bother having any firewall at all because it is not under your control.
Windows 8 and 10 with the most recent service packs default the firewall to on with very few inbound exemptions. On Jul 2, 2016 11:38 AM, "Keith Medcalf" <kmedcalf@dessus.com> wrote:
There is no difference between IPv4 and IPv6 when it comes to firewalls and reachability. It is worth noting that hosts which support IPv6 are typically a lot more secure than older IPv4-only hosts. As an example every version of Windows that ships with IPv6 support also ships with the firewall turned on by default.
Just because the firewall is turned on does not mean that it is configured properly.
Every version of Windows that ships with IPv6 support also ships with the Firewall configured in such a fashion that you may as well have it turned off.
This is especially true in Windows 8 and later where the firewall is reconfigured without your permission by Microsoft every time you install any update whatsoever back to the "totally insecure" default state -- and there is absolutely no way to fix this other than to check, every single minute, that the firewall is still configured as you configured it, and not as Microsoft (and their NSA partners) choose to configure it.
All versions of Windows 8 and later whether using IPv4 or IPv6 are completely unsuitable for use on a network attached to the Internet by any means (whether using NAT or not) that does not include an external (to Windows) -- ie, in network -- statefull firewall over which Windows, Microsoft, (and their NSA partners) have no automatic means of control. If you allow UPnP control of the external statefull firewall from Windows version 8 or later, you may as well not bother having any firewall at all because it is not under your control.
Yes, the default is "on". An exception is added for EVERY SINGLE PIECE of Microsoft Crapware, whether it is needed or not (and in every single case, it is not). And if you turn those exceptions "off", then they are turned back on by Microsoft and their NSA partners for you, without your permission, whenever automatic updates run (and also at other times that I have not determined the trigger). You must continuously check that the firewall (although ON) remains configured as you configured it, or if Microsoft (and their NSA partners) have changed the configuration without your permission. Of course, most people do not bother configuring the firewall and do not wonder why every piece of Crapware has in incoming exception, and do not bother to turn those off (including some on this list apparently). So they will never notice these nefarious doings which have been a hotbed of discussion on the Internet for many years. And this is on the latest distribution of Windows 10 including the upcoming anniversary edition and has been that way since at least the first version of Windows 8. Whether or not Windows 7 also behaves the same way I do not know because I never ran it.
-----Original Message----- From: Spencer Ryan [mailto:sryan@arbor.net] Sent: Saturday, 2 July, 2016 10:08 To: Keith Medcalf Cc: North American Network Operators' Group Subject: RE: IPv6 deployment excuses
Windows 8 and 10 with the most recent service packs default the firewall to on with very few inbound exemptions.
On Jul 2, 2016 11:38 AM, "Keith Medcalf" <kmedcalf@dessus.com> wrote:
There is no difference between IPv4 and IPv6 when it comes to firewalls and reachability. It is worth noting that hosts which support IPv6 are typically a lot more secure than older IPv4-only hosts. As an example every version of Windows that ships with IPv6 support also ships with the firewall turned on by default.
Just because the firewall is turned on does not mean that it is configured properly.
Every version of Windows that ships with IPv6 support also ships with the Firewall configured in such a fashion that you may as well have it turned off.
This is especially true in Windows 8 and later where the firewall is reconfigured without your permission by Microsoft every time you install any update whatsoever back to the "totally insecure" default state -- and there is absolutely no way to fix this other than to check, every single minute, that the firewall is still configured as you configured it, and not as Microsoft (and their NSA partners) choose to configure it.
All versions of Windows 8 and later whether using IPv4 or IPv6 are completely unsuitable for use on a network attached to the Internet by any means (whether using NAT or not) that does not include an external (to Windows) -- ie, in network -- statefull firewall over which Windows, Microsoft, (and their NSA partners) have no automatic means of control. If you allow UPnP control of the external statefull firewall from Windows version 8 or later, you may as well not bother having any firewall at all because it is not under your control.
Security that is too strict will be disabled and be far less effective than proper security measures. Security zealots are often blind to that. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" <kmedcalf@dessus.com> To: "nanog list" <nanog@nanog.org> Sent: Saturday, July 2, 2016 11:41:48 AM Subject: RE: IPv6 deployment excuses Yes, the default is "on". An exception is added for EVERY SINGLE PIECE of Microsoft Crapware, whether it is needed or not (and in every single case, it is not). And if you turn those exceptions "off", then they are turned back on by Microsoft and their NSA partners for you, without your permission, whenever automatic updates run (and also at other times that I have not determined the trigger). You must continuously check that the firewall (although ON) remains configured as you configured it, or if Microsoft (and their NSA partners) have changed the configuration without your permission. Of course, most people do not bother configuring the firewall and do not wonder why every piece of Crapware has in incoming exception, and do not bother to turn those off (including some on this list apparently). So they will never notice these nefarious doings which have been a hotbed of discussion on the Internet for many years. And this is on the latest distribution of Windows 10 including the upcoming anniversary edition and has been that way since at least the first version of Windows 8. Whether or not Windows 7 also behaves the same way I do not know because I never ran it.
-----Original Message----- From: Spencer Ryan [mailto:sryan@arbor.net] Sent: Saturday, 2 July, 2016 10:08 To: Keith Medcalf Cc: North American Network Operators' Group Subject: RE: IPv6 deployment excuses
Windows 8 and 10 with the most recent service packs default the firewall to on with very few inbound exemptions.
On Jul 2, 2016 11:38 AM, "Keith Medcalf" <kmedcalf@dessus.com> wrote:
There is no difference between IPv4 and IPv6 when it comes to firewalls and reachability. It is worth noting that hosts which support IPv6 are typically a lot more secure than older IPv4-only hosts. As an example every version of Windows that ships with IPv6 support also ships with the firewall turned on by default.
Just because the firewall is turned on does not mean that it is configured properly.
Every version of Windows that ships with IPv6 support also ships with the Firewall configured in such a fashion that you may as well have it turned off.
This is especially true in Windows 8 and later where the firewall is reconfigured without your permission by Microsoft every time you install any update whatsoever back to the "totally insecure" default state -- and there is absolutely no way to fix this other than to check, every single minute, that the firewall is still configured as you configured it, and not as Microsoft (and their NSA partners) choose to configure it.
All versions of Windows 8 and later whether using IPv4 or IPv6 are completely unsuitable for use on a network attached to the Internet by any means (whether using NAT or not) that does not include an external (to Windows) -- ie, in network -- statefull firewall over which Windows, Microsoft, (and their NSA partners) have no automatic means of control. If you allow UPnP control of the external statefull firewall from Windows version 8 or later, you may as well not bother having any firewall at all because it is not under your control.
This is a non sequitur. In what way is the blocking of incoming unsolicited connections not a "proper security measure"? What gives you (or anyone else) the right to "disable" security measures which you (or anyone else) consider "too strict"? How do you arrive at the conclusion that disabling unsolicited incoming connections to software that does not require it (and which you do not want to accept such unsolicited incoming connections) is "far less effective" than "proper security measures" (and what are those alleged "proper security measures)? Explain especially in light of built-in crapware which cannot otherwise be removed from the system because it has been "integrated" by scattering its parts (with no purpose other than to make the crapware non-removeable) into critical components so as to prevent removal without breaking the system? Please explain how expecting firewall setting to remain set as they have been deliberately set makes one a "security zealot"? If the ACLs on your Cisco router suddenly decided to change all by themselves because Cisco had decided they did not like the way you had set them, I am quite sure that you take an entirely different position!
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mike Hammett Sent: Saturday, 2 July, 2016 12:43 Cc: nanog list Subject: Re: IPv6 deployment excuses
Security that is too strict will be disabled and be far less effective than proper security measures. Security zealots are often blind to that.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest Internet Exchange http://www.midwest-ix.com
----- Original Message -----
From: "Keith Medcalf" <kmedcalf@dessus.com> To: "nanog list" <nanog@nanog.org> Sent: Saturday, July 2, 2016 11:41:48 AM Subject: RE: IPv6 deployment excuses
Yes, the default is "on". An exception is added for EVERY SINGLE PIECE of Microsoft Crapware, whether it is needed or not (and in every single case, it is not). And if you turn those exceptions "off", then they are turned back on by Microsoft and their NSA partners for you, without your permission, whenever automatic updates run (and also at other times that I have not determined the trigger). You must continuously check that the firewall (although ON) remains configured as you configured it, or if Microsoft (and their NSA partners) have changed the configuration without your permission.
Of course, most people do not bother configuring the firewall and do not wonder why every piece of Crapware has in incoming exception, and do not bother to turn those off (including some on this list apparently). So they will never notice these nefarious doings which have been a hotbed of discussion on the Internet for many years.
And this is on the latest distribution of Windows 10 including the upcoming anniversary edition and has been that way since at least the first version of Windows 8.
Whether or not Windows 7 also behaves the same way I do not know because I never ran it.
-----Original Message----- From: Spencer Ryan [mailto:sryan@arbor.net] Sent: Saturday, 2 July, 2016 10:08 To: Keith Medcalf Cc: North American Network Operators' Group Subject: RE: IPv6 deployment excuses
Windows 8 and 10 with the most recent service packs default the firewall to on with very few inbound exemptions.
On Jul 2, 2016 11:38 AM, "Keith Medcalf" <kmedcalf@dessus.com> wrote:
There is no difference between IPv4 and IPv6 when it comes to firewalls and reachability. It is worth noting that hosts which support IPv6 are typically a lot more secure than older IPv4-only hosts. As an example every version of Windows that ships with IPv6 support also ships with the firewall turned on by default.
Just because the firewall is turned on does not mean that it is configured properly.
Every version of Windows that ships with IPv6 support also ships with the Firewall configured in such a fashion that you may as well have it turned off.
This is especially true in Windows 8 and later where the firewall is reconfigured without your permission by Microsoft every time you install any update whatsoever back to the "totally insecure" default state -- and there is absolutely no way to fix this other than to check, every single minute, that the firewall is still configured as you configured it, and not as Microsoft (and their NSA partners) choose to configure it.
All versions of Windows 8 and later whether using IPv4 or IPv6 are completely unsuitable for use on a network attached to the Internet by any means (whether using NAT or not) that does not include an external (to Windows) -- ie, in network -- statefull firewall over which Windows, Microsoft, (and their NSA partners) have no automatic means of control. If you allow UPnP control of the external statefull firewall from Windows version 8 or later, you may as well not bother having any firewall at all because it is not under your control.
On 01/07/2016 21:52, Mike Jones wrote:
I am in contact with a couple of network operators trying to prod them to deploy IPv6, I figured that 10 minutes to send a couple of emails was worth the effort to make them "see a customer demand" (now none of them can use the excuse that nobody has asked for it!), but the replies I got were less than impressive to say the least.
I was wondering if you guys could summarise your experiences with people who make excuses for not deploying IPv6? I regularly see a specific person saying "we can't deploy it because X" followed by you guys "correcting them" and telling them how to deploy it without the problems they claim they will have, but that is only a small snapshot of the people who bother to post about their ignorance in public. I suspect there is also a lot of selection-bias in the NANOG membership base but you deal with a lot of enterprise networks off of this list so probably have broader experience than the NANOG archives.
Can we have a thread summarising the most common excuses you've heard, and if they are actual problems blocking IPv6 deployment or just down to ignorance? Perhaps this could be the basis for an FAQ type page that I can point people to when they say they don't know how to deploy IPv6 on their networks? :)
Our provider sale representative, who is the most tech savvy sale-rep I ever encountered by far, which is not a very high bar, but still, said something like: "You shouldn't worry about that, we have plenty of IPv4 addresses left... and besides we are "working on it(TM)"... it's going to be deployed next year... probably " Needless to say I'm still waiting. :) Ciao, Davide Davini
In message <222bac2d-800b-93c7-7d17-bd469e858184@gmail.com>, Davide Davini writ es:
On 01/07/2016 21:52, Mike Jones wrote:
I am in contact with a couple of network operators trying to prod them to deploy IPv6, I figured that 10 minutes to send a couple of emails was worth the effort to make them "see a customer demand" (now none of them can use the excuse that nobody has asked for it!), but the replies I got were less than impressive to say the least.
I was wondering if you guys could summarise your experiences with people who make excuses for not deploying IPv6? I regularly see a specific person saying "we can't deploy it because X" followed by you guys "correcting them" and telling them how to deploy it without the problems they claim they will have, but that is only a small snapshot of the people who bother to post about their ignorance in public. I suspect there is also a lot of selection-bias in the NANOG membership base but you deal with a lot of enterprise networks off of this list so probably have broader experience than the NANOG archives.
Can we have a thread summarising the most common excuses you've heard, and if they are actual problems blocking IPv6 deployment or just down to ignorance? Perhaps this could be the basis for an FAQ type page that I can point people to when they say they don't know how to deploy IPv6 on their networks? :)
Our provider sale representative, who is the most tech savvy sale-rep I ever encountered by far, which is not a very high bar, but still, said something like: "You shouldn't worry about that, we have plenty of IPv4 addresses left... and besides we are "working on it(TM)"... it's going to be deployed next year... probably "
Needless to say I'm still waiting. :)
Ciao, Davide Davini
The default comeback to that is: Are you going to give the addresses to the people I need to talk to that don't have a unshared IPv4 addresses but do have IPv6 addressess? I thought not, so get off you a#$e and deliver IPv6 today. You are already way too late delivering IPv6. It's not like you didn't already have a decade to plan how to deliver it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 11/07/2016 09:24, Mark Andrews wrote:
Our provider sale representative, who is the most tech savvy sale-rep I ever encountered by far, which is not a very high bar, but still, said something like: "You shouldn't worry about that, we have plenty of IPv4 addresses left... and besides we are "working on it(TM)"... it's going to be deployed next year... probably "
Needless to say I'm still waiting. :)
The default comeback to that is: Are you going to give the addresses to the people I need to talk to that don't have a unshared IPv4 addresses but do have IPv6 addresses? I thought not, so get off you a#$e and deliver IPv6 today. You are already way too late delivering IPv6. It's not like you didn't already have a decade to plan how to deliver it.
I don't think it's going to go a long way being rude to them. :) We would have chosen another ISP that offered IPv6 if the alternatives in the price range were half as good but they ain't... More people should ask for it, that's the way to go in my opinion. As for us I'm going to keep pestering them on regular basis on the subject but it's obvious I'm not part of a majority. The truth is though IPv6 is not yet mandatory for our business and that's why we prefer a all-around better provider then a lesser one that deployed IPv6. My 2 euro cents. Ciao, Davide Davini
participants (27)
-
Alarig Le Lay -
Baldur Norddahl -
Ca By -
Christopher Morrow -
Davide Davini -
Denis Fondras -
Filip Hruska -
Gary Wardell -
Hugo Slabbert -
Jared Mauch -
Jared Mauch
-
Keith Medcalf -
Marcin Cieslak -
Mark Andrews -
Mark Tinka -
Masataka Ohta -
Matt Hoppes -
Mikael Abrahamsson -
Mike Hammett -
Mike Jones -
Ruairi Carroll -
Saku Ytti -
Scott Morizot -
Spencer Ryan -
Tore Anderson -
Valdis.Kletnieks＠vt.edu -
William Astle