[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt



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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------