-----BEGIN PGP SIGNED MESSAGE----- Tony Hain [mailto:alh-ietf@tndh.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@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP00IUimqKFIzPnwjEQK6VgCePkHsQiI+krZ007PnEJk91h/zSCQAnRra nLyfNiqSwQ9BrVNOWEqSG5wa =sGa+ -----END PGP SIGNATURE-----