[arin-ppml] inevitability of NAT?

[Ted Mittelstaedt]

On 2/7/2011 12:39 PM, Owen DeLong wrote:
>
> On Feb 7, 2011, at 9:57 AM, Ted Mittelstaedt wrote:
>
>> 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,
>>>>
>>>> agreed.
>>>>
>>>> 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.
>>
> Big problem: Yes. Does NAT solve it today? No.  Will NAT solve it in
> the future? No.
>
> NAT isn't the solution.

Nobody is saying that it is.

  SPI is the solution. NAT is unnecessary in IPv6.
>
> You, yourself admitted that the SOHO CPE that doesn't do SPI for IPv6
> also doesn't NAT it. If there's no security solution in the SOHO CPE today,
> then, the question isn't NAT or not NAT, the question is what is the right
> SOHO security solution to be encouraging the vendors to put in these
> products. SPI is a security solution. NAT is not. As such, I think we
> should dispense with the NAT discussion and get them to implement
> SPI.
>

Hang on, the topic proposed was Do We Need Nat with the implication
I belive of Do We Need IPv4?  Please don't hijack it for a discussion of 
SPI.

So far there is no NAT implementation for IPv6 that would meet
any standard of production quality or reliability, at least not
under linux, and so IPv6 NAT is a non-starter at the current
time for the "el cheapo CPE vendor" crowd since all their stuff is based 
on Linux.

The CPE people are going to do what the Linux developers do and
they aren't embracing any type of IPv6 NAT and unless something
like it is standardized by IETF it is unlikely that they will.

>>>> 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.
>>
> Yep.
>
>> In short the CPE vendors have RETARDED development in a way.
>>
> Sure.
>
>> 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
>> costs more.
>>
> And I think that they will.
>
>> 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.
>>
> Your point being?
>
> I think they did what they could with the tools available at the time.
> I know Comcast is pushing the CPE vendors for a number of features
> they want but don't have currently.
>

both ddwrt and openwrt have demonstrated ipv6 filtering
since before Comcast got involved so I don't buy that excuse.

Comcast would have been a lot more helpful to have worked with
the openwrt people instead of taking an openwrt load - that
requires an atheros chipset with 8MB of flash, which exists in
practically no CPE other than that one Linksys "Linuxized" version -
and "forking" it off openwrt.

Because of that all the work Comcast did on that fork is
pretty much a dead end.

A much wiser course would have been for Comcast to create
an IPv6ized load on a Broadcom-based 4MB flash CPE.  It's
possible.  crushedhat did it with dd-wrt.  And such a load
would have run on a hell of a lot more CPEs out there than
what they did.

>> 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.
>>
> I think the vendors will do the right thing when they see agreement
> in the community on what the right thing is. That's why I'm hoping
> we can get the cpe-router-bis document through IAB soon. I think
> it is a major step forward in the correct direction.
>
>>>>> 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.
>>
> You're talking about two different things. I'm talking about a static
> permanent port forward which the user can configure

you lost it right there "user can configure"  We don't want that.

We want itunes(or whatever) software to have a button that Sally Joe 
User clicks and itunes automagically goes to Sally Joe User's router
and opens up the appropriate control port so that Apple can
come in and do whatever she wants them to do with her itunes.

90% of consumers don't know anything about their CPE's and DON'T
WANT TO LEARN.

  to permit
> inbound flows by using the configuration tools on the router.
>
> You're talking about a dynamic temporary state table entry under
> the control of the application (which leads me to question the
> value of even having a firewall in such an environment).
>

Any discussion of firewalling for the consumer eventually leads
down to the inevitable - consumers want the benefits of being
behind a firewall, but they don't want to lift a finger to
DO anything to configure the firewall for their environment.

You can put all the SPI you want into the CPE but if any of
it is dependent on the customer using a web browser or whatever
to configure it, then your wasting your effort.  Most of them
won't do it.

This is why the current paradigm on the Internet is a "fetch"
one.  The user wants something from the network, they initiate
a request for it (ftp, http or whatever)  We can design a
firewall "toaster" that sort of works in that environment because the
toaster assumes that a request from a host on the "inside"
is legitimate.

What we can't do is design a firewall that when it boots up
it "knows" that the user has a particular program that is
expecting a polled connection from a mothership on the Internet
at 3:46am every morning.  And your never going to get 90%
of the consumers with that program to go into their firewalls
and tell the firewall about it.

>> 2) The mothership cannot schedule the clients when they call
>> in so the client callins are not evenly distributed over
>> the day.
>>
> I'm not sure I understand what you mean by this or how it relates
> to the discussion at hand. FWIW, TiVO, at least does represent
> a case of the mothership scheduling when the clients call in for
> the most part.
>

If your
building a server farm that is going to contact 5 million users
on the Internet every night and deliver a 5MB data payload are you
going to want to make your farm dependent on all of those users
having accurate clocks?  No, you are going to want to push the
data out on your schedule, under your control.  That's why you
want all of the destinations your pushing data to to have public
numbers on the Internet.  You don't want to be talking to firewalls
or NATs you want to connect to what it behind those things.

Otherwise you end up with what Microsoft has with their Windows
Update Servers, a gigantic pipe that is mostly empty most of the
month and is saturated every Tuesday.

>
>>>> 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.
>>
> Repeat after me... We need to tell the CPE vendors what we want.
> Talking about what is and how to bring what is forward into IPv6
> only creates confusion and exacerbates the situation. Especially
> when you use terms like inevitable.
>

I would like exactly the same thing that happened with PC's to
happen with CPEs.

In the PC market today you have a single software package - Windows -
that runs on a lot of variety of hardware from many different vendors.
Hardware box makers compete on the basis of hardware

I would like the CPE vendors to settle on a standard load.  The obvious
choice would be openwrt because they don't have to pay anyone to
license it.  Then you would have a single software package - openwrt
that runs on a lot of variety of CPE hardware from many different
vendors.  Hardware CPE box makers compete on the basis of hardware.

>>>> 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.
>>
> Better is at least a step in the right direction. NAT is worse.
>
> I'm not sure why you're arguing here. You've agreed that they
> all would feel that SPI without NAT is an improvement, yet you
> say that because it isn't everything they want, they want NAT?
>
> Sorry, that isn't making any sense to me.
>

They want unimpeded access to the consumers hosts!

The advertising people want to reach out and connect to your
computer and query your computer for all of the places that it
has been.  They don't want a SPI firewall or NAT preventing
this.  They see IPv6 as a wonderful advancement because to
use it you can't use a NAT device that will block them out.

The law enforcement people want to get search warrants and
reach out and do electronic searches of your computer without
the bother of sending people to your door or even telling
you they are searching.  They don't want a SPI firewall or NAT 
preventing this.  They see IPv6 as a wonderful advancement because to
use it you can't use a NAT device that will block them out.

The Motion Picture Association people want to reach out and
get into your computer and inspect any movies that you may
have on your disk to protect their copyrights.   They don't
want a SPI firewall or NAT preventing this.  They see IPv6 as a 
wonderful advancement because to use it you can't use a NAT device that 
will block them out.

You yourself said that there's a lot of big stakeholders out
there with plenty vested interest in Ipv6.  Well, this is
who they are!  They want IPv6 because they all think they
have the right to access your machine.  They don't want it
for YOUR health, they want it for THEIRS!

Ted

>>> 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.
>>
> ISPs depend heavily on the cookie cutter model for consumer services.
> Once they inconvenience a few customers, it won't be long before they
> do the same thing universally to all of them just to avoid having to track
> exceptions.
>
>>>>> 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
>>> players.
>>>
>>>> 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)
>>
> Everything I have with an ethernet connection is firmware updatable.
> I have one BD player (not in the 10 above) which is firmware updatable,
> but, which doesn't have a network connection. (Requires USB stick
> to upgrade).
>
> In terms of obsolescence, you might be able to make the argument
> on the PS/2, Wii, and PS/3. The Toshiba HD-A30 probably is already
> considered obsolete. The others (TiVOs, Yamaha RX-V3900,
> One BD player) do not meet that definition. Finally, the remaining
> device (Apple Mac Mini) already supports IPv6 and is running native
> dual stack now. Yes, I count this Mac Mini as a home entertainment
> system because it was purchased specifically as a media player and
> is connected via HDMI to the amplifier. The only display attached
> to it is a Sharp LCD flat-screen Television (32" 1080p). While I have
> a keyboard and mouse for it that I can break out at need, it is
> 95% controlled with the Apple remote. 4% of the time, I use
> RowMote on the iPad to control it. The keyboard and mouse are
> used for the remaining 1% of the time, usually for configuration
> changes or other more serious hacking on the device.
>
> For general purpose computing, there are 2 other iMacs and
> 2 Macbook Pros in the house as well as a Linux based server.
>
> Note, all of the general purpose computing platforms are running
> native dual stack now.
>
> Owen
>
>