I think he means new releases are v6 for the first 48 hours...then trickle to v4. Which means that people wanting to see that new release urgently would have to wait two days. Netflix is definitely not the service to do that. Hulu, Amazon or HBO GO maybe. Netflix content tends to be pretty old (apart from their own content, of course). Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Sep 29, 2015 at 4:48 PM, Ca By <cb.list6@gmail.com> wrote:

On Tue, Sep 29, 2015 at 1:37 PM, David Hubbard < dhubbard@dino.hostasaurus.com> wrote:

...

Had an idea the other day; we just need someone with a lot of cash (google, apple, etc) to buy Netflix and then make all new releases v6-only for the first 48 hours. I bet my lame Brighthouse and Fios service would be v6-enabled before the end of the following week lol.

David

Yeah, i am sure VZ is going to cry a river that you cannot reach Netflix

We already slowed down IPv4 by 10-15%*, i think we can crank it down another 10-20% to punish the Luddites (AWS, Azure, Twitter, Bing, ...)

CB *

https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-bo...

On 29 Sep 2015, at 20:48 , Ca By <cb.list6@gmail.com> wrote:

On Tue, Sep 29, 2015 at 1:37 PM, David Hubbard < dhubbard@dino.hostasaurus.com> wrote:

...

Had an idea the other day; we just need someone with a lot of cash (google, apple, etc) to buy Netflix and then make all new releases v6-only for the first 48 hours. I bet my lame Brighthouse and Fios service would be v6-enabled before the end of the following week lol.

David

Yeah, i am sure VZ is going to cry a river that you cannot reach Netflix

We already slowed down IPv4 by 10-15%*, i think we can crank it down another 10-20% to punish the Luddites (AWS, Azure, Twitter, Bing, ...)

CB * https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-bo...

Well the good news is that Netflix does IPv6 for video content streaming, the bad news is that the IPv4 “slow down” (aka baseline) won’t make the video content go slower ;-) And yes, I guess, if we could make AWS more IPv6-ish then Netflix v6only might actually become possible for people who want to. /bz

s/creating an/exacerbating the/ Owen

On Sep 29, 2015, at 22:42 , Mark Andrews <marka@isc.org> wrote:

Ban the selling of IPv4 only home routers. The continued sale of these devices is just creating a e-waste problem.

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 30 September 2015 at 21:41, McElearney, Kevin < Kevin_McElearney@cable.comcast.com> wrote:

This only helps 1/3 of the challenge. Even with most Comcast customers able to obtain IPv6 today and over 70% provisioned with IPv6, less than 20% of the traffic is IPv6. There is still a need to address home device support and content provider adoption.

We will never get there 100%. There are many sites out there running 100% on autopilot. They will stay IPv4 forever until the server crashes and never comes back online. The same will be true for many homes. People who don't want to change anything. They will keep Windows XP and whatever antique device they use to connect to the internet until the thing catches fire from the accumulated dust. And then they will go on ebay to buy a replacement exactly the same. Remember that people with Windows XP with their ancient version of Internet Explorer already can not access many sites. They don't care. I believe the real goal is to get to a point, where people will accept the more invasive transition technologies such as NAT64, because everything they care about is IPv6 enabled. At some point people will start making IPv6 only sites, because everyone they know have IPv6 access. At that point the internet will split into two - the people that have access to the whole thing (IPv6+IPv4) and the IPv4-only people. Yet a lot of those IPv4-only people will stay IPv4-only even though they know they are missing out on something. Because Gmail and Facebook will always be available on IPv4 and that is all they care about. Regards, Baldur

On 1 October 2015 at 03:26, Mark Andrews <marka@isc.org> wrote:

Windows XP does IPv6 fine so long as there is a IPv4 recursive server available. It's just a simple command to install IPv6.

netsh interface ipv6 install

If the customer knew how to do that he wouldn't still be using Windows XP.

Actually I don't expect Gmail and Facebook to be IPv4 only forever.

Gmail and Facebook are already dual stack enabled. But I do not see Facebook turning off IPv4 for a very long time. Therefore a customer that only uses the Internet for a few basic things will be able to get along with being IPv4-only for a very long time. IPv6 has no killer feature for this customer segment. They will be upgraded the next time they move and get new equipment. Otherwise they will stay with what they got until the retirement home. Regards, Baldur

On 10/1/2015 2:29 PM, Owen DeLong wrote:

...

On Oct 1, 2015, at 00:39 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

On 1 October 2015 at 03:26, Mark Andrews <marka@isc.org> wrote:

...

Windows XP does IPv6 fine so long as there is a IPv4 recursive server available. It's just a simple command to install IPv6.

netsh interface ipv6 install

If the customer knew how to do that he wouldn't still be using Windows XP.

...

Actually I don't expect Gmail and Facebook to be IPv4 only forever.

Gmail and Facebook are already dual stack enabled. But I do not see Facebook turning off IPv4 for a very long time. Therefore a customer that only uses the Internet for a few basic things will be able to get along with being IPv4-only for a very long time.

Yes and no…

I think you are right about facebook.

However, I think eventually the residential ISPs are going to start charging extra for IPv4 service. Some residences may pay for it initially, but if they think there’s a way to move away from it and the ISPs start fingerpointing to the specific laggards, you’ll see a groundswell of consumers pushing to find alternatives.

Owen

ipv6 is going to force a lot of consumers to replace hardware. Worse, it's not easy to set up and get right as ipv4 is. --Curtis

If Time Warner (my ISP) put up IPv6 tomorrow, my firewall would no longer work. I could put up a pfsnse or vyatta box pretty quickly, but my off the shelf Cisco/Linksys home router has no ipv6 support hence the need to replace the hardware. There's no firmware update for it supporting ipv6 either. There would be millions of people in the same boat. Cheers, Curtis On October 1, 2015 5:44:46 PM ADT, Owen DeLong <owen@delong.com> wrote:

...

On Oct 1, 2015, at 12:06 , Curtis Maurand <cmaurand@xyonet.com> wrote:

...

...

On Oct 1, 2015, at 00:39 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

On 1 October 2015 at 03:26, Mark Andrews <marka@isc.org> wrote:

...

Windows XP does IPv6 fine so long as there is a IPv4 recursive server available. It's just a simple command to install IPv6.

netsh interface ipv6 install

If the customer knew how to do that he wouldn't still be using Windows XP.

...

Actually I don't expect Gmail and Facebook to be IPv4 only forever.

Gmail and Facebook are already dual stack enabled. But I do not see Facebook turning off IPv4 for a very long time. Therefore a customer that only uses the Internet for a few basic things will be able to get along with being IPv4-only for a very long time.

Yes and no…

I think you are right about facebook.

However, I think eventually the residential ISPs are going to start charging extra for IPv4 service. Some residences may pay for it initially, but if

On 10/1/2015 2:29 PM, Owen DeLong wrote: they think there’s a

...

way to move away from it and the ISPs start fingerpointing to the specific laggards, you’ll see a groundswell of consumers pushing to find alternatives.

Owen

ipv6 is going to force a lot of consumers to replace hardware. Worse, it's not easy to set up and get right as ipv4 is.

--Curtis

You’re going to have to elaborate on that one…. I think IPv6 is actually quite a bit easier than IPv4, so please explicate in what ways it is harder to set up and get right?

For the average household, it’s plug the IPv6-capable router in and let it go.

For more advanced environments, it might take nearly as much effort as IPv4 and the unfamiliarity might add a couple of additional challenges the first time, but once you get past that, IPv6 has a lot of features that actually make it easier than IPv4.

Not having to deal with NAT being just one of the big ones.

Owen

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

You make a point, but those ipv6 addresses would not be a available to my cpe. I would agree that if your cpe is less than 5 years old, it should support ipv6. On October 2, 2015 12:30:56 AM ADT, Mark Andrews <marka@isc.org> wrote:

In message <2BB18527-2F9C-4FEE-95DD-3F89919A8049@xyonet.com>, Curtis Maurand wr ites:

...

If Time Warner (my ISP) put up IPv6 tomorrow, my firewall would no longer wo rk. I could put up a pfsnse or vyatta box pretty quickly, but my off the sh elf Cisco/Linksys home router has no ipv6 support hence the need to replace the hardware. There's no firmware update for it supporting ipv6 either. The re would be millions of people in the same boat.

Total garbage that *everyone* here should recognise as total garbage. If Time Warner turned on IPv6 your firewall would just continue to work as it always has. TURNING ON IPv6 DOES NOT TURN OFF IPV4.

As for millions of people needing to upgrade their CPE equipement you really should be asking yourself if you should be rewarding those vendors for selling you IPv4 only equipement in the first place. If Microsoft, along with lots of other vendors could deliver IPv6 capable equipment in 2001, your and every other CPE vendor could have done so. Instead they sold you out of date garbage that you happily accepted.

Mark

...

Cheers, Curtis

On October 1, 2015 5:44:46 PM ADT, Owen DeLong <owen@delong.com> wrote:

...

...

On Oct 1, 2015, at 12:06 , Curtis Maurand <cmaurand@xyonet.com> wrote:

On 10/1/2015 2:29 PM, Owen DeLong wrote:

...

...

On Oct 1, 2015, at 00:39 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

On 1 October 2015 at 03:26, Mark Andrews <marka@isc.org> wrote:

> Windows XP does IPv6 fine so long as there is a IPv4 recursive > server available. It's just a simple command to install IPv6. > > netsh interface ipv6 install > If the customer knew how to do that he wouldn't still be using Windows XP.

> Actually I don't expect Gmail and Facebook to be IPv4 only forever. > Gmail and Facebook are already dual stack enabled. But I do not

see

...

...

...

...

Facebook turning off IPv4 for a very long time. Therefore a customer that only uses the Internet for a few basic things will be able to get along with being IPv4-only for a very long time.

Yes and no���

I think you are right about facebook.

However, I think eventually the residential ISPs are going to start charging extra for IPv4 service. Some residences may pay for it initially, but if they think there���s a way to move away from it and the ISPs start fingerpointing to the specific laggards, you���ll see a groundswell of consumers pushing to find alternatives.

Owen

ipv6 is going to force a lot of consumers to replace hardware. Worse, it's not easy to set up and get right as ipv4 is.

--Curtis

You���re going to have to elaborate on that one���. I think IPv6 is actually quite a bit easier than IPv4, so please explicate in what ways it is harder to set up and get right?

For the average household, it���s plug the IPv6-capable router in and let it go.

For more advanced environments, it might take nearly as much effort as IPv4 and the unfamiliarity might add a couple of additional challenges the first time, but once you get past that, IPv6 has a lot of features that actually make it easier than IPv4.

Not having to deal with NAT being just one of the big ones.

Owen

-- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Hardware upgrades aren’t difficulty inherent in the protocol. Sure, everyone has to upgrade their hardware sometimes. Whether it’s to get IPv6 capable hardware or to address some other need, periodic hardware upgrades are a simple fact of life. However, if TW put up IPv6 tomorrow as dual-stack, your firewall would not stop working, you just wouldn’t be able to use IPv6 until you upgraded. Owen

On Oct 1, 2015, at 19:52 , Curtis Maurand <cmaurand@xyonet.com> wrote:

If Time Warner (my ISP) put up IPv6 tomorrow, my firewall would no longer work. I could put up a pfsnse or vyatta box pretty quickly, but my off the shelf Cisco/Linksys home router has no ipv6 support hence the need to replace the hardware. There's no firmware update for it supporting ipv6 either. There would be millions of people in the same boat.

Cheers, Curtis

On October 1, 2015 5:44:46 PM ADT, Owen DeLong <owen@delong.com> wrote:

On Oct 1, 2015, at 12:06 , Curtis Maurand <cmaurand@xyonet.com> wrote:

On 10/1/2015 2:29 PM, Owen DeLong wrote: On Oct 1, 2015, at 00:39 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

On 1 October 2015 at 03:26, Mark Andrews <marka@isc.org> wrote:

Windows XP does IPv6 fine so long as there is a IPv4 recursive server available. It's just a simple command to install IPv6.

netsh interface ipv6 install

If the customer knew how to do that he wouldn't still be using Windows XP.

Actually I don't expect Gmail and Facebook to be IPv4 only forever.

Gmail and Facebook are already dual stack enabled. But I do not see Facebook turning off IPv4 for a very long time. Therefore a customer that only uses the Internet for a few basic things will be able to get along with being IPv4-only for a very long time.

Yes and no…

I think you are right about facebook.

However, I think eventually the residential ISPs are going to start charging extra for IPv4 service. Some residences may pay for it initially, but if they think there’s a way to move away from it and the ISPs start fingerpointing to the specific laggards, you’ll see a groundswell of consumers pushing to find alternatives.

Owen

ipv6 is going to force a lot of consumers to replace hardware. Worse, it's not easy to set up and get right as ipv4 is.

--Curtis

You’re going to have to elaborate on that one…. I think IPv6 is actually quite a bit easier than IPv4, so please explicate in what ways it is harder to set up and get right?

For the average household, it’s plug the IPv6-capable router in and let it go.

For more advanced environments, it might take nearly as much effort as IPv4 and the unfamiliarity might add a couple of additional challenges the first time, but once you get past that, IPv6 has a lot of features that actually make it easier than IPv4.

Not having to deal with NAT being just one of the big ones.

Owen

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

On Oct 1, 2015, at 13:55 , Grzegorz Janoszka <Grzegorz@Janoszka.pl> wrote:

On 2015-10-01 20:29, Owen DeLong wrote:

...

However, I think eventually the residential ISPs are going to start charging extra for IPv4 service.

ISP's will not charge too much. With too expensive IPv4 many customers will migrate from v4/dual stack to v6-only and ISP's will be left with unused IPv4 addresses and less income.

Nope… They’ll be left with unused IPv4 addresses which is not a significant source of income and they’ll be able to significantly reduce the costs incurred in supporting things like CGNAT.

Will ISP's still find other profitable usage for v4 addresses? If not, they will be probably be quite slowly rising IPv4 pricing, not wanting to overprice it.

Probably they will sell it to business customers instead of the residential customers. However, we’re talking about relatively large numbers of customers for relatively small numbers of IPv4 addresses that aren’t producing revenue directly at this time anyway.

Even with $1/IPv4/month - what will be the ROI of a brand new home router?

About 2.5 years at that price since a brand new home router is about $29. Owen

i'm still confused, to be honest. why are we 'encouraging' 'evangelizing' or 'forcing' ipv6 adoption. it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake, but i guess we're stuck with that now (i wish i could say something about lessons learned but i don't think any one of us has learned a lesson yet). so people will renumber their network assets into this new network namespace when either: 1) the new non-internet ipv6 network has enough good stuff only on it that it makes sense to go over there; or 2) the old ipv4 internet addresses get so expensive that ain't no one willing to pay. right now, neither of those things are true. so people who are adopting ipv6 are doing so for two reason: A) blind, unmotivated religious reasons. they "believe" in this new protocol and have somehow managed to tie their identity up in it. (this is clearly a mistake for an engineer: technology comes and goes. don't ever tie your identity up in some technology or you'll end up advocating DECNET for the cloud at some point. it won't be pretty). B) strategic reasons. there are people who think that switching costs are going to be high and that there's an advantage to moving earlier to be ready for coming demand when #1 or #2 above happen. unlike A, B is completely rational and smart. it might be wrong, but it's not stupid at all. put mike leber and HE in this B category. the only reason people are *advocating* ipv6 right now are that they've made a religious choice, which is weird and should be a personal, not public choice unless they are great commission ipv6 adherants [1], *or* they have a vested interest in getting your business. the first reason is religion and is off-topic for nanog and the second reason is marketing (however well intentioned) and should also be off topic for nanog. so can we stop talking about ipv6 advocacy and move on to the network engineering topics, please? if someone is running ipv6 for whatever reason and has questions, awesome. if someone wants to talk about addressing schemes, awesome. but trying to convince someone to run LAT^H^H^Hipv6 or whatever disconnected network protocol they're advocating today? not useful. cheers, t On Thu, Oct 1, 2015 at 6:32 PM Mark Andrews <marka@isc.org> wrote:

In message <4F2E19BA-D92A-4BEC-86E2-33B405C307BE@delong.com>, Owen DeLong writes:

...

...

On Oct 1, 2015, at 13:55 , Grzegorz Janoszka <Grzegorz@Janoszka.pl> wrote:

On 2015-10-01 20:29, Owen DeLong wrote:

...

However, I think eventually the residential ISPs are going to start charging extra for IPv4 service.

ISP's will not charge too much. With too expensive IPv4 many customers will migrate from v4/dual stack to v6-only and ISP's will be left with unused IPv4 addresses and less income.

Nope… They’ll be left with unused IPv4 addresses which is not a significant source of income and they’ll be able to significantly reduce the costs incurred in supporting things like CGNAT.

...

Will ISP's still find other profitable usage for v4 addresses? If not, they will be probably be quite slowly rising IPv4 pricing, not wanting to overprice it.

Probably they will sell it to business customers instead of the residential customers. However, we’re talking about relatively large numbers of customers for relatively small numbers of IPv4 addresses that aren’t producing revenue directly at this time anyway.

...

Even with $1/IPv4/month - what will be the ROI of a brand new home router?

About 2.5 years at that price since a brand new home router is about $29.

Owen

The hard part is the internet connected TV's and other stuff which fetches content over the internet which are IPv4 only despite being released when IPv6 existed. These are theoretically upgradable to support IPv6 so long as the manufactures release a IPv6 capable image. The real question is will governments force them to do this.

Upgrading the router is a no brainer. Upgrading the TV, games consoles, e-readers, etc. starts to add up.

Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

I can't tell if this question is serious. It's either making fun of the embarrassingly inadequate job we have done on this transition out it's naive and ignorant in a genius way. Read the asn32 migration docs for one that migrations like this can be properly done. This was harder but not impossible. We just chose badly for decades and now we have NAT *and* a dumb migration. Oh well. T On Oct 1, 2015 19:26, "Matthew Newton" <mcn4@leicester.ac.uk> wrote:

On Thu, Oct 01, 2015 at 10:42:57PM +0000, Todd Underwood wrote:

...

it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake, but i guess we're stuck with that now (i wish i could say something about lessons learned but i don't think any one of us has learned a lesson yet).

Would be really interesting to know how you would propose squeezing 128 bits of address data into a 32 bit field so that we could all continue to use IPv4 with more addresses than it's has available to save having to move to this new incompatible format.

:-)

Matthew

-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>

Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>

That sounds like only using 6to4 addresses until the entire internet

supports IPv6.

Unfortunately there were NEVER enough IPv4 addresses to actually do that. We were effectively out of IPv4 addresses before we started.

People tend to forget that TCP/IP was not the only routing protocol out there all those years ago. What if OSI or one of the others had prospered instead ? IPv4 kind of morphed into the Internet as we know it more it more from good luck than good planning I would say. Things could have been a lot worse ! To name a few - IPX, X25, Banyan Vines, DECnet and even Appletalk! Ovbiously many of these could not grow into the "internet" but.....

this is an interesting example of someone who has ill advisedly tied up his identity in a network protocol. this is a mistake i encourage you all not to make. network protocols come and go but you only get one shot at life, so be your own person. this is ad-hominem, owen and i won't engage. feel free to be principled and have technical discussion but insults and attacks really have no place. so please just stop and relax. thanks, t On Thu, Oct 1, 2015 at 8:53 PM, Owen DeLong <owen@delong.com> wrote:

OK… Let’s look at the ASN32 process.

Use ASN 23456 (16-bit) in the AS-Path in place of each ASN32 entry in the path. Preserve the ASN32 path in a separate area of the BGP attributes.

So, where in the IPv4 packet do you suggest we place these extra 128 bits of address?

Further, what mechanism do you propose for forwarding to the 128 bit destination by looking at the value in the 32 bit field?

The closest I can come to a viable implementation of what you propose would be to encapsulate IPv6 packets between IPv6 compatible hosts in an IPv4 datagram which is pretty much what 6in4 would be.

If you want the end host on the other side to be able to send a reply packet, then it pretty much has to be able to somehow handle that 128 bit reply address to set up the destination for the reply packet, no? (No such requirements for ASN32).

Seriously, Todd, this is trolling pure and simple.

Unless you have an actual complete mechanism for solving the problem, you’re just doing what you do best… Trolling.

Admittedly, most of your trolling has enough comedic value that we laugh and get past it, but nonetheless, let’s see if you have a genuine solution to offer or if this is just bluster.

Owen

...

On Oct 1, 2015, at 16:52 , Todd Underwood <toddunder@gmail.com> wrote:

I can't tell if this question is serious. It's either making fun of the embarrassingly inadequate job we have done on this transition out it's naive and ignorant in a genius way.

Read the asn32 migration docs for one that migrations like this can be properly done.

This was harder but not impossible. We just chose badly for decades and now we have NAT *and* a dumb migration.

Oh well.

T On Oct 1, 2015 19:26, "Matthew Newton" <mcn4@leicester.ac.uk> wrote:

...

On Thu, Oct 01, 2015 at 10:42:57PM +0000, Todd Underwood wrote:

...

it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake, but i guess we're stuck with that now (i wish i could say something about lessons learned but i don't think any one of us has learned a lesson yet).

Would be really interesting to know how you would propose squeezing 128 bits of address data into a 32 bit field so that we could all continue to use IPv4 with more addresses than it's has available to save having to move to this new incompatible format.

:-)

Matthew

-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>

Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>

Either there are multiple translation systems that exist that were invented late or there are not. Either Owen has never heard of any of them or he is trolling. In any case I'm giving up on that conversation. And this whole one. It goes nowhere. And this is why v6 is where it is: true believers. Instead of a simple, practical matter of engineering a transition we got 15 years of advocacy. It makes the sleazy v4 transfer market look appealing. :) T On Oct 1, 2015 8:59 PM, "Owen DeLong" <owen@delong.com> wrote:

I’m not at all tied up in a particular protocol.

Still, Todd, ignoring the other parts, the least you can do is answer this simple question:

How would you implement a 128-bit address that is backwards compatible with existing IPv4 hosts requiring no software modification on those hosts? Details matter here. Handwaving about ASN32 doesn’t cut it.

If you can’t answer that, there’s really nothing to your argument.

Owen

On Oct 1, 2015, at 17:56 , Todd Underwood <toddunder@gmail.com> wrote:

this is an interesting example of someone who has ill advisedly tied up his identity in a network protocol. this is a mistake i encourage you all not to make. network protocols come and go but you only get one shot at life, so be your own person.

this is ad-hominem, owen and i won't engage. feel free to be principled and have technical discussion but insults and attacks really have no place. so please just stop and relax.

thanks,

t

On Thu, Oct 1, 2015 at 8:53 PM, Owen DeLong <owen@delong.com> wrote:

...

OK… Let’s look at the ASN32 process.

Use ASN 23456 (16-bit) in the AS-Path in place of each ASN32 entry in the path. Preserve the ASN32 path in a separate area of the BGP attributes.

So, where in the IPv4 packet do you suggest we place these extra 128 bits of address?

Further, what mechanism do you propose for forwarding to the 128 bit destination by looking at the value in the 32 bit field?

The closest I can come to a viable implementation of what you propose would be to encapsulate IPv6 packets between IPv6 compatible hosts in an IPv4 datagram which is pretty much what 6in4 would be.

If you want the end host on the other side to be able to send a reply packet, then it pretty much has to be able to somehow handle that 128 bit reply address to set up the destination for the reply packet, no? (No such requirements for ASN32).

Seriously, Todd, this is trolling pure and simple.

Unless you have an actual complete mechanism for solving the problem, you’re just doing what you do best… Trolling.

Admittedly, most of your trolling has enough comedic value that we laugh and get past it, but nonetheless, let’s see if you have a genuine solution to offer or if this is just bluster.

Owen

...

On Oct 1, 2015, at 16:52 , Todd Underwood <toddunder@gmail.com> wrote:

I can't tell if this question is serious. It's either making fun of the embarrassingly inadequate job we have done on this transition out it's naive and ignorant in a genius way.

Read the asn32 migration docs for one that migrations like this can be properly done.

This was harder but not impossible. We just chose badly for decades and now we have NAT *and* a dumb migration.

Oh well.

T On Oct 1, 2015 19:26, "Matthew Newton" <mcn4@leicester.ac.uk> wrote:

...

On Thu, Oct 01, 2015 at 10:42:57PM +0000, Todd Underwood wrote:

...

it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake, but i guess we're stuck with that now (i wish i could say something about lessons learned but i don't think any one of us has learned a lesson yet).

Would be really interesting to know how you would propose squeezing 128 bits of address data into a 32 bit field so that we could all continue to use IPv4 with more addresses than it's has available to save having to move to this new incompatible format.

:-)

Matthew

-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>

Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>

On Fri, Oct 2, 2015 at 2:07 PM, Owen DeLong <owen@delong.com> wrote:

None of them does what you propose — Smooth seamless communication between an IPv4-only host and an IPv6-only host.

i view this point/question as an assertion by owen as follows: "it was never possible to design a smooth transition and that's why we gave up on it." furthermore, it's a also the following assertion: "it was never possible to expand our address space while allowing for an actual migration." if you believe that, then you end up in advocacy land. if you don't believe that but you see lots of people who gave up on the design process early, then you understand why we're here. v6 was designed without a migration plan and it wasn't believed to be important, or possibly wasn't believed to be possible. but there was never any pressure to use v6 because v4 worked well and we had plenty of addresses. we still have plenty of addresses and although they're no longer ~free from quasi-governmental organizations they're way cheaper than the cost to implement v6. so we're still going to use v4 ~forever.

So, please, Todd, explicate exactly how you would achieve that stated objective… What could you do differently on the IPv6-only host side that would allow smooth seamless connectivity to/from the IPv4 host while still providing a larger address space?

it sounds like you're interested in having the engineering conversation that should have been had ~15 years ago. me, too 15 years ago. sigh. i know owen is now just trolling because he's threatened by the idea that there might be something wrong with ipv6, but the reality is that none of this was necessary. ipv6 might have been done differently with a different header format and different choices around migration. routing could have been done differently to try to preserve end-to-end but still splitting locators and identifiers (which i know that dave meyer thinks might not be possible but i'm still more sanguine about). we could have explicitly made smooth migration an engineering requirement just as much as "more addresses" were. we didn't. that's fine. so we got a disconnected network that some things can talk to and others can't. and we put the full burden all the way to every edge. and now we have conversations about how to upgrade home cpe everywhere. it's tedious and boring and dumb but it's the direct result of every decision we made and how we prioritized things. so, for clarity, this "how do you magically enable smooth migration now that we didn't prioritize it in the protocol design" question is a bogus red herring. the answer is: "you prioritize it in the protocol design". i assume smart people can see that. owen: i understand you like v6 and that it's important to you. that doesn't mean it's perfect and it doesn't mean we couldn't have done better. stop being so hostile and so threatened and try to listen a bit. or don't. whatever works for you. cheers! t

In any case I'm giving up on that conversation. And this whole one. It goes nowhere.

And this is why v6 is where it is: true believers. Instead of a simple, practical matter of engineering a transition we got 15 years of advocacy.

If it’s so simple, why do you continue to refuse to explain the process?

Owen

On Friday, October 2, 2015, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

Why are some people here asserting that IPv6 failed when it looks like it is actually taking off pretty good right now?

https://www.google.com/intl/en/ipv6/statistics.html

Jan 2013 about 1% Jan 2014 about 2.5% Jan 2015 about 5% It is already past 9% so we will be at least at 10% by Jan 2016.

Looks like a good exponential growth to me.

The numbers for USA are even better at 21%.

Traffic volume is also taking off:

https://www.akamai.com/us/en/solutions/intelligent-platform/visualizing-akam...

I will bet you good money that in a not too distant future we will see that IPv6 moves more bytes than IPv4.

For some of us, IPv6 is already more bytes than IPv4. Youtube and netflix and fb will push the bytes if the users request it. CB

The IPv6 protocol is 17 years so it failed argument is meaningless. Maybe we needed IPv4 exhaustion before IPv6 could take off. No matter the reason, it is happening now.

Regards,

Baldur

On Oct 2, 2015, at 13:45 , Todd Underwood <toddunder@gmail.com> wrote:

On Fri, Oct 2, 2015 at 2:07 PM, Owen DeLong <owen@delong.com> wrote:

...

None of them does what you propose — Smooth seamless communication between an IPv4-only host and an IPv6-only host.

i view this point/question as an assertion by owen as follows:

"it was never possible to design a smooth transition and that's why we gave up on it."

furthermore, it's a also the following assertion:

"it was never possible to expand our address space while allowing for an actual migration."

if you believe that, then you end up in advocacy land. if you don't believe that but you see lots of people who gave up on the design process early, then you understand why we're here.

v6 was designed without a migration plan and it wasn't believed to be important, or possibly wasn't believed to be possible. but there was never any pressure to use v6 because v4 worked well and we had plenty of addresses. we still have plenty of addresses and although they're no longer ~free from quasi-governmental organizations they're way cheaper than the cost to implement v6. so we're still going to use v4 ~forever.

OK, so if you think those are assertions rather than fact, it should be pretty easy for you to disprove them by presenting an example of a workable solution.

...

So, please, Todd, explicate exactly how you would achieve that stated objective… What could you do differently on the IPv6-only host side that would allow smooth seamless connectivity to/from the IPv4 host while still providing a larger address space?

it sounds like you're interested in having the engineering conversation that should have been had ~15 years ago. me, too 15 years ago. sigh.

I’m willing to have it now if you’re up for it. So far, all I see is handwaving claiming that it wasn’t had 15 years ago or that the fact that the conversation 15 years ago resulted in a decision that it simply wasn’t possible was somehow incomplete rather than a recognition of the facts at hand. I’ve given quite a bit of thought to it actually and I admit I haven’t been able to come up with anything better than what we have in terms of migration strategies.

i know owen is now just trolling because he's threatened by the idea that there might be something wrong with ipv6, but the reality is that none of this was necessary. ipv6 might have been done differently with a different header format and different choices around migration. routing could have been done differently to try to preserve end-to-end but still splitting locators and identifiers (which i know that dave meyer thinks might not be possible but i'm still more sanguine about). we could have explicitly made smooth migration an engineering requirement just as much as "more addresses" were.

First, this is absurd. I’m trying to engage you in a productive discussion, despite your best efforts to avoid one. I’m the first person to admit that there are a number of things wrong with IPv6, but there are also a lot of things wrong with IPv4 and any other human invention throughout history. However, none of what you propose above solves the problem at hand… How does an unmodified IPv4 host accept a packet from a host with only a 128-bit address and reply to it from it’s 32-bit address using a packet format (IPv4) that only supports 32-bit addresses? I agree that it would have been ideal (for other reasons, actually) if the IPv6 packet had a 32-bit field for “Destination ASN” in it so that we could have populated that field at the first DFZ router and then let the packet get routed through the IDR area using just the ASN tag. Unfortunately, that didn’t happen. (Of course now we have lots of networks that, for reasons passing understanding, have deployed ASNs in an incompatible way where they have multiple separate collections of prefixes with distinct routing protocols using a single ASN). Again, if you have a solution… An actual solution, present your proposed packet header. Tell us how it would work. Tell us how the IPv4-only host with no software modifications would be able to accept connections from and respond to a host which has no unique 32-bit identifier available to it.

we didn't. that's fine. so we got a disconnected network that some things can talk to and others can't. and we put the full burden all the way to every edge. and now we have conversations about how to upgrade home cpe everywhere. it's tedious and boring and dumb but it's the direct result of every decision we made and how we prioritized things.

Yet you still haven’t presented an actual workable alternative. Lots of people smarter than me have also pondered this question and failed to come up with a workable alternative. It’s not that nobody wanted what you describe… It’s that we couldn’t find a way to implement it. If you have a solution, please present it. If you don’t, then please stop insulting everyone as if you somehow know better just because you can.

so, for clarity, this "how do you magically enable smooth migration now that we didn't prioritize it in the protocol design" question is a bogus red herring. the answer is: "you prioritize it in the protocol design". i assume smart people can see that.

It was originally prioritized in the protocol design until people much smarter than I am with much more experience and a great deal of math decided that it was mathematically impossible to do so. Again, if you have a real answer to the question, please provide it. Perhaps we can design something like what you propose and make it work. Perhaps not, but at least we’ll know where we failed. If you don’t have a real answer, then please recognize that many people did try to come up with one and couldn’t. That there’s actual math that says it’s not actually possible (I’m the first to admit the math could be wrong, but it’s not my math and I’m not that skilled in the math involved to say one way or another.). If you’re so much better than everyone else who looked at this problem that you found a solution where nobody else did, then, again, I implore you to share it with the rest of us. Otherwise, how about recognizing that a large number of people did the best they could with what they had at the time and we now have a protocol that works well enough, provides a sufficiently large address space for many more years of internet growth, and will eventually be the internet protocol. Once upon a time, IPv4 was this incompatible protocol that could only be spoken by some of the hosts on the NCP internet, you know.

owen: i understand you like v6 and that it's important to you. that doesn't mean it's perfect and it doesn't mean we couldn't have done better. stop being so hostile and so threatened and try to listen a bit. or don't. whatever works for you.

Actually, I like the internet and being able to continue to deploy it to far reaches of society is what is important to me. I recognize that IPv4 isn’t going to cut it and nobody, including you, has shown me a viable alternative other than IPv6. So… I’m not being hostile. I’m not threatened at all, and I’ve been listening. The problem is that you are talking a lot without saying anything. Todd: I understand you probably don’t have a real solution and that you don’t want to publicly admit that because it might be embarrassing after all your handwaving. It’s OK, I don’t blame you for that. However, I have listened to everything you said, including a number of erroneous assumptions about my position and where I am coming from which I find mostly amusing, but mildly harmful. I certainly understand how that perspective has corrupted your thinking about my words and I hope now that I have offered you a more accurate perspective, you will take the opportunity to review what I have said in a more accurate light. If you have a real solution, please share. If you don’t, that’s OK, but stop insisting that everyone else share your belief in magic and recognize that we need something with more than 32-bits of identifier space and we need it yesterday. We’re already way behind, so if you have a superior solution, let’s get it out there and see if we can get it moving. If not, how about you give the rest of us a hand implementing the solution we do have, ugly as it may be, instead of just snarking from the sidelines about how it’s never going to work? Owen

cheers!

t

...

In any case I'm giving up on that conversation. And this whole one. It goes nowhere.

And this is why v6 is where it is: true believers. Instead of a simple, practical matter of engineering a transition we got 15 years of advocacy.

If it’s so simple, why do you continue to refuse to explain the process?

Owen

In message <20151001232613.GD123100@rootmail.cc.le.ac.uk>, Matthew Newton writes:

On Thu, Oct 01, 2015 at 10:42:57PM +0000, Todd Underwood wrote:

...

it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake, but i guess we're stuck with that now (i wish i could say something about lessons learned but i don't think any one of us has learned a lesson yet).

Would be really interesting to know how you would propose squeezing 128 bits of address data into a 32 bit field so that we could all continue to use IPv4 with more addresses than it's has available to save having to move to this new incompatible format.

:-)

Matthew

Additionally it is now a OLD addressing protocol. We are about to see young adults that have never lived in a world without IPv6. It may not have been universally available when they were born but it was available. There are definitely school leavers that have never lived in a world where IPv6 did not exist. My daughter will be one of them next year when she finishes year 12. IPv6 is 7 months older than she is. Some of us have been running IPv6 in production for over a decade now and developing products that support IPv6 even longer. We have had 17 years to build up a universal IPv6 network. It should have been done by now. Mark

-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>

Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <CAB2RJyheVNOsVgC6Qzdk5c8QHzLhxBKmDd_rGbcGV3_0ky_qag@mail.gmail.com> , Todd Underwood writes:

one interesting thing to note...

On Thu, Oct 1, 2015 at 8:01 PM Mark Andrews <marka@isc.org> wrote:

...

Some of us have been running IPv6 in production for over a decade now and developing products that support IPv6 even longer.

We have had 17 years to build up a universal IPv6 network. It should have been done by now.

yes. huh. funny about that, right? what do you think accounts for that? *why* do you think that *17* *years* later people are still just barely using this thing.

i have a theory. i may have already mentioned that "dual stack and ipv4 will wither away by itself" turns out to have been a dumb idea that didn't happen. and there was no migration path other than that, really.

so v6 and v4 don't interoperate as designed and that was an afterthought that didn't really happen until recently (and in a way that's still arguably more complex than NAT). and here we are.

so here's my view: if you have some technical solution for a networking problem that no one wants for 17 years, you should really probably think about that. you might not even have to wait 17 years to figure out that something might be wrong.

most good stuff is adopted without "evangelism".

Actually most good stuff requires evangelism. Lots of good stuff has disappeared into history because there wasn't the right amount of evangelism. Not all good stuff is showy. Some of it every requires governments to enact laws to make companies do the right thing. Very little stuff gets anywhere without evangelism.

t

...

Mark

...

-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>

Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

--001a113f3ca014ae99052114159c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

...

</div><div>so v6 and v4 don't interoperate as designed and that was an= afterthought that didn't really happen until recently (and in a way th= at's still arguably more complex than NAT). =C2=A0and here we are.</div= <div><br></div><div>so here's my view: =C2=A0if you have some technica= l solution for a networking problem that no one wants for 17 years, you sho=

<div dir=3D"ltr"><br>one interesting thing to note...<div><br><div class=3D= "gmail_quote"><div dir=3D"ltr">On Thu, Oct 1, 2015 at 8:01 PM Mark Andrews = <<a href=3D"mailto:marka@isc.org">marka@isc.org</a>> wrote:<br></div>= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><br>Some of us have been running IPv6 in pro= duction for over a decade<br> now and developing products that support IPv6 even longer.<br> <br> We have had 17 years to build up a universal IPv6 network.=C2=A0 It<br> should have been done by now.<br></blockquote><div><br></div><div>yes. =C2= =A0huh. =C2=A0funny about that, right? =C2=A0what do you think accounts for= that? =C2=A0*why* do you think that *17* *years* later people are still ju= st barely using this thing.</div><div><br></div><div>i have a theory. =C2= =A0i may have already mentioned that "dual stack and ipv4 will wither = away by itself" turns out to have been a dumb idea that didn't hap= pen. and there was no migration path other than that, really.</div><div><br= uld really probably think about that. =C2=A0you might not even have to wait= 17 years to figure out that something might be wrong.</div><div><br></div>= <div>most good stuff is adopted without "evangelism".=C2=A0</div>= <div><br></div><div>t</div><div>=C2=A0</div><div>=C2=A0</div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"> Mark<br> <br> > --<br> > Matthew Newton, Ph.D. <<a href=3D"mailto:mcn4@le.ac.uk" target=3D"_= blank">mcn4@le.ac.uk</a>><br> ><br> > Systems Specialist, Infrastructure Services,<br> > I.T. Services, University of Leicester, Leicester LE1 7RH, United King= dom<br> ><br> > For IT help contact helpdesk extn. 2253, <<a href=3D"mailto:ithelp@= le.ac.uk" target=3D"_blank">ithelp@le.ac.uk</a>><br> --<br> Mark Andrews, ISC<br> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0INTERNET: <a href=3D"mailto:marka@isc.org" target=3D"_blank">mark= a@isc.org</a><br> </blockquote></div></div></div>

--001a113f3ca014ae99052114159c-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Greetings, Excuse my probable ignorance of such matters, but would it not then be preferred to create a whitelist of proven Email servers/ip's , and just drop the rest? Granted, one would have to create a process to vet anyone creating a new email server, but would that not be easier then trying to create and maintain new blacklists? - Blake On Thu, Oct 1, 2015 at 8:07 PM Rob McEwen <rob@invaluement.com> wrote:

RE: How to wish you hadn't rushed ipv6 adoption

Force the whole world to switch to IPv6 within the foreseeable future, abolish IPv4... all within several years or even within 50 years... and then watch spam filtering worldwide get knocked back to the stone ages while spammers and blackhat and grayhat ESPs laugh their way to the bank... that is, until e-mail becomes unworkable and is virtually abandoned.

I welcome IPv6 adoption in the near future in all but one area: the sending IPs of valid mail servers. Those need to stay IPv4 for as long as reasonably possible.

It turns out... the scarcity of IPv4 IPs in THIS area... is a feature, not a bug.

That scarcity makes it harder for spammers to acquire new IPs, and they therefore pay a price for the ones they burn through via their spam-sending. Likewise, scarcity of IPv4 IPs *forces* ESPs, hosters, and ISPs to try HARD to keep their IPs clean. THEY pay a price when a bad-apple customer soils up their IP space.

In contrast, with IPv6, order of magnitude MORE IPs are easily acquired, and order of magnitude more are in each allocation. It is truly a spammer's dream come true. This reminds me about a recent article Brian Krebs wrote about a famous hoster who slowly drove their business into the ground by allowing in the kind of spammers that look a little legit at first glance. (like the "CAN-SPAM" spammers who are doing nothing illegal, follow the law, but still send to purchase lists). But even this hoster's bank account was bursting at the seams with cash due to a booming business, their IP space's reputation was slowly turning in crap. Eventually, they started losing even their spammer customers. Then, their CEO made a decision to get serious about abuse and keeping spammers off of their network---and this turned into a success story where they now run a successful hosting business without the spammers. In an IPv6 world, I wonder if they would have ever even cared? There would always be new fresh IPv6 IPs to acquire! There would never have been the "motivation" to turn things around. There would always be new IPv6 IPs to move on to. (or at least enough available to "kick the can down the road" and not worry about any long term repercussions). It was ONLY when this CEO started seeing even the spammers start to leave him (along with some SpamHaus blacklistings)! that he realized that his IP reputation would eventually get so bad that he be virtually out of business. It was ONLY then that he decided to make changes. Would this have happened in an all-IPv6 world? I highly doubt it! He'd just keep moving on to fresh IPs!

The cumulative sum total of all those hosters and ESPs downward spiraling in an IPv6 world... could cause the spam problem to GREATLY accelerate.

Meanwhile, sender IP blacklists would become useless in an IPv6 world because the spammer now has enough IPs (in many scenarios) to EVEN SEND ONE SPAM PER IP, never to have to use that one IP again FOR YEARS, if ever. So a blacklisting is ineffective... and actually helps the spammer to listwash spamtrap addresses... since the ONE listing maps to a single recipient address. Now the sender's IP blacklist is even less effective and is helping the spammers more than it is blocking spam! And did I mention that the sender's IP list has bloated so large that it is hard to host in DNS and hard to distribute--and most of the listings are now useless anyways!

Yes, there are other types of spam filtering... including content filtering techniques. But in the real world, these only work because the heavy lifting is ALREADY done by the sender's IP blacklist. The vast majority of this worldwide "heavy lifting" is done by "zen.spamhaus.org". If many of the largest ISPs suddenly lost access to Zen, some such filters would be in huge trouble.... brought down to their knees. Now imagine that all the other sending-IP blacklists are gone too? In that spammer's dream scenario, the spammer has upgraded to a Lamborghini, while the spam filters have reverted back to the horse and buggy. Serious, that analogy isn't the slightest bit of an exaggeration.

Yes, you can STILL have your toaster and refrigerator and car send mail from an IPv6 address... they would just need to SMTP-Authenticate to a valid mail server... via an IPv6 connection... yet where that valid MTA would then send their mail to another MTA via IPv4. Since the number of IPv4 IPs needed for such valid mail servers is actually very, very small (relatively speaking), then it isn't a big problem for THOSE to get IPv4 addresses, at a trivial cost. We might even see IPv4 open up a bit as OTHER services move to IPv6. IPv6 addresses NOT being able to send directly to the e-mail recipient's IPv4 mail servers might actually help cut down on botnet spam, which is an added plus! (whereas those IPv6's IPv4 predecessors sometimes could send that botnet spam directly to the recipient's mail server).

So push IPv6 all you want.. .even "force" it... but please don't be too quick to rush the elimination of IPv4 anytime soon. And lets keep MTA sending IPs (which is server-to-server traffic) as IPv4-only, even if they are able to receive their own customers' SMTP auth mail via IPv6.

Otherwise, we'll be having discussions one day about how to limit WHICH and HOW MANY IPv6 addresses can be assigned to MTAs! (hey, maybe that isn't a bad idea either!)

-- Rob McEwen

On 10/01/2015 08:18 PM, cortana5@gmail.com wrote:

Excuse my probable ignorance of such matters, but would it not then be preferred to create a whitelist of proven Email servers/ip's , and just drop the rest? Granted, one would have to create a process to vet anyone creating a new email server, but would that not be easier then trying to create and maintain new blacklists?

Define "proven e-mail servers and IPs." Just because someone raises their hand and says "I run a mail server" doesn't mean that the hand-raiser doesn't have a ton of people behind him/her who spew spam at a frightening rate. Even when the hand-raiser represents a large company, that's no guarantee of a mail admin with clue or care. I got started in the personal mail-server game when Pacific Telesys lost control of its mail servers, and ended up with the IPv4 addresses blacklisted to hell. In order to be able to contribute to the Linux Kernal mailing list, I ended up setting up my own Postfix box, and doing everything necessary to be identified as following Best Practices regarding mail. Good training for later, it turns out. When I became the mail admin for a Web hosting company, I had to work like hell to (1) clean up the mail, and (2) convincing all the blacklists that I had successfully terminated the spammers. SPEWS, even. A dedicated-server customer was providing DNS service to spammers, which resulted in my company's entire /21 being blacklisted. I went through a private hell re-jiggering the web host mail system (Plesk, CPanel, among other web hosting products) to be able to control both inbound and outbound spam. But I did it. ALso, satisfied AOL, Yahoo, and other mailhost companies to accept my mail. Not to mention providing custom levels of spam control for my customers -- some wanted no spam blocks, others wanted no spam. No middle ground.

In message <560DF4BA.5000500@invaluement.com>, Rob McEwen writes:

RE: How to wish you hadn't rushed ipv6 adoption

Force the whole world to switch to IPv6 within the foreseeable future, abolish IPv4... all within several years or even within 50 years... and then watch spam filtering worldwide get knocked back to the stone ages while spammers and blackhat and grayhat ESPs laugh their way to the bank... that is, until e-mail becomes unworkable and is virtually abandoned.

I welcome IPv6 adoption in the near future in all but one area: the sending IPs of valid mail servers. Those need to stay IPv4 for as long as reasonably possible.

It turns out... the scarcity of IPv4 IPs in THIS area... is a feature, not a bug.

That scarcity makes it harder for spammers to acquire new IPs, and they therefore pay a price for the ones they burn through via their spam-sending. Likewise, scarcity of IPv4 IPs *forces* ESPs, hosters, and ISPs to try HARD to keep their IPs clean. THEY pay a price when a bad-apple customer soils up their IP space.

In contrast, with IPv6, order of magnitude MORE IPs are easily acquired, and order of magnitude more are in each allocation. It is truly a spammer's dream come true. This reminds me about a recent article Brian Krebs wrote about a famous hoster who slowly drove their business into the ground by allowing in the kind of spammers that look a little legit at first glance. (like the "CAN-SPAM" spammers who are doing nothing illegal, follow the law, but still send to purchase lists). But even this hoster's bank account was bursting at the seams with cash due to a booming business, their IP space's reputation was slowly turning in crap. Eventually, they started losing even their spammer customers. Then, their CEO made a decision to get serious about abuse and keeping spammers off of their network---and this turned into a success story where they now run a successful hosting business without the spammers. In an IPv6 world, I wonder if they would have ever even cared? There would always be new fresh IPv6 IPs to acquire! There would never have been the "motivation" to turn things around. There would always be new IPv6 IPs to move on to. (or at least enough available to "kick the can down the road" and not worry about any long term repercussions). It was ONLY when this CEO started seeing even the spammers start to leave him (along with some SpamHaus blacklistings)! that he realized that his IP reputation would eventually get so bad that he be virtually out of business. It was ONLY then that he decided to make changes. Would this have happened in an all-IPv6 world? I highly doubt it! He'd just keep moving on to fresh IPs!

The cumulative sum total of all those hosters and ESPs downward spiraling in an IPv6 world... could cause the spam problem to GREATLY accelerate.

Meanwhile, sender IP blacklists would become useless in an IPv6 world because the spammer now has enough IPs (in many scenarios) to EVEN SEND ONE SPAM PER IP, never to have to use that one IP again FOR YEARS, if ever. So a blacklisting is ineffective... and actually helps the spammer to listwash spamtrap addresses... since the ONE listing maps to a single recipient address. Now the sender's IP blacklist is even less effective and is helping the spammers more than it is blocking spam! And did I mention that the sender's IP list has bloated so large that it is hard to host in DNS and hard to distribute--and most of the listings are now useless anyways!

Yes, there are other types of spam filtering... including content filtering techniques. But in the real world, these only work because the heavy lifting is ALREADY done by the sender's IP blacklist. The vast majority of this worldwide "heavy lifting" is done by "zen.spamhaus.org". If many of the largest ISPs suddenly lost access to Zen, some such filters would be in huge trouble.... brought down to their knees. Now imagine that all the other sending-IP blacklists are gone too? In that spammer's dream scenario, the spammer has upgraded to a Lamborghini, while the spam filters have reverted back to the horse and buggy. Serious, that analogy isn't the slightest bit of an exaggeration.

Yes, you can STILL have your toaster and refrigerator and car send mail from an IPv6 address... they would just need to SMTP-Authenticate to a valid mail server... via an IPv6 connection... yet where that valid MTA would then send their mail to another MTA via IPv4. Since the number of IPv4 IPs needed for such valid mail servers is actually very, very small (relatively speaking), then it isn't a big problem for THOSE to get IPv4 addresses, at a trivial cost. We might even see IPv4 open up a bit as OTHER services move to IPv6. IPv6 addresses NOT being able to send directly to the e-mail recipient's IPv4 mail servers might actually help cut down on botnet spam, which is an added plus! (whereas those IPv6's IPv4 predecessors sometimes could send that botnet spam directly to the recipient's mail server).

So push IPv6 all you want.. .even "force" it... but please don't be too quick to rush the elimination of IPv4 anytime soon. And lets keep MTA sending IPs (which is server-to-server traffic) as IPv4-only, even if they are able to receive their own customers' SMTP auth mail via IPv6.

Otherwise, we'll be having discussions one day about how to limit WHICH and HOW MANY IPv6 addresses can be assigned to MTAs! (hey, maybe that isn't a bad idea either!)

-- Rob McEwen

IPv6 really isn't much different to IPv4. You use sites /48's rather than addresses /32's (which are effectively sites). ISP's still need to justify their address space allocations to RIR's so their isn't infinite numbers of sites that a spammer can get. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 10/1/2015 11:58 PM, Rob McEwen wrote:

And blocking at the /48 level WOULD cause too much collateral damage if don't indiscriminately.

I meant, "if done indiscriminately" excuse my other more minor typos too. I get in a hurry and my fingers don't always type what my brain is thinking :) -- Rob McEwen +1 478-475-9032

Not all providers are large enough to justify a /32. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Philip Dorr" <tagno25@gmail.com> To: "Rob McEwen" <rob@invaluement.com> Cc: "nanog group" <nanog@nanog.org> Sent: Thursday, October 1, 2015 11:14:35 PM Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption") On Thu, Oct 1, 2015 at 10:58 PM, Rob McEwen <rob@invaluement.com> wrote:

On 10/1/2015 11:44 PM, Mark Andrews wrote:

...

IPv6 really isn't much different to IPv4. You use sites /48's rather than addresses /32's (which are effectively sites). ISP's still need to justify their address space allocations to RIR's so their isn't infinite numbers of sites that a spammer can get.

A /48 can be subdivided into 65K subnets. That is 65 *THOUSAND*... not the 256 IPs that one gets with an IPv4 /24 block. So if a somewhat legit hoster assigns various /64s to DIFFERENT customers of theirs... that is a lot of collateral damage that would be caused by listing at the /48 level, should just one customer be a bad-apple spammer, or just one legit customer have a compromised system one day.

As a provider (ISP or Hosting), you should hand the customers at a minimum a /56, if not a /48. The provider should have at a minimum a /32. If the provider is only giving their customers a /64, then they deserve all the pain they receive.

I may be able to justify it to ARIN, but I can't make a quadrupling of ARIN's fees justifiable to me. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "Mike Hammett" <nanog@ics-il.net> Cc: "nanog group" <nanog@nanog.org> Sent: Friday, October 2, 2015 8:35:41 AM Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption") Every provider gets a /32, according to ARIN. IPv6 - INITIAL ALLOCATIONS Type of Resource Request Criteria to Receive Resource ISP Initial Allocation /32 minimum allocation (/36 upon request) NRPM 6.5.1 * Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries, or * Qualify for an IPv4 ISP allocation under current policy, or * Intend to immediately multi-home, or * Provide a reasonable technical justification, including a plan showing projected assignments for one, two, and five year periods, with a minimum of 50 assignments within five years IPv6 Multiple Discrete Networks /32 minimum allocation (/36 upon request) NRPM 6.11 * be a single entity and not a consortium of smaller independent entities -mel via cell On Oct 2, 2015, at 4:15 AM, Mike Hammett < nanog@ics-il.net > wrote: Not all providers are large enough to justify a /32. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Philip Dorr" < tagno25@gmail.com > To: "Rob McEwen" < rob@invaluement.com > Cc: "nanog group" < nanog@nanog.org > Sent: Thursday, October 1, 2015 11:14:35 PM Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption") On Thu, Oct 1, 2015 at 10:58 PM, Rob McEwen < rob@invaluement.com > wrote: <blockquote> On 10/1/2015 11:44 PM, Mark Andrews wrote: <blockquote> <blockquote> </blockquote> </blockquote> <blockquote> <blockquote> IPv6 really isn't much different to IPv4. You use sites /48's </blockquote> </blockquote> <blockquote> <blockquote> rather than addresses /32's (which are effectively sites). ISP's </blockquote> </blockquote> <blockquote> <blockquote> still need to justify their address space allocations to RIR's so </blockquote> </blockquote> <blockquote> <blockquote> their isn't infinite numbers of sites that a spammer can get. </blockquote> </blockquote> <blockquote> </blockquote> <blockquote> </blockquote> <blockquote> A /48 can be subdivided into 65K subnets. That is 65 *THOUSAND*... not the </blockquote> <blockquote> 256 IPs that one gets with an IPv4 /24 block. So if a somewhat legit hoster </blockquote> <blockquote> assigns various /64s to DIFFERENT customers of theirs... that is a lot of </blockquote> <blockquote> collateral damage that would be caused by listing at the /48 level, should </blockquote> <blockquote> just one customer be a bad-apple spammer, or just one legit customer have a </blockquote> <blockquote> compromised system one day. </blockquote> As a provider (ISP or Hosting), you should hand the customers at a minimum a /56, if not a /48. The provider should have at a minimum a /32. If the provider is only giving their customers a /64, then they deserve all the pain they receive. </blockquote>

Well, outside of RIR speak, I can't justify quadrupling my cost for what the community considers to be the minimum ISP allocation. Maybe that's a better phrasing? *shrugs* {insert rent is too damn high meme}? This 8 bit network division stuff does make it difficult for ARIN to adequately assess fees, I'm sure. Most anyone could get by with the /32 bucket, which also happens to be the minimum I should be using. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "nanog group" <nanog@nanog.org> Sent: Saturday, October 3, 2015 2:04:48 PM Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption") Yes… This is a problem the ARIN board needs to fix post haste, but that’s not justification, that’s cost. Owen

On Oct 2, 2015, at 06:45 , Mike Hammett <nanog@ics-il.net> wrote:

I may be able to justify it to ARIN, but I can't make a quadrupling of ARIN's fees justifiable to me.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

Midwest Internet Exchange http://www.midwest-ix.com

----- Original Message -----

From: "Mel Beckman" <mel@beckman.org> To: "Mike Hammett" <nanog@ics-il.net> Cc: "nanog group" <nanog@nanog.org> Sent: Friday, October 2, 2015 8:35:41 AM Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

Every provider gets a /32, according to ARIN.

IPv6 - INITIAL ALLOCATIONS Type of Resource Request Criteria to Receive Resource ISP Initial Allocation /32 minimum allocation (/36 upon request) NRPM 6.5.1

* Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries, or * Qualify for an IPv4 ISP allocation under current policy, or * Intend to immediately multi-home, or * Provide a reasonable technical justification, including a plan showing projected assignments for one, two, and five year periods, with a minimum of 50 assignments within five years

IPv6 Multiple Discrete Networks /32 minimum allocation (/36 upon request) NRPM 6.11

* be a single entity and not a consortium of smaller independent entities

-mel via cell

On Oct 2, 2015, at 4:15 AM, Mike Hammett < nanog@ics-il.net > wrote:

Not all providers are large enough to justify a /32.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

Midwest Internet Exchange http://www.midwest-ix.com

----- Original Message -----

From: "Philip Dorr" < tagno25@gmail.com > To: "Rob McEwen" < rob@invaluement.com > Cc: "nanog group" < nanog@nanog.org > Sent: Thursday, October 1, 2015 11:14:35 PM Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

On Thu, Oct 1, 2015 at 10:58 PM, Rob McEwen < rob@invaluement.com > wrote:

On 10/1/2015 11:44 PM, Mark Andrews wrote:

<blockquote>

<blockquote>

</blockquote>

<blockquote>

<blockquote> IPv6 really isn't much different to IPv4. You use sites /48's

</blockquote>

</blockquote>

<blockquote>

<blockquote> rather than addresses /32's (which are effectively sites). ISP's

</blockquote>

</blockquote>

<blockquote>

<blockquote> still need to justify their address space allocations to RIR's so

</blockquote>

</blockquote>

<blockquote>

<blockquote> their isn't infinite numbers of sites that a spammer can get.

</blockquote>

</blockquote>

<blockquote>

</blockquote>

<blockquote>

</blockquote>

<blockquote> A /48 can be subdivided into 65K subnets. That is 65 *THOUSAND*... not the

</blockquote>

<blockquote> 256 IPs that one gets with an IPv4 /24 block. So if a somewhat legit hoster

</blockquote>

<blockquote> assigns various /64s to DIFFERENT customers of theirs... that is a lot of

</blockquote>

<blockquote> collateral damage that would be caused by listing at the /48 level, should

</blockquote>

<blockquote> just one customer be a bad-apple spammer, or just one legit customer have a

</blockquote>

<blockquote> compromised system one day.

</blockquote>

As a provider (ISP or Hosting), you should hand the customers at a minimum a /56, if not a /48. The provider should have at a minimum a /32. If the provider is only giving their customers a /64, then they deserve all the pain they receive.

</blockquote>

I followed up later, but so that it doesn't look like I'm ignoring you, if I were to take a /32 at my ISP, my ARIN fee would quadruple. I can't justify that. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "nanog group" <nanog@nanog.org> Sent: Saturday, October 3, 2015 1:56:58 PM Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption") How do you figure that? Owen

On Oct 2, 2015, at 04:14 , Mike Hammett <nanog@ics-il.net> wrote:

Not all providers are large enough to justify a /32.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

Midwest Internet Exchange http://www.midwest-ix.com

----- Original Message -----

From: "Philip Dorr" <tagno25@gmail.com> To: "Rob McEwen" <rob@invaluement.com> Cc: "nanog group" <nanog@nanog.org> Sent: Thursday, October 1, 2015 11:14:35 PM Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

On Thu, Oct 1, 2015 at 10:58 PM, Rob McEwen <rob@invaluement.com> wrote:

...

On 10/1/2015 11:44 PM, Mark Andrews wrote:

...

IPv6 really isn't much different to IPv4. You use sites /48's rather than addresses /32's (which are effectively sites). ISP's still need to justify their address space allocations to RIR's so their isn't infinite numbers of sites that a spammer can get.

A /48 can be subdivided into 65K subnets. That is 65 *THOUSAND*... not the 256 IPs that one gets with an IPv4 /24 block. So if a somewhat legit hoster assigns various /64s to DIFFERENT customers of theirs... that is a lot of collateral damage that would be caused by listing at the /48 level, should just one customer be a bad-apple spammer, or just one legit customer have a compromised system one day.

As a provider (ISP or Hosting), you should hand the customers at a minimum a /56, if not a /48. The provider should have at a minimum a /32. If the provider is only giving their customers a /64, then they deserve all the pain they receive.

On 10/2/2015 12:18 AM, Mark Andrews wrote:

A hoster can get /48's for each customer. Each customer is technically a seperate site. It's this stupid desire to over conserve IPv6 addresses that causes this not IPv6.

In theory, yes. In practice, I'm skeptical. I think many will sub-delegate /64s Plus, nobody has yet addressed the fact that new /48s will be just so EASY to obtain since they are going to be plentiful... therefore... the LACK of scarcity will make hosters and ESP... NOT be very motivated to keep their IP space clean... as is the case now with IPv4. Also, it seems so bizarre that in order to TRY to solve this, we have to make sure that MASSIVE numbers of individual IPv6 IP addresses.. that equal numbers that my calculate can't reach (too many digits)... would all be allocated to one single combined usage scenario. Then allocating only /48s multiples that number by 65K. Mind boggling -- Rob McEwen +1 478-475-9032

On 10/2/2015 1:10 AM, Mark Andrews wrote:

or working out how many addresses a site needs when handing out address blocks

At first, I'm with you on this.. but then when you got to the part I quoted above... it then seems like dividing lines can get really blurred here and this statement might betray your premise. A site needing more than 1 address... subtly implies different usage case scenarios... for different parts or different addresses on that block... which could slip back into... "you blocked my whole /48... but the spam was only coming from this tiny corner of the block over here (whether that be a one IP, a /64, or a /56)... and now other parts of the block that were sending out legit mail, are suffering". Likewise, sub-allocations can come into play, where a hoster is delegated a /48, but then subdivides it for various customers. -- Rob McEwen +1 478-475-9032

On Fri, 2 Oct 2015, Mark Andrews wrote:

...

Likewise, sub-allocations can come into play, where a hoster is delegated a /48, but then subdivides it for various customers.

A hoster is a LIR. It isn't the end customer.

I think you are wrong here for a lot of szenarios. Today we have for example small web-agency gets /25 from datacenter hoster (LIR), puts two servers there, couple of VM, and then rents those VM to its 50 customers.

From the datacenter hoster point they would perhaps get one /48...

c'ya sven-haegar -- Three may keep a secret, if two of them are dead. - Ben F.

On 10/02/2015 12:44 AM, Valdis.Kletnieks@vt.edu wrote:

On Fri, 02 Oct 2015 02:09:00 -0400, Rob McEwen said:

...

Likewise, sub-allocations can come into play, where a hoster is delegated a /48, but then subdivides it for various customers.

So they apply for a /32 and give each customer a /48.

A hoster getting *just* a /48 is about as silly as a hoster getting a /32 of IPv4 and NAT'ing their customers.

I agree, for a web hosting operation, getting an allocation smaller than a /32 doesn't make sense. But...now I ask this question: WHY a /48 per customer? I used to be a web host guy, and the rule was one IPv4 address per co-location customer or dedicated-server customer -- maybe two -- and shared-IP HTTP for those customers hosted on "house" servers with multiple sites on them. We had a couple of shared-hosting server with 64 IPv4 addresses each to support SSL sites with customer-provided SSL certificates.. OLD STYLE If a customer wanted more than one IPv4 address, he had to justify it so we could copy the justification to our ARIN paperwork. A /24 was right out, because the *only* people requesting that much IPv4 space were spammers. The largest legit co-location IPv4 customer allocation, because he had enough servers in his cage and sufficient justification to warrant it, was a /26 . Which I SWIPped. Which I treated as a completely separate subnet. Which was on its own VLAN. Which used separate 10base-T Ethernet interfaces on my edge routers to provide hard flow control and traffic monitoring. THAT WAS THEN, THIS IS NOW I can see, in shared hosting, where each customer gets one IPv6 address to support HTTPS "properly". Each physical server typically hosts 300-400 web sites comfortably, so assigning a /112 to each of those servers appears to make sense. This is particularly true now that there is a push for "https everywhere". Web hosting isn't going to be a downstream link for IoT, so the need for "massive" amounts of IPv6 addressing space is simply not there.

On Oct 2, 2015, at 06:44 , Stephen Satchell <list@satchell.net> wrote:

On 10/02/2015 12:44 AM, Valdis.Kletnieks@vt.edu wrote:

...

On Fri, 02 Oct 2015 02:09:00 -0400, Rob McEwen said:

...

Likewise, sub-allocations can come into play, where a hoster is delegated a /48, but then subdivides it for various customers.

So they apply for a /32 and give each customer a /48.

A hoster getting *just* a /48 is about as silly as a hoster getting a /32 of IPv4 and NAT'ing their customers.

I agree, for a web hosting operation, getting an allocation smaller than a /32 doesn't make sense.

But...now I ask this question: WHY a /48 per customer? I used to be a web host guy, and the rule was one IPv4 address per co-location customer or dedicated-server customer -- maybe two -- and shared-IP HTTP for those customers hosted on "house" servers with multiple sites on them. We had a couple of shared-hosting server with 64 IPv4 addresses each to support SSL sites with customer-provided SSL certificates..

OLD STYLE

If a customer wanted more than one IPv4 address, he had to justify it so we could copy the justification to our ARIN paperwork. A /24 was right out, because the *only* people requesting that much IPv4 space were spammers.

The largest legit co-location IPv4 customer allocation, because he had enough servers in his cage and sufficient justification to warrant it, was a /26 . Which I SWIPped. Which I treated as a completely separate subnet. Which was on its own VLAN. Which used separate 10base-T Ethernet interfaces on my edge routers to provide hard flow control and traffic monitoring.

THAT WAS THEN, THIS IS NOW

I can see, in shared hosting, where each customer gets one IPv6 address to support HTTPS "properly". Each physical server typically hosts 300-400 web sites comfortably, so assigning a /112 to each of those servers appears to make sense. This is particularly true now that there is a push for "https everywhere".

Web hosting isn't going to be a downstream link for IoT, so the need for "massive" amounts of IPv6 addressing space is simply not there.

So there are a number of reasons. First, unless you want to be chasing ND Cache Overflow problems, you put each customer on a small link (/127) to your router and then route at least a /64 to their router if they just have one subnet. If they have more than one, then you certainly want to route them a larger prefix (/48). With virtualization and network virtualization, containers, and the like these days, treating each customer as a separate end-site is just good practice. You’re not going to have any problem explaining that to the RIRs. Owen

On Oct 2, 2015, at 08:05 , Justin M. Streiner <streiner@cluebyfour.org> wrote:

On Fri, 2 Oct 2015, Rob McEwen wrote:

...

it then seems like dividing lines can get really blurred here and this statement might betray your premise. A site needing more than 1 address... subtly implies different usage case scenarios... for different parts or different addresses on that block... which could slip back into... "you blocked my whole /48... but the spam was only coming from this tiny corner of the block over here (whether that be a one IP, a /64, or a /56)... and now other parts of the block that were sending out legit mail, are suffering".

Likewise, sub-allocations can come into play, where a hoster is delegated a /48, but then subdivides it for various customers.

That touches on the tough part of doing things like ingress/egress filtering and spam blacklisting for IPv6. Net every network assigns IPv6 space to end-users the same way, and even fewer still provide good data on how they assign to end-users (SWIP, rwhois, etc). Networks that are blocking traffic are left to make a decision that straddles the line between providing the necessary level of protection for their services and minimizing the potential of collateral damage by blocking legitimate traffic from other users.

Or you can take the approach that there are guidelines published out there that encourage /48 per end-site, /64 per subnet, and figure that anyone who chooses to do otherwise has brought about their own problems.

Blocking a single IPv6 address is generally not effective because it's trivial for a host to switch to a different address in the same /64, and hosts that have privacy extensions enabled will do so with no further action needed by the owner. This turns into an endless game of whack-a-mole. The same thing can happen with blocking /64s.

Which is why I advocate playing a very short game of whack-a-mole with the first few /64s inside a given block and then detecting a “pattern of abuse” that leads to blocking on a larger level (/48, /32, shorter?).

It's often not clear if provider XYZ is assigning /56, /48, or something else to end-users, especially if the provider doesn't provide any publicly accessible information to that end.

Who cares… If they are shortchanging their customers in this way, they have created their own pain. It’s not your fault. Owen

On Fri, Oct 2, 2015 at 1:35 PM, Owen DeLong <owen@delong.com> wrote:

...

On Oct 1, 2015, at 21:47 , Rob McEwen <rob@invaluement.com> wrote: Also, it seems so bizarre that in order to TRY to solve this, we have to make sure that MASSIVE numbers of individual IPv6 IP addresses.. that equal numbers that my calculate can't reach (too many digits)... would all be allocated to one single combined usage scenario. Then allocating only /48s multiples that number by 65K. Mind boggling

You’ll get over that eventually. Once you get some experience with the conveniences and other advantages it brings, it’s actually pretty easy to wrap your head around.

I agree with Owen (and the others who have chimed in) on that one. As long as you're thinking and talking about individual addresses you're stuck in an IPv4 mindset. One of the points in having 64 bits reserved for the host portion of the address is that you never need to think or worry about individual addresses. IPv6 eliminates the address scarcity issue. There's no reason to ever think about how many individual addresses are available on any network. The answer is always more than enough. Instead you think about networks and network size. Also, good luck trying to shove the IPv6 genie back into the bottle. I doubt you're going to have much success. I know my large organization has seen the percentage of email traffic on our edge MTAs using IPv6 steadily grow since we dual-stacked them back in 2012. It's been a while since I checked with the organization responsible for them, but I believe it's somewhere north of 10% of all email traffic now. (I know our heavily used website has reached roughly 20% IPv6 traffic now.) So it's best to just keep working on ways to manage spam in an IPv6 world since that's the present reality. Scott

So let me ask a question -- there's several folks looking at overall IPv6 usage, but what about on a per-protocol level, and compared to IPv4? Frank -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Randy Bush Sent: Saturday, October 03, 2015 11:37 AM To: Scott Morizot <tmorizot@gmail.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

Also, good luck trying to shove the IPv6 genie back into the bottle.

the problem is not getting it into the bottle. the problem is getting it out, at scale. when you actually measure, cgn and other forms of nat are now massive. it is horrifying. randy

One thing that I thought was going to be a huge help with sending-IP blacklists in the IPv6 world... was perhaps shifting to tighter standards and greater reliance for Forward Confirmed rDNS (FCrDNS).

A lot of IPv6 mail systems want you to use SPF and DKIM signatures on IPv6 mail, or they won't accept it. This is a frequent topic at MAAWG meetings. IPv6 rDNS is a can of worms. You can't do generic rDNS other than with a stunt server that generates results on the fly. The general agreement seems to be that servers (which include mail clients) should have static IPs and valid rDNS, but the pain of doing rDNS at all has made the rDNS flaky. And anyway, a DKIM signature or even an SPF record is a lot more informative than a PTR record.

For example, if a spammer who has acquired a /48 is sending from literally millions, perhaps billions, of DIFFERENT IPs on that /48, ...

Even with a /64 a spammer could easily use a different IP for every message he ever sent, which as you note would make both legitimate bounce handling and spammer list washing easier. That's why no DNSBL I know is interested in granularities less than /64. There are some hosting providers that due to poor choices made a few years back (and perhaps poorly designed equipment from vendors) have been giving customers each a /128 inside a shared /64, but the advice I've been seeing is that if you want your customers to be able to send mail, don't do that. R's, John

On Sat, Oct 3, 2015 at 10:35 AM, Scott Morizot <tmorizot@gmail.com> wrote:

One of the points in having 64 bits reserved for the host portion of the address is that you never need to think or worry about individual addresses

Well, that turned out to be a farce. Instead of worrying about running out of addresses on the lan, you have to worry about other people tracking your mobile users through their static 64 bit tail (SLAAC) or having trouble internally tracking your users (privacy extensions). Give me the straightforward problem over the subtle one any time. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

On Oct 1, 2015, at 20:58 , Rob McEwen <rob@invaluement.com> wrote:

On 10/1/2015 11:44 PM, Mark Andrews wrote:

...

IPv6 really isn't much different to IPv4. You use sites /48's rather than addresses /32's (which are effectively sites). ISP's still need to justify their address space allocations to RIR's so their isn't infinite numbers of sites that a spammer can get.

A /48 can be subdivided into 65K subnets. That is 65 *THOUSAND*... not the 256 IPs that one gets with an IPv4 /24 block. So if a somewhat legit hoster assigns various /64s to DIFFERENT customers of theirs... that is a lot of collateral damage that would be caused by listing at the /48 level, should just one customer be a bad-apple spammer, or just one legit customer have a compromised system one day.

Conversely, if a more blackhat ESP did this, but it was unclear that this was a blackhat sender until much later.. then LOTS of spam would get a "free pass" as individual /64s were blacklisted AFTER-THE-FACT, with the spammy ESP still having LOTS of /64s to spare.. remember, they started with 65 THOUSAND /64 blocks for that one /48 allocation (Sure, it would eventually become clear that the whole /48 should be blacklisted).

It seems to me that treating this as a binary all-or-nothing approach isn’t particularly useful. What about a system where each /48 and each /32 maintained a “content score”. Treat /64s as you currently treat /32s (or even /24s) in IPv4. For every hour that elapsed without sending spam, the score would decrement by one. For each unblocked spam transmitted from within the block, the score would increment by one. (IOW, new spam from an already blocked /64 won’t increment the counter). If the score for a /48 reaches 16, block the /48 and put the /48 into the block timer mode. If the score for a /32 reaches 64, block the /32 and put the /32 into the block timer mode. Block timer mode: In block timer mode, look for 24 consecutive hours with an allowable outbound spam send rate, then unblock. Allowable outbound spam rate could be anything >0 and would probably require some tuning. For a /32, I’d say up to 256 messages per day or maybe even 1024 is probably within reason. For a /48, probably more like 16/day.

other gray-hat situations between these two extremes can be even more frustrating because you then have the same "free passes" that the blackhat ESP gets... but you can't list the whole /48 without too much collateral damage.

In the proposal above, to achieve a score of 16, you have to have 16 different /64s from within your /48 sending bad stuff. Sure, you get a little bit of a free pass until the spammer cycles through 16 blocks of addresses, but not much because each of those blocks gets shut down fairly quickly. If a site has 16 independent /64s compromised or spamming, then the collateral damage really isn’t that heavy and for legitimate sites it should serve as reasonable motivation to clean things up. For the spammers, they’re going to need a new /48 pretty quickly and that’s going to be hard to explain to their service provider. Especially since that new /48 won’t last long, either. For the /32, yes, we’re talking about lots of collateral damage. Maybe 64 is too low of a threshold, maybe it should be 256 or even higher, but this can be tuned. The point is shut down the individual nets quickly at the /64 level to minimize collateral damage, but when “enough” /64s within a block are shown to be offensive, consider the entire block offensive and move on.

SUMMARY: So even if you moved into blocking at the /64 level, the spammers have STILL gained an order of magnitudes advantage over the IPv4 world.... any way you slice it. And blocking at the /48 level WOULD cause too much collateral damage if don't indiscriminately.

I’m not convinced of this. A /48 should be a single end-site. As such, any ISP that suffers significant collateral damage from having /48s blocked isn’t allocating addresses according to best operating practices. They can easily fix this. Every RIR allows end-site assignments at /48 with no questions asked.

And this is assuming that individual IPs are NEVER assigned individually (or in smaller-than-/64-allocations) . (maybe that is a safe assumption? I don't know? regardless, even if that were a safe assumption, the spammers STILL have gained a massive advantage)

It’s not a completely safe assumption, but it’s safe enough. Owen

X.400 required a session key. IIRC you had to know the other side of the mail exchange and do (weak, but of the time what we did) shared secret swaps to bootstrap the protocol. Of course, a cheat-sheet of 'your idea will not work because [ ]' kills it, but I do recall with some fondness that in those days, basic hygiene demanded you know who you sent mail to, and on whose behalf. For at least some people. -G On Tue, Oct 6, 2015 at 3:16 PM, Måns Nilsson <mansaxel@besserwisser.org> wrote:

Subject: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption") Date: Thu, Oct 01, 2015 at 11:06:34PM -0400 Quoting Rob McEwen (rob@invaluement.com):

...

I welcome IPv6 adoption in the near future in all but one area: the

sending

...

IPs of valid mail servers. Those need to stay IPv4 for as long as reasonably possible.

Using the link-level address to distinguish between good and bad email content was always daunting at best. Thanks for pointing out that this flawed behaviour must cease.

-- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Why is it that when you DIE, you can't take your HOME ENTERTAINMENT CENTER with you??

On Fri, 02 Oct 2015 00:16:50 -0000, Todd Underwood said:

yes. huh. funny about that, right? what do you think accounts for that? *why* do you think that *17* *years* later people are still just barely using this thing.

The fact that dumping too much CO2 into the atmosphere is a Bad Idea was equally well understood 17 years ago. And yet we *still* have Senators with snowballs denying it.

so here's my view: if you have some technical solution for a networking problem that no one wants for 17 years, you should really probably think about that. you might not even have to wait 17 years to figure out that something might be wrong.

See RFC1335. The problem was recognized back in 1992 - which is why the IETF chartered the whole IPng thing. Some of us recognized it would be less painful to get things working sooner rather than later - and some didn't. Now, if you want to be the Senator with the snowball, be my guest. It may make for interesting TV, but I can hardly recommend it as a busines model.

For ISPs that already exist, what benefit do they get from providing/allowing IPv6 transit to their customers? Keep in mind that the net is now basically another broadcast medium. On Fri, Oct 2, 2015 at 10:33 AM Steve Mikulasik <Steve.Mikulasik@civeo.com> wrote:

I think more focus needs to be for carriers to deliver dual stack to their customers door step, whether they demand/use it or not. Small ISPs are probably in the best position to do this and will help push the big boys along with time. If we follow the network effect (reason why IPv4 lives and IPv6 is slowly growing), IPv6 needs more nodes, all other efforts are meaningless if they do not result in more users having IPv6 delivered to their door.

I think people get too lost in the weeds when they start focusing on device support, home router support, user knowledge, etc. Just get it working to the people and we can figure out the rest later.

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mark Andrews Sent: Thursday, October 01, 2015 6:01 PM To: Matthew Newton <mcn4@leicester.ac.uk> Cc: nanog@nanog.org Subject: Re: How to force rapid ipv6 adoption

In message <20151001232613.GD123100@rootmail.cc.le.ac.uk>, Matthew Newton writes:

Additionally it is now a OLD addressing protocol. We are about to see young adults that have never lived in a world without IPv6. It may not have been universally available when they were born but it was available. There are definitely school leavers that have never lived in a world where IPv6 did not exist. My daughter will be one of them next year when she finishes year 12. IPv6 is 7 months older than she is.

Some of us have been running IPv6 in production for over a decade now and developing products that support IPv6 even longer.

We have had 17 years to build up a universal IPv6 network. It should have been done by now.

Mark

...

-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>

Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Why would they go "IPv6 only" if it costs them huge customer bases? *** anecdote below *** I hosted a discussion about IPv6 the other day to a room full of highly technically-proficient millennials (being maybe in the older portion of "millennial", myself - In spite of how I must sound, I'm actually really excited about IPv6 for some of the reasons below). About 1/3 of the way into the discussion - a discussion I was *specifically avoiding* the "2^32 versus 2^128" reason for switching to IPv6 (due to various reasons starting with the secondary IPv4 markets and continuing with today's "/27 is the new /24" thread) - I realized that most of the people in the room had not lived in the era where ports below 1024 were open to the world. Literally they'd almost all grown up in the stateful NAT-as-a-security-model era. The internet has not been much different from TV or radio for them, and it occurred to me that this could be a huge brick on IPv6 adoption in places where ISPs are happy to NAT away as much as possible (getting back to the question of "what benefit do they get from providing/allowing IPv6 transit to their customers?" from my prior post). I don't know if this is actually the case, but it sure seems that way. Re: IoT - Additionally, I am pretty up to date on IoT development (Ubiquiti, Edison, TI meetups in the city, etc). The products in development all have the *capability* to use IPv6 with some hacking, but because of the callback cloud services that much of them employ combined with most places not having IPv6, they all develop their products for use with, and train developers on their platforms, expecting IPv4 (at least the ones I've been to). On Fri, Oct 2, 2015 at 11:26 AM Stephen Satchell <list@satchell.net> wrote:

On 10/02/2015 07:48 AM, Cryptographrix wrote:

...

For ISPs that already exist, what benefit do they get from providing/allowing IPv6 transit to their customers?

Keep in mind that the net is now basically another broadcast medium.

Interesting you should use that phrase. IPv4 is the "AM band", while IPv6 is the "FM band". (The more I think about it, the better I like this parallel.) As more and more "broadcasters" offer IPv6 connectivity, either "simulcast" or IPv6 only, the more customers will want to use IPv6.

I think the "killer app" for IPv6 will be the Internet of Things (IoT). I see the trend for people to have mixed IPv4/IPv6 on their inside network, particularly wireless, but less need to bridge IPv6 to the outside world.

Need to get to your IoT stuff from the outside? (Assuming you have a fixed or quasi-fixed IPv4 address, of course.) Then you can use an appliance that will map IPv4 ports to IPv6 inside addresses. So if you really, really want to control your lights from your office, you can. Without the ISP making the investment.

The big question is, how many SERVICES will go IPv6 only? I see Google, Netflix, Hulu, and similar broadcast sources being dual stack for a long time to come. That reduces the pressure on ISPs to launch IPv6.

Unfortunately, the files at the NANOG links you posted are not available, but I think I get the premise of them from their summaries and what you're trying to say - thank you for linking. The discussion about CGN maintenance versus IPv6 adoption is important at the NANOG level because of exactly what (I think) you're trying to say, and the only contribution I have to that is that "we need more IPv6-capable NetOps and vendors" - I suspect we all know this. It makes me curious about the churn rate between ISPs, but that's a different topic and everything you've said is spot on. What seems really important/would be progressive at the moment is that vendors release IPv6-capable "plug and play" gear. Is there any vendor that's currently working on a home router that provides *only* IPv6 internally, with NAT64 IPv6->IPv4? If we wanted to really get this started, that (and a bunch of articles about "use this router to get IPv6 in your house") sounds like it could be really productive. Additionally, is it possible for ISPs to offer IPv6 transit-exclusive plans for people that would like to get just that? Maybe with the ability to have all ports open from the get-go as an incentive? On Fri, Oct 2, 2015 at 12:02 PM George, Wes <wesley.george@twcable.com> wrote:

On 10/2/15, 10:48 AM, "NANOG on behalf of Cryptographrix" <nanog-bounces@nanog.org on behalf of cryptographrix@gmail.com> wrote:

...

For ISPs that already exist, what benefit do they get from providing/allowing IPv6 transit to their customers?

If they'd like to continue growing at something above churn rate, they need additional IP addresses to give their new customers. Buying those addresses, undertaking projects to free up addresses from other internal uses, or using CGN to share existing ones all have nontrivial costs. The fewer things they need to make work on legacy IPv4, the lower those costs can be (less CGN capacity since IPv6 traffic bypasses the NAT, less support costs because less stuff breaks by going through the NAT, etc).[1,2,3] But that's dependent on content and CPE supporting it, so a number of large ISPs have chosen to go ahead and deploy[4], and focus on pushing the progress on the other fronts so that they can see that benefit of deploying.

Wes George

[1] https://www.nanog.org/meetings/abstract?id=2025

[2] https://www.nanog.org/meetings/abstract?id=2075

[3] http://nanog.org/meetings/abstract?id=2130

[4] http://www.worldipv6launch.org/measurements/

Anything below this line has been added by my company’s mail server, I have no control over it. -----------

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

On Oct 2, 2015, at 07:48 , Cryptographrix <cryptographrix@gmail.com> wrote:

For ISPs that already exist, what benefit do they get from providing/allowing IPv6 transit to their customers?

Keep in mind that the net is now basically another broadcast medium.

It really isn’t. If it were, you wouldn’t have sites like Facebook, Youtube, etc. hosting so much UGC. The net is a two-way medium and it’s getting more and more bidirectional, not less so. Sure, there’s still lots of passively consumed content, but there’s more and more interactivity as well. The benefit to providing/allowing IPv6 transit to their customers is the ability to remain in business. There is a time coming when there will be IPv6-only features and/or content on the internet due to the shortage of IPv4 addresses. We’re already seeing higher performance and better throughput on IPv6 due to not having to deal with NAT (and possibly other causes) where it is implemented (See data from Facebook & VZW for example). In most cases, the costs of deploying IPv6 in an existing network are not that high, so providing a better user experience to your customers is usually a net win. Owen

On Fri, Oct 2, 2015 at 10:33 AM Steve Mikulasik <Steve.Mikulasik@civeo.com> wrote:

...

I think more focus needs to be for carriers to deliver dual stack to their customers door step, whether they demand/use it or not. Small ISPs are probably in the best position to do this and will help push the big boys along with time. If we follow the network effect (reason why IPv4 lives and IPv6 is slowly growing), IPv6 needs more nodes, all other efforts are meaningless if they do not result in more users having IPv6 delivered to their door.

I think people get too lost in the weeds when they start focusing on device support, home router support, user knowledge, etc. Just get it working to the people and we can figure out the rest later.

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mark Andrews Sent: Thursday, October 01, 2015 6:01 PM To: Matthew Newton <mcn4@leicester.ac.uk> Cc: nanog@nanog.org Subject: Re: How to force rapid ipv6 adoption

In message <20151001232613.GD123100@rootmail.cc.le.ac.uk>, Matthew Newton writes:

Additionally it is now a OLD addressing protocol. We are about to see young adults that have never lived in a world without IPv6. It may not have been universally available when they were born but it was available. There are definitely school leavers that have never lived in a world where IPv6 did not exist. My daughter will be one of them next year when she finishes year 12. IPv6 is 7 months older than she is.

Some of us have been running IPv6 in production for over a decade now and developing products that support IPv6 even longer.

We have had 17 years to build up a universal IPv6 network. It should have been done by now.

Mark

...

-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>

Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <560E9A20.7090703@satchell.net>, Stephen Satchell writes:

On 10/02/2015 07:27 AM, Steve Mikulasik wrote:

...

I think people get too lost in the weeds when they start focusing on device support, home router support, user knowledge, etc. Just get it working to the people and we can figure out the rest later.

The reality is that if customers can get it wrong, they WILL get it wrong. So sluffing off customer support isn't an option -- it WILL bite you in the ass, and the ISP who takes your advice can find themselves in hot water, perhaps even legal hot water.

Unless you are willing to let ISPs give out your phone number... :)

And turning on IPv6 really isn't any harder than turning on IPv4. It is plug and play with modern CPE devices. Lots of homes don't even know they are running IPv6 in parallel with IPv4. It is usually a non-event. The hard part is convincing the guys and gals on this list to turn it on and to provide a reasonable sized prefix via prefix delegation. You really should be providing a /48 and non of the /56 BS. That way you all can do site based reputation using a /48 which the bigger sites will have. One size fits all has big benefits. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Hi, Stop counting /64 subnets the same way you count ipv4 addresses. The proper concept to be able to have plug-and-play customer-grade network equipment would be to use prefix delegation. Thus counting levels of network devices instead. Consider the scenario in the attached sketch. It's a home with a router cpe that get's a block from isp via PD, could be /56 or /48. Customer have a wireless router connected, that requests a block from cpe. later the customer buys another wireless router to extend the network, and connects it to the old wireless router where it requests a block. This is a case that happens today already with multiple levels of NAT, not something that might eventually happen in the future. A reasonable assumption is that each sublevel device gets a PD block 4 bits longer then the last level. This allows for up to 15 directly connected routers. If the ISP hands out /56, then the first wireless router gets a /60 assigned, allowing for 16 attached /64 networks. The second wireless router can't get an block (out of bits), and will not work, plug-and-play breaks. This is likely to cause support calls as it worked with ipv4 (using NAT4444). If a /48 is assigned to each customer, then the first wireless router gets a /52, second router a /56 and there is room to connect one more level of devices. All works out of the box, everyone is happy, no support calls. On Fri, 2 Oct 2015 08:56:54 -0600 Brett A Mansfield <lists@silverlakeinternet.com> wrote:

The problem with this is some of us smaller guys don't have the ability to get IPv6 addresses from our upstream providers that don't support it. And even if we did do dual stack, then we're paying for both IPv4 and IPv6 addresses. The cost is just too high. ARIN should give anyone with a current IPv4 address block a free equivalently sized IPv6 block (256 IPv4 = 256 /56s or one /48 IPv6). If they did that, there would be a lot more IPv6 adoption in dual stack.

I don't understand why anyone would give an end user a /48. That is over 65,000 individual devices. A /56 is 256 devices which is the standard /24 IPv4. What home user has that many devices??? A /56 to the home should be standard. Based on giving each customer a /56, I could run my entire small ISP off a single /48. I know there are a lot of IP addresses in the IPv6 realm, but why waste them? At the rate were going, everything will have an IP address soon. Maybe one day each item of your clothing will need their own IP address to tell you if it's time to wash or if it needs repair. Stranger things have happened.

Thank you, Brett A Mansfield

...

On Oct 2, 2015, at 8:27 AM, Steve Mikulasik <Steve.Mikulasik@civeo.com> wrote:

I think more focus needs to be for carriers to deliver dual stack to their customers door step, whether they demand/use it or not. Small ISPs are probably in the best position to do this and will help push the big boys along with time. If we follow the network effect (reason why IPv4 lives and IPv6 is slowly growing), IPv6 needs more nodes, all other efforts are meaningless if they do not result in more users having IPv6 delivered to their door.

I think people get too lost in the weeds when they start focusing on device support, home router support, user knowledge, etc. Just get it working to the people and we can figure out the rest later.

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mark Andrews Sent: Thursday, October 01, 2015 6:01 PM To: Matthew Newton <mcn4@leicester.ac.uk> Cc: nanog@nanog.org Subject: Re: How to force rapid ipv6 adoption

In message <20151001232613.GD123100@rootmail.cc.le.ac.uk>, Matthew Newton writes:

Additionally it is now a OLD addressing protocol. We are about to see young adults that have never lived in a world without IPv6. It may not have been universally available when they were born but it was available. There are definitely school leavers that have never lived in a world where IPv6 did not exist. My daughter will be one of them next year when she finishes year 12. IPv6 is 7 months older than she is.

Some of us have been running IPv6 in production for over a decade now and developing products that support IPv6 even longer.

We have had 17 years to build up a universal IPv6 network. It should have been done by now.

Mark

...

-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>

Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 10/03/2015 08:40 PM, Owen DeLong wrote:

So a /48 isn’t about being able to support 295,147,905,179,352,825,856 devices in every home, it’s about being able to have 16 bits of subnet mask to use in delegating addresses in a dynamic plug-and-play hierarchical topology that can evolve on demand without user configuration or intervention.

Which is IMO scarcely enough to be as flexible as IPv6 is being touted. I've always considered 16 bits of subnetting way too small for an end site. Especially if you want to do things like dynamic plug-and-play hierarchical topology. Just following Robin Johansson's example in another email: On 10/02/2015 07:08 PM, Robin Johansson wrote:

If a /48 is assigned to each customer, then the first wireless router gets a /52, second router a /56 and there is room to connect one more level of devices. All works out of the box, everyone is happy, no support calls.

We only have up to 3 levels, and each level only supports 16 branches. May be fine for mom and dad now, but certainly not for other complex cases. And when you start factoring the whole "soup cans with IPv6" thing... I still think IPv6 should've been at least 192 bits long. Israel G. Lugo

The majority of the large eyeball providers in the US are already doing this to most, if not all, of their customers. Comcast I believe has 100% IPv6 availability to residential and I think they are most of the way on Business too. I’m not sure of the percentage, but I know Time Warner Cable is well underway with their IPv6 deployment. Even AT&T is making progress on their DSL and u-Verse services. Verizon FIOS is a laggard, which is interesting given that VZW was the first and still has the best Cellular IPv6 deployment in the US (IPv6 ONLY insisting on manufacturers implementing 464XLAT is inferior in every way to dual stack, so T-Mo loses and to the best of my knowledge, SPRINT still can’t spell IPv6 to save their life) I don’t think any of the MVNOs have any IPv6 capability yet. So the problem you are suggesting we focus on is mostly a solved problem. Content Providers are progressing, modulo some serious laggards, notably Amazon and a few others. The reality, however, is that in terms of deprecating IPv4, there does need to be a focus on consumer electronics, device support, home router support and it’s quite overdue. Fortunately, we’re finally starting to see some movement in that area. Owen

On Oct 2, 2015, at 07:27 , Steve Mikulasik <Steve.Mikulasik@civeo.com> wrote:

I think more focus needs to be for carriers to deliver dual stack to their customers door step, whether they demand/use it or not. Small ISPs are probably in the best position to do this and will help push the big boys along with time. If we follow the network effect (reason why IPv4 lives and IPv6 is slowly growing), IPv6 needs more nodes, all other efforts are meaningless if they do not result in more users having IPv6 delivered to their door.

I think people get too lost in the weeds when they start focusing on device support, home router support, user knowledge, etc. Just get it working to the people and we can figure out the rest later.

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mark Andrews Sent: Thursday, October 01, 2015 6:01 PM To: Matthew Newton <mcn4@leicester.ac.uk> Cc: nanog@nanog.org Subject: Re: How to force rapid ipv6 adoption

In message <20151001232613.GD123100@rootmail.cc.le.ac.uk>, Matthew Newton writes:

Additionally it is now a OLD addressing protocol. We are about to see young adults that have never lived in a world without IPv6. It may not have been universally available when they were born but it was available. There are definitely school leavers that have never lived in a world where IPv6 did not exist. My daughter will be one of them next year when she finishes year 12. IPv6 is 7 months older than she is.

Some of us have been running IPv6 in production for over a decade now and developing products that support IPv6 even longer.

We have had 17 years to build up a universal IPv6 network. It should have been done by now.

Mark

...

-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>

Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Sat, Oct 3, 2015 at 12:22 PM, Owen DeLong <owen@delong.com> wrote:

So the problem you are suggesting we focus on is mostly a solved problem. Content Providers are progressing, modulo some serious laggards, notably Amazon and a few others.

newly released IOS9 and OSX El Capitan add some serious latency for v4 only content, see: https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html I'm expecting all content providers to jump on the IPv6 train now that they're behind.

On Thu, Oct 1, 2015 at 4:26 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:

On Thu, Oct 01, 2015 at 10:42:57PM +0000, Todd Underwood wrote:

...

it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake, but i guess we're stuck with that now (i wish i could say something about lessons learned but i don't think any one of us has learned a lesson yet).

Would be really interesting to know how you would propose squeezing 128 bits of address data into a 32 bit field so that we could all continue to use IPv4 with more addresses than it's has available to save having to move to this new incompatible format.

I solved that problem a few years ago (well, kinda -- only for backend logging, not for routing): http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net...) Damian

On Thu, Oct 1, 2015 at 8:54 PM, Hugo Slabbert <hugo@slabnet.com> wrote:

On Thu 2015-Oct-01 18:28:52 -0700, Damian Menscher via NANOG < nanog@nanog.org> wrote:

...

On Thu, Oct 1, 2015 at 4:26 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:

On Thu, Oct 01, 2015 at 10:42:57PM +0000, Todd Underwood wrote:

...

...

it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake, but i guess we're stuck with that now (i wish i could say something about lessons learned but i don't think any one of us has learned a lesson yet).

Would be really interesting to know how you would propose squeezing 128 bits of address data into a 32 bit field so that we could all continue to use IPv4 with more addresses than it's has available to save having to move to this new incompatible format.

I solved that problem a few years ago (well, kinda -- only for backend logging, not for routing):

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net...)

Squeezing 32 bits into 128 bits is easy. Let me know how you do with squeezing 128 bits into 32 bits...

I did just fine, thanks. (You may want to read the link again.... ;) Damian

On Fri 2015-Oct-02 09:43:40 -0700, Hugo Slabbert <hugo@slabnet.com> wrote:

My apologies; missed the anchor for some reason and just got the top bits of the doc. -- Hugo hugo@slabnet.com: email, xmpp/jabber also on TextSecure & RedPhone

---- From: Damian Menscher <damian@google.com> -- Sent: 2015-10-02 - 08:45 ----

...

On Thu, Oct 1, 2015 at 8:54 PM, Hugo Slabbert <hugo@slabnet.com> wrote:

...

On Thu 2015-Oct-01 18:28:52 -0700, Damian Menscher via NANOG < nanog@nanog.org> wrote:

...

On Thu, Oct 1, 2015 at 4:26 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:

On Thu, Oct 01, 2015 at 10:42:57PM +0000, Todd Underwood wrote:

...

...

it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake, but i guess we're stuck with that now (i wish i could say something about lessons learned but i don't think any one of us has learned a lesson yet).

Would be really interesting to know how you would propose squeezing 128 bits of address data into a 32 bit field so that we could all continue to use IPv4 with more addresses than it's has available to save having to move to this new incompatible format.

I solved that problem a few years ago (well, kinda -- only for backend logging, not for routing):

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net...)

Squeezing 32 bits into 128 bits is easy. Let me know how you do with squeezing 128 bits into 32 bits...

I did just fine, thanks. (You may want to read the link again.... ;)

Out of curiosity, the method you describe is lossy, though, no? It is basically just intended to ensure that we don't break the database or application when we write an IPv6 address into it because it can only handle an IPv4 value. I appreciate the hack & know you have a disclaimer on there of "only for logging, not routing," but "squeezing 128 bits of address data into a 32 bit field" is a bit of a stretch to describe a process that takes 128 bits, discards 64 of them, and then hashes the remaining 64 bits into 29 bits, no?

...

Damian

-- Hugo

On 10/1/2015 5:16 PM, Ca By wrote:

I run a large 464xlat dominated mobile network.

IPv4 bits are materially more expensive to deliver.

Isn't that simply a consequence of your engineering decision to use 464xlat instead of native dual-stack, as was originally envisioned for the transition?

And, as FB has shared, IPv6 is more performant for end users, and more performant is more profitable

Isn't that also at least partially a consequence of your engineering decision to use 464xlat? Matthew Kaufman

Nothing to do with religion at all. I advocate IPv6 all the time as some one who deals a lot with SIP. The issues are endless when dealing with NAT. NAT is an ugly hack and should die already. It will take a few years for router manufactures to get it right but them they do it will be better for all. Regards, Dovid -----Original Message----- From: Todd Underwood <toddunder@gmail.com> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Thu, 01 Oct 2015 22:42:57 To: Mark Andrews<marka@isc.org>; Owen DeLong<owen@delong.com> Cc: <nanog@nanog.org> Subject: Re: How to force rapid ipv6 adoption i'm still confused, to be honest. why are we 'encouraging' 'evangelizing' or 'forcing' ipv6 adoption. it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake, but i guess we're stuck with that now (i wish i could say something about lessons learned but i don't think any one of us has learned a lesson yet). so people will renumber their network assets into this new network namespace when either: 1) the new non-internet ipv6 network has enough good stuff only on it that it makes sense to go over there; or 2) the old ipv4 internet addresses get so expensive that ain't no one willing to pay. right now, neither of those things are true. so people who are adopting ipv6 are doing so for two reason: A) blind, unmotivated religious reasons. they "believe" in this new protocol and have somehow managed to tie their identity up in it. (this is clearly a mistake for an engineer: technology comes and goes. don't ever tie your identity up in some technology or you'll end up advocating DECNET for the cloud at some point. it won't be pretty). B) strategic reasons. there are people who think that switching costs are going to be high and that there's an advantage to moving earlier to be ready for coming demand when #1 or #2 above happen. unlike A, B is completely rational and smart. it might be wrong, but it's not stupid at all. put mike leber and HE in this B category. the only reason people are *advocating* ipv6 right now are that they've made a religious choice, which is weird and should be a personal, not public choice unless they are great commission ipv6 adherants [1], *or* they have a vested interest in getting your business. the first reason is religion and is off-topic for nanog and the second reason is marketing (however well intentioned) and should also be off topic for nanog. so can we stop talking about ipv6 advocacy and move on to the network engineering topics, please? if someone is running ipv6 for whatever reason and has questions, awesome. if someone wants to talk about addressing schemes, awesome. but trying to convince someone to run LAT^H^H^Hipv6 or whatever disconnected network protocol they're advocating today? not useful. cheers, t On Thu, Oct 1, 2015 at 6:32 PM Mark Andrews <marka@isc.org> wrote:

In message <4F2E19BA-D92A-4BEC-86E2-33B405C307BE@delong.com>, Owen DeLong writes:

...

...

On Oct 1, 2015, at 13:55 , Grzegorz Janoszka <Grzegorz@Janoszka.pl> wrote:

On 2015-10-01 20:29, Owen DeLong wrote:

...

However, I think eventually the residential ISPs are going to start charging extra for IPv4 service.

ISP's will not charge too much. With too expensive IPv4 many customers will migrate from v4/dual stack to v6-only and ISP's will be left with unused IPv4 addresses and less income.

Nope… They’ll be left with unused IPv4 addresses which is not a significant source of income and they’ll be able to significantly reduce the costs incurred in supporting things like CGNAT.

...

Will ISP's still find other profitable usage for v4 addresses? If not, they will be probably be quite slowly rising IPv4 pricing, not wanting to overprice it.

Probably they will sell it to business customers instead of the residential customers. However, we’re talking about relatively large numbers of customers for relatively small numbers of IPv4 addresses that aren’t producing revenue directly at this time anyway.

...

Even with $1/IPv4/month - what will be the ROI of a brand new home router?

About 2.5 years at that price since a brand new home router is about $29.

Owen

The hard part is the internet connected TV's and other stuff which fetches content over the internet which are IPv4 only despite being released when IPv6 existed. These are theoretically upgradable to support IPv6 so long as the manufactures release a IPv6 capable image. The real question is will governments force them to do this.

Upgrading the router is a no brainer. Upgrading the TV, games consoles, e-readers, etc. starts to add up.

Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Oct 1, 2015, at 3:42 PM, Todd Underwood <toddunder@gmail.com> wrote:

it's just a new addressing protocol that happens to not work with the rest of the internet. it's unfortunate that we made that mistake

I understand the comment, but I see some issues with it. The problem isn't that IPv6 isn't backward-compatible, or that the changes to the Socket Library aren't backward compatible (the socket interface being the reason we have to upgrade applications, and btw getaddrinfo *is* backward-compatible), it's that the old stuff (IPv4, gethostbyname) aren't forward compatible. If we had deployed a new protocol that allowed us to use IPv4 addresses as well as the new format (which, BTW, we did), it would still be a new protocol that had to be deployed and enabled. There's no way to change the IPv4 address to be larger, or to get gethostbyname to return a non-IPv4 address. Had there been an easy way to expand an IPv4 address to a larger number of bytes, we wouldn't have needed to replace IPv4.

that's crazy. why would you want a simple way to boostrap more addresses from what we have now? you'll never make yourself into an internationally known ipvNEXT advocate with engineering like that. more advocacy. less engineering! t On Fri, Oct 2, 2015 at 5:18 PM, William Herrin <bill@herrin.us> wrote:

On Fri, Oct 2, 2015 at 5:03 PM, Fred Baker (fred) <fred@cisco.com> wrote:

...

There's no way to change the IPv4 address to be larger

http://bill.herrin.us/network/ipxl.html

There's always a way.

Regards, Bill Herrin

-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

This still would have required updating every application, host, router, everything. Just as much work as deploying IPv6 without many of the benefits. No thanks, Owen

On Oct 2, 2015, at 14:18 , William Herrin <bill@herrin.us> wrote:

On Fri, Oct 2, 2015 at 5:03 PM, Fred Baker (fred) <fred@cisco.com> wrote:

...

There's no way to change the IPv4 address to be larger

http://bill.herrin.us/network/ipxl.html

There's always a way.

Regards, Bill Herrin

-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

On Oct 1, 2015, at 15:28 , Mark Andrews <marka@isc.org> wrote:

In message <4F2E19BA-D92A-4BEC-86E2-33B405C307BE@delong.com>, Owen DeLong writes:

...

...

On Oct 1, 2015, at 13:55 , Grzegorz Janoszka <Grzegorz@Janoszka.pl> wrote:

On 2015-10-01 20:29, Owen DeLong wrote:

...

However, I think eventually the residential ISPs are going to start charging extra for IPv4 service.

ISP's will not charge too much. With too expensive IPv4 many customers will migrate from v4/dual stack to v6-only and ISP's will be left with unused IPv4 addresses and less income.

Nope… They’ll be left with unused IPv4 addresses which is not a significant source of income and they’ll be able to significantly reduce the costs incurred in supporting things like CGNAT.

...

Will ISP's still find other profitable usage for v4 addresses? If not, they will be probably be quite slowly rising IPv4 pricing, not wanting to overprice it.

Probably they will sell it to business customers instead of the residential customers. However, we’re talking about relatively large numbers of customers for relatively small numbers of IPv4 addresses that aren’t producing revenue directly at this time anyway.

...

Even with $1/IPv4/month - what will be the ROI of a brand new home router?

About 2.5 years at that price since a brand new home router is about $29.

Owen

The hard part is the internet connected TV's and other stuff which fetches content over the internet which are IPv4 only despite being released when IPv6 existed. These are theoretically upgradable to support IPv6 so long as the manufactures release a IPv6 capable image. The real question is will governments force them to do this.

Governments are unlikely to force this issue. However, what I think will happen (and I wish I had the hardware skills to build the device) is that someone will come up with a compact, cheap (think price of Raspberry PI) device with two 100Mbps ethernet ports. One will be an RJ45 plug and the other will be a socket. The socket will support POE for powering the device. The device will have a small linux kernel and provide DNS64/DHCP4/NAT64 services to the RJ45 plug and the jack will connect to the IPv6-only port in the house. The software is already completely available as open source. There’s a tiny bit of integration to do. If you do this for IPv6-capable services on the outside and don’t need to connect to IPv4 laggards, this is a relatively simple solution. If you need to preserve IPv4 connectivity to the outside world, it gets a little more complicated, but not a lot.

Upgrading the router is a no brainer. Upgrading the TV, games consoles, e-readers, etc. starts to add up.

I’m betting that if someone offered the device I suggested above for a price point around $40 (add a small amount of money for a cheap POE injector if needed), it would do the trick. Owen

That reminds me of a story. Once a teacher gave each of his students a tube of toothpaste. He said "Squeeze all of the toothpaste out of the tube on to your desk." The kids laughed and did it, making a giant mess and having a ball. When things settled down, the teacher said "Now put all of the toothpaste back into the tube." The kids fell silent. A few of them even tried the futile task. Then the teacher said "The toothpaste is the Internet. Once it's deployed, it is nearly impossible to put it back the way it was."* Beckman * OK, the teacher said "The toothpaste are your words. Once they come out, you can't put them back in." Or something. My storytelling skills need work. On Thu, 1 Oct 2015, jungle Boogie wrote:

On 29 September 2015 at 13:37, David Hubbard <dhubbard@dino.hostasaurus.com> wrote:

...

Had an idea the other day; we just need someone with a lot of cash (google, apple, etc) to buy Netflix and then make all new releases v6-only for the first 48 hours. I bet my lame Brighthouse and Fios service would be v6-enabled before the end of the following week lol.

Let's just put less stuff on the internet and revert pre-internet days.

-- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si

--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------