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

>