Subject: Re: [rrg] SIP will work fine with CES, CEE won't work with NAT

From: [email-masked] (Noel Chiappa)
Date: Mon, 1 Feb 2010 15:14:03 -0500 (EST)

> From: Patrick Frejborg <[email-masked]>

    > Then the edge IP address space is only visible inside the local network
    > (in LISP that is EID)

Ah, no - LEID's are globally visible, and globally unique.

And while I'm here anyway...

    > The current address model is soon running out of addresses, what then?
    > When you are there you have to go after the host stack

Not necessarily. I suspect the answer is 'more NAT'.

Because of the inertia of the IPv4 service interface, with the amazingly huge
ball-and-chain of deployed base which speaks it, I think IPv4 addresses will
be around for a very long time - even if, inside the network, we move to
something else, e.g. between xTRs. In other words, TCP will continue to see
IPv4 addresses - even if those are mapped into 'something else' shortly after
leaving TCP.

Whether the 'something else' is more IPv4 addresses (as with NAT44), or
something different, will depend - it will be 'something different' only when
that 'something different' has a sufficient economic incentive.

	Noel

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 2 Feb 2010 09:39:51 +0200

On Mon, Feb 1, 2010 at 10:14 PM, Noel Chiappa <[email-masked]> wrote:
>    > From: Patrick Frejborg <[email-masked]>
>
>    > Then the edge IP address space is only visible inside the local network
>    > (in LISP that is EID)
>
Do they really need to be globally visible and globally unique in the future?

Do we need network aliveness detection or is this functionality
something that an endpoint could take care of?
An endpoint is interested if the remote endpoint is alive or not - if
there is a problem the endpoint could try another path to the remote
endpoint - if that fails then the problem is most likely in the remote
endpoint and not in the network.
And with multi-path enabled transport protocols this endpoint
aliveness detection is sort of integrated there.

>    > The current address model is soon running out of addresses, what then?
>    > When you are there you have to go after the host stack
>

Agree, IPv4 will be around for a very long time - especially in the
old economies

But if you ease up the rule of globally uniqueness a little bit then
you could start to reuse the edge prefixes and perhaps reduce the
amount of NAT

-- patte

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 3 Feb 2010 10:00:58 -0800

Friends,

I'm sure that Noel's insight below is not contentious to this list. However, his observation was reinforced in my own thinking when I observed how many embedded systems have been using IPv4 for some time now. This taught me that my thinking has been far too small: IPv4 has become truly ubiquitous in the literal meaning of the word and now includes so many things that never previously were networked.

Another aspect of Noel's insight was reinforced to me when I noted that many environments (especially those operating in lower bandwidth situations) had chosen frame sizes to correspond with IPv4 packet sizes to the extent that deploying IPv6 in those environments has to overcome significant performance problems unless header compression is used.

However, the bottom line remains as it always has been: there is a strong business case for the end user to *not* support non-value-added protocol diversity. I wish that RFC 1687 were no longer true for IPv6, but, unfortunately, it still is. The key question is for how much longer?

The argument that we are rapidly running out of IPv4 addresses has always been a significant concern for me personally. New deployments (e.g., civil aviation's ATN IPS) and certain industries that have vast numbers of networked devices (e.g., electrical power industry) are excellent candidates to adopt IPv6 for this very reason. However, for the majority of end users, I expect us to prefer to indefinitely use IPv4 by leveraging map-and-encaps techniques such as RANGER, despite the fact that RANGER is part of the effort to support a clean migration to IPv6.

--Eric

>Noel Chiappa wrote:

>Because of the inertia of the IPv4 service interface, with the 
>amazingly huge ball-and-chain of deployed base which speaks it, 
>I think IPv4 addresses will be around for a very long time - 
>even if, inside the network, we move to something else, e.g. 
>between xTRs. In other words, TCP will continue to see
>IPv4 addresses - even if those are mapped into 'something else' 
>shortly after leaving TCP.