Subject: RE: How the IPnG effort was started

From: "Peter Ford" <[email-masked]>
Date: Sun, 21 Nov 2004 23:29:41 -0800

Run a market survey and you will find out why people buy these NAT devices.  It shouldn't be that hard, you can hire one of many consumer research firms to do that kind of quantative research for you.
 
While you are at it, you might ask if they know about TCP/IP, and what they know about the 4th version of IP.  I suspect people understand IP just about as much as they understand the nature of powerline transmission or the nature of AC electricity.  It is probably a hallmark of success of an infrastructure that "it is just there".
 
You are of course correct that I am most likely overstating the reasons people purchase NATs, and I am certainly dating myself.   I suspect a more recent survey will reveal that people get NATs as a side product of purchasing wifi connectivity.
 
regards, peterf
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Mon, 22 Nov 2004 11:00:38 -0000

Oh dear! I did actually say I am already conducting a survey! And yes it is
about IP not just about IPv6 or IPv4.

I hope that this survey will be one of several initiatives to help us better
understand IP layer transformations and get us away from the current spate
of opinion to an evidential based analysis.

The link to the User survey is here for those interested: It is for UK based
users only.

"The IPv6 Task Force www.uk.ipv6tf.org is holding a survey aimed to provide
key metrics to aid development of Internet Protocol policy in the UK.

The survey site at http://www.questionpro.com/akira/TakeSurvey?id=186246 "

If people wish to participate or review the full survey please drop me a
note off list for a password.

I have also organised an ISP survey with the LINX (London Internet Exchange)
membership.
I also agree with Eliot that this thread has clearly gone as far as it is
going to go now.

thanks

Christian

 -----Original Message-----
From: Peter Ford [mailto:[email-masked]]
Sent: 22 November 2004 07:30
To: Christian de Larrinaga; [email-masked]
Subject: RE: How the IPnG effort was started

Run a market survey and you will find out why people buy these NAT devices.
It shouldn't be that hard, you can hire one of many consumer research firms
to do that kind of quantative research for you.

While you are at it, you might ask if they know about TCP/IP, and what they
know about the 4th version of IP.  I suspect people understand IP just about
as much as they understand the nature of powerline transmission or the
nature of AC electricity.  It is probably a hallmark of success of an
infrastructure that "it is just there".

You are of course correct that I am most likely overstating the reasons
people purchase NATs, and I am certainly dating myself.   I suspect a more
recent survey will reveal that people get NATs as a side product of
purchasing wifi connectivity.

regards, peterf

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 22 Nov 2004 09:44:18 -0500

Peter Ford <[email-masked]>:
> Run a market survey and you will find out why people buy these NAT
> devices.  It shouldn't be that hard, you can hire one of many consumer
> research firms to do that kind of quantative research for you.

Who needs market research?  All you have to do is look at the cost-feature
profile of the most popular NATs and notice who they were designed for.
Those vendors have already done the market research and bet real money on the
results.

Downstairs in my basement I have a Linksys firewalling router that does NAT.
Like millions of other SOHO users, I needed NAT in order to be able to connect
a home network of multiple machines to a DSL or cable line.  The ISP gave
me only one IP address; the NAT allows me to have several clients and one
server behind it.  (This particular box, as is now common, is also a 
WiFI access point.)

The other thing NAT does is allow me to decouple my local IP addresses
from the ISP's assignment.  So all my local machines can keep
192.168.1.x regardless of what address the world thinks my server has.
Because I have a static address (66.92.53.140) this is merely a
convenience that would make it easy for me to change ISPs if I had to;
if, like many ISP users, I had a DHCP-allocated dynamic one, it would
be a necessity.

To sum up, NAT gives me two features:

1. Multiple machines on the single-address allocation the ISP gives me.
2. Decoupling of mt local network addresses from the ISP assignment.

The Linksys, which is probably the single most popular brand, was designed
for exactly this set of requirements.  So are most of its competition -- the 
Belkins, the Netgears, the AirStations, etc.

I hear a lot of muttering about NATs being evil.  I really don't have an
opinion on the subject -- I understand some of the theoretical problems,
but they've never bitten me.  So, asking as a network administrator,
how would the implied problems be solved in an IPv6 world?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Nov 2004 15:52:00 +0000

> how would the implied problems be solved in an IPv6 world?

For #1, you use IPv6 globals on link for the global connections.

For #2, you could (if you wanted) use IPv6 ULAs for intra-site connectivity,
if you didn't want to contemplate using globals and renumbering on changing 
ISP (which is a rare events for a home user?)

With IPv6, you don't have to play port mapping shennanigans to have (for 
example) multiple web servers on your home intranet accessible from outside,
but until you have that type of requirement (access into your home net) then
you don't see the main advantage.

You can run v4+NAT alongside v6 quite happily too, so use v4 for legacy apps
like mail and web browsing to external sites and v6 for new apps where you
might want to talk direct to peers that would otherwise be behind v4 NATs.

-- 
Tim

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 22 Nov 2004 17:11:26 +0100

> > how would the implied problems be solved in an IPv6 world?

The internet does not only consist of HTTP pages.

What if you want to do VoIP from _multiple_ computers or even real VoIP
phones. Or something nice as setting up a gameserver behind your NAT.
Won't work.

That many applications have a lot of tricks to circumvent NAT's, mostly
by using some external un-nat-ted server, that is sheer luck, it still
is not end to end.

> ISP (which is a rare events for a home user?)

Depends on the type of home user ;)
Nevertheless, most homes currently only consist of maybe 3 ethernet
segments (wired, wireless, office or something) and maybe a max of 20
hosts. Changing the IP's of those hosts should not be a problem even if
you had to do it manually. Most of these NAT boxes come with built-in
DHCP support, hopefully the will come with IPv6 and RA and maybe DHCPv6
support too in the near future (Yamaha has them already :)

Greets,
 Jeroen

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Nov 2004 08:33:09 -0800

At 09:44 AM 11/22/04 -0500, Eric S. Raymond wrote:
>Those vendors have already done the market research and bet real money on 
>the results.

Yes, but be careful with that. What has happened at Linksys and others is 
that they have come up with a simple configuration that allows them to sell 
a pre-configured device to a client, advertise a few features that clients 
like, and sell them like hotcakes with little or no support costs. What the 
customer is buying is not, in most cases, "uses private addressing to 
separate your IP address space from that of your ISP so that if you move 
you will not have to reconfigure things." That may be what Linksys etc is 
selling, but what the customer is buying is "plug it in and it will work." 
Any configuration that gives the customer simplicity of implementation by a 
non-expert in the technology will meet their needs.

>but they've never bitten me.  So, asking as a network administrator, how 
>would the implied problems be solved in an IPv6 world?

In an IPv6 world, I would expect your ISP to sell you a /64 at one price or 
a /48 at another. The /48 is for if you will subnet behind your firewall, 
which is to say "if you are a business". What your Linksys gives you is a 
fairly common residential configuration - a single LAN encompassing your home.

With said /64, you have 2^64 addresses inside your home. How much equipment 
did you say you had?

I submit that if your environment is at all like mine, you don't actually 
configure 192.168.whatever addresses on the equipment in your house. You 
run DHCP within the home and it assigns such. That being the case, you 
actually don't know or care what the addresses are on your equipment. You 
care that your SIP Proxy and etc know the relationships, and they derive 
them directly without your intervention.

The one address you actually do care about is that of the server you 
mentioned. If the server is behind the NAT, you have a configuration on the 
Linksys that translates a certain set of TCP and UDP port numbers when 
addressed to the Linksys to the interior address of the server, and when 
you change ISPs you will have to change that configuration. Frankly, while 
the task is different, I don't see a large workload difference between 
changing that configuration and changing a similar configuration that poked 
an incoming hole for web and mail traffic to your web and mail servers.

So I will argue that the value of (2) is ephemeral. It is not an objective, 
it is an implementation, and in an IPv6 world you would implement in a 
slightly different fashion.

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Nov 2004 09:39:36 -0800

At 08:33 AM 11/22/04 -0800, Fred Baker wrote:
>mentioned. If the server is behind the NAT, you have a configuration on 
>the Linksys that translates a certain set of TCP and UDP port numbers when 
>changing that configuration and changing a similar configuration that 
>poked an incoming hole for web and mail traffic to your web and mail servers.

Did I mention Dynamic DNS? If your server is capable of interacting with 
your DNS server (that's a question, some are and some aren't), Dynamic DNS 
can eliminate the need to concern yourself with the server address.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 22 Nov 2004 12:35:13 -0500

> slightly different fashion. 

That's right--the device would get a range (or block) of addresses and
then either do a 6-to-4 gateway conversion on those addresses (still using
192.168.*.*) or assign v6 directly (if that option had been enabled) but
would still use DHCP for those assignments. Server-specific holes in the
incoming connection table would still have to be managed, with a default
deny policy. Very similar but still different.

One potentially technical hurdle here is the way that the device discovers
that a range/block of addresses is available to it. Some kind of DHCP
sub-lease, or maybe a collection of options (is it a range of addresses or
an actual subnet? how big is it, and does that include net/bcast
addresses?),is going to be required. So it would obviously be useful that
Linksys et al make sure that the specs are there to help them continue
providing the same kind of high-value low-management experience. This is
the kind of cross-industry participation I'm talking about needing.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Richard Shockey <[email-masked]>
Date: Mon, 22 Nov 2004 13:05:18 -0500

At 11:33 AM 11/22/2004, Fred Baker wrote:

>>Who needs market research?  All you have to do is look at the 
>>cost-feature profile of the most popular NATs and notice who they were 
>>designed for. Those vendors have already done the market research and bet 
>>real money on the results.

Has anyone mentioned that ISP's charge a absurd premium for multiple static 
V4 IP numbers in residential markets saying ..oh thats a "business" service.

NAT's exist because IP numbers are made artificially expensive by ISP's.

>that they have come up with a simple configuration that allows them to 
>sell a pre-configured device to a client, advertise a few features that 
>clients like, and sell them like hotcakes with little or no support costs. 
>What the customer is buying is not, in most cases, "uses private 
>addressing to separate your IP address space from that of your ISP so that 
>if you move you will not have to reconfigure things." That may be what 
>Linksys etc is selling, but what the customer is buying is "plug it in and 
>it will work." Any configuration that gives the customer simplicity of 
>implementation by a non-expert in the technology will meet their needs.
>
>In an IPv6 world, I would expect your ISP to sell you a /64 at one price 
>or a /48 at another. The /48 is for if you will subnet behind your 
>firewall, which is to say "if you are a business". What your Linksys gives 
>you is a fairly common residential configuration - a single LAN 
>encompassing your home.

Yes Fred I would _expect_ my ISP to sell me a /64 but at what price?  It 
continues to amaze me that no one discussing the IP V6 adoption issues will 
focus attention on the obvious question ..what is it going to cost me?

Would some nice US DSL provider out there sell me 6M ADSL transport and a 
V6  /64 for about $49.95 please?  I'll even sign a long term contract !!

If the RIR's could enforce downstream pricing policy on the IS's for V6 
numbering resources we might have a chance.

BTW there is an analogy brewing in VoIP. There are proposals out there in 
some countries to tax phone numbers in order to support universal service 
efforts. A noble goal to be sure ..but the economic effect will be create a 
disincentive for the use of phone numbers and potentially move consumers 
towards the use of URI's for phone dialing. Now that may or may not be a 
bad idea either but it should highlight that if you price a product ( 
numbering ) too high people will look for ways to "route" around it.

NAT's have been the inevitable answer to the poor pricing policy of IP 
numbering.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:[email-masked]
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Nov 2004 13:13:05 -0500

--On Monday, 22 November, 2004 08:33 -0800 Fred Baker
<[email-masked]> wrote:

>...
> Yes, but be careful with that. What has happened at Linksys
> and others is that they have come up with a simple
> configuration that allows them to sell a pre-configured device
> to a client, advertise a few features that clients like, and
> sell them like hotcakes with little or no support costs. What
> the customer is buying is not, in most cases, "uses private
> addressing to separate your IP address space from that of your
> ISP so that if you move you will not have to reconfigure
> things." That may be what Linksys etc is selling, but what the
> customer is buying is "plug it in and it will work." Any
> configuration that gives the customer simplicity of

Fred, while I agree completely with this, we all need to
understand that it has another implication.   If the customer is
offered a snazzy new IPv6 device, using public address space,
that fails to offer "plug it in and it will work", then the
customer is unlikely to buy it.  The odds go down even further
if the customer is expected to become a network expert, or even
a junior apprentice amateur network expert, to configure the
thing.  And that situation is likely to exist, IMO, regardless
of what real or imagined advantages come from IPv6 and/or
public-accessible address space and/or NAT elimination.

    john

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Nov 2004 10:29:03 -0800

At 12:35 PM 11/22/04 -0500, Eric A. Hall wrote:
>addresses?),is going to be required.

I think you're saying that the router/firewall/gateway thingie needs to 
have some sequence like:

  - initial boot or expiration of previous lease occurs
  - CPE router has or forms link-local association with upstream router
    (note that a non-link-local address on the upstream interface is optional)
  - CPE router sends DHCP request for configuration
  - upstream router replies with address of DHCP server, DNS Server, and a
    prefix with a lease. It also configures itself with a local route to that
    prefix via CPE router.
  - CPE router configures interior interface with said prefix and starts some
    combination of autoconfiguration and DHCP configuration of downstream 
hosts.
  - If Dynamic DNS is in use, some hosts may advise the DNS server of their
    new address. If there is a management contract (ISP knows about and does
    something with the CPE router), supplying the router's address upstream is
    one possible use of DDNS.

Note that in the case that DDNS is in use and we are triggering off lease 
expiration, the process needs to take the concepts and issues of
      http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-02.txt
into account.

I have added Ralph Droms to this. Ralph, your suggestion?

>So it would obviously be useful that Linksys et al make sure that the 
>specs are there to help them continue providing the same kind of 
>high-value low-management experience. This is the kind of cross-industry 
>participation I'm talking about needing.

I'll argue that this is pretty much what the IETF has always done. It comes 
down to "someone who sees the need propose a solution and make sure the 
other folks who are likely to be interested buy into it". It is fundamental 
to what we do.

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Nov 2004 10:44:07 -0800

At 01:05 PM 11/22/04 -0500, Richard Shockey wrote:
>continues to amaze me that no one discussing the IP V6 adoption issues 
>will focus attention on the obvious question ..what is it going to cost me?

Is there any way the engineer can predict that or control it?

What the architecture has made exceedingly clear is that the ISP can't 
expect to dole out /128 prefixes, and has no incentive to. It could state 
that it wants to only do address autoconfiguration on its interfaces, and 
it could watch its customers vote with their feet. ISPs aren't that stupid, 
I don't think. They understand what Linksys has done with their market.

>NAT's have been the inevitable answer to the poor pricing policy of IP 

Which comes down to a comment on the policy in use in handing out IPv4 
addresses. We (collectively) exert very heavy backpressure on ISPs getting 
new address allocations, which they pass along to their customers in this 
form. Change that policy - and we are - for IPv6 prefixes, and you can plan 
on the ISPs following suit.

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Nov 2004 10:47:33 -0800

At 01:13 PM 11/22/04 -0500, John C Klensin wrote:
>Fred, while I agree completely with this, we all need to understand that 
>it has another implication.   If the customer is offered a snazzy new IPv6 
>device, using public address space, that fails to offer "plug it in and it 
>will work", then the customer is unlikely to buy it.

No argument. That, actually, is half of my point.

The assertion I replied to was that the thing the customer bought was 
address isolation via private addressing. No, I assert, that isn't what he 
bough. He bought "plug and play". Provide "plug and play", and he will buy 
the new solution just as readily.

Your assertion is the flip side of the inference. Fail to provide "plug and 
play", and the customer will not buy it.

Very true.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Nov 2004 19:59:16 +0100

Right.  While I didn't want to continue this discussion on the IETF 
list, as I understand it this is precisely what prefix delegation was 
meant to be able to handle.

Eliot

Fred Baker wrote:
>> One potentially technical hurdle here is the way that the device 
>> discovers that a range/block of addresses is available to it. Some 
>> kind of DHCP sub-lease, or maybe a collection of options (is it a 
>> range of addresses or an actual subnet? how big is it, and does that 
>> include net/bcast addresses?),is going to be required.
> 
> 
> Note that in the case that DDNS is in use and we are triggering off 
> lease expiration, the process needs to take the concepts and issues of
>      
>> high-value low-management experience. This is the kind of 
>> cross-industry participation I'm talking about needing.
> 
> 
> I'll argue that this is pretty much what the IETF has always done. It 
> comes down to "someone who sees the need propose a solution and make 
> sure the other folks who are likely to be interested buy into it". It is 
> fundamental to what we do.
> 
>

---

From: Richard Shockey <[email-masked]>
Date: Mon, 22 Nov 2004 14:42:42 -0500

>Is there any way the engineer can predict that or control it?

Of course ..this is Economics 101 .. if you have a product you want to sell 
you look for its optimal price point based on a cost benefit analysis of 
the alternatives.

http://cepa.newschool.edu/het/profiles/samuelson.htm

Why are packet networks more efficient than circuit switched ones ?  :-)

I think the problem the Internet Engineering community has had is that we 
have not taken out to lunch  some of our friends in Economic Theory who 
would help us understand the IPV6 adoption problem for what it is an 
economic not a technical issue.

I've personally believed for some time the solution to V4 to V6 migration 
is economic. Maybe Charge more for V4 resources and less for V6 and the 
market may then decide .. hummm gee maybe I should switch. I dont know.

However that requires that wholesale pricing policy by the RIR's be 
enforceable to downstream retailers ( ISP's) which it tricky to do ( but 
possible ) and a realization by retailers that they have an incentive to 
push the product (V6).  The question then to retailers ( ISP's ) are why 
aren't you trying to sell V6? That begs the question  What are the ISP's 
economic incentive to push V6 downstream?  That is the question I've been 
trying to have answered for years.

>expect to dole out /128 prefixes, and has no incentive to.

my point exactly

Shockey's Law : Money is the answer, what is the question?

>  It could state that it wants to only do address autoconfiguration on its 
> interfaces, and it could watch its customers vote with their feet. ISPs 
> aren't that stupid, I don't think. They understand what Linksys has done 
> with their market.

Linksys is the perfect example here ..produce a product at a optimal price 
point with fantastic distribution and is easy to use  ( like duh Ipod ?? ) 
and the world will beat a path to your door.

>form. Change that policy - and we are - for IPv6 prefixes, and you can 
>plan on the ISPs following suit.

But a change in policy without built in economic incentives will not work.

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 22 Nov 2004 14:49:38 -0500

> them directly without your intervention.

Actually, I do set up static addresses.  I'd use DHCP, but if I did that
I would not be able to refer to the machines on my local net by name.

Until my DHCP client can update my DNS tables with name information
on the fly, I'll keep doing doing it this way.  Apple's zeroconf 
technology solves this problem, albeit in a slightly different way,
but Linux doesn't deploy it yet.

I don't think my situation is unique.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: shogunx <[email-masked]>
Date: Mon, 22 Nov 2004 15:51:22 -0500 (EST)

Eric,

> but Linux doesn't deploy it yet.

Please see http://sleekfreak.ath.cx:81/books/dnsupdate.  This allows a
host on a dynamic address to be its own primary authoritative dns server.
With slight adjustments, and a client/server architecture, which I have
implemented with similar code in the past, it could easily do what you
need.

Scott

> I don't think my situation is unique.

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/

---

From: Ralph Droms <[email-masked]>
Date: Mon, 22 Nov 2004 16:04:30 -0500

Eric - Fred has the model right.  The CPE router (actually a gateway with
router/firewall/DHCP/DNS services) uses DHCPv6 PD (prefix delegation; RFC
3633) to obtain a prefix (either a /64 or shorter) and then assigns /64
prefixes to any downstream links.  The devices in the home use either
autonomous address selection or DHCPv6 for address assignment and DHCPv6 for
other configuration information.  Those devices use DDNS - either in the
gateway or provided by the ISP - to announce any publicly accessible
addresses.

The net effect is that a customer can plug in a gateway and then devices on
the downstream links from the gateway without any hands-on configuration by
either the customer or the ISP.  There seems to be pretty broad consensus
among ISPs that this model describes the initial version of IPv6 service.

Check out draft-vandevelde-v6ops-nap-00.txt for more thoughts about why NATs
are in use today and how IPv6 provides the same functions.

As Fred says, the IETF continues to identify specific needs - in this case,
the need for minimal overhead to both the customer and the ISP for IPv6
service - get buy-in from the interested parties and develop solutions and
standards for protocols that can meet those needs, such as the RFCs and
Internet Drafts we've referred to in this thread...

- Ralph

At 10:29 AM 11/22/2004 -0800, Fred Baker wrote:
>>discovers that a range/block of addresses is available to it. Some kind 
>>of DHCP sub-lease, or maybe a collection of options (is it a range of 
>>addresses or an actual subnet? how big is it, and does that include 
>>net/bcast addresses?),is going to be required.
>
>comes down to "someone who sees the need propose a solution and make sure 
>the other folks who are likely to be interested buy into it". It is

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 22 Nov 2004 16:44:16 -0500

On 11/22/2004 4:04 PM, Ralph Droms wrote:

> DHCPv6 PD (prefix delegation; RFC 3633) to obtain a prefix

Yeah, that's what I was thinking about. So now we just need implementors
to provide it and for service providers to offer it before declaring the
problem as solved.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 22 Nov 2004 17:21:04 -0500

Eric - interoperability of several (~6) independent implementations was
demonstrated at TAHI '03 and Connectathon '03.  The consensus among ISPs
seems to be to use PD (although the jury is still out until IPv6 service is
more widely available).

- Ralph

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 22 Nov 2004 16:49:41 -0800

> 2. Decoupling of mt local network addresses from the ISP assignment.

This is a very restricted subset of:
http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-00.txt
Please send comments if you think something is wrong or missing.

        Market perceived benefits of IPv4 NAT 
         
        Function           IPv4                     IPv6 
     +------------------+-----------------------+-----------------------+ 
     |  Simple Gateway  |  DHCP - single        |  DHCP-PD - arbitrary	|
     |                  |  address upstream     |  length customer 	|
     |                  |  DHCP - limited       |  prefix upstream 	|
     |                  |  number of individual |  SLAAC via RA 	|
     |                  |  devices downstream   |  downstream 		|
     +------------------|-----------------------|-----------------------+ 
     |  Simple Security |  Filtering side       |  Explicit Context 	|
     |                  |  effect due to lack   |  Based Access Control	|
     |                  |  of translation state |  (Reflexive ACL) 	|
     +------------------|-----------------------|-----------------------+ 
     |  Local usage     |  NAT state table      |  Address uniqueness 	|
     |  tracking 	|			|			|
     +------------------|-----------------------|-----------------------+ 
     |  End system      |  NAT transforms       |  Temporary use  	|
     |  privacy         |  device ID bits in    |  privacy addresses 	|
     |                  |  the address 		|			|
     +------------------|-----------------------|-----------------------+ 
     |  Topology hiding |  NAT transforms       |  Untraceable addresses|
     |                  |  subnet bits in the   |  using IGP host routes|
     |                  |  address              |  /or MIPv6 tunnels for|
     |                  |                       |  stationary systems	|
     +------------------|-----------------------|-----------------------+ 
     |  Addressing      |  RFC 1918             |  RFC 3177 & ULA 	|
     |  Autonomy	|			|			|
     +------------------|-----------------------|-----------------------+ 
     |  Global Address  |  RFC 1918             |  340,282,366,920,938,	|
     |  Pool            |                       |  463,463,374,607,431,	|
     |  Conservation    |                       |  768,211,456    	|
     |                  |                       |  (3.4*10^38) addresses|
     +------------------|-----------------------|-----------------------+ 
     |  Renumbering and |  Address translation  |  Preferred lifetime 	|
     |  Multi-homing    |  at border            |  per prefix & Multiple|
     |                  |                       |  addresses per 	|
     |                  |                       |  interface 		|
     +------------------+-----------------------+-----------------------+

Chris Palmer wrote:
> There's another feature of NAT that is desirable that has not yet been
> mentioned, and which at least some customers may be cognizant of: the
> fact that NAT is a pretty restrictive firewall.

NAT != Firewall - despite all the marketing to the contrary, the artifact of
lack of state is not a firewall. Marketing needs to be retrained that an
IPv6 context based firewall will provide more comprehensive security that
doesn't mangle headers in the process. Assuming this is implemented in the
'plug-n-play' model as Fred suggests, sales could easily surpass nat.

Richard Shockey wrote:

> I think the problem the Internet Engineering community has had is that 
> we have not taken out to lunch  some of our friends in Economic Theory 
> who would help us understand the IPV6 adoption problem for what it is 
> an economic not a technical issue.

Yes deployment will be gated by economic factors. The problem the IETF and
the transit network operator community keep overlooking is that the economic
costs are not down in the plumbing. The costs are in application development
and end system/lan administration. Once the application development
community recognizes that it is cheaper for them to build over IPv6 than to
retain small armies to develop nat workaround hacks or deal with the
additional support costs from that complexity, and that through tunneling
they don't have to wait for lethargic operators to move first, there will be
plenty of economic motivation for deployment. 

The hard part is getting the word out, because the IETF still isn't serious
about making IPv6 the default protocol for all work, and the operations
community continues to spread FUD about the useful lifetime of IPv4. As
several people have pointed out on this list recently, people can't get the
space they want today, so we are effectively already out. 

The frog is in the pot and the water temperature is rising. Given the
general state of denial it is likely that the water will boil before the
dead frog wakes up to notice.

Tony

---

From: Richard Shockey <[email-masked]>
Date: Mon, 22 Nov 2004 21:54:18 -0500

At

>and end system/lan administration.

This is an excellent point that focuses on the real issue of economics. If 
these inhibitors can be more specifically quantified I'd feel a lot more 
hopeful that one could create a pricing model that drives demand.

So you would say the transit operators will not SELL the product since the 
customer ( end user and or enterprise) cannot support it or they cannot 
afford the upgrades to existing edge infrastructure  (Cisco, Juniper, usual 
suspects,  MS etal ) necessary to support the transition?

Part of the problem of course is the false perception .. perpuated by 
countless commentators that NAT's are a better security measure than firewalls.

I still think V4 to V6 pricing for numbering will and should play a role.

>Once the application development

Well the good news is that SIP principally among other new and emerging 
realtime applications driven by explosive residential broadband deployment 
is forcing the issue.

>dead frog wakes up to notice.

Well if the frog is V4 let it cook ...

---

From: Ari Ollikainen <[email-masked]>
Date: Mon, 22 Nov 2004 13:57:29 -0800

>I don't think my situation is unique.

	It isn't...I do exactly the same thing since Rendezvous(Apple's
	zeroconf) doesn't quite work across our mix of resources...

-- 

 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
 You can't depend on your judgement when your imagination is out of focus.	
						          -- Mark Twain.
 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

       OLTECO                    Ari Ollikainen
       P.O. BOX 20088            Networking Architecture & Technology
       Stanford, CA              [email-masked]
       94309-0088                415.517.3519

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 23 Nov 2004 08:55:14 +0100

> I would not be able to refer to the machines on my local net by name.

I do hope that you know you can assign 'static' addresses based on MAC
address and a number of other properties that the dhcp client provides.
The dhcp server will then just assign the configured prefix. This is
actually what most ISP's use, but they will only give people one IP.

> but Linux doesn't deploy it yet.

Even Windows can do that ;)

But so can any UNIX or basically anything where you can compile bind
utils on:

http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html

or the exact same thing but for Windows:
http://unfix.org/~jeroen/archive/Windows_DynamicDNS_Update.zip

Greets,
 Jeroen

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Nov 2004 12:17:12 +0000

> support too in the near future (Yamaha has them already :)

Or you just modify a Linksys router :)

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Nov 2004 12:35:32 +0000

> I don't think. They understand what Linksys has done with their market.

The fact that some European providers have been allocated a /20 shows they
have a plan to allocate /48's to millions of customers; ap lan at least
convincing enough to the RIR.

So certainly not a /128, and probably not a /64 :)
 
-- 
Tim

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 23 Nov 2004 13:44:30 +0100

> Or you just modify a Linksys router :)

Ack, nicely turn that NAT box into a real router by flashing it with a 
This is unfortunately not something that most people dare to do. Then
again, I know that quite a lot of people 'upgraded' their SpeedTouch
Home's to Pro's for somewhat the same purpose. And for that matter a lot
of people upgrade their Xboxes, PS2's etc. There is always somebody who
can do this around.

I understood there where Seasoft firmwares for above linksys's that even
have aiccu preloaded on it, so that the box can very easily build an
IPv6 tunnel in cases there is no native connectivity ;)

Greets,
 Jeroen

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Nov 2004 14:42:14 +0000

> of people upgrade their Xboxes, PS2's etc. There is always somebody who

I didn't say that your mother could do this, but given that some amateurs
have already modified the Linksys to do v6 then it would not be difficult
for Cisco/Linksys to do so in a short timeframe, if they chose to.

As for NAT, then v4+NAT dual-stack IPv6 will be very common.

-- 
Tim

---

From: shogunx <[email-masked]>
Date: Tue, 23 Nov 2004 10:26:29 -0500 (EST)

> As for NAT, then v4+NAT dual-stack IPv6 will be very common.

And from a dual stack v4+NAT/ v6 implementation over a year old, a very
effective solution.

Scott

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 23 Nov 2004 09:00:51 -0800

> hopeful that one could create a pricing model that drives demand.

Therein lays the problem. Quantifying something that is widely distributed
in small pockets is very difficult. At one point a few years ago I was aware
of 5 different teams working on nat traversal mechanisms for their specific
application. This was all within one company. Not only were they unaware of
each other, they were so focused on solving their specific task that they
couldn't consider trying to generalize to consolidate their efforts. 

> suspects,  MS etal ) necessary to support the transition?

The point is they can't sell you new plumbing unless you know the existing
pipes are not doing the job. Even then people only buy the plumbing to
accomplish the end use application. The plumbing is not a goal in itself,
and therefore doesn't really qualify as a marketable product. 

> countless commentators that NAT's are a better security measure than

One goal of the NAP document is to point out that a nat may be simpler than
traditional corporate firewalls, but it is not 'better security'. 

> I still think V4 to V6 pricing for numbering will and should play a role.

Numbers have no value. I understand service providers get away with charging
for numbers in IPv4, but that is an artificial market created by the real
scarcity. 

> realtime applications driven by explosive residential broadband deployment

The potential exists, but quantifying the development and complexity of
operation costs that are spread around the edge is still a challenge. 

> Well if the frog is V4 let it cook ...

Well in this case the IETF is the one in the hot water.

Tony

---

From: [email-masked]
Date: Tue, 23 Nov 2004 15:16:03 -0500

> again, I know that quite a lot of people 'upgraded' their SpeedTouch

Argh.  Flashing it with a *what*??  Toss us a bone or a URL or something :)
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked] (Kai Henningsen)
Date: 28 Nov 2004 14:37:00 +0200

> but Linux doesn't deploy it yet.

It doesn't? Then pray, what is it I use at the job that does exactly this?

(Hint: ISC DHCP 3 & ISC BIND 9, running on a Debian woody/sarge hybrid  
install.)

Oh, sorry. Not *exactly*. It's the DHCP *server* which does the DNS  
update.

> I don't think my situation is unique.

It's at least rather strange.

MfG Kai

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 29 Nov 2004 01:38:22 -0500

> Oh, sorry. Not *exactly*. It's the DHCP *server* which does the DNS  

My DHCP server is firmware in my Linksys :-).
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 29 Nov 2004 09:44:20 +0100

> My DHCP server is firmware in my Linksys :-).

Which is a Linux box, which can be upgraded ;)

http://www.openwrt.org/
http://www.seattlewireless.net/index.cgi/LinksysWrt54g
etc...

8<----------
dhcp client / server
  * caching dns server (with hooks to dhcp to lookup dhcp client
    hostnames
---------->8

Linksys WRTG's are probably one of the nicest NAT boxes, you can even
let them _route_ IPv6, including firewalling ;)
(Which reminds me to simply get one so I have a very cheap spare linux
box to fool around with, almost cheaper as buying vmware ;)

Greets,
 Jeroen

---

From: Paul Vixie <[email-masked]>
Date: 29 Nov 2004 17:47:08 +0000

> My DHCP server is firmware in my Linksys :-).

well, since linksys has bundled the ISC DHCP server, perhaps you could ask
them to upgrade their bundle to a more recent version, that supports DNS
updates.  or you could disable the linksys dhcp function and run ISC DHCP
on what i'm sure is just one of many fine linux machines on your home net.

the point being, there's no new protocol work called for in this thread;
all you have to do is use the current features of current protocols, even
if you have to change vendors to do it.
-- 
Paul Vixie

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 29 Nov 2004 06:43:39 -0500

> Which is a Linux box, which can be upgraded ;)

As the maintainer of the Linksys Blue Box Router HOWTO, I am quite well
aware of this fact.  And if my objective were to have exciting adventures 
in system and network administration, I would have reflashed my Linksys 
long since.

I don't want to have exciting adventures in system and network administration.
I want my home network to just freaking *work* so I can concentrate on the
problems where my time is most valuable.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Carl Malamud <[email-masked]>
Date: Tue, 30 Nov 2004 06:13:28 -0800 (PST)

> problems where my time is most valuable.

Hmmm ... I'm quite happy with the stability of my sveasoft code and
find that staying up with their latest releases is pretty trivial
and keeps my box humming just fine.  What I found exciting about
being able to reflash my linksys is that I could have a real router
(sort of), *not* have to be an expert, and it *works*!  No more
difficult than clicking on the "software update" button periodically.

Just one user's experience ... your horror stories may vary.

Regards,

Carl

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 30 Nov 2004 18:35:31 -0600

Thus spake "Tim Chown" <[email-masked]>
> for Cisco/Linksys to do so in a short timeframe, if they chose to.

The interesting question is why Cisco/Linksys has not done so yet.  IMHO, 
this is the single biggest _logistical_ barrier to IPv6 deployment.

> As for NAT, then v4+NAT dual-stack IPv6 will be very common.

I'd be perfectly happy to run IPv6 on my home network, and let my Linksys do 
6-to-4 NAT, real 6to4, IPv6 tunnels, etc. as appropriate.  Of course, if my 
monopoly broadband provider were to wake up and offer native IPv6, I'd want 
real IPv6 connectivity...

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking