(sipp) E.164 mapping into IPv6

Dave Katz <dkatz@cisco.com> Fri, 05 August 1994 00:01 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14994; 4 Aug 94 20:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14990; 4 Aug 94 20:01 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa18720; 4 Aug 94 20:01 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24057; Thu, 4 Aug 94 17:01:01 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA23690; Thu, 4 Aug 94 09:28:53 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05193; Thu, 4 Aug 94 09:30:54 PDT
Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05187; Thu, 4 Aug 94 09:30:41 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20929; Thu, 4 Aug 94 09:27:54 PDT
Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA12687; Thu, 4 Aug 94 09:26:26 PDT
Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id JAA23715; Thu, 4 Aug 1994 09:12:03 -0700
Date: Thu, 4 Aug 1994 09:12:03 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz@cisco.com>
Message-Id: <199408041612.JAA23715@feta.cisco.com>
To: sipp@sunroof.eng.sun.com
Cc: sipp@sunroof.eng.sun.com
In-Reply-To: greg_minshall@Novell.COM's message of Thu, 4 Aug 94 06:40:16 PDT <9408041340.AB18656@WC.Novell.COM>
Subject: (sipp) E.164 mapping into IPv6
X-Orig-Sender: owner-sipp@sunroof.eng.sun.com
Precedence: bulk
Reply-To: sipp@sunroof.eng.sun.com

My angle on stateless autoconfiguration is that any cookie that is
known to be unique within the topological scope of the rest of the
address can be wedged into the low order bits.  So E.164 is just fine.

I don't believe that there's any need to encode the "address family"
from which the low order bits were drawn (e.g., E.164, IEEE 802,
social security number) so long as the proper balance of scope and
uniqueness is maintained.  For instance, if an address has scope only
on the local subnetwork (such as a self-configured host address on a
LAN) and the hosts are using their data link addresses on that
subnetwork to build their addresses, there will be no possible
collision between address families (since there will only be one
address family in use).  The same can be enforced in any number of
more or less creative ways for global addresses by the address server
entity (it gets a little more complicated if the rest of the bits
address a blob bigger than a single subnetwork, but it's not all that

The mailing list is addrconf@cisco.com (the request list is
addrconf-request@cisco.com, naturally).

I need to send out an official announcement, obviously...

   Date: Thu, 4 Aug 94 06:40:16 PDT
   X-Sender: minshall@optics.wc.novell.com
   Mime-Version: 1.0
   Content-Type: text/plain; charset="us-ascii"
   From: greg_minshall@Novell.COM
   Sender: owner-sipp@sunroof.Eng.Sun.COM
   Precedence: bulk
   Reply-To: sipp@sunroof.Eng.Sun.COM


   >Actually, when there are no IEEE addresses assigned (the typical serial
   >link), an E.164 address would be very useful for creating a local-use
   >address.  An ISDN link will automatically learn it.  A dial-up link
   >could convert the dialing number into one.

   >It wouldn't occupy any more space than a IEEE address.  I'd like to have
   >a block assigned to local-use E.164 addresses.  (I had one in _my_ plan.)

   >Since there is no topological information in the E.164 address related
   >to _our_ nets, it should _only_ be local-use.

   Sounds cool.

   I tend to think of the local-end-system-identifier field (administratively
   assigned, MAC address, whatever) has significance on the "local wire", but
   not further away than that (sort of like the "host part" of an IPv4
   address).  But, that "local significance" doesn't mean that all addresses
   which embed such local-end-system-identifier are of local significane only;
   such addresses are quite often of global significance in my view (just like
   an IPv4 address).

   When doing "stateless autoconfiguration" on an ethernet cable,
   routers/servers would use the client's MAC address to build a
   globally-significant IP6 (?) address.  When doing "ad hoc" networking (no
   routers/servers) on an ethernet cable, there would be code, in the host,
   that knew how to cobble together an IP6 address out of its own MAC address
   (and some constant, local-use, prefix).  (This code would be "link level

   So, in my model, when doing "stateless autoconfiguration" on ISDN, it seems
   quite reasonable for the router/server to build a *globally* significant
   IP6 address out of the E.164 address...
	   if an E.164 address isn't *too* big - how big are they, anyway?
   And, if there are two ISDN "hosts" trying to communicate (dropping off a
   fax, say :-), i would think that each would have code in it that would know
   how to use its local E.164 address to generate locally-significant IP6

   Does that make sense to all and sundry?  (Really, grist for the autoconfig
   list - what *is* the address?)


   IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
   Unsubscribe:	unsubscribe sipp		(as message body, not subject)
   Direct all administrative requests to majordomo@sunroof.eng.sun.com

IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
Unsubscribe:	unsubscribe sipp		(as message body, not subject)
Direct all administrative requests to majordomo@sunroof.eng.sun.com