(sipp) E.164 mapping into IPv6

[Dave Katz <[e-mail]>]

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
difficult).

The mailing list is [e-mail] (the request list is
[e-mail], naturally).

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


   Date: Thu, 4 Aug 94 06:40:16 PDT
   X-Sender: [e-mail]
   Mime-Version: 1.0
   Content-Type: text/plain; charset="us-ascii"
   From: [e-mail]
   Sender: [e-mail]
   Precedence: bulk
   Reply-To: [e-mail]

   Bill,

   >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
   dependent".)

   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
   addresses.

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

   Greg


    ------------------------------------------------------------------------------
   IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
   Unsubscribe:	unsubscribe sipp		(as message body, not subject)
   Direct all administrative requests to [e-mail]


 ------------------------------------------------------------------------------
IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
Unsubscribe:	unsubscribe sipp		(as message body, not subject)
Direct all administrative requests to [e-mail]