Prefix Sub-delegation in a SOHO/SMB
EnvironmentCisco SystemsSanta Barbara93117CaliforniaUSAfred@cisco.com
Internet
IPv6 MaintenanceThis memo considers the question of IPv6 prefix sub-delegation.In the IPv6 Operations Working Group and the Homegate BOF, there have
been questions raised about IPv6 Prefix Sub-delegation. In short, the
CPE Router documents would like to require an algorithm for
sub-delegation, and the indicated document does not exist. This note is
intended to raise the question to the IPv6 Maintenance Working
Group.By IPv6 Prefix Sub-delegation, we refer to the issue that an upstream
provider delegates a prefix to a downstream network such as a home or
small business, which is turn allocates prefixes to LANs and other
structures within its domain. The means of delegation to the SOHO/SMB is
not really important here, although we note that DHCP has a tool for the purpose. In general, this is
presumed to apply to networks using IPv6
and using addressing conforming to the IPv6
Addressing Architecture.There are several special cases that are relatively easily solved,
and more complex cases that can be solved by divide-and-conquer methods.
The most general case, that of assigning subnet numbers throughout an
arbitrary complex topology, may be beyond algorithmic description. Here
we walk through some of the simpler cases.The simplest residential case, that of , is that of an apartment or single family
dwelling whose upstream provider delegates a single /64 to it. Such a
SOHO probably has multiple internal LANs (wired and wireless), and
uses a single residential CPE router. In this case, there are few
choices. As described in passing in in
that a prefix can be assigned to a "set of interfaces", the CPE Router
uses the delegated prefix on all of its non-upstream interfaces, and
tracks the location of various devices on its LANs.For external routing, it assigns a single default route to its
upstream router.There are some complexities in this architecture, as it doesn't
scale well to add even a second router. While a single CPE router can
track the addresses allocated by other devices, it will be forced to
proxy for them in Neighbor Discovery; it
will respond to a Neighbor Solicitation for a device on another
interface, including a device using a link-local address. This will
create issues in Secure Neighbor
Discovery, in that it will not have the private key of the
device it is proxying for. However, it can enable the connection of
devices on its various LANs by this means. Vendor implementations may
well choose to implement this using IEEE 802.1 technology for
simplicity, to make it appear to be one interface to the software.For this reason if no other, although both it and talk about prefixes being assigned to
"interfaces or sets of interfaces",
states that Currently, IPv6 continues the IPv4 model in that a subnet
prefix is associated with one link. Multiple subnet prefixes may
be assigned to the same link.The preferred architecture in the residential case, that of , has the upstream provider delegate a longer
prefix such as a /60, /56, or /48 to it. As in , a SOHO often has multiple internal wired and
wireless LANs, and often uses a single residential CPE router. The CPE
router can, however, unambiguously sub-delegate /64 prefixes to its
interfaces from the prefix delegated to it. This will facilitate
future extensions of the network which may require other routers.This configuration also simplifies Neighbor
Discovery and Secure Neighbor
Discovery, in that there is no question of the CPE Router
proxying for other devices. For external routing, as in , the CPE assigns a single default route to its
upstream router.A more complex case might be found in a residential network that is
multihomed (has multiple upstream providers) and has multiple zoned
LANs within the home. A couple might, for example, work for different
employers who require them to maintain separate and secure LANs for
their offices and who keep a common network for their home. In this
case, the SOHO has the equivalent of two corporate networks and one
common network, each comprised of some number of wired and wireless
LANs, connected via the couple's multihomed upstream networks. This is
shown in .The network in remains conceptually
simple in that it is a simple tree; the two office routers and the
home router can query the CPE Routers for sub-delegated prefixes from
their upstream networks without ambiguity. It becomes more complex if
there are additional routers further to the left in the diagram, or if
there exist LANs between interior routers turning the network into a
general graph.To handle a case such as this, the simplest approach will be to
manually configure the CPE routers to further sub-delegate prefixes
(via DHCP?), perhaps /60s from an upstream's /56, turning this into a
collection of cases more similar to that of . If the network contains internal complexities
beyond a simple tree structure, there may be a need for disambiguating
rules about which router's delegation from the CPE has precedence.Routing in such an environment calls for a routing protocol such as
RIPv6,
IS-IS, or
OSPF.
In addition, each CPE router will need to install a static default
route upstream and advertise a default route in the chosen routing
protocol. The issues raised in also
apply, meaning that the two CPE routers may each need to observe the
source addresses in datagrams they handle to divert them to the other
CPE to handle upstream ingress filtering issues.If the IETF were to build a generalized tool for enumerating subnets
in a domain, it needs to meet at least the following requirements:It needs to work with IPv6 prefixes of any type and length that
might be delegated by an ISP (PA), by an RIR (PI), or as a ULA.It needs to be able to identify or have identified to it enclaves
of interest. These may be as simple as a set of subnets that
comprise an internal administrative zone, or might more generally be
campuses.It needs to be able to enumerate enclaves of interest in a manner
that enhances aggregation - assign the longest prefix possible that
can be subdivided into the needed /64s.It needs to be able to configure one or more preferred aggregate
prefix lengths; for example, if there are /59, /62, and /57
sub-domains within a network, the administration may prefer to
allocate /56 prefixes to each of them.It needs to be able to draw its site prefix or prefixes from an
ISP or other source.The algorithm should work readily with arbitrarily complex
networks of any size consistent with RIR, NIR, or LIR allocation
practice (e.g., /60, /56, or /48 prefixes).This memo asks the IANA for no new parameters.Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author"s perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor"s discretion.There are no new security concerns with the approaches suggested in
this memo beyond those analogous to neighbor discovery or other subnet
delegation approaches. There are, however, clear concerns with
complexity in the absence of a defined sub-delegation architecture in
the more general cases.Input resulting in this came from Wes Beebee, James Woodyatt,
Iljitsch van Beijnum, and Barbara Stark. The documents suggesting a need
for sub-delegation of prefixes are and .