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

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

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: "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: "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