The logical alternative to this is to continue to use addresses, but instead of as identifiers, to retain them as locators. This would imply that we would introduce a new namespace to function as identifiers. In effect, this
Tony, that is what we recommend in LISP. So we don't have to re- address the core. We force the re-addressing of sites that don't currently have PI blocks. We also are loose about stating that sites can use PA blocks for EIDs. But with the later, the namespace is not mutually exclusive. That is okay, if the two never cross.
Having said that they will cross for IPv4 if LISP-NAT is used, but if LISP-PTR is used, the namespaces can be as separate as they are in multiple VRFs.
But using a single "super-prefix" with IPv6, we can have a much cleaner separation of the namespaces. Hence, the draft draft-meyer- lisp-eid-block-00.txt where we propose to request IANA to allocate an IPv6 /16.
is part of what Handley's proposal does: by shifting the transport to stop using addresses as part of the identification of a transport connection, it creates the need for another level of identification. Handley posits the use of multiple parallel connections between hosts, striping data across these connections to instantiate a single, address-agile transport layer. Implicit in this structure is a mechanism for the host to recognize that these individual connections are part of a greater aggregated connection.
You get that as well when middle-boxes load-split ingress and egress traffic. The transport connection in the host just sees a 32-bit value as a connection ID.
This has obvious security implications which will, in effect, require a security association between hosts. That security association effectivelyrequires some security token (e.g., a public-private key pair used tocompute a session key) so that the correspondent host can be assured that the component connections are indeed related. This security token is, forall intents and purposes, a host identifier. Accordingly, it seemsappropriate to christen this the "jack-down" model, as it jacks the network layer down a notch and inserts a layer of host identification above thenetwork layer, leaving it firmly embedded in the transport layer.
I don't see this mechanistically any different than Shim6 or Six/One. I look forward to more details of Mark's proposal so we can see the differences.
Dino -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg