[arin-ppml] inevitability of NAT?
tedm at ipinc.net
Mon Feb 7 12:57:55 EST 2011
On 2/7/2011 1:21 AM, Owen DeLong wrote:
> On Feb 6, 2011, at 10:47 PM, Ted Mittelstaedt wrote:
>> On 2/6/2011 8:36 AM, Lee Howard wrote:
>>>> From: Benson Schliesser<bensons at queuefull.net>
>>>> Sadly, because we've waited too long to grow IPv6 penetration to
>>>> the inflection point ("the moment that end users start accepting and
>>>> using IPv6"), people will still need to deploy IPv4. Vendors will
>>>> make money on NATs. And people will find ways to get addresses
>>>> - one way or another.
>>> This is often asserted and generally accepted. Is it true?
>> Today - yes. Tomorrow - IMHO it is completely dependent on the
>> CPE vendors.
>>> Nobody wants NAT: ISPs, content providers, law enforcement,
>>> copyright holders, game console manufacturers, web advertisers,
>>> home gateway vendors,
>> and end users all have an interest in
>>> avoiding NAT.
>> wrong. End users absolutely need inexpensive - and I'm talking $60 and
>> under - stateful packet inspection hardware firewalls.
> Your statement is absolutely correct except for the first word.
I did say "today - yes"
>> So far the only devices that meet that criteria are NAT devices.
> A temporary problem.
But a very big one. The CPE market is characterized by manufacturers
stripping every bit of functionality out of the devices that is not
demanded by customers, and cheapening the devices down to the point
it's incredible that they operate at all. IPv6 hasn't been on the
demand list and it's amazing any CPE vendors even offer the limited
variants of it that they do on the few devices that they do now.
>> Even the few SOHO CPE's like the D-link and Cisco RVS4000 that
>> implement IPv6 do NOT include stateful packet inspection in their
>> CPE's on the IPv6 part of it.
> As you point out, nothing currently available to the consumer does
> IPv6 SPI with or without NAT. The CPE router requirements bis
> document that is in the final stages at IAB and should be out shortly
> will require SPI, among other improvements.
> I think you will see more capable IPv6 CPE shortly. I vote we
> fix the CPE rather than break the internet, OK?
dd-wrt already has this capability in the mega load that runs on
OLDER Linksys WRT54GS devices. But the newer WRT54GS devices
have halved the amount of flash - as a cost-cutting move - and
cannot run it.
In short the CPE vendors have RETARDED development in a way.
Obviously they have to step up to the plate. IMHO adding SPI
to just about all of the currently available devices - based on
BusyBox Linux as they are - means adding more code, which means
adding flash ram - which to the CPE vendors means the device
Comcast also fell down when they provided their IPv6 modified
CPE code to flash on a Linksys 160NS - all that was, was the
wrt load with a few of the already existing IPv6 apps added.
I don't have a lot of hope for these vendors to Do The Right
Thing so far. I agree with you that we need to fix the CPE
but the selfish self-interest of these vendors is to do
exactly the opposite.
>>> Even NAT vendors are decorously sheepish in
>>> selling their products. If everyone wants to avoid it, why are we
>>> stuck with it?
>> Because in the beginning none of those stakeholders that have
>> an interest against NAT nowadays were in play, many did not exist.
>> And the end users needed stateful packet inspection, address
>> portability, and an unconstrained source of addresses. NAT
>> solved those problems.
> Sort of.
>> What has IMHO changed is the coming into existence of stakeholders
>> who want to "reach into the consumers network" Groups like
>> law enforcement, copyright digital rights management people,
>> advertisers, and so on would all love to gain "authorized"
>> access to consumers machines for their own purposes.
> No, what has changed is that with IPv6, we now have enough addresses
> that we can abandon the kludgy hack that allowed us to recycle
> addresses rapidly (NAT).
>> Today, EVEN IF a consumer WANTS a corporation like itunes to
>> contact one of their network devices in their homes, there is
>> no way they can click a box or whatever on their network device
>> to allow this - other than having a program on that device
>> initiate contact to the stakeholder. And that kind of
>> architecture is not scalable because the stakeholder cannot
>> schedule the incoming contacts.
> Actually, yeah, they sort of can. It's called "port forwarding" and
> most home gateways allow you to configure a static state table
> entry that way.
The problem with this is:
1) Among all the CPE's there is no accepted way to do this
so client programs have no way to talk to the CPE to tell it
to open a port forward. UPnP is helping in this regard
but it's completely unauthenticated and being implemented
as a massive security hole.
2) The mothership cannot schedule the clients when they call
in so the client callins are not evenly distributed over
>> The irony of it is that once the CPE market matures and we
>> have many products including IPv6, the consumers will be demanding
>> them to have firewalling.
> That's not a bad thing, but, it has nothing to do with NAT.
> Repeat after me... SPI is security. NAT is just mutilation of the
> address fields in the packet header.
Repeat after me... current CPE's treat them as the same thing,
forcing the consumers to do likewise. Any CPE discussion is
academic until the CPE vendors start separating the two functions.
>> As an admin of an ISP I would never deploy IPv6 to my "ma
>> and pa kettle" customers until a CPE existed that included
>> firewalling on the IPv6 side out of the box. The reason is
>> that if I did then within hours Ma and Pa Kettle's peecee's
>> would be cracked into and they would be on the phone with
>> me, costing me precious support dollars, wanting to know why
>> their peecee was running so slow.
> Sure... Good call. I would agree. And those boxes are coming.
>> So I do not see that the stakeholders you mentioned - law
>> enforcement, the DRM crowd, etc. - are going to be any better
>> off under IPv6. They still won't have a defined way of
>> getting at consumer network devices.
> Way way way better off. They don't have to get at the consumer
> network device, but, it sure is nice to be able to identify the
> exact device rather than just "something somewhere behind
> that gateway over there".
Without being able to interrogate the device to get ownership
info from it, they are still relying on whois data to be
accurate. It is better for most of those stakeholders but it
isn't really what most of them want.
> It's also nice that consumers will now have the option of
> allowing connections directly into their network if they so choose.
> A good SPI firewall with real addresses on the inside provides
> all of that.
>>> 1. ISPs aren't ready for IPv6. This belief is rapidly being
>>> overtaken by events--most ISPs will have broad IPv6 this year.
>>> 2. Content isn't ready for IPv6. This belief is rapidly being
>>> overtaken by events. World IPv6 Day is a test-drive of content,
>>> which should go a long way toward eliminating barriers.
>>> 3. Home gateways aren't ready for IPv6. This belief is
>>> slowly being overtaken by events. All home gateway makers
>>> are developing IPv6, and industry is doing better as telling them
>>> what needs to be fixed. However, it may still be true that all
>>> home gateways sold before ARIN runout have to be replaced.
>> Well, all of those were sold to customers who were connecting in
>> with IPv4 so they only would need to be replaced if those
>> customers's ISP's wanted to retract the IPv4 originally assigned
>> to them.
> Which is very likely to happen as address scarcity forces residential
> ISPs to look to reclaiming addresses for low value services ($20-40/month
> residential, for example) and re-use those addresses for services
> that produce more revenue (web hosting, content, etc.)
I don't think so. The number of low-value customers far exceeds
the number of high value customers. ISP's would not need to
inconvenience more than a handful of low value ones to gain
sufficient IPv4 for high value ones.
>>> 4. Consumer electronics aren't ready for IPv6. This is widely
>>> true, although more embedded OSs are becoming IPv6-capable.
>>> Most web-capable devices will be capable of simple firmware
>>> or OS updates. Untraditional networked devices (like
>>> entertainment systems) are in trouble.
>> I would tend to disagree with that last, because it is mandatory
>> that anything that plays a Blue Ray disk be easily updatable
>> by the consumer, because the blue Ray standard permits future
>> modification of the encryption algorithms.
> Yep... They'll have to provide IPv6 upgrades for all those BD
>> Blu Ray players that become orphaned because their manufacturers go out of business or whatever, they will be unable to play newer disks eventually and will have to be scrapped.
> Also true.
> One of the many reasons I am really annoyed that Toshiba threw
> in the towel on HD-DVD.
>> And there are very few entertainment systems that are IPv4
>> networkable that AREN'T blue-ray players. There's some game consoles but those will be obsoleted long before this is a problem because frequent obsolescence of game consoles is part of any game console manufacturer's business plan. And there are some HD TV sets that can do netflix that may have a problem.
> I have to disagree with you there. Of the 10 network-connected
> entertainment devices in my house, 2 are blu-ray players.
> By my calculations, that has the BD players outnumbered 4:1.
how many aren't firmware updatable? And how many aren't
scheduled for early obsolescense (ie: game consoles)
>>> How do we improve IPv6 uptake in these categories?
>> Well, if you could get NetFlix to mandate IPv6 in any hardware
>> device that is sold to stream Netflix that would be a big help.
>> If you could get them to do that now it would be great since
>> that would force Roku and the TV set makers who added support
>> for that into their products to release firmware updates now,
>> before those products get too old that those companies can
>> skank out of providing updates.
> I like it. I doubt NF would do it and I suspect some of them would
> simply skank out of NF support rather than do the right thing
>>> If all of a household's devices speak IPv6, and the ISP provides
>>> IPv6, and all of the content the household accesses is available
>>> over IPv6 (including NAT64), that household no longer needs
>>> What would it take for the number of households in that state
>>> to increase faster than new Internet activations? Think big--
>>> there are a lot of stakeholders whose interests align against
>> If there was some way to get the content providers who are
>> now providing television over the Internet to require IPv6
>> for higher resolution streaming you would have it in the bag.
> Sure, but, if we could have gotten various players to cut off their
> noses to spite their faces years ago, we'd be done with the IPv6
> transition already.
>> Netflix has done some work in this area and they say now for 1080p at 60 fps the end user needs at least 3MB of bandwidth. Few users are at this level since Netflix also charges an additional fee for HD streaming.
>> But it is inevitable that as TV broadcasting moves to the Internet that demand will grow for them to stream shows at the full 1080p. If what your saying about advertisers wanting to get rid of NAT is true, then the broadcasting industry should come out with an Internet broadcasting standard that would specify IPv6 and no-NAT and UPnP for 1080p streaming.
> I like it. Now we just need to get them to understand that instead of insisting that Ipv4
> is just fine and they don't see any near-term need for IPv6. The level of denial
> in the entertainment industry when it comes to the reality of the customer
> environment and network transport is impressive. They seem to live in a
> completely different world where even some of the laws of physics seem
> not to apply.
More information about the ARIN-PPML