(sipp) E.164 mapping into IPv6

[Dave Katz <[e-mail]>]

I'll get my architectural meanderings out onto the addrconf list some
time next week, so you can get a clearer picture of what I'm considering,
but here's an apropos bit of it.

In the scheme that I presented in Houston, the only time hosts self-
administer an address is for first-level bootstrap and same-datalink
communications, and that address has significance (and thus must be
unique) only on the local datalink.  All other address assignment is
done by a server on the local datalink that is knowledgable in the
topology and environment; a server will likely be coresident in a
router and synthesize an address based on some cookie from the host,
combined with local topology information.  Or, it could do something
completely different (and potentially stateful, tied to network
management, etc.) or forward the request to a more central location.

If the server creates an address based on the host cookie, the host
cookie must have uniqueness scope only within the lowest hierarchical
level (subnet or its moral equivalent).

   Date: Fri, 5 Aug 94 04:03:19 GMT
   From: "William Allen Simpson" <[e-mail]>
   Sender: [e-mail]
   Precedence: bulk
   Reply-To: [e-mail]

   For example, a NAS with 16 ports -- some dialed, some hardwired -- might
   have some nodes that self-assign using an IEEE from another card, and
   others that self-assign using the dialed number.  So, although they will
   all "appear" on the same subnet, they will have different families,
   depending on the implementation.  So, we really need separate families.

In this case, the scope of the self-assigned address would be the single
point-to-point link, so it wouldn't really matter what address it
chose (in fact, the NAS/router doesn't even need a local-scope address
on the datalink).  The address assignment server, coresident in the NAS
in this case, is responsible for ensuring uniqueness, so if all links
are part of the same "subnet", it could build addresses out of the
serial port number or any other number of ways.  It should also be noted
that there's no particular reason for all of these clients to be on the
same "subnet";  the NAS could just as well squeeze in one more level
of hierarchy, make each client host number 1, and advertise an aggregate
to the rest of the net.  (This is the same thing as building the host
address from the port number, with the bits in a slightly different place).

   The same problem occurs for partial mesh nets, such as Frame Relay or
   even X.25.  It was suggested some time ago that we should add an X.121
   family, despite the fact that you can "escape" from E.164 to X.121.

Once again, I don't think this is a problem if hosts only autonomously
configure addresses that are extremely local in scope, and allow a
more clueful entity to worry about this.  In the case of switched
media, the datalink address should suffice just fine.  PVC frame relay
is a bit more interesting, given the lack of any datalink addressing
whatsoever (DLCIs are meaningful only between DTE and DCE), but if you
treat each PVC as a point-to-point link for purposes of this process,
it degenerates into the NAS case above.

The only sticky case that I can think of is that of cookieless hosts
talking directly with no router and no datalink addressing (two hosts
on a point-to-point link).  This degenerate case would seem to require
a combat protocol (or preconfiguration).


   > What i *do* think we need is something that says "here is how stateless
   > configuratin works on E.164; here is how it works on 802".  And, same
   > words, more or less, for "ad hoc" case.
   >
   Maybe.  But I think that actually they will work pretty much the same.

I think the mechanism will be quite generic, but it is worth having explicit
verbiage just the same, lest implementors get overly, um, creative.


--Dave
 ------------------------------------------------------------------------------
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]