> -----Original Message----- > From: Fred Baker (fred) > Sent: 14 January 2010 00:37 > To: Wojciech Dec (wdec) > Cc: Ole Troan; ipv6@ietf.org > Subject: Re: Question: Detecting routers on a link > > 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
There are a couple of aspects here in my opinion: 1. We seem to be trying to find a solution to the automated-coordination of prefix assignment in a multi router network. This is a worthy goal, but discussing it in the context of RA with PIO suppression to me at least means that we're only looking at part of a solution, with other parts like DHCP or some other method not covered. 2. Figure 3 describes a scenario with no directly attached hosts. Advertising in RAs any PIO (ULA or other) from the two CPE RTRs would make sense if the intent was for them to auto-address the routers themselves, which I think would be of some value in this figure in terms of users being able to reach these devices. However I don't quite see why the number of ULAs actually matters much. 3. If we want to cast the problem in terms of trying to coordinate the whole customer site to use the same ULA (eg same global-id across the sire), then this requires some other means beyond RA suppression for getting the downstream customer routers to also advertise the correct ULA and suppress their own. Short of inventing RA delegation, going with what's already defined (eg DHCP PD) it would make sense to have the non-suppressed router set itself up as a DHCP DR with the ULA. So, to put my original question differently: What is the intent of suppressing a router from sending out an RA with a ULA in the presence of another router advertising a ULA? This would appear to be very specific to ULAs as it's clear that any ISP delegated prefixes are more or less always meant to make their way to address the end-hosts, but for ULAs (as in figure 3) that's not necessarily the case. -Woj. > 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 --------------------------------------------------------------------
