Hi Scott,
In "Re: [RRG] Evolutionary Possibilities - host MH/portability, IPv4
address depletion, you wrote:
so I think they are aiming their system to do "network" (many
IP addresses and hosts per EID prefix) multihoming, not "host"
multihoming.
There is an authentication problem with map-n-encap and wandering
EIDs. Suppose a device visits a site and wishes to use an EID
that is not in a prefix that that site normally announces, and
the site agrees to announce it. Why should the mapping
infrastructure, whatever it is, listen to the announcement of
that new EID? You could have it trust whatever it's told, but
more likely there will be filters in place to defend against
bogus announcements, intentional or otherwise. Compare BGP route
filters.
This may be a problem for LISP-ALT, where the ALT network somehow
has to be configured to know which particular ETR or ETRs are the
authoritative query servers for every EID prefix.
LISP-NERD has some other arrangement, I think, since there is one or
more centralised sources of mapping data, and I guess end-users
control this by a user-password system which is entirely unrelated
to ETRs or any trust-giving global network of routers, such as ALT.
Ivip control of mapping is on this basis - the end-user controls the
division of their UAB (User Address Block) in terms of splitting it
into micronets and mapping those micronets to an ETR address, in a
system which has nothing to do with ETRs. The most obvious way to
do it is by a username and password over an encrypted link, or a
challenge response system with a secret key, password etc. This
would happen in a session with some organisation which directly or
indirectly controls the mapping for a particular Mapped Address
Block (MAB) - a BGP advertised prefix which typically contains many
UABs and therefore typically this many, or probably more, micronets.