Re: IPv6 deployment excuses

[Davide Davini]

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

Re: IPv6 deployment excuses

[Mark Andrews]

In message <222bac2d-800b-93c7-7d17-bd469e858...@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: ma...@isc.org

Re: IPv6 deployment excuses

[Davide Davini]

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

Re: IPv6 deployment excuses

[Mike Hammett]

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" <mo...@necom830.hpcl.titech.ac.jp> 
To: "Valdis Kletnieks" <valdis.kletni...@vt.edu> 
Cc: nanog@nanog.org 
Sent: Monday, July 4, 2016 11:22:59 PM 
Subject: 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

[Mikael Abrahamsson]

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 Abrahamssonemail: swm...@swm.pp.se

Re: IPv6 deployment excuses

[Baldur Norddahl]

On 5 July 2016 at 07:27, Mikael Abrahamsson  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

Re: IPv6 deployment excuses

[Mikael Abrahamsson]

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

[Masataka Ohta]

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

[Valdis . Kletnieks]

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

[Jared Mauch]

> 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

[Masataka Ohta]

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

[Matt Hoppes]

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

[Spencer Ryan]

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

[Masataka Ohta]

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

[Jared Mauch]

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

[Ca By]

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

[Baldur Norddahl]

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

[Mark Tinka]

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

[Mark Tinka]

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

[Mark Tinka]

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.

IPv6 deployment excuses

[Ca By]

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: IPv6 deployment excuses

[Baldur Norddahl]

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

Re: IPv6 deployment excuses - IPv6 only resources

[Scott Morizot]

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

[Masataka Ohta]

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 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

[Jacques Latour]

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

[Scott Morizot]

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

[Hugo Slabbert]

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

[Christopher Morrow]

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

[Mikael Abrahamsson]

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

[Saku Ytti]

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

[Matt Hoppes]

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

[Baldur Norddahl]

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

[Scott Morizot]

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 

Re: IPv6 deployment excuses

[Matt Hoppes]

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

[Mark Andrews]

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

[Matt Hoppes]

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.

Re: IPv6 deployment excuses

[Filip Hruska]

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 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

[Masataka Ohta]

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 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

[Mark Tinka]

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

[Tore Anderson]

* 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

[Mark Tinka]

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.

Re: IPv6 deployment excuses

[Tore Anderson]

* 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

Re: IPv6 deployment excuses

[Ruairi Carroll]

On 3 July 2016 at 12:15, Mark Tinka  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 deployand
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.
>

Re: IPv6 deployment excuses

[Mark Tinka]

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.

Re: IPv6 deployment excuses

[Ruairi Carroll]

On 3 July 2016 at 11:42, Mark Tinka  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.
>

Re: IPv6 deployment excuses

[Mark Tinka]

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.

Re: IPv6 deployment excuses

[Mark Tinka]

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?

> - Maintaining 2x IP stacks is inherently expensive Vs 1

How so?

Mark.

RE: IPv6 deployment excuses

[Keith Medcalf]

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-boun...@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" <kmedc...@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:sr...@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" <kmedc...@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 

Re: IPv6 deployment excuses

[Jared Mauch]

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  wrote:
> 
> My upstream(s) refuse(s) to support IPv6
> 
> This *is* a deal breaker. The pat response of "get new upstreams" is not 
> helpful

Re: IPv6 deployment excuses

[Mike Hammett]

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" <kmedc...@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:sr...@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" <kmedc...@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. 
> 
> 
> 
> 
> 

Re: IPv6 deployment excuses

[Denis Fondras]

On Sat, Jul 02, 2016 at 10:49:40AM -0600, William Astle wrote:
> it usually boils down to "we don't want to put any effort or resources into
> updating anything".
> 

And they must be right as their clients won't go away... :p

Re: IPv6 deployment excuses

[William Astle]

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  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 

RE: IPv6 deployment excuses

[Keith Medcalf]

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:sr...@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" <kmedc...@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.
>
>
>
>
>

RE: IPv6 deployment excuses

[Spencer Ryan]

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"  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.
>
>
>
>
>

RE: IPv6 deployment excuses

[Keith Medcalf]

> 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.

Re: IPv6 deployment excuses

[Ruairi Carroll]

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  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  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 

Re: IPv6 deployment excuses

[Mike Jones]

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  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

Re: IPv6 deployment excuses

[Jared Mauch]

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 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  
> 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

[Masataka Ohta]

Jared Mauch wrote:


https://youtu.be/v26BAlfWBm8

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

RE: IPv6 deployment excuses

[Gary Wardell]

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-boun...@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:

> > >

> > >  <http://ipv6excuses.com/> http://ipv6excuses.com/

> >

> > 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

Re: IPv6 deployment excuses

[Hugo Slabbert]

 From: Alarig Le Lay  -- Sent: 2016-07-01 - 14:53 

> On Fri Jul  1 17:43:21 2016, Gary Wardell wrote:
>> >
>> > http://ipv6excuses.com/
>>
>> 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




signature.asc
Description: PGP/MIME digital signature

Re: IPv6 deployment excuses

[Alarig Le Lay]

On Fri Jul  1 17:43:21 2016, Gary Wardell wrote:
> > 
> > http://ipv6excuses.com/
> 
> 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


signature.asc
Description: Digital signature

RE: IPv6 deployment excuses

[Gary Wardell]

> 
> http://ipv6excuses.com/

That website only supports IPv4.

Gary

Re: IPv6 deployment excuses

[Jared Mauch]

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  wrote:
> 
> http://ipv6excuses.com/
> https://twitter.com/ipv6excuses

Re: IPv6 deployment excuses

[Hugo Slabbert]

 From: Mike Jones  -- 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



signature.asc
Description: PGP/MIME digital signature

Re: IPv6 deployment excuses

[Marcin Cieslak]

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

IPv6 deployment excuses

[Mike Jones]

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