OK, now I'm clear on the terminology. Thanks.
In your modified example, where the Office/Home routers are all
connected to one LAN, there appear to be two different modes of
operation for the routers: the CPE routers, getting prefixes from
different ISPs, should ignore each others RAs and each should
advertise the prefix it receives from its ISP on the root LAN. The
Office/Home routers, on the other hand, should listen to each others
RAs and only one of those routers should advertise a prefix on the LAN
they are all attached to. Assuming all these routers are "plug-and-
play", I don't see how they identify their location in the network and
how they determine their appropriate mode of operation.
Similarly, how do the CPE routers identify themselves as such and
determine they should elect a single "ULA authority" that generates
and advertises a site ULA?
- Ralph
On Jan 14, 2010, at 1:39 PM 1/14/10, Fred Baker wrote:
On Jan 14, 2010, at 9:29 AM, Ralph Droms wrote:
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...
To me, a LAN is an instance of some lower layer networking
technology, such as an Ethernet or a WiFi; where a lawyer might have
defined it as a network that doesn't cross a legal boundary (for
which reason we don't call Frame Relay or ATM networks "LANs" but
rather "WANs"), RFC 872 defines it as
The second thing we need to know is somewhat less
straightforward: A LAN is, properly speaking [2], a
communications mechanism (or subnetwork) employing a transmission
technology suitable for relatively short distances (typically a
few kilometers) at relatively high bit-per-second rates
(typically greater than a few hundred kilobits per second) with
relatively low error rates, which exists primarily to enable
suitably attached computer systems (or "Hosts") to exchange bits,
and secondarily, though not necessarily, to allow terminals of
the teletypewriter and CRT classes to exchange bits with Hosts.
A subnet is a set of interfaces that are assigned IP addresses
within the same prefix and can communicate without the intervention
of an IP router; some are "broadcast" (all of the interfaces can
talk with each other) and some are non-broadcast (they use the same
lower layer network but may not all have direct connectivity to each
other). The first use of the term in the RFC series is in RFC 61,
and is used synonymously with "subnetwork" in many RFCs prior to RFC
1000. The term as we use it today, to refer to hierarchical
structure within a site prefix, probably derives from IEN 82 (1979),
which describes the MIT LCS Net Address Format, and in so doing
describes having "subnets" within the MIT campus that were not
separately advertised to the ARPANET, but advertised as a single
block network. It is commented on in a way more like a definition in
RFCs 891 and 898; 898 reports that
Postel: A description of the gateway implemented at MIT. The
gateway was first developed by Noel Chiappa. It is written in C.
The MIT environment has 32 internal networks which are treated as
subnets of the MITNET on the Internet. The MIT gateways then do
subnet routing in their interior protocol. The subnet routing
scheme is similar to GGP. Liza has added an EGP implementation
to
this gateway.
Jeff Mogul and others generalized that in RFCs 917, 922, 932, 936,
940, and 950, and it finally got defined in a form we would
recognize today in RFCs 1122, 1123, and 1812.
I think the term "subnet" is well understood in our context.
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.
I think the CPE Router Design Team agrees with that statement.
They're asking whether 6man agrees with it.
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.
That is probably true. My question is: which interface should those
prefixes be assigned to?
/-------+-/ /
prefix:2| |
+---+--+ |
|Office| |
|RTR 1 +--+ --
+---+--+ | +-------+ /
prefix:3| | |CPE RTR| |
/-------+-/ +--+ISP 1 +------ ISP 1
| +-------+ |
/-------+-/ |p \
prefix:4| |r --
+---+--+ |e
|Office| |f
|RTR 2 +--+i
+---+--+ |x
prefix:5| |: --
/-------+-/ |0 +-------+ /
| |CPE RTR| |
/-------+-/ +--+ISP 2 +------ ISP 2
prefix:6| | +-------+ |
+---+--+ | \
|Home | | --
|RTR +--+
+---+--+ |
prefix:7| |
/-------+-/ /
Figure 3: Complex SOHO
In this diagram, the network is conveniently tree-structured. Let me
throw a ringer in here; the even numbered subnets are discovered to
be WiFi using the same SSID, so that the picture really looks like:
/ /
| |
|prefix:2 +------+ |
+---------|Office| |
| |RTR 1 +--+ --
| +---+--+ | +-------+ /
| prefix:3| | |CPE RTR| |
| /-------+-/ +--+ISP 1 +------ ISP 1
| | +-------+ |
| |p \
| |r --
|prefix:4 +------+ |e
+---------|Office| |f
| |RTR 2 +--+i
| +---+--+ |x
| prefix:5| |: --
| /-------+-/ |0 +-------+ /
| | |CPE RTR| |
| +--+ISP 2 +------ ISP 2
| | +-------+ |
|prefix:6 +------+ | \
+---------|Home | | --
| |RTR +--+
| +---+--+ |
| prefix:7| |
| /-------+-/ /
/
Figure 3++: Incredibly Complex SOHO
You note that the same LAN now has three prefixes on it - and not
just three, but three subnets of the common ULA, three subnets of
ISP#1's prefix, and three subnets of ISP#2's prefix. I submit that
this might just possibly be overkill, but there is no way apart from
configuration for the CPE RTR's to discern that.
I submit that therefore DHCP can't solve that, at least at the level
of technology as it exists today. However, OR#1, OR#2, and HR can
hear each other asserting RAs on it, and can sort it out among
themselves.
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.
Understood. I submit that we have enough mechanism to achieve that
if we use it creatively.
- 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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
http://www.ipinc.net/IPv4.GIF
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
