Subject: [lisp] EID Address space

From: Ronald Bonica <[email-masked]>
Date: Fri, 20 May 2011 16:48:56 -0400

Folks,

How will people acquire IPv4 EID address space?

Given that IPv4 address space is already in short supply, I suspect that some owners if IPv4 PI address space will convert it to IPv4 EID address space. However, the end-points that are currently numbered from that space still need to be accessible from the non-lisp Internet. So, those addresses will serve as both EIDs and RLOCs.

Do I have this right? I don't think so, but I couldn't find anything in the document addressing this issue and I can't think of any other solution.

                                                        Ron

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 20 May 2011 14:47:26 -0700

> How will people acquire IPv4 EID address space?

It is not new space. They use their already allocated prefixes today  
as EID-prefixes. That is, the ones they get from registries.

All one needs to do to make a prefix an EID-prefix is to withdraw  
advertisement from the DFZ and register them to the mapping database  
system.

> Given that IPv4 address space is already in short supply, I suspect  
> that some owners if IPv4 PI address space will convert it to IPv4  
> EID address space. However, the end-points that are currently  
> numbered from that space still need to be accessible from the non- 
> lisp Internet. So, those addresses will serve as both EIDs and RLOCs.

If a prefix is in the mapping database, it is known to have ETRs  
resident at the site boundary and therefore the site is defined to be  
a LISP site.

> Do I have this right? I don't think so, but I couldn't find anything  
> in the document addressing this issue and I can't think of any other  
> solution.

Read the definition of "EID-prefix" from the definition section. The  
text was contributed by about 20 people at this point.  ;-)

Dino

>
>                                                        Ron
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 May 2011 07:45:19 -0700

Dino,

> advertisement from the DFZ and register them to the mapping database  

Wouldn't this IPv4 prefix still be advertised into the DFZ by some PITR ?

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 08:25:56 -0700

> Wouldn't this IPv4 prefix still be advertised into the DFZ by some  

It could or be subsumed by a more coarse advertisement. Maybe a PE  
will advertise 0.0.0.0/0 to its tail circuits to its customers and be  
configured as a PITR. Then the stretch remains 1 and there are no more  
specifics that need to be injected. Plus the maintenance of this  
advertisement doesn't have to change as prefixes are taken out of the  
DFZ and put into the LISP mapping database.

For IPv6, rather than 0::/0, the prefix advertised could be  
2610:d0::/32 (the currently assigned IANA IPv6 EID-prefix).

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 May 2011 09:13:13 -0700

Dino,

> configured as a PITR. 

How does this impact the need to advertise this prefix into *the DFZ* ?
(note that routers that receive 0/0 are *not* part of the DFZ)
 
Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 09:46:40 -0700

> (note that routers that receive 0/0 are *not* part of the DFZ)

You need not and do not want to advertise 0.0.0.0/0 into the core.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 23 May 2011 14:24:45 -0400

\

Dino,

What would happen if someone were to do exactly that, out of ignorance or malice? In not that, something almost as bad
(eg., 16.0.0.0.0/5)?

                                                       Ron

---

From: Darrel Lewis <[email-masked]>
Date: Mon, 23 May 2011 11:32:30 -0700

> What would happen if someone were to do exactly that, out of ignorance or malice? In not that, something almost as bad

I would just mention that the community has quite a of operational experience with announcing short aggregates in SP cores.

Those announcements are usually motivated by research/security requirements, but also sometimes by routing table size.  

Likely those experiences would apply to this case also, both for good and ill.

-Darrel

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 23 May 2011 14:37:50 -0400

Darrell,

I am not sure that the consequence are the same. In today's world, if somebody announces 0.0.0.0/0 into the core (and people accept it), the advertising party will be blessed with all of the world's non-routable traffic. In the world of LISP, if somebody advertises 0.0.0.0 and another party sends a map-request for a non-routable address, that party may get a very long map-reply.

Do I have this right?

                                            Ron

> -----Original Message-----
> From: Darrel Lewis [mailto:[email-masked]]
> Sent: Monday, May 23, 2011 2:33 PM
> To: Ronald Bonica
> Cc: Darrel Lewis; Dino Farinacci; Yakov Rekhter; [email-masked]
> Subject: Re: [lisp] EID Address space
> 
> 
> > What would happen if someone were to do exactly that, out of
> ignorance or malice? In not that, something almost as bad
> > (eg., 16.0.0.0.0/5)?
> >
> 
> I would just mention that the community has quite a of operational
> experience with announcing short aggregates in SP cores.
> 
> Those announcements are usually motivated by research/security
> requirements, but also sometimes by routing table size.
>

---

From: Darrel Lewis <[email-masked]>
Date: Mon, 23 May 2011 15:04:14 -0700

> I am not sure that the consequence are the same. In today's world, if somebody announces 0.0.0.0/0 into the core (and people accept it), the advertising party will be blessed with all of the world'…

The short prefixes announced today (that I mention below) are usually scoped within the AS.  In the example you mention above, if say a Proxy-ITR operator disregarded the spec and announced 0/0 from it (maybe tagged with no-export), traffic that was then sinked to this Proxy-ITR would result in encapsulation if the destination was an EID, and dropped if it was not.  Of course, like Joel pointed out, there could be alot of other negative (non lisp related) consequences to doing this, so their milage will surely vary.

So I don't follow you on the very long map-reply issue you mention above, could you be a bit more clear?  The bogus traffic (dark space, bogons, spoofed packets, etc) that would end up at the P-ITR would not generate or cause long map-replies (i think you mean map replies with a long mask in the EID prefix), they would be dropped since their destination is non-lisp (and the 0/0 route's next hop is the Proxy-ITR).

-Darrel

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 May 2011 10:30:50 -0400

Darrel,

Thanks for the reply. However, I really do mean map replies. Somebody (erroneously) registers 0.0.0.0/0 as an EID prefix. Somebody else sends an otherwise non-routable packet. That ITR sends a map-request and receives a reply with 0.0.0.0 and every prefix subsidiary to it.

> Sent: Monday, May 23, 2011 6:04 PM
> To: Ronald Bonica
> > I am not sure that the consequence are the same. In today's world, if
> somebody announces 0.0.0.0/0 into the core (and people accept it), the
> advertising party will be blessed with all of the world's non-routable
> traffic. In the world of LISP, if somebody advertises 0.0.0.0 and
> another party sends a map-request for a non-routable address, that
> party may get a very long map-reply.
> >
> > Do I have this right?
> >
> 
> The short prefixes announced today (that I mention below) are usually
> scoped within the AS.  In the example you mention above, if say a
> Proxy-ITR operator disregarded the spec and announced 0/0 from it
> (maybe tagged with no-export), traffic that was then sinked to this
> Proxy-ITR would result in encapsulation if the destination was an EID,
> and dropped if it was not.  Of course, like Joel pointed out, there
> could be alot of other negative (non lisp related) consequences to
> doing this, so their milage will surely vary.
> 
> So I don't follow you on the very long map-reply issue you mention
> above, could you be a bit more clear?  The bogus traffic (dark space,
> bogons, spoofed packets, etc) that would end up at the P-ITR would not
> generate or cause long map-replies (i think you mean map replies with a
> long mask in the EID prefix), they would be dropped since their
> destination is non-lisp (and the 0/0 route's next hop is the Proxy-
> ITR).
> 
> -Darrel
> 
> >                                            Ron
> >
> >
> >> Likely those experiences would apply to this case also, both for
> good
> >> and ill.
> >>
> >> -Darrel
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 May 2011 11:04:06 -0400

Well, given that mistakes are being made, the answer they receive will 
be erroneous.

The first obvious limit is that the ETR will only send back prefixes it 
knows.  In the normal case, that is fine because due to allocation 
policy the administrator of the ETR knows the overlapping sets.  In this 
error case, teh configuring individual does not know that.  So they 
don't configure it.  So the ETR doesn't return what it doesn't know.

I would also expect that the ALT would not expect the registration of 
0/0.  The spec requires that the registration match the provisioning 
information.  If an MS operator is willing to accept a provisioning 
request for 0/0, they have some real operational problems.  And everyone 
else will see it and human communication will ensue.

Yours,
Joel

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 May 2011 13:07:22 -0400

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2011 11:04 AM
> To: Ronald Bonica
> Cc: [email-masked]

My problem is that the ETR makes the mistake, the ITR feels the pain.

> else will see it and human communication will ensue.

That's why I asked about other less specifics, like 32.0.0.0/5

                                           Ron

> > Thanks for the reply. However, I really do mean map replies. Somebody
> (erroneously) registers 0.0.0.0/0 as an EID prefix. Somebody else sends
> an otherwise non-routable packet. That ITR sends a map-request and
> receives a reply with 0.0.0.0 and every prefix subsidiary to it.
> >

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 May 2011 10:17:18 -0700

> My problem is that the ETR makes the mistake, the ITR feels the pain.

If the ETR makes a mistake, the map-server has to be in cahoots with  
it. So that has to happen. And then the upstream ALT box peering with  
the map-server has no ingress route filtering. And the upstream ALT  
from that ALT box the same.

The bottom line is that bogus EID-prefix will not be registered into  
the mapping database.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 May 2011 14:57:38 -0400

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2011 1:17 PM
> To: Ronald Bonica
> Cc: Joel M. Halpern; [email-masked]

What will prevent it? Some central authority? 

                                          Ron

> >>>>> I am not sure that the consequence are the same. In today's
> world,
> >> if