Fred - your figure three and your e-mail describes the general case.
I'm a little confused by your use of the terms "LAN" and "subnet". A
couple of questions come to mind...
A ULA for the site network is a special case, because (ideally, I
think), one CPE RTR (terminology from figure 3) needs to generate the
ULA for the site network. If there is more than one CPE RTR, care
must be taken to generate one ULA for the site and to keep that ULA
consistent (as much as possible) over time.
Let me try to write out your three configuration scenarios in more
detail.
On the "root" link in figure 3 ("prefix:0"), if there are three
prefixes for the site network, say, ISP1::/48, ISP2::/48 and ULA::/48,
then that root link would be assigned ISP1:0::/64 (pls give me
suspension of disbelief for notation here), ISP2:0::/64 and ULA:
0::/64. Further suppose "CPE RTR ISP 1" has been in some way
designated as the ULA source for the site network. Each of the
routers presumably needs an address from each of the three prefixes on
its interface to the root link. As you wrote, those addresses could
be provided through manual assignment, DHCP or RS/RA/SLAAC:
* manual - all interfaces are assigned manually
* DHCP
- CPE RTR ISP 1 assigns an address from ISP1:0::/64 and ULA:0::/64 to
its interface and acts as a DHCP server for ISP1:0::/64 and ULA:
0::/64
- CPE RTR ISP 2 assigns an address from ISP2:0::/64 to its interface
and acts as a DHCP server for ISP2:0::/64
- the CPE RTRs and the Office RTRs all perform DHCP on the root link;
CPE RTR ISP 2 and the Office RTRs receive addresses from ISP1:0::/64
and from ULA:0::/64 from CPE RTR ISP 1; CPE RTR ISP 1 and the Office
RTRs receive an address from ISP2:0::/64 from CPE RTR ISP 2
* RS/RA/SLAAC
- CPE RTR ISP 1 assigns an address from ISP1:0::/64 and ULA:0::/64 to
its interface; acts as a DHCP server for ISP1:0::/64 and ULA:0::/64;
sends RAs advertising and specifying SLAAC on ISP1:0::/64 and ULA:
0::/64
- CPE RTR ISP 2 assigns an address from ISP2:0::/64 to its interface;
acts as a DHCP server for ISP2:0::/64; sends RAs advertising and
specifying SLAAC on ISP2:0::/64
- the CPE RTRs and the Office RTRs all receive RAs on the root link;
they each
use SLAAC to assign addresses from the advertised prefixes
The only way I know to get the prefixes for the links labeled "prefix:
[234567]" in figure 3 is through DHCP-PD. In this case, CPE RTR ISP 1
acts as a DHCP-PD server for ISP1:0::/64 and ULA:0::/64 and CPE RTR
ISP 2 acts as a DHCP-PD server for ISP2:0::/64. The Office RTRs will
receive delegated prefixes from both CPE RTRs and configure each of
those "downstream" links with, e.g., ISP1:2::/64, ISP2:2::/64 and ULA:
2::/64. Note that I don't think RFC 3633 (DHCP-PD) allows for
interaction with multiple DHCP-PD servers, so this scenario needs some
extensions to RFC 3633.
Getting back to the ULA issue, if there is to be just one ULA, then
the CPE RTRs have to elect a ULA source and have a mechanism for ULA
persistence in case the ULA source fails. I suppose multiple ULAs in
the site network would avoid the election and persistence issues at
the cost of extra prefixes and complexity?
The various routers need some way to know which role they are playing
and which configuration mechanism to use. There also may be a need to
exchange routing/forwarding information about the routers.
- Ralph
On Jan 13, 2010, at 1:36 PM 1/13/10, Fred Baker wrote:
stepping away from ULAs, I should think the point is to propagate
routing configuration information throughout a small zero-config
network. The several routers on a given LAN want to be in the same
subnet; if there are several subnets on the same LAN, with the
possible exception of DMZ routers to specific ISPs, they want to
each be in all of them. ULA management is special case of this.
Going back to the figure I referenced (figure 3 of http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation)
, you have a single LAN with five routers on it, plus LANs beyond
three of those. Two of the routers connect to ISPs and presumably
get prefixes delegated to them by those ISPs. In addition, to cover
the case in which one has no connectivity to either ISP (and
therefore no prefix lease from them), one needs a ULA. So in this
network, thee is a need for three prefixes, two of which are global,
plus link-local addressing. On each LAN, apart from local policy
that might have one of the offices using one ISP and the other using
the other ISP or some such thing, you want an IP subnet from each of
those prefixes, and you want all of the routers on the LAN in each
subnet, with the possible exception of the two ISP-facing routers
being in each other's delegated prefixes.
This can be accomplished by manual configuration, by a DHCP option
that to my knowledge is not currently defined, or by listening to
each other's RAs as I suggested. How would you suggest achieving it?
As to what to do when one loses connectivity to the critical router,
and again considering such a network, there are some interesting
issues. I tend to think the best bet is to use some form of lease
concept rather than making the prefix suddenly go away throughout,
but can be argued into other positions.
On Jan 13, 2010, at 2:27 AM, Wojciech Dec (wdec) wrote:
Perhaps a basic question or two: What is the purpose of the ULA being
advertised on the shared segment, and is the intent for the "2nd
router"
to auto-config itself an address in the ULA space and begin
advertising
that ULA too?
http://www.ipinc.net/IPv4.GIF
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
