Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U)

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Nov 2006 20:09:35 +0100

> Well, my thoughts on how to jack up IPv4 (or IPv6, although there's no
> benefit to deploying that if you do this), turn it into an end-end endpoint
> identification layer, 

When you have more than 4 billion nodes, or any nodes with ambiguous IPv4
addresses, surely you need extra address bits?

     Brian

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Tony Li" <[email-masked]>
Date: Fri, 10 Nov 2006 11:17:31 -0800

> addresses, surely you need extra address bits?

NAT

T

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Nov 2006 20:41:50 +0100

Tony Li wrote:
>  
> 
> 
>>>Well, my thoughts on how to jack up IPv4 (or IPv6, although 
>>
>>there's no
>>
>>>benefit to deploying that if you do this), turn it into an 
>>
>>end-end endpoint
>>
>>>identification layer, 
>>

Even if you have an antiNAT at the other end, address ambiguity
destroys the e2e identification property and third party referrals.

     Brian

---

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 10 Nov 2006 11:44:54 -0800

Tony,

Your answer surprises me. Could you give a bit longer answer for what
you are thinking? That is, I recognize the desirability of IPv4. Are you
thinking of a large number of devices using private addresses behind a
NAT that exposes a few public addresses? If so, then how can the
receiving NAT do that mapping? I'm just not following you here. What are
you thinking?

--Eric

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Friday, November 10, 2006 11:18 AM
To: 'Brian E Carpenter'; 'Noel Chiappa'
Cc: [email-masked]
Subject: RE: Ok, so what should we do then? (Was: Re:
[arch-d][Off-topic]Further thoughts: about systems theory and the theory
U)

NAT

T

---

From: "Tony Li" <[email-masked]>
Date: Fri, 10 Nov 2006 12:17:17 -0800

> receiving NAT do that mapping? I'm just not following you 

Eric,

Sorry for being terse.  I was simply pointing out that appropriate use
of address translation can easily allow us to map much more than 4
billion nodes onto 4 billion addresses.  This was brought up at one of
the first ROAD meetings.

Please note that I do *NOT* advocate this approach, I simply mentioned
it because we all need to be on the same page about the solution
envelope be it good, bad, or ugly.  I'm less than interested in applying
more kludges to, or underneath, the existing architecture.  I'm much
more interested in doing it Right, doing it Once and doing it Forever.

Tony

---

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 10 Nov 2006 13:41:02 -0800

Tony,

I believe that I'm tracking with you, though I'm naturally curious what
specific technical approach you would recommend. For example, the IETF
has preferred to view locators to be absolute identifiers within a
universal schema (e.g., a SPF approach to location). However, they could
also be relative locators in a Bellman-Ford or Landmark routing manner.
Regardless, how would you solve the EGP routing and end point ID
addressing issue?

Changing topics, I was surprised by this email thread because it is
apparent that my memory of IPng (IPv6) differs significantly from the
views I've seen thus far. Specifically, I believe that the IETF
consensus position today supports Noel's distinction between end point
IDs and topology locators -- we just don't agree on how to achieve it. I
also believe that this distinction was also part of our original IPng
consensus position and it is part of what I was thinking when I
originally suggested the proto-IPv6 autoconfiguration approach: the
first 10 bytes (in my original version) is the locator and the last 6
bytes are the identifiers. 8x8 is fine -- I'm not really talking about
where the division is made just that it occurs and that the locators
locate the routing topology to subnetworks. I then left Boeing and the
IETF and when I eventually returned I was surprised to note that the
standards had diverged from the positions that I thought we had agreed
upon, as if Noel's contributions hadn't achieved the mindshare that I
thought they had. Anyway, when I first saw Vince Fuller's material
earlier this week, I resonated with his points, believing that he was
restating our original IPng consensus position before it evolved into
becoming "IPv4 with larger addresses."

Regardless, from where we stand today, how would you technically solve
EGP routing and end-point ID addressing if you were the king of the
world?  

--Eric

-----Original Message-----

Eric,

Tony

---

From: "Tony Li" <[email-masked]>
Date: Fri, 10 Nov 2006 15:13:12 -0800

> destroys the e2e identification property and third party referrals.

Third party referrals are just security problems and should be wholly
eliminated as intrinsically untrustworthy.

Point made about e2e identification.  

Tony

---

From: "Tony Li" <[email-masked]>
Date: Fri, 10 Nov 2006 15:38:06 -0800

Eric,
 
> IDs and topology locators -- we just don't agree on how to 
> achieve it.

I agree that that seems to be the growing consensus today.  However, I
also believe that this consensus is relatively recent.  Not long ago, a
loc/id split was anathema.

> I
> locate the routing topology to subnetworks. 

Sorry, I don't believe that we ever got to a consensus where the locator
was truly independent of the identifier.  In particular, I'll claim that
if the locator is part of the TCP pseudo-header, then it's definitely
not sufficiently independent.  We never got that far.

> EGP routing and end-point ID addressing if you were the king of the

If I were king, I'd tend to worry about bigger things.  ;-)

My favorite approach is to morph GSE, but the most signficant bits are
a) separation of loc and id, resulting in b) much better multi-level
locator abstraction, c) multi-homing without global prefixes, d) easier
renumbering, e) better mobility, and f) a reasonably clean architecture.
Not necessarily in that order.

Tony

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Nov 2006 15:41:57 -0800

On Nov 10, 2006, at 11:41 AM, Brian E Carpenter wrote:

> Even if you have an antiNAT at the other end

noting that I am neither ultimately anti-nat or pro-nat... I just see  
some problems that nats solve and others that it creates or doesn't  
fix, and I see other ways of fixing the problems that don't have  
those issues (but in a 32 bit address space have other problems).

Please, could we manage to not be arguing about NATs? We are using  
NATs now, probably as effectively as we collectively know how, and a  
five year old with a ruler and the RIR address allocation data can  
draw valid conclusions that lead us to believe that we have a limited  
timeframe to do something different.

We need a problem statement, preferably a set of requirements, one or  
more proposed solutions, and for each solution an honest analysis  
that leads to to believe whether it actually fixes the issues set  
forth in the problem statement. Let's target that.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 11 Nov 2006 00:55:37 +0100

> noting that I am neither ultimately anti-nat or pro-nat...

What he meant was that even if at the other end, the NAT rewriting is  
reversed so that the original addresses are restored, certain  
problems remain.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 11 Nov 2006 00:52:57 +0100

> eliminated as intrinsically untrustworthy.

You may want to be careful going down this road; before long you'll  
have eliminated the entire internet...

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Nov 2006 01:32:06 +0100

Iljitsch van Beijnum wrote:
> reversed so that the original addresses are restored, certain  problems 
> remain.

Exactly...

---

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 10 Nov 2006 16:50:03 -0800

From: Iljitsch van Beijnum [mailto:[email-masked]] 

>have eliminated the entire internet...

Trust models are a very important security issue. Unless an assured
basis to trust third party referrals is provided then hostile attackers
are provided a target-rich opportunities for damage.

Your point, Iljitsch, is centrally important: do the existing third
party referrals (e.g., mobile IP, SIP, large number of proxy
implementations) provide an adequate trust model foundation?
Specifically, do the IETF protocols do so? 

My personal conclusion is that the IETF protocols do not adequately
address this issue but rather punt this issue to us end users.
Therefore, the actual vulnerability of these approaches in real life
networks is a function of how we end users actually deploy them in our
specific deployments. Therefore, beware of referrals that span
administrative domains!

---

From: Peter Tomsu <[email-masked]>
Date: Sat, 11 Nov 2006 08:33:00 +0100

Agree, spanning multiple administrative domains has always issues.

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 11 Nov 2006 08:40:35 -0500

Dear Tony, et al;

> loc/id split was anathema.

One place where the loc/id split might make a lot of sense would be  
in mobile platform internets (MPI's), such as
modern commercial airliners with routers, lots of networked devices  
and three or more internal subnets and address blocks per plane (see  
some of the documents at http://www.multicasttech.com/mpi/ if you  
want more details). 10,000 such planes flying around would tax even  
an airplane only BGP network.

Suppose this was done in a loc/id split, with (say)

a /8 allocated to this with
22 bits each assigned to latitude and longitude (for ~1 meter  
location precision),
12 bits to altitude (~ 10 meters accuracy, although you might want to  
do a mu law type enocding)
there would be 64 bits for the ID.

That implies a pretty high density of stuff per square meter and  
would make MPI routing pretty easy.

It may make a lot of sense to assume that the internet is divided  
into pieces with different needs, and different routing policies.

Regards
Marshall

---

From: Fred Baker <[email-masked]>
Date: Sat, 11 Nov 2006 06:45:11 -0800

On Nov 11, 2006, at 5:40 AM, Marshall Eubanks wrote:
> 12 bits to altitude (~ 10 meters accuracy, although you might want  
> to do a mu law type enocding)

This has been discussed by Tony Hain for quite a while, along the  
lines of "if I can enumerate the locations on the earth I don't need  
an RIR to assign me a prefix". We probably have some internet drafts  
about it somewhere.

The presumed routing algorithm here is something like "find the next  
hop router most obviously in the same direction as the target". Sort  
of like routing in a hypercube: "calculoate the difference between  
the address of this corner and the target corner, and send the  
message on an edge to a device with a lower difference".

I worry about backhauls. Lets imagine you're routing to some south  
pacific island. The only path to it may be by routing to an undersea  
cable landfall on an island quite a distance away, so that  
topological and target-based routing take you in exactly opposite  
directions.

I also worry about the possibility of distinguishing one's location -  
GPS has a minimum footprint that it can discern - and the possibility  
of having multiple objects within that distance. If I put 50 single  
RU boxes in a rack, do they all get the same address? What leads me  
to believe that they are all by virtual of being on the same rack on  
the same LAN?

---

From: John Day <[email-masked]>
Date: Sat, 11 Nov 2006 09:59:59 -0500

You guys are being too literal in thinking about "location." 
Location has to be relative to the topology of the network.  (And I 
do mean topology, not graph.)  The topology of the address space and 
the topology of the network must be compatible.  Even then, one will 
have exceptions that will have to be explicitly noted.  But then this 
is why we maintain a mapping between addresses and routes.

Remember addresses are location-dependent.  They tell you *where* 
they are not how to get there.  They may give you a hint about where 
to look for a how! ;-)  But that is all.

Take care,
John

At 6:45 -0800 2006/11/11, Fred Baker wrote:
>I also worry about the possibility of distinguishing one's location 
>- GPS has a minimum footprint that it can discern - and the 
>possibility of having multiple objects within that distance. If I 
>put 50 single RU boxes in a rack, do they all get the same address? 
>What leads me to believe that they are all by virtual of being on 
>the same rack on the same LAN?
>

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 11 Nov 2006 09:59:13 -0500

Dear Fred;

(Note cross-posted to the MPI list.)

On Nov 11, 2006, at 9:45 AM, Fred Baker wrote:

> lines of "if I can enumerate the locations on the earth I don't  
> need an RIR to assign me a prefix". We probably have some internet  
> drafts about it somewhere.
>

I would be interested to see them.

> The presumed routing algorithm here is something like "find the  
> next hop router most obviously in the same direction as the  
> target". Sort of like routing in a hypercube: "calculoate the  
> difference between the address of this corner and the target  
> corner, and send the message on an edge to a device with a lower  
> difference".
>

In the wired case, this can indeed be problematic (especially if you  
add in tunnels and VPNs and ...). In the
MPI case, where connectivity is by wireless or maybe P2P laser, then  
it works better. You _can_ only connect
to something nearby. (Of course, there are satellites, but then you  
can only connect to the ones in your foot-print.) And, at least in  
the aircraft MPI case, there is a desire to connect to _everything_  
nearby.

> pacific island. The only path to it may be by routing to an  
> undersea cable landfall on an island quite a distance away, so that  

With differential GPS/Galileo, you can do 1 meter pretty straight- 
forwardly. You need that near airports, at least if you are landing  
there. Over the ocean the accuracy might be less, but so is the  
crowding.

Planes certainly pass over each other, so you need another separator,  
which I called altitude, which is one possibility (if two planes have  
the same location and altitude, I am afraid that they would no longer  
need routing). But the separator could be something else.

I would say, if I have 50 1U boxes all in the same airplane, yes,  
they get the same "loc" but of course different "ids". In any case,  
the idea of MPI is that it is (in fact if not in name) an autonomous  
system, with internal routing.

Regards
Marshall

---

From: John Day <[email-masked]>
Date: Sat, 11 Nov 2006 09:59:59 -0500

Take care,
John

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 11 Nov 2006 09:59:13 -0500

Dear Fred;

Regards
Marshall

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 11 Nov 2006 16:22:32 +0100

> I would be interested to see them.

http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-10.txt

I haven't read the latest version, but unless something has changed  
this is only addressing. A few years ago, I wrote a draft about how  
to make use of geographically aggregatable address space to have more  
scalable routing, which includes a different way to do geographic  
address allocation, but should be compatible with Tony's system as well:

http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt

Iljitsch

---

From: Jefsey_Morfin <[email-masked]>
Date: Sat, 11 Nov 2006 16:42:04 +0100

At 15:59 11/11/2006, John Day wrote:
>have exceptions that will have to be explicitly noted.  But then 
>this is why we maintain a mapping between addresses and routes.

Is there not something named X.121 about that? Or E.164?

>to look for a how! ;-)  But that is all.

It helps depending on their segmentation and the dependance between segments.
May be, we could consider if instead of obtaining an IP address from 
the DNS we could obtain a path? What I learned to call a "needle"?
It could be kept in cache for a TTL or until an broken path report is received?

That DNS would be a Distributed Network Supervisor System?

It could be also called with an IP address.

By default the origin end would be the calling IP address, but that 
DNSS could be called to know the status of a different network area.
The system could be loaded with a "bandwidth cost per segment" to 
permit to trim the cheapest (fastest) path.

What would be interesting is that it would address the multihoming 
issue while preserving the origin end autonomy (it could calculate 
its own needle). Other services would be very easy to support such as 
ISP rotation (I rotate ISP within a same cession), Daisy Chaining 
Back-up, Follow-me (mobile, semimobiles), externets (open walled 
gardens, open user groups) and extranets.

The DNSS algorithm and network status knowledge would be simpler if 
the segments resulted from a topology oriented numbering plan. 
Obviously the routers would need far less computing power and memory 
and could easily reconfigure the network in case of line problem or addition.

I think the DNSS could be a ONES like the DNS using OPES at the ends 
to enter the needle and receiving reports from the routers and 
gateways (line status, traffic load, result of tests, etc.). May be 
could it be associated directly with the DNS to share security and 
dynamic network knowledge. And as an extended redesign some 
additional features could be associated from the offing such as the 
support of enhanced unicode for foolproof ML.DNs. May be also the 
needle could be checked at the receiving end to filter out spoofing?

This could certainly be part of a distributed network operating system.
Or may be is it a too smart yet proven solution?
Cheers.
jfc

---

From: "Tony Li" <[email-masked]>
Date: Sat, 11 Nov 2006 11:45:07 -0800

> an airplane only BGP network.

Hi Marshall,

That's certainly one approach.  However, there's another solution to
this issue that doesn't really require architectural changes.  

If you take a look at how our friends at Connexion did things, they
assigned one prefix per plane and then injected it into global routing
at the point of its current downlink.

With all due respect, an alternate approach would be to have a separate
global domain that provides backhaul and have that domain inject all
plane prefixes from all points simultaneously, effectively causing
everyone to perform hot-potato routing to them with stable BGP
injection.  Note that the backhaul network need not be physically
instantiated: a full mesh of tunnels between the downlink sites and an
IGP carrying plane prefixes should work very nicely for little
additional (physical) cost.  It also has the nice property that your
latency to the plane is not nearly as bad as bouncing to a single, fixed
downlink would be.  You can also decrease latency by adding (virtual)
connectivity anywhere in the global topology to redirect traffic into
the backhaul topology.

Hiding mobility is a good option for the cases where you're not going to
actually change providers.

Tony

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 Nov 2006 04:46:55 -0500

Backhauling is a notion whose day has come and I for one believe we need
to understand how it can assist the routing.  Agree totally that when
one changes providers the mobility has to be "seamless" simply because
there is a good chance the locator has to change for the mobile node.
The reason that is relative it requires routing analysis and I believe
part of this problem.

But it would be real great if we could write up the set of "what
problems are we trying to solve". 

/jim 

> Sent: Saturday, November 11, 2006 2:45 PM
> To: 'Marshall Eubanks'; [email-masked]
> Cc: 'Fleischman, Eric'; 'Noel Chiappa'; 'Terry L Davis'; 
> [email-masked]
> Subject: RE: Ok, so what should we do then? (Was: 
> Re:[arch-d][Off-topic]Further thoughts: about systems theory 
> andthe theory U)
> 
>  
> 
> > One place where the loc/id split might make a lot of sense 
> would be in 
> > mobile platform internets (MPI's), such as modern 
> commercial airliners 
> > with routers, lots of networked devices and three or more internal 
> > subnets and address blocks per plane (see some of the documents at 
> > http://www.multicasttech.com/mpi/ if you want more details). 10,000 
> > such planes flying around would tax even an airplane only 
> BGP network.
> 
> 
> Hi Marshall,
> 
> That's certainly one approach.  However, there's another 
> solution to this issue that doesn't really require 
> architectural changes.  
> 
> If you take a look at how our friends at Connexion did 
> things, they assigned one prefix per plane and then injected 
> it into global routing at the point of its current downlink.
> 
> With all due respect, an alternate approach would be to have 
> a separate global domain that provides backhaul and have that 
> domain inject all plane prefixes from all points 
> simultaneously, effectively causing everyone to perform 
> hot-potato routing to them with stable BGP injection.  Note 
> that the backhaul network need not be physically
> instantiated: a full mesh of tunnels between the downlink 
> sites and an IGP carrying plane prefixes should work very 
> nicely for little additional (physical) cost.  It also has 
> the nice property that your latency to the plane is not 
> nearly as bad as bouncing to a single, fixed downlink would 
> be.  You can also decrease latency by adding (virtual) 
> connectivity anywhere in the global topology to redirect 
> traffic into the backhaul topology.
> 
> Hiding mobility is a good option for the cases where you're 
> not going to actually change providers.
> 
> Tony
> 
> 
>

---

From: David Meyer <[email-masked]>
Date: Sun, 12 Nov 2006 12:36:45 -0800

> forth in the problem statement. Let's target that.

	Fred,

	Both of the latter (problem statement + requirements). I
	didn't see another way that the IAB could kick the IETF
	into action other than what we did (and yeah, we couldn't
	get everyone we wanted [or even everyone *I* wanted]
	there, but at least it was a start, and you have to start
	somewhere). In any event, the next steps Leslie outlined
	in the plenary include exactly these action items, so I
	think we're (at least) pointed in the right
	direction. That's more than I could have expected (given
	the history, etc). 

	--dmm

---

From: "Davis, Terry L" <[email-masked]>
Date: Mon, 13 Nov 2006 07:21:55 -0800

Jim

For aviation mobility, that's what Marshall, Will Ivancic and I are
trying to do with the web site and drafts below.  By the Prague IETF
meeting, we hope to have made significant updates to both the problem
statement draft and the aviation requirements draft.

Website:
http://www.multicasttech.com/mpi/ 

Drafts:
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-10.txt 
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-10.txt 

Take care
Terry

> From: Bound, Jim [mailto:[email-masked]]
> Sent: Sunday, November 12, 2006 1:47 AM
> To: [email-masked]; Marshall Eubanks
> Cc: Fleischman, Eric; Noel Chiappa; Davis, Terry L; architecture-
> [email-masked]
> Subject: RE: Ok, so what should we do then? (Was: Re:[arch-d][Off-
> topic]Further thoughts: about systems theory andthe theory U)
>

---

From: "Davis, Terry L" <[email-masked]>
Date: Mon, 13 Nov 2006 07:28:19 -0800

Tony/Marshall

This type of concept is one of several we are discussing for the global
ATC network and we could conceivably extend it for the airline
operations domain.

Take care
Terry

> Sent: Saturday, November 11, 2006 11:45 AM
> Cc: Fleischman, Eric; 'Brian E Carpenter'; 'Noel Chiappa';
architecture-
> [email-masked]; Davis, Terry L
> Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-
> topic]Further thoughts: about systems theory and the theory U)
> 
> 
>

---

From: "Davis, Terry L" <[email-masked]>
Date: Mon, 13 Nov 2006 07:28:19 -0800

Tony/Marshall

Take care
Terry

architecture-

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 13 Nov 2006 10:48:08 -0500

Terry, ACK.

Best,
/jim 

> From: Davis, Terry L [mailto:[email-masked]] 
> Sent: Monday, November 13, 2006 10:22 AM
> To: Bound, Jim; [email-masked]; Marshall Eubanks; 
> [email-masked]
> Cc: Fleischman, Eric; Noel Chiappa; 
> [email-masked]; Ivancic, William D. ((GRC-RCN0))
> and the theory U)
> For aviation mobility, that's what Marshall, Will Ivancic and 
> I are trying to do with the web site and drafts below.  By 
> the Prague IETF meeting, we hope to have made significant 
> updates to both the problem statement draft and the aviation 
> requirements draft.
> 
> Website:
> > > Re:[arch-d][Off-topic]Further thoughts: about systems 
> theory andthe 
> > > theory U)
> > >
> > >
> > >
> solution to 
> things, they 
> > > assigned one prefix per plane and then injected it into global 
> > > routing at the point of its current downlink.
> > >
> > > With all due respect, an alternate approach would be to have a 
> > > separate global domain that provides backhaul and have 
> that domain 
> > > inject all plane prefixes from all points simultaneously, 
> > > effectively causing everyone to perform hot-potato 
> routing to them 
> > > with stable BGP injection.  Note that the backhaul 
> network need not 
> > > be physically
> sites and 
> > > an IGP carrying plane prefixes should work very nicely for little 
> > > latency to the plane is not nearly as bad as bouncing to 
> a single, 
> > > fixed downlink would be.  You can also decrease latency by adding 
> > > (virtual) connectivity anywhere in the global topology to 
> redirect 
> > > Hiding mobility is a good option for the cases where you're not 
> > > going to actually change providers.
> > >
> > > Tony
> > >
> > >
> > >

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 14 Nov 2006 08:59:36 -0500

I would not support this as you state, but would support updates once
identity and location were clearly determined with consensus.

/jim 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, November 14, 2006 7:53 AM
> To: Bound, Jim; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: Ok, so what should we do then? 
> (Was:Re:[arch-d][Off-topic]Further thoughts: about systems 
> theoryandthe theory U)
> 
> How about starting with a denouncement of MIPv4/MIPv6 as they 
> both are based on the assumption that the IP address can be 
> used both as a locator and an identifier?
> 
> /Mikael
> 
> >

---

From: <[email-masked]>
Date: Tue, 14 Nov 2006 14:52:54 +0200

How about starting with a denouncement of MIPv4/MIPv6 as they both are
based on the assumption that the IP address can be used both as a
locator and an identifier?

/Mikael

>
>But it would be real great if we could write up the set of 
>"what problems are we trying to solve". 
>
>/jim 
>