Subject: [Int-area] Discrete IP

From: Pars Mutaf <[email-masked]>
Date: Mon, 10 Sep 2012 12:07:10 +0300

Dear colleagues,

I believe that the next step in IP's evolution would not be IPv6. It would
be "Discrete IP" allowing any IP version.
I concluded that Discrete IP better respects the end-to-end principles
therefore it is economically more viable.

Please read the full document here:

http://www.scribd.com/doc/105448105/Discrete-IP

Cheers,

Pars

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Sep 2012 06:34:57 +0900

You might want to look at Vintage Cerf's Catenet paper (which this reinvents - , http://en.wikipedia.org/wiki/Catenet), and consider the whole point of a single common internerworking layer (of which the Internet is an example).

Joe

On Sep 10, 2012, at 6:07 PM, Pars Mutaf <[email-masked]> wrote:

> Dear colleagues, 
> 
> I believe that the next step in IP's evolution would not be IPv6. It would be "Discrete IP" allowing any IP version.
> I concluded that Discrete IP better respects the end-to-end principles therefore it is economically more viable.
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Sep 2012 22:17:39 -0700

PS - I just updated the Wikipedia page to provide the current URL for 
IENs. Here is this one for convenience:

http://www.rfc-editor.org/in-notes/ien/ien48.txt

Joe

On 9/10/2012 2:34 PM, Joe Touch wrote:
> You might want to look at Vintage Cerf's Catenet paper (which this
> reinvents - , http://en.wikipedia.org/wiki/Catenet), and consider the
> whole point of a single common internerworking layer (of which the
> Internet is an example).
>
> Joe
>
> On Sep 10, 2012, at 6:07 PM, Pars Mutaf <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Dear colleagues,
>>
>> I believe that the next step in IP's evolution would not be IPv6. It
>> would be "Discrete IP" allowing any IP version.
>> [email-masked] <mailto:[email-masked]>

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 11 Sep 2012 08:34:39 +0300

A single common internetworking layer helps reach other nodes regardless of
their underlying technology.

Current situation shows that, now we need to reach other nodes regardless
of their underlying technology, and regardless of their IP version. This is
what Discrete IP does.

Not allowing different IP versions is a technology blocker. IPv6 is ready,
some entities need it, but they cannot use it fully.
This is because it is required that other entities also transition to IPv6.
They do not have to because they do not see the economical incentive. We
clearly have a paradox here. Some entities need IPv6, others do not. It is
also assumed that IP research is done. Someone may invent a totally new and
wonderful concept of IP and call it IPv7. Some entities may use it, while
others still use IPv6 and IPv4.

Discrete IP solves this paradox: Everybody do what they wish. It is
possible that all entities agree on the same IP version. But we cannot make
this decision for them. Discrete IP allows Continuous IP too.

Technology is free.

Pars

On Tue, Sep 11, 2012 at 12:34 AM, Joe Touch <[email-masked]> wrote:

> whole point of a single common internerworking layer (of which the Internet
> is an example).
>
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Sep 2012 22:44:57 -0700

On 9/10/2012 10:34 PM, Pars Mutaf wrote:
> A single common internetworking layer helps reach other nodes regardless
> of their underlying technology.
>
> Current situation shows that, now we need to reach other nodes
> regardless of their underlying technology, and regardless of their IP
> version. This is what Discrete IP does.

The Internet asks each new technology to support IP, and thus leverage 
everyone else who already speaks IP. In that case, ONE node (the new 
node) needs to be modified.

Your proposal asks others (potentially many others) to adjust to you. 
The Internet was created because that doesn't scale.

> Not allowing different IP versions is a technology blocker.  IPv6 is
> ready, some entities need it, but they cannot use it fully.

We already use the kind of translators you're thinking of to support 
allowing IPv4 to talk to IPv6. It works, but it's cumbersome and has a 
lot of opportunity for error.

That's why we try to minimize the number of IP versions - at most, to 
the "preferred" one and sometimes (and hopefully briefly) a "legacy" one.

> They do not have to because they do not see the economical
> incentive. We clearly have a paradox here. Some entities need IPv6,
> others do not. It is also assumed that IP research is done. Someone may
> invent a totally new and wonderful concept of IP and call it IPv7. Some
> entities may use it, while others still use IPv6 and IPv4.
>
> Discrete IP solves this paradox: Everybody do what they wish.

People can do that today, but in the paragraph above this one you 
explain why that didn't work - in the 1960's and today.

Joe

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 11 Sep 2012 10:20:49 +0300

On Tue, Sep 11, 2012 at 8:44 AM, Joe Touch <[email-masked]> wrote:

> everyone else who already speaks IP. In that case, ONE node (the new node)
> needs to be modified.
>
> Your proposal asks others (potentially many others) to adjust to you. The
> Internet was created because that doesn't scale.

The situation changed now, we have new problems like IP version transition.
In my view, we are all adjusting to China with the current proposal, and
China is waiting for us.

We can set up Discrete IP and solve this IP transition problem forever.

> allowing IPv4 to talk to IPv6. It works, but it's cumbersome and has a lot
> of opportunity for error.
>
>
Of course. What I am saying is: Let entities do what they wish. If they
find that translators do not work well, or they are now convinced that
changing their core network is beneficial for them, they can remove the
translators and transition to IPv6. I believe that not everybody will take
the same decisions.

Discrete IP can allow Continuous IP. Let everybody decide for themselves.

The best technology wins.

Discrete IP:

1. Can be a very good transition mechanism to worldwide IPv6 without
enforcement (meaning that we have no idea what is good for others)
2. Can solve the IP transition problem forever.

Everybody, including us, suffer less because we do not decide for others,
we do not pretend to know the future.

The IETF's problem here is choosing between:

1. Designing Discrete IP and solving this IP transition problem forever. We
do not intervene in others' affairs anymore because there is Discrete IP.
2. Working on pushing everybody to IPv6 and see what happens later.

Pars

> That's why we try to minimize the number of IP versions - at most, to the
> "preferred" one and sometimes (and hopefully briefly) a "legacy" one.
>
>
In my opinion, there is too much "we" here. We are blocking the technology.

> People can do that today, but in the paragraph above this one you explain
> why that didn't work - in the 1960's and today.
>
> Joe
>

---

From: Arturo Servin <[email-masked]>
Date: Tue, 11 Sep 2012 10:22:11 +0100

On 11 Sep 2012, at 08:20, Pars Mutaf wrote:

> Discrete IP:
> 
> 1. Can be a very good transition mechanism to worldwide IPv6 without enforcement (meaning that we have no idea what is good for others)

	Do you have some running code?

> 2. Can solve the IP transition problem forever. 

	Forgive for being sceptical of those all magical technologies that solve all the problems of the world. Of course, if you had running code that would change my view.

Cheers,
as

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 11 Sep 2012 12:55:24 +0300

"Do you have some running code?"

These are all ideas and behavior that we adopted without questioning. We
use them in wrong situations generally.

We first discuss the idea, then implement.

The fact that there is running code doesn't mean that it is a good idea.

On Tue, Sep 11, 2012 at 12:22 PM, Arturo Servin <[email-masked]> wrote:

> Forgive for being sceptical of those all magical technologies that solve
> all the problems of the world. Of course, if you had running code that
> would change my view.
>
> Cheers,
> as
>

---

From: Arturo Servin <[email-masked]>
Date: Tue, 11 Sep 2012 11:04:22 +0100

On 11 Sep 2012, at 10:55, Pars Mutaf wrote:

> These are all ideas and behavior that we adopted without questioning. We use them in wrong situations generally. 

	Which already exists in many forms of translation mechanisms that we know are not the best way to solve the problem. There are plenty of documents on the Internet that will tell you why.

> The fact that there is running code doesn't mean that it is a good idea.

	But if it were, it would help to convince the sceptical like me.

	Also, the fact that there is not running code could mean that the idea is impractical and infeasible.

Cheers,
as

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 11 Sep 2012 13:21:52 +0300

Hi Arturo,

On Tue, Sep 11, 2012 at 1:04 PM, Arturo Servin <[email-masked]> wrote:

> Which already exists in many forms of translation mechanisms that we know
> are not the best way to solve the problem. There are plenty of documents on
> the Internet that will tell you why.
>

I believe that people should be able to choose their own solutions. Would
you transition to IPv6 if Discrete IP worked for you? Some entities may,
others may not, others may do it when they have money, yet others may
invent and use IPv7. We cannot know.

This means that China may use IPv6, Uruguay may not. We see what people
decide, we cannot force them. They use translators if they wish. I want to
develop and test a new IPvX in my university and be reachable to the world,
who can say no?

Not knowing what is good for others, not knowing the future, helps
technology develop. It also reduces our suffering because we do not try to
know the unknowable.

> But if it were, it would help to convince the sceptical like me.
I don't see why this would convince you.

> impractical and infeasible.
No you can implement anything. Even the worst idea.

Pars

> Cheers,
> as
>
>
>
> On Tue, Sep 11, 2012 at 12:22 PM, Arturo Servin <[email-masked]>wrote:
>
>>

---

From: Arturo Servin <[email-masked]>
Date: Tue, 11 Sep 2012 11:38:37 +0100

The big flaw of your idea is that you suppose that translation magically works, which it is not true due to the complexity of some protocols. That is why I am sceptical.

	You are very welcome to try your idea. Let me know how it goes.

/as

On 11 Sep 2012, at 11:21, Pars Mutaf wrote:

> I believe that people should be able to choose their own solutions. Would you transition to IPv6 if Discrete IP worked for you? Some entities may, others may not, others may do it when they have money, yet others may invent and use IPv7. We cannot know. 
> 
> This means that China may use IPv6, Uruguay may not. We see what people decide, we cannot force them. They use translators if they wish. I want to develop and test a new IPvX in my university and be reachable to the world, who can say no?
> 
> Not knowing what is good for others, not knowing the future, helps technology develop. It also reduces our suffering because we do not try to know the unknowable.
> 
>  
>>

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 11 Sep 2012 14:58:03 +0300

By "translation" I mean something completely new. It is written in the
paper:

Splitting the path to two (or more) parts. One part is IPv4, the other part
is IPv6.

Source IPv4 <-> Translator IPv4
Translator IPv6 <-> Destination IPv6

We take the data found in the IPv4 packet, we put it in an IPv6 packet (and
vice versa).

By translation, I do not mean translating the information found the in the
headers. We only copy data. (from IPv4 packet to IPv6 packet and vice
versa). See the paper for illustration (Figure 2).

How TCP works on this, I don't know yet. I don't have to know it right now.
What is important is "What we want".

1. Worry about the core network, i.e. others' IP version preferences
forever, or
2. Change the end-node TCP design, if necessary to solve this problem.

Sending a packet from an IPv4 host to an IPv6 host, connected using such a
translator, is a routing problem. The problem is that TCP assumes same IP
version for source and destination. We need another type of identifier,
perhaps. Such proposals exist already. But again, what is important here is
not the solution. What is important is "What we want". It is one of the two
possibilities mentioned above. The second one, better respects the
end-to-end principle.

Pars

On Tue, Sep 11, 2012 at 1:38 PM, Arturo Servin <[email-masked]> wrote:

>
> The big flaw of your idea is that you suppose that translation magically
> works, which it is not true due to the complexity of some protocols. That
> is why I am sceptical.
>

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 11 Sep 2012 17:31:43 +0300

Hi all,

Instead of IP translator, I use the new term "IP payload copier". It copies
payload between different IP versions. TCP does not work on this because it
assumes same IP version for source and destination.

We probably need a new host identifier, and change TCP to use this
identifier but the IP version transition problem is solved
forever. Everybody use the IP version of their preference. This is the
end-to-end princple, we do not care about the core Internet, we change the
end-hosts.

See details in the paper:

On Tue, Sep 11, 2012 at 2:58 PM, Pars Mutaf <[email-masked]> wrote:

> Splitting the path to two (or more) parts. One part is IPv4, the other
> part is IPv6.
>
> We take the data found in the IPv4 packet, we put it in an IPv6 packet
> (and vice versa).
>
> How TCP works on this, I don't know yet. I don't have to know it right
> now. What is important is "What we want".
>
>> On Tue, Sep 11, 2012 at 1:04 PM, Arturo Servin <[email-masked]>wrote:
>>
>>>
>>> Which already exists in many forms of translation mechanisms that we
>>> know are not the best way to solve the problem. There are plenty of
>>> documents on the Internet that will tell you why.
>>>
>>
>>
>>>> Forgive for being sceptical of those all magical technologies that
>>>> solve all the problems of the world. Of course, if you had running code
>>>> that would change my view.
>>>>
>>>> Cheers,
>>>> as
>>>>
>>>
>>>
>>>
>>
>>
>

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 11 Sep 2012 19:44:45 +0300

On Tue, Sep 11, 2012 at 5:38 PM, Warren Kumari <[email-masked]> wrote:

>
> On Sep 11, 2012, at 10:31 AM, Pars Mutaf wrote:
>
> > Hi all,
> >
> > Instead of IP translator, I use the new term "IP payload copier". It
> copies payload between different IP versions.
>
> Right… And who runs these? And who pays for them? And how many do you
> need? And how do you scale them? And how does discovery work? And how are
> they different to current NAT64 type things?
>
> W
>
>

They are like other routing devices. ISPs pay.

NAT64 works by translating the headers if I am not wrong (I just checked).
IP payload copiers that I propose, copy payload from one version to
another.

We need 1 or 2 between this Internet and China's IPv6 Internet. Then
another one, etc. As I see they are not different from backbone routers.

The real question is not how it works, for the moment. The real question
is: What do we want:

1. Worry about the whole core Internet, others' IP version choices? (a
question that has no end no answer), or
2. Change the end nodes.

Pars

>
>
> > TCP does not work on this because it assumes same IP version for source
> and destination.
> >
> identifier but the IP version transition problem is solved forever.
> Everybody use the IP version of their preference. This is the end-to-end
> princple, we do not care about the core Internet, we change the end-hosts.
> >
> > By translation, I do not mean translating the information found the in
> the headers. We only copy data. (from IPv4 packet to IPv6 packet and vice
> > Sending a packet from an IPv4 host to an IPv6 host, connected using such
> a translator, is a routing problem. The problem is that TCP assumes same IP
> >       The big flaw of your idea is that you suppose that translation
> magically works, which it is not true due to the complexity of some
> protocols. That is why I am sceptical.
> >
> >>> These are all ideas and behavior that we adopted without questioning.
> We use them in wrong situations generally.
> >>
> >>      Which already exists in many forms of translation mechanisms that
> we know are not the best way to solve the problem. There are plenty of
> >> I believe that people should be able to choose their own solutions.
> Would you transition to IPv6 if Discrete IP worked for you? Some entities
> may, others may not, others may do it when they have money, yet others may
> --
> After you'd known Christine for any length of time, you found yourself
> fighting a desire to look into her ear to see if you could spot daylight
> coming the other way.
>
>     -- (Terry Pratchett, Maskerade)
>
>
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Sep 2012 04:07:04 +0900

On Sep 11, 2012, at 11:31 PM, Pars Mutaf <[email-masked]> wrote:

> Hi all, 
> 
> Instead of IP translator, I use the new term "IP payload copier". It copies payload between different IP versions. TCP does not work on this because it assumes same IP version for source and destination.
> 
> We probably need a new host identifier,

And that is IPv6 right now.

Call us when you fix that. and maybe also look at realm-specific IP.

> and change TCP to use this identifier but the IP version transition problem is solved forever. Everybody use the IP version of their preference. This is the end-to-end princple, we do not care about the core Internet, we change the end-hosts.
> 

There are no details.

E.g., let's say I'm ipv4 and want to talk to you who are ipv6 right now. So I go to the DNS and ask for you.  First, you have to assume a global namespace above IP - the DNS name - the identifies endpoints.  Second, what will you give me? I don't understand an ipv6 address.  So you hand me the ipv4 of the translator? Then if I send a packet there, it won't know who to send it onward to.

You have a paper, but it is lacking in exactly the solutions everyone has been trying to find for years, and some have shown don't or can't exist.

So I agree with some others that if you insist a solution can exist, you need to demonstrate that with code..that is how the IETF works when the community is skeptical of your approach, which is the case here.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Sep 2012 04:17:40 +0900

On Sep 11, 2012, at 8:58 PM, Pars Mutaf <[email-masked]> wrote:

> By "translation" I mean something completely new. It is written in the paper:
> 
> Splitting the path to two (or more) parts. One part is IPv4, the other part is IPv6. 
> 
> We take the data found in the IPv4 packet, we put it in an IPv6 packet (and vice versa).

Addressed to where? The translator needs the state - like a nat would - to map packets it receives to destinations.  The ipv4 destination is what - the translator itself? Or some alias for the ipv6 destination? The former cant work because the translator can't know where to send the packet. The latter can't work because ipv4 addresses aren't large enough to support aliases for all of ipv6. 

> By translation, I do not mean translating the information found the in the headers. We only copy data. (from IPv4 packet to IPv6 packet and vice versa). See the paper for illustration (Figure 2).
> 

Yes you do.

....
> Sending a packet from an IPv4 host to an IPv6 host, connected using such a translator, is a routing problem. The problem is that TCP assumes same IP version for source and destination. We need another type of identifier, perhaps.

Yes you do.  But that would render ipv4 and ipv6 into link layers over which your new packets with their addresses would traverse.

> Such proposals exist already. But again, what is important here is not the solution. What is important is "What we want".

What is important is whether you have a solution.  This is not a research venue.  

Joe

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 12 Sep 2012 06:50:32 +0300

Hi Warren,

On Tue, Sep 11, 2012 at 8:12 PM, Warren Kumari <[email-masked]> wrote:

>
> On Sep 11, 2012, at 12:44 PM, Pars Mutaf wrote:
>
> >
> >
> And their incentive for this is?
>

Same incentives for buying a router. The copier is like a router but it is
not a router.

>
> >
> > NAT64 works by translating the headers if I am not wrong (I just
> checked). IP payload copiers that I propose, copy payload from one version
> to another.
> >
> You left out:
> 3. Not have a small number of devices that break the end-to-end principle,
> cause performance issues,  end up as monitoring / choke points and make
> debugging hard.
>

I don't understand what you mean exactly, it is not clear. In any case,
this is their problem, you cannot intervene in others' affairs.

>
> W
>
>
> >
> >
> >
> > Pars
> >
> >
> >
> >
> >
> >
> >
> > > TCP does not work on this because it assumes same IP version for
> source and destination.
> > >
> > > Sending a packet from an IPv4 host to an IPv6 host, connected using
> such a translator, is a routing problem. The problem is that TCP assumes
> same IP version for source and destination. We need another type of
> identifier, perhaps. Such proposals exist already. But again, what is
> important here is not the solution. What is important is "What we want". It
> is one of the two possibilities mentioned above. The second one, better
> respects the end-to-end principle.
> > >
> > > Pars
> > >
> > >
> > >
> > >>> These are all ideas and behavior that we adopted without
> questioning. We use them in wrong situations generally.
> > >>
> > >>      Which already exists in many forms of translation mechanisms
> that we know are not the best way to solve the problem. There are plenty of
> > >> This means that China may use IPv6, Uruguay may not. We see what
> people decide, we cannot force them. They use translators if they wish. I
> want to develop and test a new IPvX in my university and be reachable to
> the world, who can say no?
> > >>
> > >>>> 1. Can be a very good transition mechanism to worldwide IPv6
> without enforcement (meaning that we have no idea what is good for others)
> > >>>
> > >>>     Forgive for being sceptical of those all magical technologies
> that solve all the problems of the world. Of course, if you had running
> code that would change my view.
> > >>>
> > >>> Cheers,
> > >>> as
> > >>>
> > >>
> > >>
> > >
> > >
> > >
> "Working the ICANN process is like being nibbled to death by ducks,
> it takes forever, it doesn't make sense, and in the end we're still dead
> in the water."
>     -- Tom Galvin, VeriSign's vice president for government relations.
>
>
>
>

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 12 Sep 2012 07:07:37 +0300

On Tue, Sep 11, 2012 at 10:07 PM, Joe Touch <[email-masked]> wrote:

> copies payload between different IP versions. TCP does not work on this
> because it assumes same IP version for source and destination.
>
> and change TCP to use this identifier but the IP version transition
> problem is solved forever. Everybody use the IP version of their
> preference. This is the end-to-end princple, we do not care about the core
> Internet, we change the end-hosts.
>
> E.g., let's say I'm ipv4 and want to talk to you who are ipv6 right now.
> So I go to the DNS and ask for you.  First, you have to assume a global
> namespace above IP - the DNS name - the identifies endpoints.  Second, what
> will you give me? I don't understand an ipv6 address.  So you hand me the
> ipv4 of the translator? Then if I send a packet there, it won't know who to
> send it onward to.
>

All these are explained in the paper Joe. I tunnel the first packet to the
copier. (I don't use the term translator to avoid confusion)

Why do you refuse to *read it?*

>
> You have a paper, but it is lacking in exactly the solutions everyone has
> been trying to find for years, and some have shown don't or can't exist.
>
> So I agree with some others that if you insist a solution can exist, you
> need to demonstrate that with code..that is how the IETF works when the
> community is skeptical of your approach, which is the case here.
>

This is just loss of time. There are many IETF protocols that are designed
first, implemented later. Ex: IPv6, MIPv6 etc.  So...

In addition, as I said earlier, having running code doesn't mean that it is
a good idea.

The correct approach is:

1. Decide what we want.
2. See if it is feasible. If it is not, we know that what we want is not
feasible. (I would be surprised because anything is feasible)

In my opinion Discrete IP is feasible. The paper (you did not read before
entering this discussion) gives enough evidence. But if you look for
unnecessary details like running code you cannot see this.

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Sep 2012 21:37:26 -0700

On 9/11/2012 9:07 PM, Pars Mutaf wrote:
...
> Why do you refuse to *read it?*

 From the paper:

-----
> All nodes in all Internets are registered to the DNS. The following
> example designis illustrated in Figure 2. IP payload copier, IPPC,
> copies the payload in IPv4 packets to IPv6 packets, and vice versa.
> It is different from IP translators which translate header
> information. I discuss later how TCP can work over this scheme.
>
> 1. Node A makes a DNS request, obtains the destination address D and
> the IPaddress of the IPPC to reach the address D. In this example,
> the IPPC address is B.
>
> 2. Node A tunnels the packet to the IPPC.
>
> 3. IPPC creates state for the addresses A and D.
>
> 4. IPPC copies the payload found in IPv4 packets to IPv6 packets, and
> vice versa,between A and D.
>
> 5. Tunneling is done for the first packet only.

----

So the IPPC acts as a NAT, and the state is setup by the first request 
to the DNS.

Known problems, in no specific order:

	a) like NAT, this fails for all protocols that use in-band
	identifiers (e.g., FTP) unless the entire body of the packet
	is translated too, and that might not be possible for some
	services

	b) you fail to explain why this needs to happen for the
	first packet and not all subsequent packets, or what to do
	with subsequent packets (and what happens when the second
	packet arrives - e.g., at the translator or elsewhere -
	before the first one?)

	c) the first packet won't be tunneled unless you upgrade
	the source endpoint node to speak your new version of things;
	if we could do that, everyone would be speaking IPv6

	d) what name/ID are you looking up in the DNS?
	the node application already did a lookup for the
	destination, and you now need to rewrite every application
	to use your solution instead

	(i.e., right now the DNS use is decoupled from network
	packet processing; you want to integrate it - have you
	seen Cheriton's I3 proposal along these lines?)

	e) which DNS do you register endpoints in? (answer: all of
	them, except that you can't know where the ones outside your
	"IP version" bubble are) so basically you're never going to
	find the endpoints in other bubbles anyway

	f) which payload-only are you forwarding? the one in the
	tunneled packet includes headers the next bubble doesn't
	understand; if you strip off those headers, you lose a lot
	of state

Again, from your paper: "We do not need to use NATs anymore" only 
because you don't call them that, but you're implementing a stateful NAT 
as a translator.

You claim:

---

> We do not touch the core network, i.e. the current IPv4
> infrastructurewhich works. Those who wish, add additional infrastructure
> if necessary(IPv4, IPv6, etc.)

You change the DNS and add translators on that IPv4 network.

> We modify the end-hosts only

Your translators are not end-hosts.

> We do not have worry about others' IP version preferences, we do not have to implement IPv6 for example

Your translators have to worry a lot about version preference.

---

Please read the Catenet paper.

You are treating each IP version as a link layer, your translators are 
IP routers, and your DNS works like ARP.

Unfortunately, that doesn't remove the need for an end-to-end 
internetworking layer with global addresses, which you don't have and 
don't address at all.

Joe

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 12 Sep 2012 08:20:23 +0300

On Wed, Sep 12, 2012 at 7:37 AM, Joe Touch <[email-masked]> wrote:

> So the IPPC acts as a NAT, and the state is setup by the first request to
> the DNS.
>

I don't understand. I just copy the whole payload. Or, replace the IPv4
header with an IPv6 header. I don't have to know what's in the payload.

>         packet arrives - e.g., at the translator or elsewhere -

1. I send the first packet to the copier. In the same message, I tell the
destination IPv6 address that I learned using DNS for example. (this is not
exactly a tunnel I don't have to speak IPv6)
3. The copier creates state for my IPv4 address and destination IPv6
address.
4. Forwards packets in both directions

>         if we could do that, everyone would be speaking IPv6

Yes it is not a tunnel exactly. This is my bad. The first packet is a
special packet, call it a Discrete IP packet, telling the copier the
destination IPv6 address.

>         to use your solution instead

I assume a new host identifier, other than IP address.

>         seen Cheriton's I3 proposal along these lines?)

I am not sure if it should be integrated.

>         find the endpoints in other bubbles anyway

You do not know what we can or cannot do yet. We didn't even discuss if we
want my proposal.
We attacked the details.

>         understand; if you strip off those headers, you lose a lot

No. The copier copies IPv4 payload to the IPv6 header that it creates
itself.

>
> Again, from your paper: "We do not need to use NATs anymore" only because
> you don't call them that, but you're implementing a stateful NAT as a
> translator.
>
>
The question is not they are like NATs or not, we are changing the
architecture. I can reuse yahoo's global IP address at home.

> You change the DNS and add translators on that IPv4 network.
I change DNS, I also change TCP. IPsec doesn't work, multicast is gone. But
this is a trade-off:

We are now free from core Internet's IP version decisions forever. This is
the real discussion that we should have here. Do we want this approach or
not? Once we decided that it is desirable, anything is designable. Because
we do not depend on core network anymore, we change the end points. This is
the end-to-end principle.

Do we want to be free from this IP version problem forever? What can we
sacrifice to solve this problem?

> Your translators are not end-hosts.
It is not a modification. People add them and remove them as they wish. It
is not like modifying all Internet routers.

> Your translators have to worry a lot about version preference.

They are designed for that. And it is not big deal, they just copy payload.

> You are treating each IP version as a link layer, your translators are IP
> routers, and your DNS works like ARP.
>
> internetworking layer with global addresses, which you don't have and don't
> address at all.
>

Let's first discuss what we want. We may have a host identification layer
above IP for example but it is early to discuss technical details. We do
not even know what we want.

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Sep 2012 22:35:39 -0700

On 9/11/2012 10:20 PM, Pars Mutaf wrote:
...
> header with an IPv6 header. I don't have to know what's in the payload.

If the payload includes an IP address (take a look at how FTP works), 
then you have to translate that. That's how current NATs work for *many* 
protocols.

> 1. I send the first packet to the copier. In the same message, I tell
> the destination IPv6 address that I learned using DNS for example. (this
> is not exactly a tunnel I don't have to speak IPv6)

Why does the second packet not also need to be tunneled?

FWIW, what happens if the second packet shows up at the copier before 
the first one? Keep in mind that many protocols (including some variants 
of TCP) don't wait for an exchange to complete before sending the 
second, third, etc., packets.

> destination IPv6 address.

Is this from the DNS or the source?

And if this is a signalling packet, it's not a tunnel at all, FWIW.

> I assume a new host identifier, other than IP address.

Have you considered the implications of this assumption? Aren't you then 
assuming that this identifier *never changes* as you deploy new versions 
of IP, e.g.? Why do you think that will be true if it wasn't for IPv4?

> You do not know what we can or cannot do yet. We didn't even discuss if
> we want my proposal.
> We attacked the details.

I do know that you need to register in every DNS or you won't find the 
name (or you need to tie the DNSes together - and if you do that, you 
provably already have a common internetworking layer, but you can't 
assume a common internetworking layer in your solution to provide one).

Until you prove otherwise.

Having a blank margin and a claim didn't work for Fermat, and it isn't 
sufficient here either.

> No. The copier copies IPv4 payload to the IPv6 header that it creates

OK, so that's just a NAT at that point.

>     because you don't call them that, but you're implementing a stateful
>     NAT as a translator.
>
> I change DNS, I also change TCP.

DNS is part of the core of the network - at least it's in-network 
infrastructure, not an end service on the user's host.

> IPsec doesn't work, multicast is gone.

How do you restore those capabilities? Or will security not work here?

> But this is a trade-off:
>
> We are now free from core Internet's IP version decisions forever. This
> is the real discussion that we should have here. Do we want this
> approach or not? Once we decided that it is desirable, anything is
> designable. Because we do not depend on core network anymore, we change
> the end points. This is the end-to-end principle.
>
> It is not a modification. People add them and remove them as they wish.

If I remove them - all of them - then the system won't work. You need to 
have them for your solution.

> It is not like modifying all Internet routers.

It's a lot like installing new boxes that act a lot like routers, except 
that you refuse to call them routers and they're not nearly as robust or 
useful as routers.

>     You are treating each IP version as a link layer, your translators
>     are IP routers, and your DNS works like ARP.
>
>     internetworking layer with global addresses, which you don't have
>     and don't address at all.
>
> Let's first discuss what we want. We may have a host identification
> layer above IP for example but it is early to discuss technical details.

That's not a technical detail; that's the key to the solution. That IS 
what IP *is*. That's why shifting from IPv4 to IPv6 is hard.

> We do not even know what we want.

Then write a paper on the requirements. But you cannot expect to satisfy 
a want you *agree* we do not currently understand.

Joe

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 12 Sep 2012 09:36:07 +0300

Hi Joe, all,

We really shouldn't enter in design questions before we understand what we
want. Please question everything you learned, even the research method.

As I see it, the following research style would be ideal:

-I propose that we do not touch the core Internet.
-People should be free to choose the IP version that they wish because
deciding for others is a technology blocker. IETF designs IPv6, IETF blocks
its development. Because IETF does not give freedom of choice. This is not
normal. Some entities may use IPv6 others IPv4 yet others IPv7 for unknown
reasons. Everybody may agree on IPv6, or not. We do not know. We do not
have to.
-To give such freedom of choice, we need to change the end-nodes.
-This is the end-to-end principle.

Here is a picture:
http://htmlimg3.scribdassets.com/2hdm1jwfcw1sxm1y/images/4-5930b39cea.jpg

Is this the model that we would prefer? Could we first answer this
question? Anything can be designed. The hard part of research is deciding
on the best solution.

Thanks,
Pars

On Wed, Sep 12, 2012 at 8:35 AM, Joe Touch <[email-masked]> wrote:

> If the payload includes an IP address (take a look at how FTP works), then
> you have to translate that. That's how current NATs work for *many*
> protocols.
>
>
> FWIW, what happens if the second packet shows up at the copier before the
> first one? Keep in mind that many protocols (including some variants of
> TCP) don't wait for an exchange to complete before sending the second,
> third, etc., packets.
>
>
> assuming that this identifier *never changes* as you deploy new versions of
> IP, e.g.? Why do you think that will be true if it wasn't for IPv4?
>
>
> provably already have a common internetworking layer, but you can't assume
> a common internetworking layer in your solution to provide one).
>
> Then write a paper on the requirements. But you cannot expect to satisfy a
> want you *agree* we do not currently understand.
>
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Sep 2012 00:10:32 -0700

Hi, Pars,

On 9/11/2012 11:36 PM, Pars Mutaf wrote:
> Hi Joe, all,
>
> We really shouldn't enter in design questions before we understand what
> we want.

Sure. However, INT-AREA isn't the place for this sort of discussion. You 
might consider trying at [email-masked], which is the 
typical place where end-to-end discussions on architecture are first made.

The IETF is a place for engineering solutions, not research. The IRTF 
serves that purpose, and the above list is the original IRTF list for 
these sorts of discussions.

You (and others) are welcome to take this discussion there, but I expect 
the thread has lost its usefulness to the INTAREA WG.

Joe

> Please question everything you learned, even the research method.
>
> deciding for others is a technology blocker. IETF designs IPv6, IETF
> blocks its development. Because IETF does not give freedom of choice.
> This is not normal. Some entities may use IPv6 others IPv4 yet others
> IPv7 for unknown reasons. Everybody may agree on IPv6, or not. We do not
> know. We do not have to.
> question? Anything can be designed. The hard part of research is
> deciding on the best solution.
>
> Thanks,
> Pars
>
>
>
>
> On Wed, Sep 12, 2012 at 8:35 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     If the payload includes an IP address (take a look at how FTP
>     works), then you have to translate that. That's how current NATs
>     work for *many* protocols.
>
>
>     FWIW, what happens if the second packet shows up at the copier
>     before the first one? Keep in mind that many protocols (including
>     some variants of TCP) don't wait for an exchange to complete before
>     sending the second, third, etc., packets.
>
>
>     Have you considered the implications of this assumption? Aren't you
>     then assuming that this identifier *never changes* as you deploy new
>     versions of IP, e.g.? Why do you think that will be true if it
>     wasn't for IPv4?
>
>
>     I do know that you need to register in every DNS or you won't find
>     the name (or you need to tie the DNSes together - and if you do
>     that, you provably already have a common internetworking layer, but
>     you can't assume a common internetworking layer in your solution to
>     provide one).
>
>     Having a blank margin and a claim didn't work for Fermat, and it
>     isn't sufficient here either.
>
>
>     If I remove them - all of them - then the system won't work. You
>     need to have them for your solution.
>
>
>     It's a lot like installing new boxes that act a lot like routers,
>     except that you refuse to call them routers and they're not nearly
>     as robust or useful as routers.
>
>
>                  We do not have worry about others' IP version
>         preferences, we do
>                  not have to implement IPv6 for example
>
>     That's not a technical detail; that's the key to the solution. That
>     IS what IP *is*. That's why shifting from IPv4 to IPv6 is hard.
>
>
>     Then write a paper on the requirements. But you cannot expect to
>     satisfy a want you *agree* we do not currently understand.
>
>     Joe
>
>

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 12 Sep 2012 10:32:57 +0300

OK. See you there.
Cheers,
Pars

On Wed, Sep 12, 2012 at 10:10 AM, Joe Touch <[email-masked]> wrote:

> serves that purpose, and the above list is the original IRTF list for these
> sorts of discussions.
>
>> http://htmlimg3.scribdassets.**com/2hdm1jwfcw1sxm1y/images/4-**
>> 5930b39cea.jpg<http://htmlimg3.scribdassets.com/2hdm1jwfcw1sxm1y/images/4-5930b39cea.jpg>
>>