Hi Dino,
Fine, LISP wants to serve multiple types of EIDs (IPv4, IPv6, Mac, E164 (too?) .
So I take for granted that LISP (still) wants to serve IPv4-addressed EIDs
also when globally uniqueness of IPv4 addresses cannot be maintained anymore
due to the IPv4 unicast address depletion issue.
Scenario which I think MUST run as follows :
Source host A wants to send an email to destination host B.
At first it must send out a DNS-query indicating the FQDN for B. DNS MUST send
back the info-doublet
{non-globally unique IPv4 address of B; locator of B}. Thereafter, host A MUST
send IP packets with prepended LISP Headers to the ingress router !!!
If it only sends the packet with its IP header containing the destination
host's non-globally unique IPv4 address, the ingress router won't be able to
get to know the proper locator of B !!!!!!!!
As far as I know, LISP tries to avoid bothering the hosts. But you cannot stick
to this objective with ipv4 host addresses loosing their globally uniqueness.
Not long ago, I think it was on the rrg-list, voices were raised "why not
involving hosts". But no one mentioned this
argument of absolute necessity.
Returning the info-doublet {non-globally unique IPv4 address of B; locator of
B} in one single stroke can only by done based on FQDN as the key which makes
me conclude can only be done by DNS and not by DDT or any other database.
There will be a second issue: How to handle non-globally unique IPv4.
IMO it is an overdoing if IPv4-addresses have only to be unique at their
(single) specific site which is indicated by the locator.
According to my TARA concept, the EID's IPv4 addresses have to be unique per
geopatch (whereby the geopatch# is 2 out of 5 octets of the locator).
There is more to say on this topic. But we first of all need a mutual agreement
on the first topic above.
Heiner
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp