-----BEGIN PGP SIGNED MESSAGE-----
Tony Hain [mailto:alh-ietf(_at_)tndh(_dot_)net] wrote:
<SNIP similar part>
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.
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
-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen(_at_)unfix(_dot_)org / http://unfix.org/~jeroen/
iQA/AwUBP00IUimqKFIzPnwjEQK6VgCePkHsQiI+krZ007PnEJk91h/zSCQAnRra
nLyfNiqSwQ9BrVNOWEqSG5wa
=sGa+
-----END PGP SIGNATURE-----