Subject: RE: Solving the right problems ...

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Aug 2003 13:18:38 +0200

-----BEGIN PGP SIGNED MESSAGE-----

Tony Hain wrote:

> Mobile IP, and the multi6 DHT work are attempts to mitigate it through
> slight of hand at the IP layer, while SCTP attempts to mask the topology
> reality in the transport layer. (These are probably not the only examples,
> but they are the ones that come to mind this morning.) Yet none of these
> really do the job in all cases.

I totally agree with your current insight that we need to seperate
the routing from the host identifier. IMHO every host should have
one globally unique ID and could have multiple transports, even if
those are IPv4, IPv6, IPX or whatever based and going over multiple
links or not. Though we should limit to IP based protocols to not
make it too complicated. Such a mechanism could solve problems for:
"site-locals" constructions, multihoming, mobile-ip without hindering
the size of the routing table as people could continue to use current
routing, thus TLA based and fully aggregated to the TLA level in the GRT.

I've been looking into this since the very heated debate about site-locals.
As imho there might be a way to solve that in the same problem too.
Though I am still conducting research on that topic. As far as it stands
I think that HIP is going the best way there is. LIN6 is flawed as it
won't scale and can't be deployed easily. Next to those I got my
own odd idea and I will probably work it out and implement it as a proof
of concept. Though timing on when and how may be completely unknown.

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Aug 2003 16:49:46 +0200

On woensdag, aug 27, 2003, at 13:18 Europe/Amsterdam, Jeroen Massar 

> routing, thus TLA based and fully aggregated to the TLA level in the 

The multi6 wg has been working on locator/identifier separation as a 
way to solve the multihoming in IPv6 problem for a while now.

The problems we're facing (apart from the fact that there are many ways 
to skin this particular cat and everyone has a different preference) is 
that additional mechanisms are needed to get the extra information 
across, and there is a price to be paid in one or more of: additional 
round trips, more dependence on the DNS or something similar to DNS, 
additional per-packet overhead, loss of backward compatibility, 
increased complexity.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Aug 2003 18:20:10 +0200

-----BEGIN PGP SIGNED MESSAGE-----

> way to solve the multihoming in IPv6 problem for a while now.

And ever since they haven't progressed much unfortunatly :(
 
> The problems we're facing (apart from the fact that there are 
> many ways to skin this particular cat and everyone has a different 
> preference) is that additional mechanisms are needed to get the extra
> information across, and there is a price to be paid in one or more of:
> additional round trips, more dependence on the DNS or something similar
> to DNS,

Indeed, one will always have this problem, my current idea relies
on DNS, but if a program currently tries to contact another host
it will usually already do a forward resolve and some apps
(ssh for instance) also like to do a reverse resolve already.
So these shouldn't be much of a problem. In the idea I have I
have also added the possibility to limit these lookups until
a failure occurs.

> additional per-packet overhead,

Not required for my idea.

> loss of backward compatibility, 

I covered that in my idea, by simply adding functionality
and not replacing it in a manner which could cause
unexpected effects on the installed base.
The installed base won't have the benefit

> increased complexity.

Not overcomable, but it should not be noticeble much in
the idea I have. It's also more of a Proof of concept for me
to see if I can get such a mechanism to work and to proof
that such mechanisms are viable. Query me at RIPE next week
if you want to hear more about it.

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Aug 2003 09:39:16 -0700

Jeroen Massar wrote:
> ... As far as it stands I think that HIP 
> is going the best way there is. LIN6 is flawed as it won't 
> scale and can't be deployed easily. Next to those I got my 
> own odd idea and I will probably work it out and implement it 
> as a proof of concept. Though timing on when and how may be 
> completely unknown.

What I was trying to point out is that HIP/etc. is only part of the
solution. What an identity protocol needs is a point in the stack which is
being identified. We can try to stuff it into each of the transport
protocols, but we will have to do that over for each, and there would need
to be complex api options if apps wanted to avoid the identity / topology
mapping. It will be much simpler to leave the existing api path for the apps
that want that service, and provide a layer above transport to manage the
mappings.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Aug 2003 09:48:42 -0700

Iljitsch van Beijnum wrote:
> many ways 

At least the backward compatibility issue is primarily due to trying to
force a lower layer to mask the topological realities. There may be some
need for additional round trips, or enhanced mapping infrastructure, but if
that only applied to apps using a new stabilization layer, there wouldn't be
as much complaint because those would see a clear benefit. In any case I
don't think adding a layer will be a trivial task, but from here it looks
like the least the path of least resistance.

Tony

---

From: jfcm <[email-masked]>
Date: Wed, 27 Aug 2003 18:52:29 +0200

Using a 1D numbering plan to support 5 (?) distinct dimensions (plan, 
technology, network routing, global host addressing and interface 
identification) looks like X121 or old telephony.

Which additionnal information do you need to move accross if you use fixed 
size dimension and gives evey dimension its separate numbering 
authority/structure and then concatenate them into a multidimentional 
address? Like for mobiles.

I remember when CCITT voted they would never allocate addresses of more 
than X bytes. (was it not 32?). Would anyone recall if at that time they 
discussed some kind of layer splitting? Old experience often carries 
interesting concepts. They were probably thinking hierarchichal instead of 
multidimensional?
jfc

At 16:49 27/08/03, Iljitsch van Beijnum wrote:

>On woensdag, aug 27, 2003, at 13:18 Europe/Amsterdam, Jeroen Massar wrote:
>
>The multi6 wg has been working on locator/identifier separation as a way 
>to solve the multihoming in IPv6 problem for a while now.
>
>The problems we're facing (apart from the fact that there are many ways to 
>skin this particular cat and everyone has a different preference) is that 
>additional mechanisms are needed to get the extra information across, and 
>there is a price to be paid in one or more of: additional round trips, 
>more dependence on the DNS or something similar to DNS, additional 
>per-packet overhead, loss of backward compatibility, increased complexity.
>
>
>
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/03

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Aug 2003 19:15:53 +0200

-----BEGIN PGP SIGNED MESSAGE-----

Tony Hain [mailto:[email-masked]] wrote:

[?Does this need to keep going to both [email-masked] & ipng@sunroof?]

> solution. What an identity protocol needs is a point in the 
> stack which is being identified. We can try to stuff it into each
> of the transport protocols, but we will have to do that over for
> each, and there would need to be complex api options if apps
> wanted to avoid the identity / topology mapping. It will be 
> much simpler to leave the existing api path for the apps
> that want that service, and provide a layer above transport 
> to manage the mappings.

My current idea puts it at the resolver level. The application
gets the 128bits identifier, which actuall is a IPv6 address,
either given out from a special registry or simply from an
/48 that is already assigned to you. This address can be used
for both routing and identification purposes and can easily
be assigned to hosts by using RA.

The stack/API then maintains a list of routing IP's that
are associated by that "IdentifierIP" and then replaces it
before it enters the network with the routing IP that is
to be used for actually routing the packet. On initial
communication there could be an extra header sent along
which says "this packet originates from this Identifier IP"
along with a signature, verifyable through eg DNS to check
it is really it. HIP is much further there though.

This way apps don't need to know about it, they only need
to know about IPv6. One could also pass this along to IPv4
except then it needs an extra magic packet for the IDIP.
See HIP again. And I am thinking about using the above for
solving a little problem for dynamic hosts in the SixXS project.

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Aug 2003 19:25:34 +0200

On woensdag, aug 27, 2003, at 18:48 Europe/Amsterdam, Tony Hain wrote:

> but if that only applied to apps using a new stabilization layer, 
> there wouldn't be as much complaint because those would see a clear 
> benefit.

So when will vendors recompile their apps for multihoming? Right after 
they're done recompiling them for IPv6?

It might be useful to start thinking about what we can do in the long 
term if we don't care about supporting existing applications, but this 
won't solve any of today's or tomorrow's problems.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Aug 2003 19:22:49 +0200

> Which additionnal information do you need to move accross if you use 
> fixed size dimension and gives evey dimension its separate numbering 

I have three problems with this.

First, "fixed size" always means "wrong size".

Second, with going from 20 to 40 bytes for the IP header I feel we've 
pretty much used up our overhead increasing budget for this decade.

Last but not least: having an identifier and a locator in the same 
packet is useless as we have mechanisms to authenticate identifiers and 
mechanisms to authenticate locators, but without mechanisms to 
authenticate the association between a locator and an identifier, we 
open up a whole new world of denial of service. Fixing this by carrying 
auth data (= a signature) inband would be an unacceptable increase of 
overhead, and doing it out of band would be redundant as it is much 
more efficient to carry the actual data out of band than the 
authentication data for the inband data.

> I remember when CCITT voted they would never allocate addresses of 
> more than X bytes. (was it not 32?).

32 bytes? This wasn't for voice, was it? I really wouldn't care much 
for dialing 75 digit phone numbers...

The way I see it:

We now have FQDNs that identify services or hosts, and we have IP 
addresses, that identify hosts or routing+interface. In order to 
decrease the ambiguity to managable levels, we need to move the FQDNs 
and especially IP addresses away from identifying hosts, and introduce 
and explicit host or "stack name" identifier. Host identifiers should 
look like IPv6 (maybe optionally IPv4) addresses, in order to be able 
to keep using our current protocols that expect 16/4 bit values. (And 
there isn't much of substance to be gained by giving them a different 
shape.) Where necessary, FQDNs can be replaced by application specific 
namespaces with a system to map those names to host identifiers to go 
along with such a new space. The hard part is coming up with a way to 
do the host/location mapping in a way that is simple, fast, cheap, 
secure, flexible and reliable.

Iljitsch

---

From: Fred Templin <[email-masked]>
Date: Wed, 27 Aug 2003 10:51:33 -0700

Iljitsch van Beijnum wrote:

> The hard part is coming up with a way to do the host/location mapping 
> in a way that is simple, fast, cheap, secure, flexible and reliable.

Wouldn't we all start deploying, e.g., HIP tomorrow if we had a solution for
this? And, how might that solution be any different than MIP HoA/CoA
binding management? Again, I'm looking forward to seeing any proposals
that may be forthcoming.

Fred
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Aug 2003 14:33:34 -0400

> shape.) 

mostly agree, except that I suspect it works better to put the new layer
between IP and transport than to insert a layer underneath IP.  part of
this assumption is that the new layer can still be nil for hosts whose
location is fixed and that do not need unreasonably stable addresses.

> Where necessary, FQDNs can be replaced by application specific
> along with such a new space. 

I don't see a need to change FQDNs themselves - but the meanings of the
IP addresses that they map to will change slightly.

> The hard part is coming up with a way to 

yup.  that, and making the transition work smoothly.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Aug 2003 12:11:08 -0700

> they're done recompiling them for IPv6?

It will be the same step, because the only reason they would be recompiling
for IPv6 is to accomidate customer demand. Since the larger customers that
might create demand are almost all multihomed, that will be a primary
feature in the porting effort.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Aug 2003 12:04:34 -0700

> [?Does this need to keep going to both [email-masked] & ipng@sunroof?]

Not as far as I am concerned. If we take the suggested path, the work is
clearly outside the IPv6 WG, and anyone on the IPv6 list that cares to
follow the discussion is now aware of it. I will be dropping ipng from any
further responses to this thread.

> My current idea puts it at the resolver level. The 
> application gets the 128bits identifier, which actuall is a 
> IPv6 address, either given out from a special registry or 
> simply from an /48 that is already assigned to you. This 
> address can be used for both routing and identification 
> purposes and can easily be assigned to hosts by using RA.
> 
> before it enters the network with the routing IP that is to 
> be used for actually routing the packet. On initial 
> communication there could be an extra header sent along which 
> says "this packet originates from this Identifier IP" along 
> with a signature, verifyable through eg DNS to check it is 
> really it. HIP is much further there though.

The only issue is the slight of hand in 'The stack/API then maintains a list
of routing IP's ...'. It would appear your assumption is that L4 or below
would perform the substitution magic, and have a protocol to communicate to
the peer what the magic is. I am saying that this should simply be a formal
layer between L4 & L7. This avoids messing with existing lower layers which
would create compatibility issues both for the peer node, as well as
application expectations about what the lower layers do.

> except then it needs an extra magic packet for the IDIP. See 
> HIP again. And I am thinking about using the above for 

So you prove my original point, 'there is a sacred invariant, and we must
avoid messing with the app / transport interface at all costs'. Everything
you described would fit cleanly in an entity that sat between L4 & L7. In
fact from an architectural perspective, the "IdentifierIP" you describe
would be the name of the point in the stack shared by all interfaces &
transports. It really doesn't matter if that name is variable length ascii,
or fixed length binary, but I am sure many will share their favorite
opinion.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Aug 2003 15:34:41 -0400

> Not as far as I am concerned. If we take the suggested path, the work
> is clearly outside the IPv6 WG, 

only because you insist that the layer belongs between 4 and 7.  but
since the layer belongs between 3 and 4, or maybe between 2 and 3,
it clearly does impinge on IPv6.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Aug 2003 21:36:51 +0200

-----BEGIN PGP SIGNED MESSAGE-----

<SNIP similar part>

> So you prove my original point, 'there is a sacred invariant, 
> and we must avoid messing with the app / transport interface at all 
> costs'. Everything you described would fit cleanly in an entity
> that sat between L4 & L7.

Agreed.

As for transparency for 'old' application that don't support this
we could invent a new RR which holds the identifier for that host,
or simply use TXT records, eg:

purgatory.unfix.org.   TXT   "POINT 2042::1"
                       AAAA  3ffe:8114:2000:240:290:27ff:fe24:c19f
                       AAAA  2001:db8:1:1:210:dcff:fe20:7c7c

The reverse of the Identifier IP contains the Routing IP's to be used.
Additionally the TXT record contains it's public key with which the
extension headers are signed and which could also be used for the switchovers.

POINT <Identifier IP> <Public Key>

Example: 
1....2.4.0.2.ip6.arpa. TXT   "POINT 2042::1 8d9f2acfbe7c54e4893a34e50656a602"
                       AAAA  3ffe:8114:2000:240:290:27ff:fe24:c19f
                       AAAA  2001:db8:1:1:210:dcff:fe20:7c7c

I chose IPv6 for the identifier, as every new installation will
be getting IPv6 addresses anyways (hopefully) and there should
be enough to address all the hosts in the world and beyond.
Distribution of this Identifier IP could easily be done by RA
or DHCPv6 with a special flag for example. The address can be
taken from a standard delegation from an ISP, as long as
you also get to control the reverse, or from a seperate registry
that doesn't allow using these addresses for routing, almost like
the IX allocations but not quite like those. This will give
companies PI _like_ addresses, but they are not used for routing
and thus don't do any harm to the size of the GRT.

Applications keep to see IPv6 addresses but they are actually
Identifier IP's, so no harm done to the installed base.
We only need the 'magic' for passing along what happens when
a link breaks down and thus that the packet
Next to that the stack must replace the Identifier IP with
the routing IP, based on some rules/assumptions/...
Thus hosts that support this scheme benefit from it, others don't.

Same trick can be applied to IPv4, except for the updates
being stuffed in the Extension headers we could use a special
udp proto which does the same trick. The signature in DNS
can be used in verifying that it is really the sending host
thus even allowing other routing IP's to be used than those
stored in DNS.

Yes, in this setup we have a dependency on DNS, but that is
just a way of distributing data that works. Lowering the TTL
could allow 'mobility' if we wanted that remote hosts could
contact the moving host. LIN6 solves this by introducing a
faster and directer form of DNS called a Mobile Agent.

> In fact from an architectural perspective, the "IdentifierIP" 
> you describe would be the name of the point in the stack shared by
> all interfaces & transports.

Actually my document called it IdentifierIP at first but I changed
it to "Point" as it is a point in the network, not a node, which
represents the "Routing IP".

> It really doesn't matter if that name
> is variable length ascii, or fixed length binary, but I am sure
> many will share their favorite opinion.

A current application calls getaddrinfo() or similar to retrieve
the IP of a remote host. In my idea I choose for an IPv6 address
to be returned. The kernel or the API would then mask the IPv6
address passed to the program, which it further uses to identify
the remote host replacing incoming packets to the identifier ip
and outgoing packets with the routing IP's. Keeping normal
behaviour, allowing multiple independent uplinks etc.

As for OSI:
7: Application
6: Presentation - we replace the IdentifierIP with the routing IP
5: Session      - 
4: Transport    - TCP/UDP
3: Network      - The IP protocol
2: Data link    - Ethernet/POS/ATM/DSL/*
1: Physical     - The cable or the air ;)

Presentation, as we 'present' the network to the application.
Just like it says :)

There generally explains my idea for my final thesis...

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 28 Aug 2003 19:05:19 +0200

On woensdag, aug 27, 2003, at 19:51 Europe/Amsterdam, Fred Templin 

> Wouldn't we all start deploying, e.g., HIP tomorrow if we had a 
> solution for this?

I'm not exactly current on what's happening with HIP but aren't there 
supposed to be working implementations today?

> And, how might that solution be any different than MIP HoA/CoA
> binding management?

One of the main mechanisms we're considering in the multi6 design team 
(or multi6 DT #1 I should say) is a distributed database that holds the 
mapping from identifier to a set of locators. For multihoming this 
makes a lot of sense as you know all your possible addresses in 
advance. With MIP this is different, but there you have the advantage 
that the home agent is (presumably) always available, while the point 
of multihoming is to survive failures.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 28 Aug 2003 19:32:23 +0200

On woensdag, aug 27, 2003, at 20:33 Europe/Amsterdam, Keith Moore wrote:

>> we need to move the FQDNs and especially IP addresses away from 
>> identifying hosts, and introduce and explicit host or "stack name" 
>> identifier.

> between IP and transport than to insert a layer underneath IP.

Not sure where you got the idea that I was talking about a layer 
underneath IP. The best way to do this would architecturally between 
transport and IP. It should be possible to implement this in such a way 
that both TCP and other transport and also IP remain unchanged, but I 
expect implementers to take advantage of the TCP state to make better 
rehoming decisions.

> part of

Unfortunately, it's not this simple. A single homed, fixed location 
host could be talking to another host that is multihomed and/or moving 
around. Both ends must implement something like this for it to work.

> IP addresses that they map to will change slightly.

There is no need to change FQDNs. But today we let an FQDN point to a 
bunch of hosts and then let the application take care of selecting the 
host it wants to talk to and what exactly it wants from the host. I can 
imagine a system where things like files in a peer to peer file sharing 
network or TV channels streamed from a network of streaming servers use 
a namespace particular to that application, with an 
application-specific lookup service to go with it. So I can type 
something like tv://cnn/ and the lookup service for the A/V streaming 
namespace returns the closest host that can stream the required 
content. Obviously we can do this today using our existing protocols 
and some glue here and there, but that way we don't get to take 
advantage of the special properties of A/V streaming, such as a 
carefully synchronized jump from one server to another in mid-stream so 
there is no interruption in the image or sound.

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 29 Aug 2003 15:06:32 +1200

-----BEGIN PGP SIGNED MESSAGE-----

- --On Thursday, August 28, 2003 07:05:19 PM +0200 Iljitsch van Beijnum 
<[email-masked]> wrote:

> On woensdag, aug 27, 2003, at 19:51 Europe/Amsterdam, Fred Templin wrote:
>

There are.  Four of them, in fact, but none are yet production quality.

If anyone wants to play or read some code, these are the available ones:

<http://gaijin.iki.fi/hipl/> Linux USAGI, IPv6 only

<http://www.hip4inter.net/index.shtml> NetBSD, dual stack

<http://www.sharemation.com/adm01bass/pyhip-2003-07-19.tar.bz2> Linux, 
Python in userspace (therefore needs no kernel IPSEC), dual stack

There are drafts about the various mappings, but no implementation yet.

There are also ideas around about how to transparently autodetect HIP 
support in the responder, with no a-priori knowledge.

The (new) hipsec mailing list is at 
<http://honor.trusecure.com/mailman/listinfo/hipsec>.

Andrew

---

From: S Woodside <[email-masked]>
Date: Fri, 29 Aug 2003 22:42:34 -0400

> won't solve any of today's or tomorrow's problems.

Well since a lot of people are still looking for a good reason to move 
to IPv6, and this might be one of them ...

simon

--
simonwoodside.com -- openict.net -- 99% Devil, 1% Angel