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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
http://www.ipinc.net/IPv4.GIF
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
