Re: How to force rapid ipv6 adoption

[Mark Andrews]

In message <56157950.5040...@lugosys.com>, "Israel G. Lugo" writes:
> 
> 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 
> > devic
> es 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:

Which is why "homenet" routers don't do that.  They just get the
prefixes they need now and route them within the site.  If they
need a additional prefix they ask for it when they needed it.  65000
routes is not a lot of routes for even the smallest of routers to
handle.

Mark

> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: How to force rapid ipv6 adoption

[Israel G. Lugo]

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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[John Levine]

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

I don't know anyone who does that.  But I know a lot of people who use
both IPv4 and IPv6 addresses to distinguish among "has sent legit
mail", "is a spambot", and "no history".  Those are handy when mixed
into the usual multi-factor spam filtering.  Outright blocking on
conservative lists of spambots like the CBL (now XBL) works well, too.

R's,
John

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[George Michaelson]

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 
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 (r...@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??
>

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Måns Nilsson]

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 
(r...@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??


signature.asc
Description: Digital signature

Re: How to force rapid ipv6 adoption

[Wolfgang S. Rupprecht]

> (IPv6 ONLY insisting on manufacturers implementing 464XLAT is inferior
> in every way to dual stack,

There is one way it is superior; it rewards web and other content sites
that implement IPv6.  Unlike dual stack, it applies pressure where it is
needed, on the IPv4-only sites.   Grottiness can be a good thing.

-wolfgang

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Barry Shein]

>From the time we began to take the idea of an address runout seriously
in the early 90s to the actual address runout which would be just
about now new priorities arose such as spam which I'll say really got
going in the late 90s.

There were others such as the potential routing table explosion which
no doubt got passing notice from the start but I think it's safe to
say has been looming more and more as a potential big problem in
recent years.

And security & privacy which perhaps something like an IPv6 couldn't
much solve, most of that is higher in the stack, but then again maybe
not. Didn't OSI have some sort of L2 credentials passing?

That's all difficult to debate if for no other reason than one says
"security" and several different definitions and priorities pop into
people's heads ranging from low-level issues such as ddos and spoofing
and simple sniff and MITM avoidance to what it might mean to a bank
security officer or credit card undewriter or an individual at
risk. And spam and phishing and all that. Oh and toss intellectual
property rights management on the fire because it casts such a lovely
glow.

This has been a moving target and a canvas on which to paint each now
and evolving challenge of a technology which has grown into ubiquity.

Around 1992 when IPv6 was just picking up steam the net engineering
community was pretty happy if an email got delivered in well under a
minute and an FTP went smoothly. Words like congestion and route
flapping could take up entire career paths.

I think we need to stop replaying history like what if there weren't a
Russian winter and just press forward.

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Owen DeLong]

> On Oct 3, 2015, at 14:01 , William Herrin  wrote:
> 
> On Sat, Oct 3, 2015 at 10:35 AM, Scott Morizot  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.

Both of these are solved through network-hashed persistent IPv6 privacy 
addresses.

Owen

Re: How to force rapid ipv6 adoption

[Jérôme Fleury]

On Sat, Oct 3, 2015 at 12:22 PM, Owen DeLong  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.

Re: How to force rapid ipv6 adoption

[Scott Weeks]

--- ma...@isc.org wrote:
From: Mark Andrews 

:: Lots of homes don't even know they are running 
:: IPv6 in parallel with IPv4.  It is usually a 
:: non-event.
--

That's for sure.  I have been focusing a lot on work
lately instead of my home network and one day I just
happened to notice one of my ISPs (TW) turned on IPv6 
in Hawaii.  Embarrassingly, I don't even know when 
they turned it on.  It just worked.


:: The hard part is convincing the guys and gals on 
:: this list to turn it on

In defense of many folks on the list it is many times
a VERY hard task convincing non-technical or minimally
technically oriented managers to let us have the time
and permission to roll it out.  It's one thing that's 
got me really grumpy about where I work.  They just 
don't (and don't want to) understand.


scott

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[William Herrin]

On Sat, Oct 3, 2015 at 10:35 AM, Scott Morizot  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  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: How to force rapid ipv6 adoption

[Ca By]

On Saturday, October 3, 2015, Owen DeLong  wrote:

> 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 believe the Samsung Galaxy 6 launched with ipv6 by default on all 4
national networks in the USA


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  > 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-boun...@nanog.org ] On Behalf
> Of Mark Andrews
> > Sent: Thursday, October 01, 2015 6:01 PM
> > To: Matthew Newton >
> > Cc: nanog@nanog.org 
> > Subject: Re: How to force rapid ipv6 adoption
> >
> >
> > In message <20151001232613.gd123...@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. >
> >>
> >> Systems Specialist, Infrastructure Services, I.T. Services, University
> >> of Leicester, Leicester LE1 7RH, United Kingdom
> >>
> >> For IT help contact helpdesk extn. 2253,  >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 
> >
>
>

Re: How to force rapid ipv6 adoption

[Owen DeLong]

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  wrote:
> 
> On Fri, Oct 2, 2015 at 5:03 PM, Fred Baker (fred)  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  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 

Re: How to force rapid ipv6 adoption

[Owen DeLong]

> On Oct 2, 2015, at 13:45 , Todd Underwood  wrote:
> 
> On Fri, Oct 2, 2015 at 2:07 PM, Owen DeLong  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 insulti

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Owen DeLong]

> On Oct 2, 2015, at 08:05 , Justin M. Streiner  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

Re: How to force rapid ipv6 adoption

[Owen DeLong]

> On Oct 2, 2015, at 07:56 , Brett A Mansfield  
> 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. 

False… ARIN will charge you the fee for the largest category you fall into, v4 
or v6, but not both.

So, if you are in the ISP category and have a /22 or less, you’re currently not 
really able to deploy IPv6 for free, but it will only cost you $500/year more 
than what you are already paying to ARIN.

If you have a /20 or less, then you can get IPv6 from ARIN without increasing 
your fees (/36) simply by requesting it. However, you should seriously consider 
requesting a /32 and biting the bullet on the $2000/year fee.

There is work in progress on getting ARIN fees brought more in line between 
IPv4 and IPv6 and you may want to consider participating in that process and 
submitting your thoughts to the board for consideration. There will be a 
discussion of this at the upcoming ARIN meeting in Montreal. Please attend 
either in person or remotely and voice your thoughts.

If you have more than a /20, then you can easily get a /32 IPv6 just for the 
asking with no fee impact whatsoever.

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

Clearly you have not taken the time to understand the fundamentals of IPv6.

First, a /48 is 65,536 subnets, not 65,000+ devices. Each of those subnets can 
support more than 18 quintillion devices (18,446,744,073,709,551,616 to be 
exact), assuming that the customer uses /64 subnets.

A /56 is 256 subnets, and /24s are not really standard for end users in IPv4, 
especially residential users, so I’m not sure what you’re talking about there.

You’re thinking like IPv4. In IPv4, we had to count individual devices and 
think about hosts. In IPv6, we want to get completely away from that. We also 
want to pave the way for auto-conf/zero-conf even with complex topologies that 
may evolve.

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.

If you cut that down to 8 bits, you seriously reduce the ability for these 
designs to ever get off the ground.

So… IPv6 Lesson 1: Stop counting hosts and start thinking about counting 
subnets… Then realize that if you give 65,536 subnets to every end-site, you 
don’t even have to count subnets and move on.

There’s no legitimate reason not to give an end-site a /48. There is no benefit 
whatsoever to preserving the scarcity mentality of IPv4. Please move forward.

Thanks,

Owen


> 
> Thank you,
> Brett A Mansfield
> 
>> On Oct 2, 2015, at 8:27 AM, Steve Mikulasik  
>> 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-boun...@nanog.org] On Behalf Of Mark Andrews
>> Sent: Thursday, October 01, 2015 6:01 PM
>> To: Matthew Newton 
>> Cc: nanog@nanog.org
>> Subject: Re: How to force rapid ipv6 adoption
>> 
>> 
&g

Re: How to force rapid ipv6 adoption

[Owen DeLong]

> On Oct 2, 2015, at 07:48 , 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.

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 
> 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-boun...@nanog.org] On Behalf Of Mark Andrews
>> Sent: Thursday, October 01, 2015 6:01 PM
>> To: Matthew Newton 
>> Cc: nanog@nanog.org
>> Subject: Re: How to force rapid ipv6 adoption
>> 
>> 
>> In message <20151001232613.gd123...@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. 
>>> 
>>> Systems Specialist, Infrastructure Services, I.T. Services, University
>>> of Leicester, Leicester LE1 7RH, United Kingdom
>>> 
>>> For IT help contact helpdesk extn. 2253, 
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>> 
>> 

Re: How to force rapid ipv6 adoption

[Owen DeLong]

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  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-boun...@nanog.org] On Behalf Of Mark Andrews
> Sent: Thursday, October 01, 2015 6:01 PM
> To: Matthew Newton 
> Cc: nanog@nanog.org
> Subject: Re: How to force rapid ipv6 adoption
> 
> 
> In message <20151001232613.gd123...@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. 
>> 
>> Systems Specialist, Infrastructure Services, I.T. Services, University 
>> of Leicester, Leicester LE1 7RH, United Kingdom
>> 
>> For IT help contact helpdesk extn. 2253, 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Mike Hammett]

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"  
To: "Mike Hammett"  
Cc: "nanog group"  
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  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"  
> To: "Mike Hammett"  
> Cc: "nanog group"  
> 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 < na...@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" < tagn...@gmail.com > 
> To: "Rob McEwen" < r...@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 < r...@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. 
> 
> 
>  

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[John Levine]

>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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Owen DeLong]

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  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"  
> To: "Mike Hammett"  
> Cc: "nanog group"  
> 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 < na...@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" < tagn...@gmail.com > 
> To: "Rob McEwen" < r...@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 < r...@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. 
> 
> 
> 

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Owen DeLong]

> On Oct 2, 2015, at 06:44 , Stephen Satchell  wrote:
> 
> On 10/02/2015 12:44 AM, valdis.kletni...@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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Mike Hammett]

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"  
To: "Mike Hammett"  
Cc: "nanog group"  
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  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"  
> To: "Rob McEwen"  
> Cc: "nanog group"  
> 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  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. 

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Owen DeLong]

How do you figure that?

Owen

> On Oct 2, 2015, at 04:14 , Mike Hammett  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"  
> To: "Rob McEwen"  
> Cc: "nanog group"  
> 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  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. 

RE: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Frank Bulk]

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-boun...@nanog.org] On Behalf Of Randy Bush
Sent: Saturday, October 03, 2015 11:37 AM
To: Scott Morizot 
Cc: North American Network Operators' Group 
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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Rob McEwen]

On 10/3/2015 10:35 AM, Scott Morizot 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. 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.


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). For 
example, already in the IPv4 world, not having a PTR record means that 
lots of your mail won't get delivered. And not having a PTR record puts 
a "hair trigger" on your IP as far as getting blacklisted. Furthermore, 
having a dynamic-formatted PTR record is also a red flag. In contrast, a 
properly formatted PTR record, that ends in your primary domain name, 
does two HUGE things: It conveys both IDENTITY and REPUTATION upon that 
IP. Then FCrDNS follows that up by proving that the PTR record is authentic.


Sadly, some very legit sources of e-mail that frustrate customers when 
blocked.. don't follow these rules... even a few senders with *no* PTR 
records. Fortunately, those are rare, and are generally handled with 
whitelistings, etc.--once confirmed to be sending important/desired mail.


I was hoping that IPv6 could, if anything, tighten up these standards... 
ideally, these standards WOULD/SHOULD tighten up... but it looks like 
IPv6 is going to destroy these standards instead.


Why? Because if an anti-spam blacklist is operating according to so many 
people's suggestions on this thread... and treating a /48 as if it were 
one IP. (or even a /56 or /64)... and should "not worry about individual 
addresses"... doesn't it remain true that in the IPv6 world... that PTR 
records are assigned on an individual IP basis? Or am I wrong and there 
is some kind of more generic PTR record lookup for a whole /64, or /48?


If they are assigned individually, then this this is yet another reason 
that spam filtering for IP6 is thrown back into the dark ages (among 
others I've mentioned--that have NOT been fully answered).


For example, if a spammer who has acquired a /48 is sending from 
literally millions, perhaps billions, of DIFFERENT IPs on that /48, then 
(a) the individual PTR records lookups would be prohibitively expensive 
(no scaling) and DNS caches of those would fill up RAM and hard drives, 
and (b) those actual PTR lookups could map back 1-to-1 to the spammers 
distribution list and give the spammer valuable intel about spamtraps, 
helping them "listwash", etc. (they would merely need to figure out the 
sources of the anti-spam blacklist's PTR lookups... this isn't an issue 
in the IPv4 world because they can't map that lookup to an individual 
e-mail address)


Losing that tool (PTR and FCrDNS) for tracking/identifying senders... is 
a HUGE loss for spam filters and for anti-spam blacklists.. not just in 
the ability to identify spammers, but also in their ability to minimize 
false positives due to being able to more accurately identifying legit 
senders. (especially legit sender's newly acquired IP ranges that they 
deploy for mail sending)


And on a simpler level, if there are multiple DIFFERENT PTR records for 
different IPs on that same /48 or /56 or /64 (different as in, ending 
with a different domain)... which one should be used for identifying the 
validity of the whole block?


Sure, IP whois info is another helpful source... but I find LOTS of 
situations the IP4 world where IP whois doesn't drill down very far, and 
MASSIVE numbers of very diverse and separate networks are under one 
massive umbrella, where treating them all the same would cause massive 
FPs or massive FNs. is IPv6 any (or much!) better? Or can that 
too-large-umbrella happen with IPv6, too?


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.


You sound like you think I'm looking for a problem. But I'm actually 
looking for solutions, and I think you're underestimating the problems. 
I wonder if you read my posts. I'm all in favor of rapid adoption of 
IPv6 for SMTP-Authenticated traffic from the client to server. And I'm 
in favor of all non-mail rapid adoption of IPv6. The ONLY area where I 
think IPv6 shouldn't be too fast is MTA-to-MTA communication, and where 
we shouldn't eliminate IPv4 too fast for this reason alone.


when you say, "north of 10%"... I wonder, what is that percentage if you 
don't include client-to-serve

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Randy Bush]

> 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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Scott Morizot]

On Fri, Oct 2, 2015 at 1:35 PM, Owen DeLong  wrote:

>
> > On Oct 1, 2015, at 21:47 , Rob McEwen  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

Re: How to force rapid ipv6 adoption

[Randy Bush]

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

indeed.  a tragedy.

randy

Re: How to force rapid ipv6 adoption

[Ca By]

On Friday, October 2, 2015, Baldur Norddahl 
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-akamai/ipv6-traffic-volume.jsp
>
> 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
>

Re: How to force rapid ipv6 adoption

[Mark Andrews]

In message <560e9a20.7090...@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: ma...@isc.org

Re: How to force rapid ipv6 adoption

[Baldur Norddahl]

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-akamai/ipv6-traffic-volume.jsp

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

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

Re: How to force rapid ipv6 adoption

[Fred Baker (fred)]

> On Oct 2, 2015, at 2:18 PM, William Herrin  wrote:
> 
> On Fri, Oct 2, 2015 at 5:03 PM, Fred Baker (fred)  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

We could discuss IPv8 and IPv16...

The question I would ask about your model is how one determines whether one is 
looking at a 32 or 64 bit destination address. Does one, for example, have to 
parse the options field before making that determination? How does that work in 
a router that drops an IPv4 header that is not 20 bytes in length?

There were a number of options kicked around that, in one way or another, 
reused packet fields (what is we assume that fragmentation doesn't ever 
happen?) or inserted options. Right, wrong, or indifferent, it wasn't that it 
wasn't considered, it was that it wasn't chosen.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: How to force rapid ipv6 adoption

[Todd Underwood]

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  wrote:
> On Fri, Oct 2, 2015 at 5:03 PM, Fred Baker (fred)  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  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 

Re: How to force rapid ipv6 adoption

[William Herrin]

On Fri, Oct 2, 2015 at 5:03 PM, Fred Baker (fred)  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  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: How to force rapid ipv6 adoption

[Fred Baker (fred)]

> On Oct 1, 2015, at 3:42 PM, 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

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.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: How to force rapid ipv6 adoption

[Hugo Slabbert]

On Fri 2015-Oct-02 09:43:40 -0700, Hugo Slabbert  wrote:


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

 From: Damian Menscher  -- Sent: 2015-10-02 - 08:45 


On Thu, Oct 1, 2015 at 8:54 PM, Hugo Slabbert  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 
wrote:

On Thu, Oct 01, 2015 at 10:42:57PM +, 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/InetAddresses.html#getCoercedIPv4Address(java.net.InetAddress)



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


signature.asc
Description: Digital signature

Re: How to force rapid ipv6 adoption

[Todd Underwood]

On Fri, Oct 2, 2015 at 2:07 PM, Owen DeLong  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
>
>

Re: How to force rapid ipv6 adoption

[George, Wes]

From: Cryptographrix mailto:cryptograph...@gmail.com>>
Date: Friday, October 2, 2015 at 12:35 PM
To: "George, Wes" mailto:wesley.geo...@twcable.com>>
Cc: "nanog@nanog.org<mailto:nanog@nanog.org>" 
mailto:nanog@nanog.org>>
Subject: Re: How to force rapid ipv6 adoption

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.

WG] hmm, hopefully someone reading from NANOG will unbork the URLs. If nothing 
else, they post the presentation videos to their youtube channel, so you can 
find it there by going directly.

It makes me curious about the churn rate between ISPs, but that's a different 
topic and everything you've said is spot on.\
WG] in this context I was talking about churn within the ISP rather than 
between them, and it probably would have been more accurate to talk in terms of 
net customer growth – how many customers do you lose vs how many new ones you 
add?

What seems really important/would be progressive at the moment is that vendors 
release IPv6-capable "plug and play" gear.
WG] and that's a mixed bag. Many routers, all computers, smartphones, tablets, 
etc are plug and play for IPv6, but the IoT widgetry, video streaming devices, 
etc have a ways to go yet. Lots of folks like me pulling every lever we can 
find to make sure our vendors and partners in CPE and content land understand 
that IPv6 is a requirement, but it's little by little and progress is slow.

Is there any vendor that's currently working on a home router that provides 
*only* IPv6 internally, with NAT64 IPv6->IPv4?
WG] well, TMobile has a considerable amount of IPv6-only Android devices on 
their mobile network using 464xlat as the shim. On the home router side, there 
are devices that are capable of terminating an IPv6 in IPv4 tunnel to allow 
people to hop over their ISP that isn't supporting IPv6 and dual stack their 
home. Lots of us use this method + a tunnel provider like HE to have IPv6 at 
home, but that's becoming less important as Comcast and TWC and other broadband 
providers enable IPv6 for real across their networks. There are also devices 
that can do DSLite so that it's IPv6-only out of the house (encapsulate IPv4 in 
IPv6 to a remote NAT), but still supports dual-stack in the house. The number 
of devices in the average house that don't support IPv6 makes IPv6-only in the 
house problematic and a much longer-term goal.

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.
WG] Generally my philosophy has been that customers just want their internet 
service to work, not know anything about which IP stack they're using, and thus 
IPv6 isn't a value-added feature that you can sell to the average folks buying 
a cheap plastic router off of Amazon. Now that we're seeing evidence that IPv6 
is faster, there's a potential marketing angle for gamers (better network 
performance!!!) but we're still building the case for that, and tunnels tend to 
negate those sorts of benefits (you need native IPv6) so that's probably 
premature.

Additionally, is it possible for ISPs to offer IPv6 transit-exclusive plans for 
people that would like to get just that?
WG] I think that day is coming, but not yet. There has to be a critical mass of 
common/important IPv6-enabled content and devices, and the problem is that most 
of the folks who know enough about networking to know that they only need IPv6 
probably still need IPv4 (see also previous comment). But if someone only uses 
their internet connection for webmail (G or Y!) and Facebook and maybe a little 
Youtube with a small subset of devices, it's workable today, and it keeps 
getting more workable, either with or without an IPv4 shim like 464Xlat or 
NAT64/DNS64. It's really a question of when you get far enough along to be 
confident that it's reliable enough for average customers (for some value of 
"average") without making the phone ring.

Thanks,

Wes

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.

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Owen DeLong]

> On Oct 1, 2015, at 21:47 , Rob McEwen  wrote:
> 
> 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

Then as another poster suggested, they deserve whatever pain they suffer from 
this.

Mark is correct… It is the ISP’s poor decision in these cases that is the 
problem. Not the SPAM block and not IPv6.

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

That’s not as true as you want to believe it to be.

While /48s are not scarce globally, there is a significant cost to going back 
to the RIR for a larger allocation. You have to show active utilization of your 
existing space in order to get more.

As such, ISPs are going to be motivated not to treat blocks as disposable 
entities.

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


Owen

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Owen DeLong]

> On Oct 1, 2015, at 20:58 , Rob McEwen  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

Re: How to force rapid ipv6 adoption

[Owen DeLong]

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  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  wrote:
> 
>  On Oct 1, 2015, at 12:06 , Curtis Maurand  wrote:
>  
>  
>  
>  On 10/1/2015 2:29 PM, Owen DeLong wrote:
>  On Oct 1, 2015, at 00:39 , Baldur Norddahl  wrote:
>  
>  On 1 October 2015 at 03:26, Mark Andrews  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.

Re: How to force rapid ipv6 adoption

[Robin Johansson]

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

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  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
> >  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-boun...@nanog.org] On Behalf Of Mark
> > Andrews Sent: Thursday, October 01, 2015 6:01 PM
> > To: Matthew Newton 
> > Cc: nanog@nanog.org
> > Subject: Re: How to force rapid ipv6 adoption
> > 
> > 
> > In message <20151001232613.gd123...@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. 
> >> 
> >> Systems Specialist, Infrastructure Services, I.T. Services,
> >> University of Leicester, Leicester LE1 7RH, United Kingdom
> >> 
> >> For IT help contact helpdesk extn. 2253, 
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> > 
> 


pgpxJL5uuR52j.pgp
Description: OpenPGP digital signature

Re: How to force rapid ipv6 adoption

[Owen DeLong]

> On Oct 1, 2015, at 18:37 , Todd Underwood  wrote:
> 
> 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. 
> 
> 
There are multiple translation systems and I’ve heard of most, if not all of 
them.

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

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

Re: How to force rapid ipv6 adoption

[Hugo Slabbert]

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

 From: Damian Menscher  -- Sent: 2015-10-02 - 08:45 

> On Thu, Oct 1, 2015 at 8:54 PM, Hugo Slabbert  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 
>>> wrote:
>>>
>>> On Thu, Oct 01, 2015 at 10:42:57PM +, 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/InetAddresses.html#getCoercedIPv4Address(java.net.InetAddress)
>>>
>>
>> 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




signature.asc
Description: PGP/MIME digital signature

Re: How to force rapid ipv6 adoption

[Cryptographrix]

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

>
> On 10/2/15, 10:48 AM, "NANOG on behalf of Cryptographrix"
>  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.
>

Re: How to force rapid ipv6 adoption

[George, Wes]

On 10/2/15, 10:48 AM, "NANOG on behalf of Cryptographrix"
 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.

Re: How to force rapid ipv6 adoption

[Damian Menscher via NANOG]

On Thu, Oct 1, 2015 at 8:54 PM, Hugo Slabbert  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 
>> wrote:
>>
>> On Thu, Oct 01, 2015 at 10:42:57PM +, 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/InetAddresses.html#getCoercedIPv4Address(java.net.InetAddress)
>>
>
> 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

Re: How to force rapid ipv6 adoption

[Cryptographrix]

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

Re: How to force rapid ipv6 adoption

[Stephen Satchell]

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.

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Justin M. Streiner]

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.


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.


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.


jms

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Stephen Satchell]

On 10/01/2015 08:18 PM, corta...@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.

Re: How to force rapid ipv6 adoption

[Brett A Mansfield]

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  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-boun...@nanog.org] On Behalf Of Mark Andrews
> Sent: Thursday, October 01, 2015 6:01 PM
> To: Matthew Newton 
> Cc: nanog@nanog.org
> Subject: Re: How to force rapid ipv6 adoption
> 
> 
> In message <20151001232613.gd123...@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. 
>> 
>> Systems Specialist, Infrastructure Services, I.T. Services, University 
>> of Leicester, Leicester LE1 7RH, United Kingdom
>> 
>> For IT help contact helpdesk extn. 2253, 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 

Re: How to force rapid ipv6 adoption

[jungle Boogie]

On 1 October 2015 at 16:12, Peter Beckman  wrote:
> 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.

Sadly, both are true and I wish many times over I could take back some
of my words. ;)

I suppose the same could be said for electricity, too. The vast
majority of us are not willing to go through a summer without our A/C
and there's still problems with storms taking out utilities so nothing
is perfect.
I really hope manufactures of internet of things will make their
devices work on ipv6 without much (if any) wild configuring done by
the end user. We all use A/C but don't know how the compressor works
or the electrical grid is held together.


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si

Re: How to force rapid ipv6 adoption

[Stephen Satchell]

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

Re: How to force rapid ipv6 adoption

[Cryptographrix]

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 
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-boun...@nanog.org] On Behalf Of Mark Andrews
> Sent: Thursday, October 01, 2015 6:01 PM
> To: Matthew Newton 
> Cc: nanog@nanog.org
> Subject: Re: How to force rapid ipv6 adoption
>
>
> In message <20151001232613.gd123...@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. 
> >
> > Systems Specialist, Infrastructure Services, I.T. Services, University
> > of Leicester, Leicester LE1 7RH, United Kingdom
> >
> > For IT help contact helpdesk extn. 2253, 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
>

RE: How to force rapid ipv6 adoption

[Steve Mikulasik]

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-boun...@nanog.org] On Behalf Of Mark Andrews
Sent: Thursday, October 01, 2015 6:01 PM
To: Matthew Newton 
Cc: nanog@nanog.org
Subject: Re: How to force rapid ipv6 adoption


In message <20151001232613.gd123...@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. 
> 
> Systems Specialist, Infrastructure Services, I.T. Services, University 
> of Leicester, Leicester LE1 7RH, United Kingdom
> 
> For IT help contact helpdesk extn. 2253, 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[corta...@gmail.com]

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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Chris Adams]

Once upon a time, Stephen Satchell  said:
> THAT WAS THEN, THIS IS NOW
> 
> I can see, in shared hosting, where each customer gets one IPv6
> address to support HTTPS "properly".

All the browsers in common use (except IE on XP, which shouldn't be in
common use) handle SNI just fine, so HTTPS no longer requires an IP per
site.  Shared web hosting servers can do just fine with one IP now.

-- 
Chris Adams 

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Mike Hammett]

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"  
To: "Mike Hammett"  
Cc: "nanog group"  
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 < na...@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" < tagn...@gmail.com > 
To: "Rob McEwen" < r...@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 < r...@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. 

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Stephen Satchell]

On 10/02/2015 12:44 AM, valdis.kletni...@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.

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Mel Beckman]

Every provider gets a /32, according to ARIN.

IPv6 - INITIAL ALLOCATIONS
Type of Resource RequestCriteria to Receive Resource
ISP Initial Allocation
/32 minimum allocation
(/36 upon request)
NRPM 6.5.1<https://www.arin.net/policy/nrpm.html#six51>

  *   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<https://www.arin.net/policy/nrpm.html#six_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 
mailto:na...@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" mailto:tagn...@gmail.com>>
To: "Rob McEwen" mailto:r...@invaluement.com>>
Cc: "nanog group" mailto: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 
mailto:r...@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.

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Mike Hammett]

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"  
To: "Rob McEwen"  
Cc: "nanog group"  
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  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. 

Re: How to force rapid ipv6 adoption

[Matthew Newton]

On Thu, Oct 01, 2015 at 05:58:59PM -0700, Owen DeLong wrote:
> 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.

It was a semi-serious question, hence the smiley. I'd be genuinely
interested if there is a sensible way to do the above. I can't
think of one.

Sometimes you just have to say something is broken and start
again. I think fitting 128 bit addresses into something only
designed for 32 bit is one of those. The resulting enchancement is
likely to be such a cludge that we'd be moaning about it for
decades to come, and would still require everything to be upgraded
(e.g. router ASICs that only look at 32 bits), so why not upgrade
to something cleanly designed from the start?

There's much wrong with IPv6 as well, but it's a shedload nicer
than a hack on something not designed to support it.

I've run IPv6 on my home network for over 10 years. It's not hard.
The only real reason we've not done a bit rollout at work yet is
that there are always other things that take priority, not that
it's actually that difficult to do.

Matthew


-- 
Matthew Newton, Ph.D. 

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

For IT help contact helpdesk extn. 2253, 

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Sven-Haegar Koch]

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.

Re: How to force rapid ipv6 adoption

[Valdis . Kletnieks]

On Fri, 02 Oct 2015 00:16:50 -, 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.




pgp_TXq3ksqht.pgp
Description: PGP signature

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Valdis . Kletnieks]

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.


pgpFtQLfDIhI_.pgp
Description: PGP signature

Re: How to force rapid ipv6 adoption

[Grzegorz Janoszka]

On 02/10/2015 04:52, Curtis Maurand 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.


There should be a software for your box which supports IPv6 - DD-WRT or 
anything similar. However I agree that it is not a solutions for 
millions of Johnny Sixpacks.


--
Grzegorz Janoszka

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Mark Andrews]

In message <560e1f7c.6030...@invaluement.com>, Rob McEwen writes:
> 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.

A hoster is a LIR.  It isn't the end customer.
 
> -- 
> Rob McEwen
> +1 478-475-9032
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: How to force rapid ipv6 adoption

[Curtis Maurand]

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  wrote:
>
>In message <2bb18527-2f9c-4fee-95dd-3f89919a8...@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 
>wrote:
>> >
>> >> On Oct 1, 2015, at 12:06 , Curtis Maurand 
>> >wrote:
>> >> 
>> >> 
>> >> 
>> >> On 10/1/2015 2:29 PM, Owen DeLong wrote:
>>  On Oct 1, 2015, at 00:39 , Baldur Norddahl
>> > wrote:
>>  
>>  On 1 October 2015 at 03:26, Mark Andrews  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: ma...@isc.org

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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Rob McEwen]

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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Mark Andrews]

In message <560e0c44.5060...@invaluement.com>, Rob McEwen writes:
> 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.

The brakes are already in place at the RIR level.  At this level
you can't just get more /48's with no accountability.

> 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

There are 281474976710656 /48's.  That is what you manage, not IPv6
addresses.  It's also most probably got more digits than you
calculator supports. :-)

Stop thinking addresses and start thinking sites.  We went to 128
bit of addresses so that we could stop worrying about individual
address, the sizes of subnets or working out how many addresses a
site needs when handing out address blocks except in the most extreme
cases.

Mark

> -- 
> Rob McEwen
> +1 478-475-9032
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Rob McEwen]

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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Mark Andrews]

In message <560e00d4.7090...@invaluement.com>, Rob McEwen writes:
> 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.

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.

> 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).
> 
> 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.
> 
> 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.
> 
> 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)
> 
> -- 
> Rob McEwen
> +1 478-475-9032
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Philip Dorr]

On Thu, Oct 1, 2015 at 10:58 PM, Rob McEwen  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.

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Rob McEwen]

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

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Rob McEwen]

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


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.


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.


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)


--
Rob McEwen
+1 478-475-9032

Re: How to force rapid ipv6 adoption

[Hugo Slabbert]

On Thu 2015-Oct-01 18:28:52 -0700, Damian Menscher via NANOG 
 wrote:



On Thu, Oct 1, 2015 at 4:26 PM, Matthew Newton  wrote:


On Thu, Oct 01, 2015 at 10:42:57PM +, 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/InetAddresses.html#getCoercedIPv4Address(java.net.InetAddress)


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




Damian


--
Hugo


signature.asc
Description: Digital signature

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Mark Andrews]

In message <560df4ba.5000...@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 re

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Rob McEwen]

On 10/1/2015 11:18 PM, corta...@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?




I have heard that mentioned before. Unfortunately, this wouldn't work:

(1) we already have extensive IPv4 whitelists, many of which are used by 
prominent anti-spam blacklists (and ISPs) to prevent false positives. 
However, if tomorrow, ALL IPv4 blacklists disappears, and all mail 
servers only allowed in the traffic coming from the IPs listed on the 
better IPv4 whitelists, then a massive percentage of VERY legit mail 
would STILL be blocked. Therefore, if IPv4 whitelists can't keep up in 
the IPv4 work, how are they going to do so in the IPv6 world?


(2) Then there is the chicken-N-egg problem. How do you get your mail 
delivered if you are a new sender, but aren't on that list yet. How do 
you prove your sending practices are valid if you can't get your first 
e-mail delivered?


(3) Any solution to that "chicken-N-egg problem"... which tries to 
provide some kind of verification of legit senders... is a hoop that the 
spammers could jump through just as easily... and they will! (some of 
them doing so convince that they are doing nothing wrong because they 
were told that the list they bought isn't spam because the recipient 
forgot to uncheck a button that said, "receive offers from third parties"!)


(4) and this idea oversimplifies the complexity of the spam problem. For 
example, many of the better blacklists know just when it is appropriate 
to blacklist that legit sender who sends 100 legit messages a day, but 
had a compromised system that triggered 50 thousand spam to be sent out 
that day... and the better blacklists are good about delisting that 
sender soon after the problem is fixed. But in a whitelist-only world, 
you're stuck receiving all that spam!


--
Rob McEwen
+1 478-475-9032

Re: How to force rapid ipv6 adoption

[Mark Andrews]

In message <2bb18527-2f9c-4fee-95dd-3f89919a8...@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  wrote:
> >
> >> On Oct 1, 2015, at 12:06 , Curtis Maurand 
> >wrote:
> >> 
> >> 
> >> 
> >> On 10/1/2015 2:29 PM, Owen DeLong wrote:
>  On Oct 1, 2015, at 00:39 , Baldur Norddahl
> > wrote:
>  
>  On 1 October 2015 at 03:26, Mark Andrews  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: ma...@isc.org

How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Rob McEwen]

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

Re: How to force rapid ipv6 adoption

[Curtis Maurand]

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  wrote:
>
>> On Oct 1, 2015, at 12:06 , Curtis Maurand 
>wrote:
>> 
>> 
>> 
>> On 10/1/2015 2:29 PM, Owen DeLong wrote:
 On Oct 1, 2015, at 00:39 , Baldur Norddahl
> wrote:
 
 On 1 October 2015 at 03:26, Mark Andrews  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.

Re: How to force rapid ipv6 adoption

[Ca By]

On Thursday, October 1, 2015, Matthew Kaufman  wrote:

> 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?
>
>
Steady state would be nat44, which also is materially more expensive to
deliver than IPv6

>
>> 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?
>
>
Perhaps. But it is Verizon's dual-stack in the quote, not me

http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6-is-a-real-world-big-deal/a/d-id/718395




> Matthew Kaufman
>
>

Re: How to force rapid ipv6 adoption

[Todd Underwood]

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"  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  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  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  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"  wrote:
>> >
>> >> On Thu, Oct 01, 2015 at 10:42:57PM +, 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. 
>> >>
>> >> Systems Specialist, Infrastructure Services,
>> >> I.T. Services, University of Leicester, Leicester LE1 7RH, United
>> Kingdom
>> >>
>> >> For IT help contact helpdesk extn. 2253, 
>> >>
>>
>>
>
>

Re: How to force rapid ipv6 adoption

[Todd Underwood]

Yep. Nat is terrible. Dual stack is even worse for end user exclusive.
Clients that migrate back and forth between different protocols at will
(hello Mac OS) are going to be really challenging for everyone, too.

But we didn't get magical, free, simple migration. So we could have done
some kind of 8+8 or LISP thing but we didn't. And here we are.


T

On Thu, Oct 1, 2015, 21:15 Dovid Bender  wrote:

> 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 
> Sender: "NANOG" Date: Thu, 01 Oct 2015 22:42:57
> To: Mark Andrews; Owen DeLong
> Cc: 
> 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  wrote:
>
> >
> > In message <4f2e19ba-d92a-4bec-86e2-33b405c30...@delong.com>, Owen
> DeLong
> > writes:
> > >
> > > > On Oct 1, 2015, at 13:55 , Grzegorz Janoszka 
> > > 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.
> > >
> > > Probab

Re: How to force rapid ipv6 adoption

[Damian Menscher via NANOG]

On Thu, Oct 1, 2015 at 4:26 PM, Matthew Newton  wrote:

> On Thu, Oct 01, 2015 at 10:42:57PM +, 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/InetAddresses.html#getCoercedIPv4Address(java.net.InetAddress)

Damian

Re: How to force rapid ipv6 adoption

[Dovid Bender]

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 
Sender: "NANOG" Date: Thu, 01 Oct 2015 22:42:57 
To: Mark Andrews; Owen DeLong
Cc: 
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  wrote:

>
> In message <4f2e19ba-d92a-4bec-86e2-33b405c30...@delong.com>, Owen DeLong
> writes:
> >
> > > On Oct 1, 2015, at 13:55 , Grzegorz Janoszka 
> > 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: ma...@isc.org
>

Re: How to force rapid ipv6 adoption

[Owen DeLong]

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  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  > 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  > > 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"  > > wrote:
> >
> >> On Thu, Oct 01, 2015 at 10:42:57PM +, 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. mailto:m...@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,  >> >
> >>
> 
> 

Re: How to force rapid ipv6 adoption

[Todd Underwood]

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  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  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"  wrote:
> >
> >> On Thu, Oct 01, 2015 at 10:42:57PM +, 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. 
> >>
> >> Systems Specialist, Infrastructure Services,
> >> I.T. Services, University of Leicester, Leicester LE1 7RH, United
> Kingdom
> >>
> >> For IT help contact helpdesk extn. 2253, 
> >>
>
>

Re: How to force rapid ipv6 adoption

[Owen DeLong]

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  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"  wrote:
> 
>> On Thu, Oct 01, 2015 at 10:42:57PM +, 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. 
>> 
>> Systems Specialist, Infrastructure Services,
>> I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
>> 
>> For IT help contact helpdesk extn. 2253, 
>> 

Re: How to force rapid ipv6 adoption

[Matthew Kaufman]

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

Re: How to force rapid ipv6 adoption

[Mark Andrews]

In message 
, Todd Underwood writes:
> 
> one interesting thing to note...
> 
> On Thu, Oct 1, 2015 at 8:01 PM Mark Andrews  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. 
> > >
> > > Systems Specialist, Infrastructure Services,
> > > I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
> > >
> > > For IT help contact helpdesk extn. 2253, 
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
> 
> --001a113f3ca014ae99052114159c
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> one interesting thing to note... "gmail_quote">On Thu, Oct 1, 2015 at 8:01 PM Mark Andrews =
> ma...@isc.org> wrote:=
>  x #ccc solid;padding-left:1ex">Some of us have been running IPv6 in pro=
> duction 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.=C2=A0 It
> should have been done by now.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.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. >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. >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=
> uld really probably think about that. =C2=A0you might not even have to wait=
>  17 years to figure out that something might be wrong.=
> most good stuff is adopted without "evangelism".=C2=A0=
> t=C2=A0=C2=A0 ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
> adding-left:1ex">
> Mark
> 
> > --
> > Matthew Newton, Ph.D.  blank">m...@le.ac.uk>
> >
> > Systems Specialist, Infrastructure Services,
> > I.T. Services, University of Leicester, Leicester LE1 7RH, United King=
> dom
> >
> > For IT help contact helpdesk extn. 2253,  le.ac.uk" target=3D"_blank">ith...@le.ac.uk>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0 =C2=A0INTERNET: mailto:ma...@isc.org"; target=3D"_blank">mark=
> a...@isc.org
> 
> 
> --001a113f3ca014ae99052114159c--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

RE: How to force rapid ipv6 adoption

[Tony Wicks]

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

Re: How to force rapid ipv6 adoption

[Mark Andrews]

In message 
, Todd 
Underwood writes:
> 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

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.

Add to that no one wanted to run 6to4 relays.  For the asn32 strategy
to work every IPv6 capable router needed to be a 6to4 relay and to
perform encapsulation / decapsulation depending upon whether the
next hop supported IPv6 or not.

Mark

> On Oct 1, 2015 19:26, "Matthew Newton"  wrote:
> 
> > On Thu, Oct 01, 2015 at 10:42:57PM +, 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. 
> >
> > Systems Specialist, Infrastructure Services,
> > I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
> >
> > For IT help contact helpdesk extn. 2253, 
> >
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: How to force rapid ipv6 adoption

[Todd Underwood]

one interesting thing to note...

On Thu, Oct 1, 2015 at 8:01 PM Mark Andrews  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".

t



> Mark
>
> > --
> > Matthew Newton, Ph.D. 
> >
> > Systems Specialist, Infrastructure Services,
> > I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
> >
> > For IT help contact helpdesk extn. 2253, 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>

Re: How to force rapid ipv6 adoption

[Ca By]

On Thursday, October 1, 2015, Todd Underwood  wrote:

> 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.
>
>
I run a large 464xlat dominated mobile network.

IPv4 bits are materially more expensive to deliver.

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



> 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 >
> wrote:
>
> >
> > In message <4f2e19ba-d92a-4bec-86e2-33b405c30...@delong.com
> >, Owen DeLong
> > writes:
> > >
> > > > On Oct 1, 2015, at 13:55 , Grzegorz Janoszka 
> > > 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: ma...@isc.org
> 
> >
>

Re: How to force rapid ipv6 adoption

[Mark Andrews]

In message <20151001232613.gd123...@rootmail.cc.le.ac.uk>, Matthew Newton 
writes:
> On Thu, Oct 01, 2015 at 10:42:57PM +, 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. 
> 
> Systems Specialist, Infrastructure Services,
> I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
> 
> For IT help contact helpdesk extn. 2253, 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: How to force rapid ipv6 adoption

[Todd Underwood]

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"  wrote:

> On Thu, Oct 01, 2015 at 10:42:57PM +, 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. 
>
> Systems Specialist, Infrastructure Services,
> I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
>
> For IT help contact helpdesk extn. 2253, 
>

Re: How to force rapid ipv6 adoption

[Matthew Newton]

On Thu, Oct 01, 2015 at 10:42:57PM +, 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. 

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

For IT help contact helpdesk extn. 2253,