[arin-ppml] inevitability of NAT?
On 2/8/2011 6:43 PM, Frank Bulk wrote:
> The hardware came before the implementation of IPv6 support.
wrong. Most small CPE's are built on Linux and that has IPv6 support
for many years.
They tried to
> fit in existing hardware, but it didn't work.
Not true. Quite a lot of existing hardware will fit it. And some
existing hardware can be modified very simply to fit it - for example:
Netgear WGR614 v9 - user soldered on a jtag, and replaced dram chip and
is going to be doing the flash chip - that was last week. There is
absolutely no need to redesign the entire thing.
that one is a ram update. Or
wrt54g v8 with 2MB flash, was upgraded to 8MB flash by the user.
I repeat, NO NEED FOR REDESIGNS!!!
Future hardware revisions of
> some models will include expanded storage, allowing for SPI support.
It is a lot more accurate to say that future hardware revs will
NOT ship with limited flash. The real truth though is in the CPE market
there have always been versions that had adequate storage.
What happened in the CPE market was the
earlier CPE's had more flash. The later versions had less flash. But
it has been known since 2008 that you cannot fit a full IPv6
implementation into anything less than 8MB. However, you CAN fit an
IPv6 implementation - WITH an IPv6 firewall - into 4MB if you give up
dhcpv6. It's been done.
The Comcast "IPv6 open-wrt reference implementation" which is a "full"
IPv6 implementation on Sourceforge was built to run in 8MB of flash.
This is an adequate amount of flash and will serve CPEs for some time.
The Comcast load is, IMHO, intended for Comcast to be able to pressure
it's CPE vendors to put in IPv6 so that they cannot make ridiculous
excuses like they can't do it without making a super expensive CPE.
Here is a list of common CPE models with 8MB of flash. Some are older
and no longer shipping. Some are new and are currently shipping.
D-link has both an older and a newer model with the required 8MB so they
cannot make that excuse that they "tried" fitting it in. Baloney. They
didn't try at all. They just put out a deficient IPv6 stack in a 4MB
router, hoping nobody would notice.
ALL of these can have special loads built that run a full IPv6 stack:
WAPM- HP- AM 54G54
WRT54GS (version 1 through 3.)
DIR-330 ver A1
DIR-825 version B1 and B2
> I suspect that most consumer/SOHO router vendors are in the same predicament
> at D-Link.
No, they are not. Most if not all have designs they have shipped or are
shipping now that they can come out with newer flash versions that
support IPv6 because they ALREADY HAVE the required amount of storage.
And of their designs that they have shipping now that don't have
adequate storage, it is simplicity to ship those with adequate storage,
they just replace one flash chip part number with another - nothing else
in the design needs to be changed.
> We can complain about the past, but that won't change anything. Better to
> make current and future purchasing decisions about what's out there -- I am.
> -----Original Message-----
> From: Mark Andrews [mailto:marka at isc.org]
> Sent: Tuesday, February 08, 2011 7:31 PM
> To: frnkblk at iname.com
> Cc: 'Ted Mittelstaedt'; arin-ppml at arin.net
> Subject: Re: [arin-ppml] inevitability of NAT?
> In message<email@example.com>, "Frank Bulk" writes:
>> Due to device (storage) limitations D-Link wasn't able to put a firewall
>> many of its IPv-6 capable releases for its different hardware models, but
>> DIR-655 is supposed to support SPI.
> Also IPv6 equipment should be capable of being put on the net without
> a seperate firewall. If it isn't then the product really isn't fit
> for the purpose it was designed for. Its been a hostile net for
> the entire time IPv6 has existed and that should have been factored
> into the design. A seperate firewall provides additional isolation
> but shouldn't be needed.
> Giving a device a ULA and not a public address if it doesn't need to
> talk to the world will give you as much protection as a NAT gives.
> Feature parity should also be there. I've got a Brother network
> printer that has accept/deny filters for IPv4 but not for IPv6. I
> don't know what they were thinking. IPv6 doesn't need accept/deny
> filters but IPv6 does? It would have been less than a days work
> to add them as they already have them working for IPv4. A bit more
> for testing and documentation. At least I can set the IPv6 address
> statically to a ULA.