[arin-ppml] inevitability of NAT?

[Owen DeLong]

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

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

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

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


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

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

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