RE: Last Call: Implications of Various Address Allocation Policies for Internet
Eric Fleischman <ericfl@microsoft.com> Tue, 13 February 1996 19:01 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21933; 13 Feb 96 14:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21925; 13 Feb 96 14:01 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12179; 13 Feb 96 14:01 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21885; 13 Feb 96 14:00 EST
Received: from tide03.microsoft.com by IETF.CNRI.Reston.VA.US id aa21751; 13 Feb 96 13:57 EST
Received: by tide03.microsoft.com; id JAA28876; Tue, 13 Feb 1996 09:33:54 -0800
Received: from unknown(157.54.17.73) by tide03.microsoft.com via smap (g3.0.3) id xma028734; Tue, 13 Feb 96 09:33:14 -0800
Received: from xnet2 ([157.54.17.205]) by imail1.microsoft.com (8.7.3/8.7.1) with SMTP id JAA09475 for <ietf-list@IETF.CNRI.Reston.VA.US>; Tue, 13 Feb 1996 09:26:12 -0800 (PST)
X-Received: from xmtp1 by xnet2 with receive; Tue, 13 Feb 1996 09:22:27 -0800
X-Received: from RED-01-IMC by xmtp1 with recvsmtp; Tue, 13 Feb 1996 09:22:23 -0800
Received: by red-01-imc.itg.microsoft.com with Microsoft Exchange (IMC 4.3.736) id <01BAF9F4.C4358C10@red-01-imc.itg.microsoft.com>; Tue, 13 Feb 1996 09:22:16 -0800
Message-ID: <c=US%a=_%p=msft%l=RED-68-MSG960213092214YB004B00@red-01-imc.itg.microsoft.com>
X-Orig-Sender: ietf-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Eric Fleischman <ericfl@microsoft.com>
To: "ietf-list@IETF.CNRI.Reston.VA.US" <ietf-list@IETF.CNRI.Reston.VA.US>, Brian Carpenter CERN-CN <brian@dxcoms.cern.ch>
Subject: RE: Last Call: Implications of Various Address Allocation Policies for Internet
Date: Tue, 13 Feb 1996 09:22:14 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.3.736
Encoding: 41 TEXT
X-MsXMTID: xmtp1960213172223RECVSMTP[01.52.00]000000c3-27252
Brian, I suspect that we are in basic agreement except on the viability of IPv6. Let's verify: Due to the increasing requirements for End User's to renumber and the lack of adequate tools for them to do so easily, End Users are increasingly motivated to only have a finite number of nodes with publicly advertised addresses, thus shielding their site from external renumbering requests. This posture is supported by firewalls being built due to security concerns and proxy services due to security/cacheing needs. Thus, a) the tendency is for a small public address space and a large private address spaces and b) a request to renumber from ISPs only impacts a small set of machines. The concerns of the last call are solely limited to the small public address space. Because there are few user demands for IPv6 (why: increased functionality gains are negligible) only a few vendors will bundle IPv6 in with IPv4 (because it costs money to build IPv6). Some major vendors have no existing plans to ever deploy IPv6. No smooth migration to IPv6 is conceivable unless that changes. Note that IPv6 offers us the possibility of carrying on the "old view" of a globally connected Internet made up of public addresses. Since IPv6 is not viable, this viewpoint is also not viable. Thus, an underlying assumption of the "Last Call" is becoming obsolete. Unless IPv6 suddenly becomes viable, I believe that the solution to our problem is best found by 1) advancing "plug and play" technologies 2) Improving the linkages/mappings between private/public address spaces so that communication is not impaired by having multiple address spaces. 3) Once the disadvantages of private addresses have been removed (from the users perspective), then the IETF may target "freeing up" already allocated public addresses which are being used solely for private purposes. --Eric >
- RE: Last Call: Implications of Various Address Al… Eric Fleischman