Subject: Re: [lisp] LISP and IPv4

From: [email-masked]
Date: Thu, 17 Jan 2013 16:00:21 -0500 (EST)

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 17 Jan 2013 13:40:14 -0800

> Fine, LISP wants to serve multiple types of EIDs (IPv4, IPv6, Mac, E164 (too?) .

Right.

> 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 i…

Right.

> {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 !!!

It must not do anything of the sort. We do not want to change DNS. We do not require any new support from DNS.

You may be trying to solve some other problem and think LISP can either solve it, or if you think LISP cannot solve it, you think LISP is broken in this context.  ;-)

> 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 !!!!!!!! 

Outbound packets from a network that is privately address must be sent to a publicly addressed system. Like your house that uses private addresses and wants to send to www.yahoo.com. Of course, a NAT is at your house that will translate the source of these outbound packets to a global address so www.yahoo.com can return packets to you.

If LISP is running at your house, the private address is the EID, and the NAT translated it to a PUBLIC EID, then the packet gets encapsulated by a LISP box with PUBLIC locators.

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

I'll just say many of us are running LISP behind NAT boxes at our homes.  ;-)

> argument of absolute necessity.

We want LISP to be deployed as soon as possible. Keeping hosts out of the change-set of devices will allow it to happen sooner. We are on our 6.25 year anniversary from when LISP started in RRG.

> 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 n…

DNS maps from name to EID, DDT helps Map-Resolvers get Map-Requests to Map-Servers so an EID can be resolved to a locator. See the two slides enclosed. The first slide shows the API between ITRs and MRs and ETRs and MSes. And the second slides shows you how all MRs get connected to all MSes.

> IMO it is an overdoing if IPv4-addresses have only to be unique  at their (single) specific site which is indicated by the locator. 

Heiner, let me put it another way. We purposely don't put any machinery in to help or hurt the private versus public issue. We just try to get LISP to work in the existing IPv4 world. And hopefully, if IPv6 designers don't repeat the mistakes of IPv4, we will only have IPv6 global addresses (and no NATs). 

And if the IPv6 designers choose to not repeat the mistakes, you can sleep soundly at night. ;-) Otherwise, LISP will work with IPv6 NATs like it does with IPv4 NATs.

> There is more to say on this topic. But we first of all need a mutual agreement on the first topic above.

And what if you want to talk outside of that boundary? What we suggest to network administrators is that two LISP VPNs can use the same 10.0.0.0/8 space (and the mapping system distinguish these EIDs by instance-IDs and the use of global locators). They can talk with unique addresses WITHIN the VPN and they can even talk cross VPNs AS LONG AS THE ADDRESSES don't clash. When they do, a NAT IS REQUIRED. 

No magic here.

> Heiner

Dino

---

From: [email-masked]
Date: Fri, 18 Jan 2013 17:46:23 -0500 (EST)

Dino,

In spite of adding 4 locator octets you still need NAT !:-( C'mmon!

And you try to sell it as a great feature! :-(

Your position is: Thanks to NAT you have no ipv4 address depletion problem, right ?!

NAT is indeed a great bail out (like GRE which I mentioned lately), but nevertheless a poor and cumbersome solution.
And there are many IETF goers who know much much better than me about NAT's uglyness. And combined with LISP's servers infrastructure solutions become even more cumbersome.

So I admit: NAT will keep LISP alive. But also: I expected LISP to be better: Having an IPv4 address plus a locator there is no need to depend on NAT i.e. on additional TCP octets in order to provide global uniqueness.

LISP will cement the bad IPv4 AND IPv6 paradigms. Dino, you shouldn't point to IPv6 and say that IPv6 shall/will do better.
In the past IPv6 has always emulated whichever IPv4 protocol. And IPv6 will rather emulate LISP than come up with better routing.

You also wrote:
 "We do not want to change DNS. We do not require any new support from DNS."

Well, TARA as outlined by draft-tara-hummel-00.txt only required DNS service as by RFC1712.
Yes, Its current status however requires some extra DNS service which is to provide also a host's "home geopatch number"
This I need for stateless multicast whereby the mobile sender is roaming.
Do you think there will ever be such models with LISP ? So far you do not have a Multicast-Locator nor an Anycast Locator!

Regards
Heiner

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Jan 2013 17:50:57 -0500

Heiner, I am having trouble determining what you would like the working 
group to do with your input.

You keep mentioning TARA.  There is no Internet-Draft for TARA, and even 
if there were, it would be out of scope for this working group.

Your concerns about overlapping addresses, seem to be aimed at use cases 
which while interesting are not within the charter of the working group. 
  Dino has nonetheless gone out of his way to address your comments. 
What are you looking for?

Yours,
Joel M. Halpern, speaking as co-chair

On 1/18/2013 5:46 PM, [email-masked] wrote:
> NAT is indeed a great bail out (like GRE which I mentioned lately), but
> nevertheless a poor and cumbersome solution.
> And there are many IETF goers who know much much better than me about
> NAT's uglyness. And combined with LISP's servers infrastructure
> solutions become even more cumbersome.
>
> So I admit: NAT will keep LISP alive. But also: I expected LISP to be
> better: Having an IPv4 address plus a locator there is no need to depend
> on NAT i.e. on additional TCP octets in order to provide global uniqueness.
>
> LISP will cement the bad IPv4 AND IPv6 paradigms. Dino, you shouldn't
> point to IPv6 and say that IPv6 shall/will do better.
> In the past IPv6 has always emulated whichever IPv4 protocol. And IPv6
> will rather emulate LISP than come up with better routing.
>
>
> You also wrote:
> Yes, Its current status however requires some extra DNS service which is
> to provide also a host's "home geopatch number"
> Do you think there will ever be such models with LISP ? So far you do
> not have a Multicast-Locator nor an Anycast Locator!
>
>
> Regards
> Heiner
>
>
>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: [email-masked]
Date: Sat, 19 Jan 2013 05:50:58 -0500 (EST)

Joel,

I honestly thought that LISP would maintain/provide global uniqueness by the doublet

{LISP-site unique IPv4 address of the EID; Locator} and only in case my memory doesn't deceive me it was once (long ago) a pro-argument of LISP.

Given this assumption you must admit that only LISP-DNS would work, not -ALT, nor -DDT, and that under such a presumption my emails would have really mattered for THIS group.

By Dino's yesterday email I learned that LISP-DDT presumes global uniqueness of the IPv4 address which means
more NAT, and not less NAT. He also mentioned IPv6-NAT which can pretty easyily be predicted: Company XYZ switches from IPv4 to IPv6 but wants to keep its NAT.
The result: Complexity induces even more complexity.

Facit: At least myself I have learned that NAT is the ultimate solution ( and not LISP-DDT) for this particular problem.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Joel M. Halpern <[email-masked]>
An: heinerhummel <[email-masked]>
Cc: lisp <[email-masked]>
Verschickt: Fr, 18 Jan 2013 11:51 pm
Betreff: Re: [lisp] LISP and IPv4

Yours,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 19 Jan 2013 12:47:20 -0500

Heiner,
     I do not know of any point where the problem you describe was 
stated, or intended to be addressed by ISP or most o the other proposals 
that the RRG looked at.  It is not within the scope of the LISP WG.

Yours,
Joel

On 1/19/2013 5:50 AM, [email-masked] wrote:
> {LISP-site unique IPv4 address of the EID; Locator} and only in case my
> memory doesn't deceive me it was once (long ago) a pro-argument of LISP.
> Given this assumption you must admit that only LISP-DNS would work, not
> -ALT, nor -DDT, and that under such a presumption my emails would have
> really mattered for THIS group.
>
> By Dino's yesterday email I learned that LISP-DDT presumes global
> uniqueness of the IPv4 address which means
> more NAT, and not less NAT. He also mentioned IPv6-NAT which can pretty
> easyily be predicted: Company XYZ switches from IPv4 to IPv6 but wants
> to keep its NAT.
> Facit: At least myself I have learned that NAT is the ultimate solution
> ( and not LISP-DDT) for this particular problem.
>
> Heiner
>
>
>
> On 1/18/2013 5:46 PM,[email-masked]  <mailto:[email-masked]>  wrote:
>>
>> Dino,
>>
>>[email-masked]  <mailto:[email-masked]>