Re: Host-based may be the way to go, but network controls areneccessary

["Craig A. Huegen" <chuegen@cisco.com>]

On Tue, 19 Nov 2002, Shane Kerr wrote:

> Perhaps it is best to identify three categories of operator:
>
> 1. Large network operators
> These people can get IP space and AS from their RIR, and advertise
> into the DFZ, as in IPv4 today.

ARIN's IPv6 policy (which is almost globally equivalent to the rest of
the RIR's, right?), states:

---
5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an
organization must:

a) be an LIR;

b) not be an end site;

c) plan to provide IPv6 connectivity to organizations to which it will
assign /48s, by advertising that connectivity through its single
aggregated address allocation; and

d) have a plan for making at least 200 /48 assignments to other
organizations within two years.
---

This policy disqualifies large enterprises based on b).

The bootstrap criteria allowed some end-users who deploy IPv6 to get
address space.  I'm hoping that we can come up with a multihoming method
that would cover the large enterprise networks as well as the larger of
the "in-betweens" you mentioned, such that the allocated space to
end-users could be given back.

I concur with you that host-based multihoming may be sufficient for a
class of smaller networks, like homes and small businesses.

Also, remember that large enterprise networks generally do not announce
their entire address space from every Internet attachment point.  This
essentially turns each region served by a particular Internet attachment
point into a "site".  If we went into particulars, I know this one large
enterprise network that has 5 "major" Internet attachment points (for
general access and services) globally, and a handful of "minor" Internet
attachment points (for VPN only).  Should that enterprise then get 5 /32's
for the major points, and use host-based multihoming for the minor points?
Or, should the enterprise get a single /32, but announce (and have
accepted through a recommendation from this WG supporting it) /36's into
the DFZ?  Either way, that's 5 routes in the DFZ for this network.

> Which category is this group trying to help?  If it is #1, then we're
> done.  If it is #2, then I think we have a good start.  If it is #3,
> then there is basically MHAP.  I think for the long-term support of
> category #3 we need real routing changes, perhaps BGP won't do it.
>
> If we can agree on this breakdown perhaps we can move forward by
> identify the needs of each.

I hope the group is trying to address all three sizes you mention.  Size
isn't the only factor, though -- I can envision a small site that needs
greater policy control than allowing the end-host to pick the closest
matching source/dest addresses.

/cah

---
Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
IT Transport, Network Technology & Design           ||        ||
Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
San Jose, CA  95134, (408) 526-8104                ||||      ||||
email: chuegen@cisco.com       CCIE #2100      ..:||||||:..:||||||:..