[30962] in North American Network Operators' Group
FW: (ngtrans) IAB/IESG Recommendations on IPv6 Address Delegation
daemon@ATHENA.MIT.EDU (Gregory Soo)
Sat Sep 2 17:51:20 2000
Message-ID: <456E6DB7180ED3118A670000F8BDCA290233D0E5@zcard00p.ca.nortel.com>
From: "Gregory Soo" <gsoo@nortelnetworks.com>
To: nanog@merit.edu
Date: Sat, 2 Sep 2000 17:49:13 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C01527.A2146F90"
Errors-To: owner-nanog-outgoing@merit.edu
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C01527.A2146F90
Content-Type: text/plain;
charset="iso-8859-1"
-----Original Message-----
From: Steve Deering [SMTP:deering@cisco.com]
Sent: Friday, September 01, 2000 7:02 PM
To: ipng@sunroof.eng.sun.com
Cc: ngtrans@sunroof.eng.sun.com; Bob Hinden
Subject: (ngtrans) Fwd: IAB/IESG Recommendations on IPv6 Address Delegation
Appended below is the message that was sent today to the RIRs from the IAB
and IESG, regarding IPv6 address allocation policy. It contains most of the
material that was in the draft I forwarded here on Sunday, but reorganized
into a more coherent document.
Steve
>-----Original Message-----
>Date: Fri, 01 Sep 2000 12:40:48 -0700
>To: lir-wg@ripe.net (RIPE), policy@arin.net (ARIN),
> apnic-talk@apnic.net (APNIC)
>From: Fred Baker <chair@ietf.org>
>Subject:IAB/IESG Recommendations on IPv6 Address Delegation
>Cc: ipv6-directorate@sunroof.eng.sun.com, iesg@ietf.org, iab@ISI.EDU,
> ipv6-wg@ripe.net (RIPE), sig-ipv6@lists.apnic.net (APNIC)
>
>Folks:
>
>The RIR community asked the IETF community for advice regarding the
>assignment of IPv6 prefixes to service providers and edge networks, both
>with a view to topological address assignment and to multihomed networks.
>The IPv6 Directorate prepared a statement, which the IESG and IAB have
>reviewed and approved. This is attached.
>
>I trust that this answers the questions you asked, and serves as a basis
for
>IPv6 deployment in the near term. If you have questions or issues
concerning
>it, I would suggest that you address them to the IPv6 Directorate copying
>the IESG and IAB.
>
>We intend to publish an Informational RFC in the near future documenting
the
>contents of this note.
>
>Fred Baker
>
>-----------------------------------------------------------------------
>
> IAB/IESG Recommendations on IPv6 Address Allocations
> September 1, 2000
>
>Introduction
>
>During a discussion between IETF and RIR experts at the Adelaide IETF,
>a suggestion was made that it might be appropriate to allocate /56
>prefixes instead of /48 for homes and small businesses. However,
>subsequent analysis has revealed significant advantages in using /48
>uniformly. This note is an update following further discussions at
>the Pittsburgh IETF.
>
>This document was developed by the IPv6 Directorate, IAB and IESG, and
>is a recommendation from the IAB and IESG to the RIRs.
>
>Background
>
>The technical principles that apply to address allocation seek to
>balance healthy conservation practices and wisdom with a certain ease
>of access. On the one hand, when managing the use of a potentially
>limited resource, one must conserve wisely to prevent exhaustion
>within an expected lifetime. On the other hand, the IPv6 address
>space is in no sense as precious a resource as the IPv4 address space,
>and unwarranted conservatism acts as a disincentive in a marketplace
>already dampened by other factors. So from a market development
>perspective, we would like to see it be very easy for a user or an ISP
>to obtain as many IPv6 addresses as they really need without a
>prospect of immediate renumbering or of scaling inefficiencies.
>
>The IETF makes no comment on business issues or relationships.
>However, in general, we observe that technical delegation policy can
>have strong business impacts. A strong requirement of the address
>delegation plan is that it not be predicated on or unduly bias
>business relationships or models.
>
>The IPv6 address, as currently defined, consists of 64 bits of
>"network number" and 64 bits of "host number". The technical reasons
>for this are several. The requirements for IPv6 agreed to in 1993
>included a plan to be able to address approximately 2^40 networks and
>2^50 hosts; the 64/64 split effectively accomplishes this. Procedures
>used in host address assignment, such as the router advertisement of a
>network's prefix to hosts [RFC 2462], which in turn place a locally
>unique number in the host portion, depend on this split. Examples of
>obvious choices of host number (IEEE Mac Address, E.164 number, E.214
>IMSI, etc) suggest that no assumption should be made that bits may be
>stolen from that range for subnet numbering; current generation MAC
>layers and E.164 numbers specify up to 64 bit objects. Therefore,
>subnet numbers must be assumed to come from the network part. This is
>not to preclude routing protocols such as IS-IS level 1 (intra-area)
>routing, which routes individual host addresses, but says that it may
>not be depended upon in the world outside that zone.
>
>The IETF has also gone to a great deal of effort to minimize the
>impacts of network renumbering. None-the-less, renumbering of IPv6
>networks is neither invisible nor completely painless. Therefore,
>renumbering should be considered an acceptable event, but to be
>avoided if reasonably avoidable.
>
>The IETF's IPNG working group has recommended that the address block
>given to a single edge network which may be recursively subnetted be a
>
>48 bit prefix. This gives each such network 2^16 subnet numbers to
>use in routing, and a very large number of unique host numbers within
>each network. This is deemed to be large enough for most enterprises,
>and to leave plenty of room for delegation of address blocks to
>aggregating entities.
>
>It is not obvious, however, that all edge networks are likely to be
>recursively subnetted; an individual PC in a home, or a single cell in
>a mobile telephone network, for example, may or may not be further
>subnetted (depending whether they are acting as, e.g., gateways to
>personal, home, or vehicular networks). When a network number is
>delegated to a place that will not require subnetting, therefore, it
>might be acceptable for an ISP to give a single 64 bit prefix -
>perhaps shared among the dial-in connections to the same ISP router.
>However this decision may be taken in the knowledge that there is
>objectively no shortage of /48s, and the expectation that personal,
>home and vehicle networks will become the norm. Indeed, it is widely
>expected that all IPv6 subscribers, whether domestic (homes), mobile
>(vehicles or individuals), or enterprises of any size, will eventually
>possess multiple always-on hosts, at least one subnet with the
>potential for additional subnetting, and therefore some internal
>routing capability. Note that in the mobile environment, the device
>connecting a mobile site to the network may in fact be a third
>generation cellular telephone. In other words the subscriber
>allocation unit is not always a host; it is always potentially a site.
>
>Address Delegation Recommendations
>
>The RIR communities, with the IAB, have determined that reasonable
>address prefixes delegated to service providers for initial
>allocations should be on the order of 29 to 35 bits in length, giving
>individual delegations support for 2^13 (8K) to 2^19 (512K) subscriber
>networks. Allocations are to be given in a manner such that an
>initial prefix may be subsumed by subsequent larger allocations
>without forcing existing subscriber networks to renumber. We concur
>that this meets the technical requirement for manageable and scalable
>backbone routing while simultaneously allowing for managed growth of
>individual delegations.
>
>The same type of rule could be used in the allocation of addresses in
>edge networks; if there is doubt whether an edge network will in turn
>be subnetted, the edge network might be encouraged to allocate the
>first 64 bit prefix out of a block of 8..256, preserving room for
>growth of that allocation without renumbering up to a point. However,
>for the reasons described below, we recommend use of a fixed boundary
>at /48 for all subscribers except the very largest (who could receive
>multiple /48's), and those clearly transient or otherwise have no
>interest in subnetting (who could receive a /64). Note that there
>seems to be little benefit in not giving a /48 if future growth is
>anticipated. In the following, we give the arguments for a uniform
>use of /48 and then demonstrate that it is entirely compatible with
>responsible stewardship of the total IPv6 address space.
>
>The arguments for the fixed boundary are:
>
> - only by having an ISP-independent boundary can we guarantee that a
> change of ISP will not require a costly internal restructuring or
> consolidation of subnets.
>
> - to enable straightforward site renumbering, i.e., when a site
> renumbers from one prefix to another, the whole process, including
> parallel running of the two prefixes, would be greatly complicated
> if the prefixes had different lengths (depending of course on the
> size and complexity of the site).
>
> - there are various possible approaches to multihoming for IPv6
> sites, including the techniques already used for IPv4 multihoming.
> The main open issue is finding solutions that scale massively
> without unduly damaging route aggregation and/or optimal route
> selection. Much more work remains to be done in this area, but it
> seems likely that several approaches will be deployed in practice,
> each with their own advantages and disadvantages. Some (but not
> all) will work better with a fixed prefix boundary. (Multihoming
> is discussed in more detail below.)
>
> - to allow easy growth of the subscribers' networks-no need to
> keep going back to ISPs for more space (except for that relatively
> small number of subscribers for which a /48 is not enough).
>
> - remove the burden from the ISPs and registries of judging sites'
> needs for address space, unless the site requests more space than a
> /48, with several advantages:
>
> - ISPs no longer need to ask for details of their customers'
> network architecture and growth plans
> - ISPs and registries no longer have to judge rates of address
> consumption by customer type
> - registry operations will be made more efficient by reducing the
> need for evaluations and judgements
> - address space will no longer be a precious resource for
> customers, removing the major incentive for subscribers to
> install v6/v6 NATs, which would defeat the ability of IPv6 to
> restore address transparency.
>
> - to allow the site to maintain a single reverse-DNS zone covering
> all prefixes.
>
> - If and only if a site can use the same subnetting structure under
> each of its prefixes, then it can use the same zone file for the
> address-to-name mapping of all of them. And, using the
> conventions of RFC 2874, it can roll the reverse mapping data
> into the "forward" (name-keyed) zone.
>
>Specific advantages of the fixed boundary being at /48 include
>
> - to leave open the technical option of retro-fitting the GSE
> (Global, Site and End-System Designator, a.k.a "8+8") proposal for
> separating locators and identifiers, which assumes a fixed boundary
> between global and site addressing at /48. Although the GSE
> technique was deferred a couple of years ago, it still has strong
> proponents. Also, the IRTF Namespace Research Group is actively
> looking into topics closely related to GSE. It is still possible
> that GSE or a derivative of GSE will be used with IPv6 in the
> future.
>
> - since the site local prefix is fec0::/48, global site prefixes of
> /48 will allow sites to easily maintain a simple 1 to 1 mapping
> between the global topology and the site local topology in the SLA
> field.
>
> - similarly, if the 6to4 proposal is standardized, migration from a
> 6to4 prefix, which is /48 by construction, to a native IPv6 prefix
> will be simplified if the native prefix is /48.
>
>Note that none of these reasons imply an expectation that homes,
>vehicles, etc. will intrinsically require 16 bits of subnet space.
>
>Conservation of Address Space
>
>The question naturally arises whether giving a /48 to every subscriber
>represents a profligate waste of address space. Objective analysis
>shows that this is not the case. A /48 prefix under the Aggregatable
>Global Unicast Address (TLA) format prefix actually contains 45
>variable bits, i.e., the number of available prefixes is 2**45 or about
>35 trillion (35,184,372,088,832). If we take the limiting case of
>assigning one prefix per human, then the utilization of the TLA space
>appears to be limited to approximately 0.03% on reasonable
>assumptions.
>
>More precisely,
>
> - RFC 1715 defines an "H ratio" based on experience in address space
> assignment in various networks. Applied to a 45 bit address space,
> and projecting a world population of 10.7 billion by 2050 (see
> http://www.popin.org/pop1998/), the required assignment efficiency
> is log_10(1.07*10^10) / 45 = 0.22. This is less than the
> efficiencies of telephone numbers and DECnetIV or IPv4 addresses
> shown in RFC 1715, i.e., gives no grounds for concern.
>
> - We are highly confident in the validity of this analysis, based on
> experience with IPv4 and several other address spaces, and on
> extremely ambitious scaling goals for the Internet amounting to an
> 80 bit address space *per person*. Even so, being acutely aware of
> the history of under-estimating demand, we have reserved more than
> 85% of the address space (i.e., the bulk of the space not under the
> Aggregatable Global Unicast Address (TLA) format prefix).
> Therefore, if the analysis does one day turn out to be wrong, our
> successors will still have the option of imposing much more
> restrictive allocation policies on the remaining 85%.
>
> - For transient use by non-routing hosts (e.g., for stand-alone
> dial-up users who prefer transient addresses for privacy reasons),
> a prefix of /64 might be OK. But a subscriber who wants "static"
> IPv6 address space, or who has or plans to have multiple subnets,
> ought to be provided with a /48, for the reasons given above, even
> if it is a transiently provided /48.
>
>To summarize, we argue that although careful stewardship of IPv6
>address space is essential, this is completely compatible with the
>convenience and simplicity of a uniform prefix size for IPv6 sites of
>any size. The numbers are such that there seems to be no objective
>risk of running out of space, giving an unfair amount of space to
>early customers, or of getting back into the over-constrained IPv4
>situation where address conservation and route aggregation damage each
>other.
>
>Multihoming Issues
>
>In the realm of multi-homed networks, the techniques used in IPv4 can
>all be applied, but they have known scaling problems. Specifically,
>if the same prefix is advertised by multiple ISPs, the routing tables
>will grow as a function of the number of multihomed sites. To go
>beyond this for IPv6, we only have initial proposals on the table at
>this time, and active work is under way in the IETF IPNG working
>group. Until existing or new proposals become more fully developed,
>existing techniques known to work in IPv4 will continue to be used in
>IPv6.
>
>Key characteristics of an ideal multi-homing proposal include (at
>minimum) that it provides routing connectivity to any multi-homed
>network globally, conserves address space, produces high quality
>routes at least as well as the single-homed host case previously
>discussed via any of the network's providers, enables a multi-homed
>network to connect to multiple ISPs, does not inherently bias routing
>to use any proper subset of those networks, does not unduly damage
>route aggregation, and scales to very large numbers of multi-homed
>networks.
>
>One class of solution being considered amounts to permanent parallel
>running of two (or more) prefixes per site. In the absence of a fixed
>prefix boundary, such a site might be required to have multiple
>different internal subnet numbering strategies, (one for each prefix
>length) or, if it only wanted one, be forced to use the most
>restrictive one as defined by the longest prefix it received from any
>of its ISPs. In this approach, a multi-homed network would have an
>address block from each of its upstream providers. Each host would
>either have exactly one address picked from the set of upstream
>providers, or one address per host from each of the upstream
>providers. The first case is essentially a variant on RFC 2260, with
>known scaling limits.
>
>In the second case (multiple addresses per host), if two multi-homed
>networks communicate, having respectively m and n upstream providers,
>then the one initiating the connection will select one address pair
>from the n*m potential address pairs to connect from and to, and in so
>doing will select the providers, and therefore the applicable route,
>for the life of the connection. Given that each path will have a
>different ambient bit rate, loss rate, and delay, if neither host is
>in possession of any routing or metric information, the initiating
>host has only a 1/(m*n) probability of selecting the optimal address
>pair. Work on better-than-random address selection is in progress in
>the IETF, but is incomplete.
>
>An existence proof exists in the existing IPv4 Internet that a network
>whose address is distinct from and globally advertised to all upstream
>providers permits the routing network to select a reasonably good path
>within the applicable policy. Present-day routing policies are not
>QoS policies but reachability policies, which means that they will not
>necessarily select the optimal delay, bit rate, or loss rate, but the
>route will be the best within the metrics that are indeed in use. One
>may therefore conclude that this would work correctly for IPv6
>networks as well, apart from scaling issues.
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Fred Baker | 519 Lado Drive
>IETF Chair | Santa Barbara California 93111
>www.ietf.org | Desk: +1-408-526-4257
> | Mobile: +1-805-886-3873
> | FAX: +1-413-473-2403
------_=_NextPart_001_01C01527.A2146F90
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>FW: (ngtrans) IAB/IESG Recommendations on IPv6 Address =
Delegation</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Steve Deering =
[SMTP:deering@cisco.com] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, September 01, 2000 =
7:02 PM </FONT>
<BR><FONT SIZE=3D2>To: =
ipng@sunroof.eng.sun.com </FONT>
<BR><FONT SIZE=3D2>Cc: =
ngtrans@sunroof.eng.sun.com; Bob Hinden </FONT>
<BR><FONT SIZE=3D2>Subject: (ngtrans) Fwd: IAB/IESG Recommendations on =
IPv6 Address Delegation </FONT>
<BR><FONT SIZE=3D2>Appended below is the message that was sent today to =
the RIRs from the IAB and IESG, regarding IPv6 address allocation =
policy. It contains most of the material that was in the draft I =
forwarded here on Sunday, but reorganized into a more coherent =
document.</FONT></P>
<P><FONT SIZE=3D2>Steve </FONT>
<BR><FONT SIZE=3D2>>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>>Date: Fri, 01 Sep 2000 12:40:48 =
-0700 </FONT>
<BR><FONT SIZE=3D2>>To: lir-wg@ripe.net =
(RIPE), policy@arin.net (ARIN), </FONT>
<BR><FONT SIZE=3D2>> =
apnic-talk@apnic.net (APNIC) </FONT>
<BR><FONT SIZE=3D2>>From: Fred Baker =
<chair@ietf.org> </FONT>
<BR><FONT SIZE=3D2>>Subject:IAB/IESG Recommendations on IPv6 Address =
Delegation </FONT>
<BR><FONT SIZE=3D2>>Cc: =
ipv6-directorate@sunroof.eng.sun.com, iesg@ietf.org, iab@ISI.EDU, =
</FONT>
<BR><FONT SIZE=3D2>> =
ipv6-wg@ripe.net (RIPE), sig-ipv6@lists.apnic.net (APNIC) </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Folks: </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The RIR community asked the IETF community for =
advice regarding the </FONT>
<BR><FONT SIZE=3D2>>assignment of IPv6 prefixes to service providers =
and edge networks, both </FONT>
<BR><FONT SIZE=3D2>>with a view to topological address assignment =
and to multihomed networks. </FONT>
<BR><FONT SIZE=3D2>>The IPv6 Directorate prepared a statement, which =
the IESG and IAB have </FONT>
<BR><FONT SIZE=3D2>>reviewed and approved. This is attached. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>I trust that this answers the questions you =
asked, and serves as a basis for </FONT>
<BR><FONT SIZE=3D2>>IPv6 deployment in the near term. If you have =
questions or issues concerning </FONT>
<BR><FONT SIZE=3D2>>it, I would suggest that you address them to the =
IPv6 Directorate copying </FONT>
<BR><FONT SIZE=3D2>>the IESG and IAB. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>We intend to publish an Informational RFC in the =
near future documenting the </FONT>
<BR><FONT SIZE=3D2>>contents of this note. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Fred Baker </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>>-----------------------------------------------------------=
------------ </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> IAB/IESG =
Recommendations on IPv6 Address Allocations </FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
; September 1, 2000 </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Introduction </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>During a discussion between IETF and RIR experts =
at the Adelaide IETF, </FONT>
<BR><FONT SIZE=3D2>>a suggestion was made that it might be =
appropriate to allocate /56 </FONT>
<BR><FONT SIZE=3D2>>prefixes instead of /48 for homes and small =
businesses. However, </FONT>
<BR><FONT SIZE=3D2>>subsequent analysis has revealed significant =
advantages in using /48 </FONT>
<BR><FONT SIZE=3D2>>uniformly. This note is an update =
following further discussions at </FONT>
<BR><FONT SIZE=3D2>>the Pittsburgh IETF. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>This document was developed by the IPv6 =
Directorate, IAB and IESG, and </FONT>
<BR><FONT SIZE=3D2>>is a recommendation from the IAB and IESG to the =
RIRs. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Background </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The technical principles that apply to address =
allocation seek to </FONT>
<BR><FONT SIZE=3D2>>balance healthy conservation practices and =
wisdom with a certain ease </FONT>
<BR><FONT SIZE=3D2>>of access. On the one hand, when managing =
the use of a potentially </FONT>
<BR><FONT SIZE=3D2>>limited resource, one must conserve wisely to =
prevent exhaustion </FONT>
<BR><FONT SIZE=3D2>>within an expected lifetime. On the other =
hand, the IPv6 address </FONT>
<BR><FONT SIZE=3D2>>space is in no sense as precious a resource as =
the IPv4 address space, </FONT>
<BR><FONT SIZE=3D2>>and unwarranted conservatism acts as a =
disincentive in a marketplace </FONT>
<BR><FONT SIZE=3D2>>already dampened by other factors. So from =
a market development </FONT>
<BR><FONT SIZE=3D2>>perspective, we would like to see it be very =
easy for a user or an ISP </FONT>
<BR><FONT SIZE=3D2>>to obtain as many IPv6 addresses as they really =
need without a </FONT>
<BR><FONT SIZE=3D2>>prospect of immediate renumbering or of scaling =
inefficiencies. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The IETF makes no comment on business issues or =
relationships. </FONT>
<BR><FONT SIZE=3D2>>However, in general, we observe that technical =
delegation policy can </FONT>
<BR><FONT SIZE=3D2>>have strong business impacts. A strong =
requirement of the address </FONT>
<BR><FONT SIZE=3D2>>delegation plan is that it not be predicated on =
or unduly bias </FONT>
<BR><FONT SIZE=3D2>>business relationships or models. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The IPv6 address, as currently defined, consists =
of 64 bits of </FONT>
<BR><FONT SIZE=3D2>>"network number" and 64 bits of =
"host number". The technical reasons </FONT>
<BR><FONT SIZE=3D2>>for this are several. The requirements for =
IPv6 agreed to in 1993 </FONT>
<BR><FONT SIZE=3D2>>included a plan to be able to address =
approximately 2^40 networks and </FONT>
<BR><FONT SIZE=3D2>>2^50 hosts; the 64/64 split effectively =
accomplishes this. Procedures </FONT>
<BR><FONT SIZE=3D2>>used in host address assignment, such as the =
router advertisement of a </FONT>
<BR><FONT SIZE=3D2>>network's prefix to hosts [RFC 2462], which in =
turn place a locally </FONT>
<BR><FONT SIZE=3D2>>unique number in the host portion, depend on =
this split. Examples of </FONT>
<BR><FONT SIZE=3D2>>obvious choices of host number (IEEE Mac =
Address, E.164 number, E.214 </FONT>
<BR><FONT SIZE=3D2>>IMSI, etc) suggest that no assumption should be =
made that bits may be </FONT>
<BR><FONT SIZE=3D2>>stolen from that range for subnet numbering; =
current generation MAC </FONT>
<BR><FONT SIZE=3D2>>layers and E.164 numbers specify up to 64 bit =
objects. Therefore, </FONT>
<BR><FONT SIZE=3D2>>subnet numbers must be assumed to come from the =
network part. This is </FONT>
<BR><FONT SIZE=3D2>>not to preclude routing protocols such as IS-IS =
level 1 (intra-area) </FONT>
<BR><FONT SIZE=3D2>>routing, which routes individual host addresses, =
but says that it may </FONT>
<BR><FONT SIZE=3D2>>not be depended upon in the world outside that =
zone. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The IETF has also gone to a great deal of effort =
to minimize the </FONT>
<BR><FONT SIZE=3D2>>impacts of network renumbering. =
None-the-less, renumbering of IPv6 </FONT>
<BR><FONT SIZE=3D2>>networks is neither invisible nor completely =
painless. Therefore, </FONT>
<BR><FONT SIZE=3D2>>renumbering should be considered an acceptable =
event, but to be </FONT>
<BR><FONT SIZE=3D2>>avoided if reasonably avoidable. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The IETF's IPNG working group has recommended =
that the address block </FONT>
<BR><FONT SIZE=3D2>>given to a single edge network which may be =
recursively subnetted be a </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>48 bit prefix. This gives each such =
network 2^16 subnet numbers to </FONT>
<BR><FONT SIZE=3D2>>use in routing, and a very large number of =
unique host numbers within </FONT>
<BR><FONT SIZE=3D2>>each network. This is deemed to be large =
enough for most enterprises, </FONT>
<BR><FONT SIZE=3D2>>and to leave plenty of room for delegation of =
address blocks to </FONT>
<BR><FONT SIZE=3D2>>aggregating entities. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>It is not obvious, however, that all edge =
networks are likely to be </FONT>
<BR><FONT SIZE=3D2>>recursively subnetted; an individual PC in a =
home, or a single cell in </FONT>
<BR><FONT SIZE=3D2>>a mobile telephone network, for example, may or =
may not be further </FONT>
<BR><FONT SIZE=3D2>>subnetted (depending whether they are acting as, =
e.g., gateways to </FONT>
<BR><FONT SIZE=3D2>>personal, home, or vehicular networks). =
When a network number is </FONT>
<BR><FONT SIZE=3D2>>delegated to a place that will not require =
subnetting, therefore, it </FONT>
<BR><FONT SIZE=3D2>>might be acceptable for an ISP to give a single =
64 bit prefix - </FONT>
<BR><FONT SIZE=3D2>>perhaps shared among the dial-in connections to =
the same ISP router. </FONT>
<BR><FONT SIZE=3D2>>However this decision may be taken in the =
knowledge that there is </FONT>
<BR><FONT SIZE=3D2>>objectively no shortage of /48s, and the =
expectation that personal, </FONT>
<BR><FONT SIZE=3D2>>home and vehicle networks will become the =
norm. Indeed, it is widely </FONT>
<BR><FONT SIZE=3D2>>expected that all IPv6 subscribers, whether =
domestic (homes), mobile </FONT>
<BR><FONT SIZE=3D2>>(vehicles or individuals), or enterprises of any =
size, will eventually </FONT>
<BR><FONT SIZE=3D2>>possess multiple always-on hosts, at least one =
subnet with the </FONT>
<BR><FONT SIZE=3D2>>potential for additional subnetting, and =
therefore some internal </FONT>
<BR><FONT SIZE=3D2>>routing capability. Note that in the =
mobile environment, the device </FONT>
<BR><FONT SIZE=3D2>>connecting a mobile site to the network may in =
fact be a third </FONT>
<BR><FONT SIZE=3D2>>generation cellular telephone. In other =
words the subscriber </FONT>
<BR><FONT SIZE=3D2>>allocation unit is not always a host; it is =
always potentially a site. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Address Delegation Recommendations </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The RIR communities, with the IAB, have =
determined that reasonable </FONT>
<BR><FONT SIZE=3D2>>address prefixes delegated to service providers =
for initial </FONT>
<BR><FONT SIZE=3D2>>allocations should be on the order of 29 to 35 =
bits in length, giving </FONT>
<BR><FONT SIZE=3D2>>individual delegations support for 2^13 (8K) to =
2^19 (512K) subscriber </FONT>
<BR><FONT SIZE=3D2>>networks. Allocations are to be given in a =
manner such that an </FONT>
<BR><FONT SIZE=3D2>>initial prefix may be subsumed by subsequent =
larger allocations </FONT>
<BR><FONT SIZE=3D2>>without forcing existing subscriber networks to =
renumber. We concur </FONT>
<BR><FONT SIZE=3D2>>that this meets the technical requirement for =
manageable and scalable </FONT>
<BR><FONT SIZE=3D2>>backbone routing while simultaneously allowing =
for managed growth of </FONT>
<BR><FONT SIZE=3D2>>individual delegations. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The same type of rule could be used in the =
allocation of addresses in </FONT>
<BR><FONT SIZE=3D2>>edge networks; if there is doubt whether an edge =
network will in turn </FONT>
<BR><FONT SIZE=3D2>>be subnetted, the edge network might be =
encouraged to allocate the </FONT>
<BR><FONT SIZE=3D2>>first 64 bit prefix out of a block of 8..256, =
preserving room for </FONT>
<BR><FONT SIZE=3D2>>growth of that allocation without renumbering up =
to a point. However, </FONT>
<BR><FONT SIZE=3D2>>for the reasons described below, we recommend =
use of a fixed boundary </FONT>
<BR><FONT SIZE=3D2>>at /48 for all subscribers except the very =
largest (who could receive </FONT>
<BR><FONT SIZE=3D2>>multiple /48's), and those clearly transient or =
otherwise have no </FONT>
<BR><FONT SIZE=3D2>>interest in subnetting (who could receive a =
/64). Note that there </FONT>
<BR><FONT SIZE=3D2>>seems to be little benefit in not giving a /48 =
if future growth is </FONT>
<BR><FONT SIZE=3D2>>anticipated. In the following, we give the =
arguments for a uniform </FONT>
<BR><FONT SIZE=3D2>>use of /48 and then demonstrate that it is =
entirely compatible with </FONT>
<BR><FONT SIZE=3D2>>responsible stewardship of the total IPv6 =
address space. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The arguments for the fixed boundary are: =
</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - only by having an ISP-independent boundary =
can we guarantee that a </FONT>
<BR><FONT SIZE=3D2>> change of ISP will not require a =
costly internal restructuring or </FONT>
<BR><FONT SIZE=3D2>> consolidation of subnets. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - to enable straightforward site renumbering, =
i.e., when a site </FONT>
<BR><FONT SIZE=3D2>> renumbers from one prefix to =
another, the whole process, including </FONT>
<BR><FONT SIZE=3D2>> parallel running of the two =
prefixes, would be greatly complicated </FONT>
<BR><FONT SIZE=3D2>> if the prefixes had different =
lengths (depending of course on the </FONT>
<BR><FONT SIZE=3D2>> size and complexity of the site). =
</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - there are various possible approaches to =
multihoming for IPv6 </FONT>
<BR><FONT SIZE=3D2>> sites, including the techniques =
already used for IPv4 multihoming. </FONT>
<BR><FONT SIZE=3D2>> The main open issue is finding =
solutions that scale massively </FONT>
<BR><FONT SIZE=3D2>> without unduly damaging route =
aggregation and/or optimal route </FONT>
<BR><FONT SIZE=3D2>> selection. Much more work =
remains to be done in this area, but it </FONT>
<BR><FONT SIZE=3D2>> seems likely that several =
approaches will be deployed in practice, </FONT>
<BR><FONT SIZE=3D2>> each with their own advantages and =
disadvantages. Some (but not </FONT>
<BR><FONT SIZE=3D2>> all) will work better with a fixed =
prefix boundary. (Multihoming </FONT>
<BR><FONT SIZE=3D2>> is discussed in more detail below.) =
</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - to allow easy growth of the subscribers' =
networks-no need to </FONT>
<BR><FONT SIZE=3D2>> keep going back to ISPs for more =
space (except for that relatively </FONT>
<BR><FONT SIZE=3D2>> small number of subscribers for =
which a /48 is not enough). </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - remove the burden from the ISPs and =
registries of judging sites' </FONT>
<BR><FONT SIZE=3D2>> needs for address space, unless the =
site requests more space than a </FONT>
<BR><FONT SIZE=3D2>> /48, with several advantages: =
</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - ISPs no longer need to ask for det=
ails of their customers' </FONT>
<BR><FONT SIZE=3D2>> network architecture =
and growth plans </FONT>
<BR><FONT SIZE=3D2>> - ISPs and registries no longer =
have to judge rates of address </FONT>
<BR><FONT SIZE=3D2>> consumption by customer =
type </FONT>
<BR><FONT SIZE=3D2>> - registry operations will be made =
more efficient by reducing the </FONT>
<BR><FONT SIZE=3D2>> need for evaluations =
and judgements </FONT>
<BR><FONT SIZE=3D2>> - address space will no longer be a =
precious resource for </FONT>
<BR><FONT SIZE=3D2>> customers, removing the =
major incentive for subscribers to </FONT>
<BR><FONT SIZE=3D2>> install v6/v6 NATs, =
which would defeat the ability of IPv6 to </FONT>
<BR><FONT SIZE=3D2>> restore address =
transparency. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - to allow the site to maintain a single =
reverse-DNS zone covering </FONT>
<BR><FONT SIZE=3D2>> all prefixes. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - If and only if a site can use the =
same subnetting structure under </FONT>
<BR><FONT SIZE=3D2>> each of its prefixes, =
then it can use the same zone file for the </FONT>
<BR><FONT SIZE=3D2>> address-to-name mapping =
of all of them. And, using the </FONT>
<BR><FONT SIZE=3D2>> conventions of RFC =
2874, it can roll the reverse mapping data </FONT>
<BR><FONT SIZE=3D2>> into the =
"forward" (name-keyed) zone. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Specific advantages of the fixed boundary being =
at /48 include </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - to leave open the technical option of =
retro-fitting the GSE </FONT>
<BR><FONT SIZE=3D2>> (Global, Site and End-System =
Designator, a.k.a "8+8") proposal for </FONT>
<BR><FONT SIZE=3D2>> separating locators and =
identifiers, which assumes a fixed boundary </FONT>
<BR><FONT SIZE=3D2>> between global and site addressing =
at /48. Although the GSE </FONT>
<BR><FONT SIZE=3D2>> technique was deferred a couple of =
years ago, it still has strong </FONT>
<BR><FONT SIZE=3D2>> proponents. Also, the IRTF =
Namespace Research Group is actively </FONT>
<BR><FONT SIZE=3D2>> looking into topics closely related =
to GSE. It is still possible </FONT>
<BR><FONT SIZE=3D2>> that GSE or a derivative of GSE =
will be used with IPv6 in the </FONT>
<BR><FONT SIZE=3D2>> future. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - since the site local prefix is fec0::/48, =
global site prefixes of </FONT>
<BR><FONT SIZE=3D2>> /48 will allow sites to easily =
maintain a simple 1 to 1 mapping </FONT>
<BR><FONT SIZE=3D2>> between the global topology and the =
site local topology in the SLA </FONT>
<BR><FONT SIZE=3D2>> field. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - similarly, if the 6to4 proposal is =
standardized, migration from a </FONT>
<BR><FONT SIZE=3D2>> 6to4 prefix, which is /48 by =
construction, to a native IPv6 prefix </FONT>
<BR><FONT SIZE=3D2>> will be simplified if the native =
prefix is /48. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Note that none of these reasons imply an =
expectation that homes, </FONT>
<BR><FONT SIZE=3D2>>vehicles, etc. will intrinsically require 16 =
bits of subnet space. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Conservation of Address Space </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>The question naturally arises whether giving a =
/48 to every subscriber </FONT>
<BR><FONT SIZE=3D2>>represents a profligate waste of address =
space. Objective analysis </FONT>
<BR><FONT SIZE=3D2>>shows that this is not the case. A /48 =
prefix under the Aggregatable </FONT>
<BR><FONT SIZE=3D2>>Global Unicast Address (TLA) format prefix =
actually contains 45 </FONT>
<BR><FONT SIZE=3D2>>variable bits, i.e., the number of available =
prefixes is 2**45 or about </FONT>
<BR><FONT SIZE=3D2>>35 trillion (35,184,372,088,832). If we =
take the limiting case of </FONT>
<BR><FONT SIZE=3D2>>assigning one prefix per human, then the =
utilization of the TLA space </FONT>
<BR><FONT SIZE=3D2>>appears to be limited to approximately 0.03% on =
reasonable </FONT>
<BR><FONT SIZE=3D2>>assumptions. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>More precisely, </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - RFC 1715 defines an "H ratio" based =
on experience in address space </FONT>
<BR><FONT SIZE=3D2>> assignment in various =
networks. Applied to a 45 bit address space, </FONT>
<BR><FONT SIZE=3D2>> and projecting a world population =
of 10.7 billion by 2050 (see </FONT>
<BR><FONT SIZE=3D2>> <A =
HREF=3D"http://www.popin.org/pop1998/" =
TARGET=3D"_blank">http://www.popin.org/pop1998/</A>), the required =
assignment efficiency </FONT>
<BR><FONT SIZE=3D2>> is log_10(1.07*10^10) / 45 =3D =
0.22. This is less than the </FONT>
<BR><FONT SIZE=3D2>> efficiencies of telephone numbers =
and DECnetIV or IPv4 addresses </FONT>
<BR><FONT SIZE=3D2>> shown in RFC 1715, i.e., gives no =
grounds for concern. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - We are highly confident in the validity of =
this analysis, based on </FONT>
<BR><FONT SIZE=3D2>> experience with IPv4 and several =
other address spaces, and on </FONT>
<BR><FONT SIZE=3D2>> extremely ambitious scaling goals =
for the Internet amounting to an </FONT>
<BR><FONT SIZE=3D2>> 80 bit address space *per =
person*. Even so, being acutely aware of </FONT>
<BR><FONT SIZE=3D2>> the history of under-estimating =
demand, we have reserved more than </FONT>
<BR><FONT SIZE=3D2>> 85% of the address space (i.e., the =
bulk of the space not under the </FONT>
<BR><FONT SIZE=3D2>> Aggregatable Global Unicast Address =
(TLA) format prefix). </FONT>
<BR><FONT SIZE=3D2>> Therefore, if the analysis does one =
day turn out to be wrong, our </FONT>
<BR><FONT SIZE=3D2>> successors will still have the =
option of imposing much more </FONT>
<BR><FONT SIZE=3D2>> restrictive allocation policies on =
the remaining 85%. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - For transient use by non-routing hosts (e.g., =
for stand-alone </FONT>
<BR><FONT SIZE=3D2>> dial-up users who prefer transient =
addresses for privacy reasons), </FONT>
<BR><FONT SIZE=3D2>> a prefix of /64 might be OK. =
But a subscriber who wants "static" </FONT>
<BR><FONT SIZE=3D2>> IPv6 address space, or who has or =
plans to have multiple subnets, </FONT>
<BR><FONT SIZE=3D2>> ought to be provided with a /48, =
for the reasons given above, even </FONT>
<BR><FONT SIZE=3D2>> if it is a transiently provided =
/48. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>To summarize, we argue that although careful =
stewardship of IPv6 </FONT>
<BR><FONT SIZE=3D2>>address space is essential, this is completely =
compatible with the </FONT>
<BR><FONT SIZE=3D2>>convenience and simplicity of a uniform prefix =
size for IPv6 sites of </FONT>
<BR><FONT SIZE=3D2>>any size. The numbers are such that there =
seems to be no objective </FONT>
<BR><FONT SIZE=3D2>>risk of running out of space, giving an unfair =
amount of space to </FONT>
<BR><FONT SIZE=3D2>>early customers, or of getting back into the =
over-constrained IPv4 </FONT>
<BR><FONT SIZE=3D2>>situation where address conservation and route =
aggregation damage each </FONT>
<BR><FONT SIZE=3D2>>other. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Multihoming Issues </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>In the realm of multi-homed networks, the =
techniques used in IPv4 can </FONT>
<BR><FONT SIZE=3D2>>all be applied, but they have known scaling =
problems. Specifically, </FONT>
<BR><FONT SIZE=3D2>>if the same prefix is advertised by multiple =
ISPs, the routing tables </FONT>
<BR><FONT SIZE=3D2>>will grow as a function of the number of =
multihomed sites. To go </FONT>
<BR><FONT SIZE=3D2>>beyond this for IPv6, we only have initial =
proposals on the table at </FONT>
<BR><FONT SIZE=3D2>>this time, and active work is under way in the =
IETF IPNG working </FONT>
<BR><FONT SIZE=3D2>>group. Until existing or new proposals =
become more fully developed, </FONT>
<BR><FONT SIZE=3D2>>existing techniques known to work in IPv4 will =
continue to be used in </FONT>
<BR><FONT SIZE=3D2>>IPv6. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>Key characteristics of an ideal multi-homing =
proposal include (at </FONT>
<BR><FONT SIZE=3D2>>minimum) that it provides routing connectivity =
to any multi-homed </FONT>
<BR><FONT SIZE=3D2>>network globally, conserves address space, =
produces high quality </FONT>
<BR><FONT SIZE=3D2>>routes at least as well as the single-homed host =
case previously </FONT>
<BR><FONT SIZE=3D2>>discussed via any of the network's providers, =
enables a multi-homed </FONT>
<BR><FONT SIZE=3D2>>network to connect to multiple ISPs, does not =
inherently bias routing </FONT>
<BR><FONT SIZE=3D2>>to use any proper subset of those networks, does =
not unduly damage </FONT>
<BR><FONT SIZE=3D2>>route aggregation, and scales to very large =
numbers of multi-homed </FONT>
<BR><FONT SIZE=3D2>>networks. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>One class of solution being considered amounts =
to permanent parallel </FONT>
<BR><FONT SIZE=3D2>>running of two (or more) prefixes per =
site. In the absence of a fixed </FONT>
<BR><FONT SIZE=3D2>>prefix boundary, such a site might be required =
to have multiple </FONT>
<BR><FONT SIZE=3D2>>different internal subnet numbering strategies, =
(one for each prefix </FONT>
<BR><FONT SIZE=3D2>>length) or, if it only wanted one, be forced to =
use the most </FONT>
<BR><FONT SIZE=3D2>>restrictive one as defined by the longest prefix =
it received from any </FONT>
<BR><FONT SIZE=3D2>>of its ISPs. In this approach, a =
multi-homed network would have an </FONT>
<BR><FONT SIZE=3D2>>address block from each of its upstream =
providers. Each host would </FONT>
<BR><FONT SIZE=3D2>>either have exactly one address picked from the =
set of upstream </FONT>
<BR><FONT SIZE=3D2>>providers, or one address per host from each of =
the upstream </FONT>
<BR><FONT SIZE=3D2>>providers. The first case is essentially a =
variant on RFC 2260, with </FONT>
<BR><FONT SIZE=3D2>>known scaling limits. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>In the second case (multiple addresses per =
host), if two multi-homed </FONT>
<BR><FONT SIZE=3D2>>networks communicate, having respectively m and =
n upstream providers, </FONT>
<BR><FONT SIZE=3D2>>then the one initiating the connection will =
select one address pair </FONT>
<BR><FONT SIZE=3D2>>from the n*m potential address pairs to connect =
from and to, and in so </FONT>
<BR><FONT SIZE=3D2>>doing will select the providers, and therefore =
the applicable route, </FONT>
<BR><FONT SIZE=3D2>>for the life of the connection. Given that =
each path will have a </FONT>
<BR><FONT SIZE=3D2>>different ambient bit rate, loss rate, and =
delay, if neither host is </FONT>
<BR><FONT SIZE=3D2>>in possession of any routing or metric =
information, the initiating </FONT>
<BR><FONT SIZE=3D2>>host has only a 1/(m*n) probability of selecting =
the optimal address </FONT>
<BR><FONT SIZE=3D2>>pair. Work on better-than-random address =
selection is in progress in </FONT>
<BR><FONT SIZE=3D2>>the IETF, but is incomplete. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>>An existence proof exists in the existing IPv4 =
Internet that a network </FONT>
<BR><FONT SIZE=3D2>>whose address is distinct from and globally =
advertised to all upstream </FONT>
<BR><FONT SIZE=3D2>>providers permits the routing network to select =
a reasonably good path </FONT>
<BR><FONT SIZE=3D2>>within the applicable policy. Present-day =
routing policies are not </FONT>
<BR><FONT SIZE=3D2>>QoS policies but reachability policies, which =
means that they will not </FONT>
<BR><FONT SIZE=3D2>>necessarily select the optimal delay, bit rate, =
or loss rate, but the </FONT>
<BR><FONT SIZE=3D2>>route will be the best within the metrics that =
are indeed in use. One </FONT>
<BR><FONT SIZE=3D2>>may therefore conclude that this would work =
correctly for IPv6 </FONT>
<BR><FONT SIZE=3D2>>networks as well, apart from scaling issues. =
</FONT>
<BR><FONT =
SIZE=3D2>>=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
</FONT>
<BR><FONT SIZE=3D2>>Fred Baker | 519 Lado =
Drive </FONT>
<BR><FONT SIZE=3D2>>IETF Chair | Santa =
Barbara California 93111 </FONT>
<BR><FONT SIZE=3D2>>www.ietf.org | Desk: =
+1-408-526-4257 </FONT>
<BR><FONT =
SIZE=3D2>>  =
; | Mobile: +1-805-886-3873 </FONT>
<BR><FONT =
SIZE=3D2>>  =
; | FAX: +1-413-473-2403 =
</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C01527.A2146F90--
