below...
Andrew White wrote:
>
> 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).
Agreed. It would be rather tragic to define a new form of address to meet
the requirements in this draft, and another very similar new form of address
to meet multihoming requirements. It should be a goal to avoid this, and it
needs to be a shared goal of the ipv6 and multi6 WGs.
So I don't think it's possible to eliminate mention of multihoming from
this draft, but it should be mentioned mainly for this reason.
Brian C
>
> 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
> --------------------------------------------------------------------
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
