As the originator of section 4.8, I'll speak to this one... Fred Templin wrote: > > > 4.8 I'm afraid I couldn't understand this scenario at all. When the > > two sites connect, do they essentially merge into a single, > > multi-homed site? > > I believe the answer to this is yes, and I believe Brian Haberman > also expressed concerns about such scenarios since they touch on > site multi-homing. (My answer to Brian is that we are not trying > to re-create RFC 3582 in this document.) What you would suggest > in terms of this block of text?
I don't think it's possible to completely divorce local addressing from multi-homing, unless we want to go down the NAT path (any takers? No, I thought not). One local addressing model that both Tony and I have been envisioning (and IMO the most compelling) is that of disjoint, overlapping addressing spaces. The local network uses an internal addressing scheme for all internal operations. When and if 'external' connectivity is applied (which may be another 'local' network) the external space is also made available to all nodes within the network that want external operation. Local nodes are configured to prefer the internal addresses for internal use and the global addresses for destinations that don't have a matching internal address. Note that the 'internal' addresses could be global unicast addresses or 'local' addresses. Likewise the 'external' addresses, although these will probably be global. The key issue is that the 'internal' addresses are provider independent. The core address space of the network is independent of the presence or absence of an ISP. For the 'zeroconf home' scenario, registration-free local addresses become very attractive for the internal address space. They don't need to care about ISPs or any external stuff, and unique address spaces can be easily configured. And a RFC3484 implementation will favour them over global addresses. Connecting two of these networks together is interesting. The assumption is that the connection is via a 'local' channel - one that is (virtually) 'inside' whatever mechanisms define the borders between the local address spaces and the global space. However, what sort of 'merging' occurs is harder to determine. Some scenarios: (1) Minimal merging: The two 'local' networks talk via a pair of gateways, and all traffic for the other network's address space/s is directed to that network's gateway. DNS and like services are similarly redirected. (2) Routing table merging: Full routing information is passed across the two networks. Addresses are allocated independently by each network. (3) Full merging: The two networks become one network, sharing prefixes originally owned by one or the other network across all nodes. Option 1 is probably easiest. Local addresses provide an advantage here again, in that if both networks are using local addresses RFC3484 will cause inter-network communications to favour the local addresses. The most interesting case in network merging occurs when the local addresses are allocated by the routers, using the strategy described in 'draft-white-auto-subnet-00' (<ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-white-auto-subnet-00.txt>). >From an address allocation perspective, only 'external' prefixes are propagated - the internal addressing scheme is built into the routers. Under this model, there is no need to propagate the internal prefixes - the address spaces are already compatible. All that is required is to connect the routes and propagate service information (such as DNS). External prefixes still need to be propagated. -- Andrew White -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
