Message-Id: <9501111901.AA28426@caraway.lcs.mit.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng) A thought on addressing From: David Clark Date: Wed, 11 Jan 1995 11:01:09 -0800 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reply-To: ipng@sunroof.eng.sun.com Folks, This is a comment on how addresses might be used in IPv6. Perhaps there is a more addressing-specific mailing list that might be a better place to start an addressing debate, but... The problem I want to deal with is the continuing concern with provider based addresses, which seem to lock subscribers into a particular provider, unless we implement highly dynamic address reassignment. The ways out of this box (dynamic reassignment or geographical addressing) each seem to have their own perils. I feel we need a different approach. I want to offer one for consideration. Doing so takes us down a path with certain different forms of difficulty and tastelessness, but with advantages as well, so hold on. (BTW, I believe that I am not the first person to propose this idea, but I cannot sort out who else has proposed it. So if its your idea, I know I heard it somewhere; I just cannot remember where.) While the IPv6 address field has an unconstrained format, I note that in fact, for many uses of that field, it is moving towards a fixed two part structure, with a provider and subscriber part. Lets take advantage of that, and architect it (for certain address prefixes, perhaps.) Let's divide the address into the "UID" part, like the 48 bit thing, and the "prefix". The prefix would identify the provider, and the provider's name for the subscriber, and so on. The rule I want to propose is that the prefix can be rewritten in a packet during its transit in the net; both the source and destination prefix. A subscriber would be issued a prefix for internal use, probably unique but not generally routable. At the edge of the subscriber region (at a "subscriber boundary point"), an outgoing packet is rewritten to have its source prefix replaced by the prefix routable by the provider attached to that point. How would the destination prefix be filled in? If this packet is being sent in reply to an arriving packet, the destination address is just the source in the incoming packet, which the foreign subscriber modified at its boundary point to indicate the preferred provider prefix for that subscriber. If this outgoing packet originates the communication, the destination comes from a DNS lookup. The destination subscriber would provide a DNS server that returns addresses with the preferred (routable) prefix. What does this approach buy us? o Provider independence -- when a subscriber moves from one provider to another, the only change is to adjust the prefix inserted by the DNS and the subscriber boundary point. This approach provides an easy form of dynamic address reassignment, with no requirements for topological limitations. o Multi-homed subscribers -- a subscriber can now be multi-homed with no support in individual host software, and no inefficient use of provider address space. The boundary point just inserts the correct prefix for the provider being used for these packets. o Control of incoming provider -- a multi-homed subscriber can, as described above, control what provider is used for outgoing connections. But by returning different prefixes in response to different DNS lookups, it can also control which provider is used for a connection originated at the other end. o Mobile hosts -- while I have not thought about it much, this ability to rewrite the prefix should make it possible to route packets to a mobile host. All these are powerful advantages. Here are some additional thoughts. First, any host should be able to be a subscriber boundary point. While a host deep inside a subscriber network will not need this ability, it should be part of the base IPv6 implementation. The feature would be used in a number of situations. Running PPP, dynamic address assignment would imply setting the prefix to the correct current value. When mobile, a similar event would occur. In general, setting the prefix would arise as a interchange between the IPv6 code, a user interface, and the network device driver. Second, this approach gives the subscriber a means to enter into complex pricing deal with providers, and select among them. Different prefixes can be bound to different charging agreements, such as "collect connections". There would arise a market in sophisticated DNS servers that would return different prefixes in different circumtances, to control how distant hosts would send to a subscriber. Sophisticated subscribers will demand such capabilites, and the packet headers have to able to express them, without the ugly option of opening connections underneath to select the desired service. Third, not all addresses need look like this. There could be address forms (selected by their first byte) that do not have the prefix/UID boundary, and are not rewritable. TCP (and other protocols) would have to compute a pseudo-header based only on the unique part of the address. If this part were not really unique, a failure could occur in unusual circumstances. I believe that this problem is not a real one. A distasteful issue is that if not all addresses have this form, then TCP might need to compute pseudo-headers across different parts of the address in different cases. People with long memories will recognize that we have been here before... The major drawback to this schem is that the boundary between the prefix and the UID gets frozen which restricts the use of the address field. While this is a valid point, the address field is so big, perhaps it does not really matter. So here is the marketing slogan for IPv6: "Use IPv6 -- it makes NAT boxes work." (The last line was the joke, the rest of the message was the serious point. Think about the problems this approach solves, and think how else we can solve them.) Dave ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com