Subject: Re: [midcom] RE: Some comments on scenario draft

From: Scott Bradner <[email-masked]>
Date: Fri, 11 May 2001 16:18:58 -0400 (EDT)

> however in order to avoid the interoperability problems caused by NATs
> it is imperative that no address translation occur when using IPv6
> between v6-aware applications.

while it would clearly be good to avoid any such translations I fully
expect that vendors will develop and sell such devices and that
customers will buy them - for reasons such as the one already
mentioned: some ISPs charge per IP address

Scott

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 May 2001 18:09:26 -0400

> mentioned: some ISPs charge per IP address

if that happens we might as well just declare IPv6 dead, because we 
will have polluted IPv6 with all of the problems of NAT.  the fact
that this group has such difficult problems to solve should be evidence
enough that we don't want this to happen.  one of the major incentives
to deploy IPv6 is to enable applications that cannot work through NATs.  

if ISPs charge for multiple IP addresses, when everyone is forced to use
a NAT straitjacket for everything, will those ISPs also charge for other
demultiplexing tags?  like DNS names?  I won't swear that they won't do it,
but they would just be shooting themselves in the feet. 

IETF cannot ensure sanity  but we can do the groundwork to take advantage
of sanity if it should prevail, and we can encourage sanity to some degree.
All of our investment in IPv6 is wasted if IPv6 is widely NATted. 
In order to attempt to preserve that investment we should declare that 
traffic between IPv6 hosts should not be NATted.

Keith

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 13 May 2001 00:31:13 -0700 (PDT)

> mentioned: some ISPs charge per IP address

I am sad to say that you're probably right. For example, I'm told that
dialup ISPs are likely to assign /128s to users even though we would
probably like them to assign /64s or /48s, just because IPv4 behavior will
carry over (use of addresses as a value pricing mechanism, fear of routing
headaches, difficulty in administering both prefix assignment & route
plumbing consistently, etc.). 

To get this right needs a change in mindset as much as a new code
loads. Value pricing is a very powerful force that has consumed  more than
its share of technically good ideas. Probably the best we can hope for is
to address the technical issues thoroughly and make enough information
available that those so inclined can use what's available if they're so
inclined.