Provider IPv6 Deployment

[Nicholas Warren]

Can anyone share resources on deploying IPv6 in a provider network?
Most all documentation I find is from the customer perspective; which is great 
and all, but what about setting up dhcpv6-pd, what about the relay agent, or 
what about an equivalent of dhcp option 82?

Nich

RIPE NCC Global IPv6 Deployment Survey

[Massimiliano Stucchi]

Hi,

just a little reminder that there are a few days left to help the RIPE
NCC by filling up our Global IPv6 Deployment Survey.  We have already
received a considerable amount of responses, but would like to hear from
more people.

The goal of the survey is to get an overview of IPv6 deployment across
the world, and to assess how this is seen from the perspective of ISPs
and Enterprise users.

The 2018 survey is a follow up to similar surveys run between 2008 and
2013, and will serve as a comparison with the data acquired back then.

You can find the survey at the following address:

https://www.surveymonkey.com/r/GlobalIPv6survey2018

Responses can be submitted until 31 March 2018.

We will then collect the data with the aim of presenting the preliminary
results during the upcoming RIPE 76 meeting in Marseille.

If you have any question about the survey, please feel free to email us
at: ipv6survey2...@ripe.net.

Thank you very much in advance for your participation!

-- 

Massimiliano Stucchi
IPv6 Programme Manager
RIPE NCC
mstuc...@ripe.net

Follow us on Twitter for the fastest and latest RIPE NCC Training news!
@TrainingRIPENCC



signature.asc
Description: OpenPGP digital signature

TIMELY - Fwd: RIPE NCC Global IPv6 Deployment Survey

[John Curran]

NANOGers -

An important reminder: this Global IPv6 deployment survey is closing at the end 
of March.

If you have a moment, please take the time to complete this survey so that the 
RIRs may collectively have a better understanding of the status of IPv6 
deployment in the Internet.

Thanks!
/John

John Curran
President and CEO
ARIN

> Begin forwarded message:
> 
> From: Massimiliano Stucchi <mstuc...@ripe.net>
> Subject: RIPE NCC Global IPv6 Deployment Survey
> Date: 12 February 2018 at 9:14:57 AM EST
> To: nanog@nanog.org
> Reply-To: mstuc...@ripe.net
> 
> 
> Dear colleagues,
> 
> The RIPE NCC would like to invite you to participate in its Global IPv6
> Survey 2018. The goal of the survey is to get an overview IPv6
> deployment across the world, and to assess how this is seen from the
> perspective of ISPs and Enterprise users.
> 
> The 2018 survey is a follow up to similar surveys run between 2008 and
> 2013, and will serve as a
> comparison with the data acquired back then.
> 
> You can find the survey at the following address:
> 
> https://www.surveymonkey.com/r/GlobalIPv6survey2018
> 
> Responses can be submitted until 31 March 2018.
> 
> We will then collect the data with the aim of presenting the preliminary
> results during the upcoming RIPE 76 meeting in Marseille.
> 
> If you have any question about the survey, please feel free to email us
> at: ipv6survey2...@ripe.net.
> 
> Thank you very much in advance for your participation!
> 
> --
> 
> Massimiliano Stucchi
> IPv6 Programme Manager
> RIPE NCC
> mstuc...@ripe.net
> 
> Follow us on Twitter for the fastest and latest RIPE NCC Training news!
> @TrainingRIPENCC
> 



signature.asc
Description: Message signed with OpenPGP

RIPE NCC Global IPv6 Deployment Survey

[Massimiliano Stucchi]

Dear colleagues,

The RIPE NCC would like to invite you to participate in its Global IPv6
Survey 2018. The goal of the survey is to get an overview IPv6
deployment across the world, and to assess how this is seen from the
perspective of ISPs and Enterprise users.

The 2018 survey is a follow up to similar surveys run between 2008 and
2013, and will serve as a
comparison with the data acquired back then.

You can find the survey at the following address:

https://www.surveymonkey.com/r/GlobalIPv6survey2018

Responses can be submitted until 31 March 2018.

We will then collect the data with the aim of presenting the preliminary
results during the upcoming RIPE 76 meeting in Marseille.

If you have any question about the survey, please feel free to email us
at: ipv6survey2...@ripe.net.

Thank you very much in advance for your participation!

-- 

Massimiliano Stucchi
IPv6 Programme Manager
RIPE NCC
mstuc...@ripe.net

Follow us on Twitter for the fastest and latest RIPE NCC Training news!
@TrainingRIPENCC



signature.asc
Description: OpenPGP digital signature

Verizon Wireless IPv6 deployment contact?

[Randy Carpenter]

Is there anyone from Verizon Wireless that I can talk to regarding IPv6 
deployment? I am getting nonsensical answers from my local contacts.

Please contact me off-list.

thanks,
-Randy

Re: Questions on IPv6 deployment

[William Herrin]

On Tue, Jan 17, 2017 at 5:13 PM, Matthew Huff  wrote:
> Please check the nanog archives.
> I was just responding to the argument that a /64 is wasteful and serves 
> little purpose.

Then respond. With explanation, reasoning and evidence. Telling me to
search a massive archive for nebulous discussions is a total cop-out.

Regards,
Bill


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[William Herrin]

On Tue, Jan 17, 2017 at 6:06 PM, Sander Steffann  wrote:
> One thing that comes to mind is that it seems that some routers only have 
> limited space in their routing tables for prefixes longer than a /64. If you 
> would configure a /127 on the link but push the /64 to the routing table then 
> you might both avoid ND Cache exhaustion and avoid the limitations on 
> longer-than-/64 prefixes.

Hi Sander,

IIRC, the problem was that some routers could only fit the first 64
bits in the TCAM so routes longer than /64 fell out of the fast path.
That was about half a decade ago. No idea if anything modern still
suffers from this.

That would impact every route in Matthew's proposed solution: the
loopbacks from the infrastructure /64 and the /127's from otherwise
unpopulated /64's. Because programmatically those /64's don't have one
prefix, they have two: the /127 for the link and the implicit null
route for everything else. The router has to honor the implicit null
route so it can't aggregate the /127 to /64 and keep it in the fast
path.

Regards,
Bill Herrin




-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[Sander Steffann]

Hi Bill,

> Op 17 jan. 2017, om 22:55 heeft William Herrin  het volgende 
> geschreven:
> 
> I'm always interested in learning something new. Please explain the
> DOS vectors you're referring to and how they're mitigated by
> allocating a /64 to the point to point link.

One thing that comes to mind is that it seems that some routers only have 
limited space in their routing tables for prefixes longer than a /64. If you 
would configure a /127 on the link but push the /64 to the routing table then 
you might both avoid ND Cache exhaustion and avoid the limitations on 
longer-than-/64 prefixes.

I personally prefer to set up my addressing plan that things like this are 
possible even if I don't do it today, but I also understand the choices you 
make. I don't think any of the choices is wrong. It mostly depends on 
expectations, used equipment and personal preference.

And thanks for mentioning "Minimum assignment to a customer: /60". That is 
indeed a very important one!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

RE: Questions on IPv6 deployment

[Matthew Huff]

Please check the nanog archives. There were some arguments that I and I assume 
others felt compelling why allocating a /64 per point to point link was a good 
idea. Your network, your rules. I was just responding to the argument that a 
/64 is wasteful and serves little purpose.



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


> -Original Message-
> From: William Herrin [mailto:b...@herrin.us]
> Sent: Tuesday, January 17, 2017 4:56 PM
> To: Matthew Huff <mh...@ox.com>
> Cc: Michael Still <stillwa...@gmail.com>; nanog@nanog.org
> Subject: Re: Questions on IPv6 deployment
> 
> On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff <mh...@ox.com> wrote:
> > The reason for allocating a /64 for a point to point link is due to
> various denial of service attack vectors.
> 
> Hi Matthew,
> 
> I'm always interested in learning something new. Please explain the
> DOS vectors you're referring to and how they're mitigated by
> allocating a /64 to the point to point link.
> 
> 
> > Just do it.
> 
> No. But if you offer a good reason, I'll factor your reason in to my
> considerations.
> 
> Regards,
> Bill Herrin
> 
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: <http://www.dirtside.com/>

Re: Questions on IPv6 deployment

[joel jaeggli]

On 1/17/17 1:55 PM, William Herrin wrote:
> On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff  wrote:
>> The reason for allocating a /64 for a point to point link is due to various 
>> denial of service attack vectors.


if you mean allocating a /127, then... sure.

Neighbor discovery on point to point links could be a problem as is the
poential for looping behavior . There are of course ways other than
allocating a longer prefix to a point to point link to achieve that, 
e.g. disabling it. among other things You have to disable DAD anyway if
you ever plan to loop them up for testing.

these are detailed in

https://tools.ietf.org/html/rfc6164
>> Hi Matthew,
>>
>> I'm always interested in learning something new. Please explain the
>> DOS vectors you're referring to and how they're mitigated by
>> allocating a /64 to the point to point link.
>>
>>
>> Just do it.
> No. But if you offer a good reason, I'll factor your reason in to my
> considerations.
>
> Regards,
> Bill Herrin
>




signature.asc
Description: OpenPGP digital signature

Re: Questions on IPv6 deployment

[William Herrin]

On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff  wrote:
> The reason for allocating a /64 for a point to point link is due to various 
> denial of service attack vectors.

Hi Matthew,

I'm always interested in learning something new. Please explain the
DOS vectors you're referring to and how they're mitigated by
allocating a /64 to the point to point link.


> Just do it.

No. But if you offer a good reason, I'll factor your reason in to my
considerations.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[Owen DeLong]

I think you mean /127 since a /128 would not support 2 points on the point to 
point.

Owen

> On Jan 17, 2017, at 13:07 , Matthew Huff <mh...@ox.com> wrote:
> 
> The reason for allocating a /64 for a point to point link is due to various 
> denial of service attack vectors. Just do it. The numbers in IPv6 are 
> staggering. The generally accepted best practice is to allocate a /64 and use 
> a /128 within that /64 for point to point links.
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff| Fax:   914-694-5669
> 
> 
>> -Original Message-
>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William
>> Herrin
>> Sent: Tuesday, January 17, 2017 4:02 PM
>> To: Michael Still <stillwa...@gmail.com>
>> Cc: nanog@nanog.org
>> Subject: Re: Questions on IPv6 deployment
>> 
>> On Tue, Jan 17, 2017 at 12:48 PM, Michael Still <stillwa...@gmail.com>
>> wrote:
>>> http://nabcop.org/index.php/IPv6_Subnetting
>> 
>> That's overall good advice. I quibble with a couple of points:
>> 
>> 1. If you plan to use a /126 on a point to point and can't imagine how
>> you would use a /64 on that point to point, don't allocate a /64. Odds
>> are that by the time you can imagine some way to use a /64 there, the
>> details will require you to assign a new block anyway.
>> 
>> Why be concerned about resource consumption? Because it's a good
>> habit. Don't overdo it, IPv6 is not resource constrained the way IPv4
>> is, but shrewd use of available resources is a good habit even when
>> resources are plentiful.
>> 
>> 2. Make all your point to points /124. That will work for all your
>> point to points. Serial or ethernet. Even the ethernets which have two
>> high-availability routers on both ends along with the failover address
>> needing a total of 6 IPs plus 1 for your troubleshooting laptop.
>> Configuring /124 every time allows you to standardize your
>> configuration, the same way /64 standardizes the netmask on a LAN
>> deployment.
>> 
>> 
>> 
>> One additional point not brought up:
>> 
>> Minimum assignment to a customer: /60. Never ever /64 or /128. How
>> much more than a /60 you choose as your minimum is up to you. Common
>> choices are /56 and /48. But never, ever less than a /60.   Your
>> customer will want to deploy a /64 to each LAN. And there are so many
>> cases where he'll want to deploy more than one LAN.
>> 
>> I've noticed a lot of hosting providers getting this wrong. Some of
>> your customers do create VPNs on their VPC you know.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> --
>> William Herrin  her...@dirtside.com  b...@herrin.us
>> Owner, Dirtside Systems . Web: <http://www.dirtside.com/>

RE: Questions on IPv6 deployment

[Matthew Huff]

The reason for allocating a /64 for a point to point link is due to various 
denial of service attack vectors. Just do it. The numbers in IPv6 are 
staggering. The generally accepted best practice is to allocate a /64 and use a 
/128 within that /64 for point to point links.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William
> Herrin
> Sent: Tuesday, January 17, 2017 4:02 PM
> To: Michael Still <stillwa...@gmail.com>
> Cc: nanog@nanog.org
> Subject: Re: Questions on IPv6 deployment
> 
> On Tue, Jan 17, 2017 at 12:48 PM, Michael Still <stillwa...@gmail.com>
> wrote:
> > http://nabcop.org/index.php/IPv6_Subnetting
> 
> That's overall good advice. I quibble with a couple of points:
> 
> 1. If you plan to use a /126 on a point to point and can't imagine how
> you would use a /64 on that point to point, don't allocate a /64. Odds
> are that by the time you can imagine some way to use a /64 there, the
> details will require you to assign a new block anyway.
> 
> Why be concerned about resource consumption? Because it's a good
> habit. Don't overdo it, IPv6 is not resource constrained the way IPv4
> is, but shrewd use of available resources is a good habit even when
> resources are plentiful.
> 
> 2. Make all your point to points /124. That will work for all your
> point to points. Serial or ethernet. Even the ethernets which have two
> high-availability routers on both ends along with the failover address
> needing a total of 6 IPs plus 1 for your troubleshooting laptop.
> Configuring /124 every time allows you to standardize your
> configuration, the same way /64 standardizes the netmask on a LAN
> deployment.
> 
> 
> 
> One additional point not brought up:
> 
> Minimum assignment to a customer: /60. Never ever /64 or /128. How
> much more than a /60 you choose as your minimum is up to you. Common
> choices are /56 and /48. But never, ever less than a /60.   Your
> customer will want to deploy a /64 to each LAN. And there are so many
> cases where he'll want to deploy more than one LAN.
> 
> I've noticed a lot of hosting providers getting this wrong. Some of
> your customers do create VPNs on their VPC you know.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: <http://www.dirtside.com/>

Re: Questions on IPv6 deployment

[William Herrin]

On Tue, Jan 17, 2017 at 12:48 PM, Michael Still  wrote:
> http://nabcop.org/index.php/IPv6_Subnetting

That's overall good advice. I quibble with a couple of points:

1. If you plan to use a /126 on a point to point and can't imagine how
you would use a /64 on that point to point, don't allocate a /64. Odds
are that by the time you can imagine some way to use a /64 there, the
details will require you to assign a new block anyway.

Why be concerned about resource consumption? Because it's a good
habit. Don't overdo it, IPv6 is not resource constrained the way IPv4
is, but shrewd use of available resources is a good habit even when
resources are plentiful.

2. Make all your point to points /124. That will work for all your
point to points. Serial or ethernet. Even the ethernets which have two
high-availability routers on both ends along with the failover address
needing a total of 6 IPs plus 1 for your troubleshooting laptop.
Configuring /124 every time allows you to standardize your
configuration, the same way /64 standardizes the netmask on a LAN
deployment.



One additional point not brought up:

Minimum assignment to a customer: /60. Never ever /64 or /128. How
much more than a /60 you choose as your minimum is up to you. Common
choices are /56 and /48. But never, ever less than a /60.   Your
customer will want to deploy a /64 to each LAN. And there are so many
cases where he'll want to deploy more than one LAN.

I've noticed a lot of hosting providers getting this wrong. Some of
your customers do create VPNs on their VPC you know.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[Michael Still]

Oops:
http://nabcop.org/index.php/IPv6_Subnetting


On Tue, Jan 17, 2017 at 12:48 PM, Michael Still <stillwa...@gmail.com>
wrote:

> Hi, a few years back some in the community got together to write this:
>
> On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker <
> matt...@corp.crocker.com> wrote:
>
>>
>> Hello,
>>
>> I’m AS7849 and I have an IP problem.
>>
>> I’m running IPv4 ( /16 legacy + /20) and have enough space to last me
>> for  a while,  multi-homed, BGP4 full tables + peering, ect.
>> I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core.
>>
>> I want to start building my IPv6 infrastructure.
>>
>> I have a /32 assigned from ARIN (2001:4918::/32)
>>
>> I’m looking for some direction/reading list of how to properly configure
>> IPv6.  I’ve read to use a /64 for PtP interfaces and I’ve read use a /128
>> instead.Assign all loopbacks from the same /64, use a different /64 for
>> each loopback. Ect, ect.
>>
>> I’m trying not to light a religious war but what is the current best
>> practice for IPv6 deployment in a service provider network?
>>
>> PS.  I’ll be at NANOG69 in DC next month,  1st NANOG for me after 22
>> years.  ☺
>>
>> -Matt
>>
>> --
>> Matthew Crocker
>> Crocker Communications, Inc.
>> President
>>
>
>
>
> --
> [stillwa...@gmail.com ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwa...@gmail.com ~]$
>



-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

Re: Questions on IPv6 deployment

[Michael Still]

Hi, a few years back some in the community got together to write this:

On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker <matt...@corp.crocker.com>
wrote:

>
> Hello,
>
> I’m AS7849 and I have an IP problem.
>
> I’m running IPv4 ( /16 legacy + /20) and have enough space to last me for
> a while,  multi-homed, BGP4 full tables + peering, ect.
> I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core.
>
> I want to start building my IPv6 infrastructure.
>
> I have a /32 assigned from ARIN (2001:4918::/32)
>
> I’m looking for some direction/reading list of how to properly configure
> IPv6.  I’ve read to use a /64 for PtP interfaces and I’ve read use a /128
> instead.Assign all loopbacks from the same /64, use a different /64 for
> each loopback. Ect, ect.
>
> I’m trying not to light a religious war but what is the current best
> practice for IPv6 deployment in a service provider network?
>
> PS.  I’ll be at NANOG69 in DC next month,  1st NANOG for me after 22
> years.  ☺
>
> -Matt
>
> --
> Matthew Crocker
> Crocker Communications, Inc.
> President
>



-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

Re: Questions on IPv6 deployment

[Sander Steffann]

Hi,

> Suggest /128's for loopbacks and /124's for point to points, all from
> the same /64. This way you don't burn space needlessly, don't open
> yourself to neighbor discovery issues on point to points

I usually reserve one /64 for loopbacks, reserve a /64 per point-to-point 
connection and configure a /127 using ::a on one side and ::b on the other. All 
of these from a block reserved for infrastructure for filtering:

> and can
> filter inbound Internet packets to that /64 in one fell swoop so that
> it's harder to hit your routers directly. Just make sure not to filter
> the outbound packets.

Having a single block for infrastructure makes this very easy. In most cases I 
don't need to worry about "burning space needlessly" so I reserve /64s per 
point-to-point. Worrying about "wasting" address space is more often an 
IPv4-ism than good practice with IPv6 IMHO :-)  But it all depends on the 
complexity of your network. There are cases where it makes sense to think about 
this.

> Reminder: No matter what size you pick, use nibble boundaries for
> visual and DNS convenience. So /124, not /126.

Good advice!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Questions on IPv6 deployment

[William Herrin]

On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker
 wrote:
> I’m looking for some direction/reading list of how to properly configure 
> IPv6.  I’ve read to use a /64 for PtP interfaces and I’ve read use a /128 
> instead.Assign all loopbacks from the same /64, use a different /64 for 
> each loopback. Ect, ect.

Hi Matthew,

Suggest /128's for loopbacks and /124's for point to points, all from
the same /64. This way you don't burn space needlessly, don't open
yourself to neighbor discovery issues on point to points and can
filter inbound Internet packets to that /64 in one fell swoop so that
it's harder to hit your routers directly. Just make sure not to filter
the outbound packets.

Reminder: No matter what size you pick, use nibble boundaries for
visual and DNS convenience. So /124, not /126.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[Ca By]

 Why do not you feel compelled to ask this question?

Did you ask this question when you deployed ipv4?

AFAIK, everyone deploys ipv4 in a unique way. Same for ipv6. IPv6 is not
exotic or filled with unique pitfalls.  A lot of networks have deployed
production networks with ipv6, each one unique, so you don't need to watch
out for that one weird bug ( at least any more than ipv4). So, just like
ipv4, read about the standards, read about vendor implementation that are
close to you, make informed decisions.

My only nugget of advice is to deploy ipv6 in such a way it is not forever
coupled with ipv4.  There will be a day when you deploy ipv6 without ipv4,
this day already came for  Facebook, Comast, T-mobile and others.

I have not read this, but you may find the discussion helpful

https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-12




On Mon, Jan 16, 2017 at 7:13 AM Matthew Crocker <matt...@corp.crocker.com>
wrote:

>
>
> Hello,
>
>
>
> I’m AS7849 and I have an IP problem.
>
>
>
> I’m running IPv4 ( /16 legacy + /20) and have enough space to last me for
> a while,  multi-homed, BGP4 full tables + peering, ect.
>
> I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core.
>
>
>
> I want to start building my IPv6 infrastructure.
>
>
>
> I have a /32 assigned from ARIN (2001:4918::/32)
>
>
>
> I’m looking for some direction/reading list of how to properly configure
> IPv6.  I’ve read to use a /64 for PtP interfaces and I’ve read use a /128
> instead.Assign all loopbacks from the same /64, use a different /64 for
> each loopback. Ect, ect.
>
>
>
> I’m trying not to light a religious war but what is the current best
> practice for IPv6 deployment in a service provider network?
>
>
>
> PS.  I’ll be at NANOG69 in DC next month,  1st NANOG for me after 22
> years.  ☺
>
>
>
> -Matt
>
>
>
> --
>
> Matthew Crocker
>
> Crocker Communications, Inc.
>
> President
>
>

Re: Questions on IPv6 deployment

[Chris Russell]

I have a /32 assigned from ARIN (2001:4918::/32)

I’m looking for some direction/reading list of how to properly
configure IPv6.  I’ve read to use a /64 for PtP interfaces and I’ve
read use a /128 instead.Assign all loopbacks from the same /64,
use a different /64 for each loopback. Ect, ect.

I’m trying not to light a religious war but what is the current best
practice for IPv6 deployment in a service provider network?

PS.  I’ll be at NANOG69 in DC next month,  1st NANOG for me after 22 
years.  ☺


 At the start, the advice was to configure individual /64 for 
loopbacks, however latterly its assign a /64 for loopbacks and configure 
/128 instead.


 Stick with a /48 for sites/customers.

 The best advice is to use nibble boundaries  (see: 
https://www.ripe.net/manage-ips-and-asns/ipv6/ipv6-subnetting-card) 
hence /52 /56 /60


 I also recommend watching this (Tom Coffeen from Infoblox at UKNOF35 
which covers this exact subject):


 
https://www.youtube.com/watch?v=lWFcIk4oMMU=youtu.be=PLjzK5ZtLlc90teq9-rGzytIVu-hvsF9hd


 Its worth a watch and covers the basics


HTH

Chris

Questions on IPv6 deployment

[Matthew Crocker]

Hello,

I’m AS7849 and I have an IP problem.

I’m running IPv4 ( /16 legacy + /20) and have enough space to last me for  a 
while,  multi-homed, BGP4 full tables + peering, ect.
I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core.

I want to start building my IPv6 infrastructure.

I have a /32 assigned from ARIN (2001:4918::/32)

I’m looking for some direction/reading list of how to properly configure IPv6.  
I’ve read to use a /64 for PtP interfaces and I’ve read use a /128 instead.
Assign all loopbacks from the same /64, use a different /64 for each loopback. 
Ect, ect.

I’m trying not to light a religious war but what is the current best practice 
for IPv6 deployment in a service provider network?

PS.  I’ll be at NANOG69 in DC next month,  1st NANOG for me after 22 years.  ☺

-Matt

--
Matthew Crocker
Crocker Communications, Inc.
President

Re: Kudos to Rogers Wireless on IPv6 deployment

[Jay R. Ashworth]

- Original Message -
> From: "Ida Leung" 


> [ ...   ... ]  Fido Internet 
> is
> coming!   

Cool!

My gateway is 1:3603/150.  Who do I poll?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re:Kudos to Rogers Wireless on IPv6 deployment

[Ida Leung]

Yes, we have started the IPv6 enablement of our wireless network.  West was 
completed dual stack on Sept 29, Ontario will come next then east region.  
Rogers Internet has completed all the IPv6 enablement.  Fido Internet is 
coming!   Please email me directly for your IPv6 experience with Rogers.

...Ida (IPv6Mom)






  
This communication is confidential. We only send and receive email on the basis 
of the terms set out at 
www.rogers.com/web/content/emailnotice



Ce message est confidentiel. Notre transmission et r?ception de courriels se 
fait strictement suivant les modalit?s ?nonc?es dans l'avis publi? ? 
www.rogers.com/aviscourriel 
  

Re: Kudos to Rogers Wireless on IPv6 deployment

[Theodore Baschak]

I'm also seeing IPv6 on Rogers 4g/LTE on an Android in Winnipeg!
Looks like I'm part of 2605:8d80:400::/38

Theodore Baschak - AS395089 - Hextet Systems
https://ciscodude.net/ - https://hextet.systems/
http://mbix.ca/

> On Oct 1, 2016, at 10:37 PM, Hugo Slabbert  wrote:
> 
> So frequently on this list we hear people asking/begging their providers for 
> IPv6 roadmaps or chastising them for the lack of same, that I thought it 
> might be nice to actually give props to a provider actually moving the needle.
> 
> I was pleasantly surprised today to notice an IPv6 address on my Android 
> smartphone on the Rogers Wireless LTE network.  I had to do a double-take and 
> poke through test-ipv6.com to make sure something wasn't amiss, but there it 
> was: honest-to-$deity dual stack service on a Canadian mobile provider, with 
> a dual-stack resolver and everything! ;)
> 
> So, kudos, Rogers Wireless!
> 
> So that's Rogers on the wireless side (with Telus Mobility at last check 
> being in early stages but not yet fully rolled out), and basically Rogers, 
> Telus and a bunch of smaller or regional ISPs that have deployed IPv6 on 
> residential and/or business wired service.  Shaw?  Bell?  (FYI Bell, your 
> IPv6 Starter Kit linked from http://ipv6.bell.ca/ currently hits a 404.
> 
> -- 
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
> 

Re: Kudos to Rogers Wireless on IPv6 deployment

[Mikael Abrahamsson]

On Sat, 1 Oct 2016, Hugo Slabbert wrote:


So, kudos, Rogers Wireless!


http://labs.apnic.net/cgi-bin/ccpagev6?c=CA

Sort on "samples".

Seems Telus and Rogers are the only top10 with any double digit % IPv6 
users. Telus is at 65-70%, that's a really good number.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Kudos to Rogers Wireless on IPv6 deployment

[Lyndon Nerenberg]

> On Oct 1, 2016, at 8:37 PM, Hugo Slabbert  wrote:
> 
> So, kudos, Rogers Wireless!

This has also been live on Roger's Fido sub-brand for a while now, too.  
2605:8d80:484:: is live in Vancouver.

--lyndon

Kudos to Rogers Wireless on IPv6 deployment

[Hugo Slabbert]

So frequently on this list we hear people asking/begging their providers 
for IPv6 roadmaps or chastising them for the lack of same, that I thought 
it might be nice to actually give props to a provider actually moving the 
needle.


I was pleasantly surprised today to notice an IPv6 address on my Android 
smartphone on the Rogers Wireless LTE network.  I had to do a double-take 
and poke through test-ipv6.com to make sure something wasn't amiss, but 
there it was: honest-to-$deity dual stack service on a Canadian mobile 
provider, with a dual-stack resolver and everything! ;)


So, kudos, Rogers Wireless!

So that's Rogers on the wireless side (with Telus Mobility at last check 
being in early stages but not yet fully rolled out), and basically Rogers, 
Telus and a bunch of smaller or regional ISPs that have deployed IPv6 on 
residential and/or business wired service.  Shaw?  Bell?  (FYI Bell, your 
IPv6 Starter Kit linked from http://ipv6.bell.ca/ currently hits a 404.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



signature.asc
Description: Digital signature

Re: IPv6 Deployment for Mobile Subscribers

[Carsten Bormann]

RFC 6177:

   This document obsoletes RFC 3177, updating its recommendations in the
   following ways:

  1) It is no longer recommended that /128s be given out.  While
 there may be some cases where assigning only a single address
 may be justified, a site, by definition, implies multiple
 subnets and multiple devices.

Generally, when you look at an obsolete document such as

https://tools.ietf.org/html/rfc3177

there is a link to the current version ("Obsoleted by: 6177"):

https://tools.ietf.org/html/rfc6177

Do not use websites showing RFCs that do not show this information;
you'll be stuck with outdated specifications.

Grüße, Carsten


Ricardo Ferreira wrote:
> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
> 
> In RFC 3177, it says:
> 3. Address Delegation Recommendations
> 
>The IESG and the IAB recommend the allocations for the boundary
>between the public and the private topology to follow those general
>rules:
> 
>   -  /48 in the general case, except for very large subscribers.
>   -  /64 when it is known that one and only one subnet is needed by
>  design.
>   -  /128 when it is absolutely known that one and only one device
>  is connecting.
> 
> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.
> 
> Cheers
> 

Re: IPv6 Deployment for Mobile Subscribers

[Valdis . Kletnieks]

On Fri, 22 Jul 2016 10:54:48 +0200, Ricardo Ferreira said:
> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
>
> In RFC 3177, it says:

>   -  /128 when it is absolutely known that one and only one device
>  is connecting.

See this RFC, which is a recently released BCP:

7934 Host Address Availability Recommendations. L. Colitti, V. Cerf, S.
 Cheshire, D. Schinazi. July 2016. (Format: TXT=37124 bytes) (Also
 BCP0204) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7934)

In short - even when you have only one device connecting, you probably need
more than one address.

Also, consider the common practice of tethering


pgpqTrkjoYHfo.pgp
Description: PGP signature

Re: IPv6 Deployment for Mobile Subscribers

[Tore Anderson]

* Baldur Norddahl

> Den 22. jul. 2016 20.25 skrev "Ca By" :
> 
> > Phones, as in 3gpp? If so, each phone alway gets a /64, there is
> > no choice.
> >
> > https://tools.ietf.org/html/rfc6459  
> 
> Here the cell companies are marketing their 4G LTE as an alternative
> to DSL, Coax and fiber for internet access in your home with a 4G
> wifi router. If they can not do prefix delegation it is no
> alternative!

Actually, that /64 prefix is delegated, after a fashion. RFC 7278.

That said, according to RFC 6459 section 5.3, full DHCPv6-PD support
was specified in 3GPP Rel-10. Not sure if there are production
deployments of that yet though, and if not how far off they are. But at
least it looks like it's coming.

Tore

Re: IPv6 Deployment for Mobile Subscribers

[Ryan, Spencer]

> I would love to test it, but it will be no surprise that none of the four
carriers enabled IPv6.


Verizon Wireless has been dual stack for many years, before they ran out of 
public IPv4 addresses and switched handsets to RFC1918 space for v4.


From: NANOG <nanog-boun...@nanog.org> on behalf of Baldur Norddahl 
<baldur.nordd...@gmail.com>
Sent: Friday, July 22, 2016 4:10:41 PM
To: nanog@nanog.org
Subject: Re: IPv6 Deployment for Mobile Subscribers

Den 22. jul. 2016 20.25 skrev "Ca By" <cb.li...@gmail.com>:

> Phones, as in 3gpp? If so, each phone alway gets a /64, there is no
choice.
>
> https://tools.ietf.org/html/rfc6459

Here the cell companies are marketing their 4G LTE as an alternative to
DSL, Coax and fiber for internet access in your home with a 4G wifi router.
If they can not do prefix delegation it is no alternative!

I would love to test it, but it will be no surprise that none of the four
carriers enabled IPv6.

Regards

Baldur

Re: IPv6 Deployment for Mobile Subscribers

[Baldur Norddahl]

Den 22. jul. 2016 20.25 skrev "Ca By" :

> Phones, as in 3gpp? If so, each phone alway gets a /64, there is no
choice.
>
> https://tools.ietf.org/html/rfc6459

Here the cell companies are marketing their 4G LTE as an alternative to
DSL, Coax and fiber for internet access in your home with a 4G wifi router.
If they can not do prefix delegation it is no alternative!

I would love to test it, but it will be no surprise that none of the four
carriers enabled IPv6.

Regards

Baldur

Re: IPv6 Deployment for Mobile Subscribers

[Mikhail Gusarov]

Good day,

On 22 Jul 2016, at 10:54, Ricardo Ferreira wrote:

> Is there anyone here working in an ISP where IPv6 is deployed?

I am not, but I can answer from the consumer's point of view:

> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.

Tethering.

With best regards,
Mikhail.

Re: IPv6 Deployment for Mobile Subscribers

[Ca By]

On Friday, July 22, 2016, Ricardo Ferreira 
wrote:

> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
>
> In RFC 3177, it says:
> 3. Address Delegation Recommendations
>
>The IESG and the IAB recommend the allocations for the boundary
>between the public and the private topology to follow those general
>rules:
>
>   -  /48 in the general case, except for very large subscribers.
>   -  /64 when it is known that one and only one subnet is needed by
>  design.
>   -  /128 when it is absolutely known that one and only one device
>  is connecting.
>
> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.
>
> Cheers
>
>
Phones, as in 3gpp? If so, each phone alway gets a /64, there is no choice.

https://tools.ietf.org/html/rfc6459


> --
> Ricardo Ferreira
>

Re: IPv6 Deployment for Mobile Subscribers

[Ryan, Spencer]

As far as I'm aware Android still today does not support DHCPv6.


https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems


From: NANOG <nanog-boun...@nanog.org> on behalf of james machado 
<hvgeekwt...@gmail.com>
Sent: Friday, July 22, 2016 12:57:58 PM
To: Ricardo Ferreira
Cc: NANOG
Subject: Re: IPv6 Deployment for Mobile Subscribers

Ricardo,

I know from previous discussions on this list that Android phones are
looking for DHCPD leases and not /128's or /64's.  From what I remember
this is due to the current requirement for multiple ipv6 subnets for
various applications (vpns among others) to function correctly.  As a
result Google has disabled Android from receiving a DHCP lease as it wasn't
long enough.

if you look back about 6 months there is probably 100+ posts on the subject.

All I really know is that I can not provide an ipv6 dhcp lease to an
android phone and have it receive the address.


james

On Fri, Jul 22, 2016 at 1:54 AM, Ricardo Ferreira <
ricardofbferre...@gmail.com> wrote:

> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
>
> In RFC 3177, it says:
> 3. Address Delegation Recommendations
>
>The IESG and the IAB recommend the allocations for the boundary
>between the public and the private topology to follow those general
>rules:
>
>   -  /48 in the general case, except for very large subscribers.
>   -  /64 when it is known that one and only one subnet is needed by
>  design.
>   -  /128 when it is absolutely known that one and only one device
>  is connecting.
>
> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.
>
> Cheers
>
> --
> Ricardo Ferreira
>

Re: IPv6 Deployment for Mobile Subscribers

[james machado]

Ricardo,

I know from previous discussions on this list that Android phones are
looking for DHCPD leases and not /128's or /64's.  From what I remember
this is due to the current requirement for multiple ipv6 subnets for
various applications (vpns among others) to function correctly.  As a
result Google has disabled Android from receiving a DHCP lease as it wasn't
long enough.

if you look back about 6 months there is probably 100+ posts on the subject.

All I really know is that I can not provide an ipv6 dhcp lease to an
android phone and have it receive the address.


james

On Fri, Jul 22, 2016 at 1:54 AM, Ricardo Ferreira <
ricardofbferre...@gmail.com> wrote:

> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
>
> In RFC 3177, it says:
> 3. Address Delegation Recommendations
>
>The IESG and the IAB recommend the allocations for the boundary
>between the public and the private topology to follow those general
>rules:
>
>   -  /48 in the general case, except for very large subscribers.
>   -  /64 when it is known that one and only one subnet is needed by
>  design.
>   -  /128 when it is absolutely known that one and only one device
>  is connecting.
>
> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.
>
> Cheers
>
> --
> Ricardo Ferreira
>

IPv6 Deployment for Mobile Subscribers

[Ricardo Ferreira]

Is there anyone here working in an ISP where IPv6 is deployed?
We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
am interesting in knowing the mask you use for the assignment; whether it
is /64 or /128.

In RFC 3177, it says:
3. Address Delegation Recommendations

   The IESG and the IAB recommend the allocations for the boundary
   between the public and the private topology to follow those general
   rules:

  -  /48 in the general case, except for very large subscribers.
  -  /64 when it is known that one and only one subnet is needed by
 design.
  -  /128 when it is absolutely known that one and only one device
 is connecting.

Basically a sole device will be connecting to the internet so I am
wondering if this rule is follwed.

Cheers

-- 
Ricardo Ferreira

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

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