Subject: Regionally aggregatable address space for multihoming

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Jun 2001 11:33:00 +0200 (West-Europa (zomertijd))

Hi.

I guess I'll jump right in.

After reading "IAB/IESG Recommendations on IPv6 Address Allocations to 
Sites" it occurred to me that a way to keep the number of routes in the
routing tables down could be to use regionally aggregatable address space for
multihoming.

The idea is that routers on one end of the globe have little need to know
very specific routes to multihomed networks in some another part of the
world. For instance, a router on the US west coast doesn't need to know how a
network in Europe is connected. It should just send the packet to the
east. At some point, the packet would end up in the destination region, or as
close to the destination region as the originating network extends, and only
there the originating network would have to know where to send the packet
next.

Individual networks could implement filters in strategic places to keep the
specific routes for multihomed networks inside the proper region. There is no
requirement that networks use the same regional subdivision: a European
network may use regions that map to two countries, while another network that
has only a few points of presence in Europe may see the entire continent as a
region. Some networks may prefer to keep carrying all routes everywhere.

All networks announce their customer's routes everywhere, but peers simply
filter out these announcements on exchange points that do not fall within
their idea of the region. So our European network would normally only accept
routes to Dutch addresses in Amsterdam and Brussels (for backup) but the
other network only connects to the exchanges in London and Paris so it would
pick up the announcements for the Dutch multihomed address range there.

A further reduction of the routing tables could be possible by installing
exchange routers for regions at internet exchanges. The exchange router would
announce an aggregate for the region and all networks may send traffic to
that router. The exchange router holds all the more specific routes for the
aggregate and forwards the packets to one of the providers for the
destination network.

A problem with this is that all networks that have multihomed customers in a
region must connect to all the exchanges where the aggregate is announced.
All other default free networks have to connect to at least two of the
exchanges for that region. Exchange routers should be present outside as well
as within the region they service, for reasons of redundancy and because not
all networks are present in all regions.

The granularity of the address assignments has to be fairly fine, so that it
doesn't conflict with the hierarchical structure of any existing network. A
granularity of 1 to 10 million people to a region seems reasonable. (This
would mean large cities or small countries/states/provinces.) With
potentially 1% of the population being multihomed that would make for about
100k routes per region, so today's routers would be able to handle several of
those regions.

Iljitsch van Beijnum

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Jun 2001 07:25:12 -0500

How would this work for intercontinental private networks,
whose multiple connection points are in several different
continents?

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Jun 2001 14:44:17 +0200 (West-Europa (zomertijd))

> whose multiple connection points are in several different

There are two ways this could work. Either the network basically functions as
its own ISP, and it tries to attract traffic as close to the origin as
possible, or it tries to keep the long distance lines free for private
traffic and has ISPs transport the traffic to as close to the destination as
possible.

In the first case, they would use a globally visible PI address range and
announce a single prefix everywhere in the world. In the second case, they
would get a number of smaller regionally aggregatable ranges and use them in
the appropriate regions.

Iljitsch van Beijnum

---

From: Jim Bound <[email-masked]>
Date: Tue, 5 Jun 2001 09:28:30 -0400 (EDT)

also for inter-planetary networks too. seriously I have people asking. 

/jim

---

From: leo vegoda <[email-masked]>
Date: Tue, 5 Jun 2001 15:51:24 +0200

On Tue, Jun 05, 2001 at 09:28:30AM -0400, Jim Bound ([email-masked]) wrote: Re: Re: Regionally aggregatable address space for multihoming
> also for inter-planetary networks too. seriously I have people asking. 

Interplanetary Internet (IPN):  Architectural Definition 
http://www.ietf.org/internet-drafts/draft-irtf-ipnrg-arch-00.txt

This ID suggests a separte Internet for each planet (or
space-ship, or whatever) with a 'Bundle Layer' for the
connections between them.

Certainly an eye-opening read but probably slightly off-topic.

Regards,

-- 
leo vegoda
"One size never fits all"
RFC1925 - The Twelve Networking Truths

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Jun 2001 13:55:23 -0700

Here is the text of a very drafty-draft I have been working on for a couple
of weeks to address this specific issue. If things are not aligning right,
try putting the font in Courier 12.  Comments please.

Tony

Multi-6
Internet Draft                                               T. Hain
Document: draft-hain-ipv6-geo-addr-00.txt                      Cisco
Expires: December 2001                                     June 2001

An IPv6 Provider Independent (Geographic) Global Unicast Address Format

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [i].

Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups.  Note that      other groups may
also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time.  It
is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Abstract

This document defines an IPv6 Provider Independent global unicast address
format for use in the Internet.  The address format defined in this document
is consistent with the IPv6 Protocol [IPV6] and the "IPv6 Addressing
Architecture" [ARCH].  It is designed to facilitate scalable Internet
routing when sites attach to multiple service providers, by using a
geographic reference to the site. A natural byproduct of this address
allocation mechanism is that all addresses are portable allowing sites to
change providers at will without requiring their network to renumber.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [ii].

Introduction

This document defines an address format for the IPv6 provider independent
global unicast address assignment based on geographic location. This address
format is expected to complement the Aggregatable [RFC 2374] format by
addressing some of the scaling concerns related to site multi-homing. Recent
observations show that sites are frequently connecting to multiple service
providers, and this breaks the base aggregation assumption in rfc 2374. The
geographic nature of this provider independent address format is designed to
provide sites with addresses which aggregate well in direct proportion to
the distance from the site. It also allows a site to change providers
without impacting the nodes or connections within a site. The mechanism
breaks down the geographic location of the site into prefix lengths that map
well into existing routing protocols. This will allow efficient routing
aggregation for single sites that connect directly to multiple providers and
for sites that connect to metropolitan scale exchanges. Sites will have the
choice to connect to either type of aggregation entity. The details about
specific site topology will be limited to the service providers that are
making the direct connections. This format will also work well for
organizations with multiple sites distributed geographically, when used
concurrently with [draft-draves-addr-selection]. As each end system will
select the source address that has the longest match with the destination,
connections will naturally find the transition point between the
organizations private network and the public Internet that is closest to the
publicly connected site.

The basic mechanism is an Earth surface location defined by WGS-84
latitude/longitude that represents the center of a nominal square
approximately 10 meters on a side. An interleave is used to create a 44-bit
address, if necessary dropping the low order nibbles allows for local
management and increases flexibility of assignments to sites by expanding
the grid scope.

While this address format is designed to support exchange-based aggregation
in a metro context, it is not dependent on exchanges for it's overall route
aggregation properties. It will provide efficient route aggregation in a
global context when providers in a metro region interconnect by whatever
means, and only announce the shorter prefix outside. Any provider announcing
a short prefix SHOULD be able to deliver packets to anywhere in the region,
either directly or through other arrangements. In the case where a service
provider does not interconnect with others in its region it MUST advertise
the longer prefixes associated with its customers.

IPv6 defines the case that nodes will have multiple addresses so having a
set of provider independent ones as well as potentially several sets of
provider dependent ones should not present any particular concerns to the
end nodes. The primary technical issue will be limitations in the size of a
DNS response packet. There may be concerns raised about timing out
connection attempts, but [addr-selection] selection rules should
consistently provide the optimal pairing of addresses.

Addresses defined with this format prefix are not portable by definition.
Entities that expect identifiers to be portable across physical location
moves MUST use alternatives such as provider-based addresses [rfc 2374] or
DNS names. Multi-site organizations SHOULD be using all the available
prefixes; so if any specific facility moved, deprecating one should be a
non-event for all but very long lifetime connections.

Another issue is the business model being flipped from the current
destination's ISP choice determines sources routing; to one of source's ISP
choice determines at least its first hop. The other consideration is this
may cause the traffic flow between ISPs to flip from dump-early to dump-late
(in smallest peering scope of destination). The number of packets carried
should remain the same, but the transit agreements may be the opposite
direction from provider-based allocations.

Question about how does an ISP find out what scope they can aggregate. If
everyone just starts announcing site specific /48's and use the upstream
pressure / feedback to correct the situation there is no need for a specific
registration. Clearly all of the significant players in a region need to
communicate well to contain the specifics, but the consequence of not doing
that is simply a larger table at the next larger boundary. Providers at the
larger scopes are motivated to encourage providers in the smaller scopes to
interconnect locally and avoid announcing the specifics any wider than
necessary.

Overview of the IPv6 Address

IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces. There are three types of addresses: Unicast, Anycast, and
Multicast. This document defines a specific type of Unicast    address.

In this document, fields in addresses are given specific names, for
example "subnet". When this name is used with the term "ID" (for
"identifier") after the name (e.g., "subnet ID"), it refers to the
contents of the named field. When it is used with the term "prefix" (e.g.
"subnet prefix") it refers to all of the addressing bits to    the left of
and including this field.

IPv6 unicast addresses are designed assuming that the Internet    routing
system makes forwarding decisions based on a "longest prefix    match"
algorithm on arbitrary bit boundaries and does not have any    knowledge of
the internal structure of IPv6 addresses. The structure in IPv6 addresses is
for assignment and allocation. The only exception to this is the distinction
made between unicast and multicast addresses.

The specific type of an IPv6 address is indicated by the leading bits in the
address.  The variable-length field comprising these leading bits is called
the Format Prefix (FP).

This document defines an address format for the 0001 (binary) Format Prefix
for Geographic Global Unicast addresses. The same address format could be
used for other Format Prefixes, as long as these Format Prefixes also
identify IPv6 unicast addresses.  Only the "0001" Format Prefix is defined
here.

IPv6 Geographic Global Unicast Address Format

Provider Independent addresses are organized into a nibble-based hierarchy
using a 2-bit interleave of the WGS-84 based latitude and longitude of a
site. While the available 44-bit field allows for resolution of a grid
approximately 10 meters on a side, addressing privacy concerns may require
the allocation to be at 40-bits with site assignments in that 40 meter grid
to be managed by the smallest local jurisdiction. Accommodating dense
population areas may require that the grid size be increased to 150 meters
or more to allow a sufficient number of bits in the locally assigned field
identifying the specific site. This will allow more flexible assignments for
multi-story buildings and business centers with multiple independent sites
per geographic grid. Actual assignments within a geographic grid will be a
local jurisdictional issue (matching scope jurisdiction; building owner,
community board, local government, etc.), and independent of any service
provider. The only rules are that the allocation point MUST be measured at
the center of, a grid and any overlap must be coordinated. If a grid needs
to be expanded to accommodate density, it MUST avoid or otherwise coordinate
use of any existing values that fall within its new boundaries.

In the case where the local jurisdiction acts as a local service provider to
its tenants, it MAY choose to allocate prefix lengths longer than /48 as
appropriate for the number and needs of its customers. In any case the
allocation MUST NOT exceed 64 bits in length.

In a few places there may exist regions with extreme densities (greater than
1M independent sites per square 25 km on a side) where it is not reasonable
to expand any given grid to a sufficiently large area to provide enough
addresses for local administration. Generally these are expected to be
adjacent to sizable regions of water where it is highly unlikely there will
ever be permanent Internet service provided. The local jurisdiction for
areas of extreme density may choose to map a nearby unusable grid onto an
area requiring more addresses. When this is done the jurisdiction MUST
coordinate with neighbors to avoid duplication.

This address allocation mechanism SHOULD NOT be used on a dial access
network pop, as scaling routes to sites attached this way are best addressed
through provider based allocations consistent with Aggregatable [RFC 2374].

Service provision from points of attachment for wireless nodes MAY choose to
allocate prefixes longer than 48 bits (from the site prefix for the antenna)
as appropriate for the number and needs of the customers currently attached.
In any case the allocation MUST NOT exceed 64 bits in length.

Geography provides distinguished meaning to the term 'home address'.

The basic mechanism is a 2-bit interleave of the WGS-84 latitude / longitude
values to minimize routing table size on 4-bit increments. While the prefix
length MAY be established on any nibble boundary, the requirement for all
service providers at that boundary to directly peer with all others will
naturally limit the operational choices.

Core routing SHOULD be based on best match of sparsely populated table using
fixed first 3 bytes (FP + 20 bits) to find a region.

Regional routing SHOULD be based on best match of moderately populated table
using next 2-3 bytes to find neighborhood-site.

for layer-3 exchanges to work there has to be a way to do source routing
within a region to select ixc : rest of the system dst based routing
        simple directory lookup on flat 48 bit site id
        if so lec would dest route within region / src route to ixc
        ixc would dest route to next region
        dest lec would dest route within region

Specification of the WGS-84 reference point SHOULD be the responsibility of
the layer-1 service provider, and SHOULD represent the demarcation point of
the layer-1 service. In the case where reference points overlap, the layer-1
service provider MUST coordinate the specification with the local
jurisdiction.

translation of deg.xxxxx into 44 bits of 2-bit interleaved binary
the base angle is found by dividing 360 by the 2 ^ # of bits
{ie: Microsoft Excel formula >  = 360/(2^22) }

16 bits ~ 0.0054931640625 deg (grids 32763 lat - 65526 long)
18 bits ~ 0.001373291015625 deg (grids 131052 lat - 262104 long)
20 bits ~ 0.00034332275390625 deg (grids 524208 lat - 1048416 long)
22 bits ~ 0.0000858306884765625 deg (grids 2096832 lat - 4193664 long)

Formation sequence:
1. for east/west (convert all west values to east - ie: 90w = 270e)
2. divide degrees (5 significant decimal places) by 0.0000858306884765625
(5 places of significance right of decimal in lat/long readings results in 1
m increment : within rounding error of 22 bit resolution : while 4 places of
significance results in 11.1 m increments which is longer than the side ~
9.5 m of the grid being identified)
3. convert each of the integers to 22-digit binary
4. north/south (set MSB for south)
5. interleave 2-bits lat, 2-bits long into 44-bit result
(examples below)
6. convert result to 11-digit hex, insert : between digits 3-4 & 7-8
7. prepend FP 0x1 to form 12-digit hex as /48 prefix

Format

This document specifies the format for format prefix (FP) 0001 binary.

| 4 |           44            |   16   |          64 bits          |
+---+---~---~---~---~~~~~-----+--------+---------------------------+
|FP | Region / Metro }{ Site  |  SLA   |       Interface ID        |
+---+---~---~---~---~~~~~-----+--------+---------------------------+

The geographic reference field MUST be calculated at 44-bits, but may be
used in routing calculations on any 4-bit boundary. The approximate surface
area covered by each grid value is provided in the table below. The size in
meters is based on rounded values for the equatorial circumference and
should only be used as a conceptual guideline.

bits   degrees            nominal square    scope           sites
--------------------------------------------------------------------
  4 -> 90.00000                 10000 km   octant
  8 -> 22.50000                  2500 km   expanse
 12 -> 5.625000                   600 km   zone
 16 -> 1.406250                   150 km   region
 20 -> 0.3515625                   40 km   metro           16777216
 24 -> 0.087890625                 10 km   city             1048576
 28 -> 0.02197265625              2.5 km   locality           65536
 32 -> 0.0054931640625            600  m   neighborhood        4096
 36 -> 0.001373291015625          150  m   block                256
 40 -> 0.00034332275390625         40  m   lot                   16
 44 -> 0.0000858306884765625       10  m   site                   1

The location addressed as 1000:0000:0000/48 covers an area ~ 10 m on a side,
centered at equator and the 0 meridian (Greenwich).

Core routing table examples:
Region                  lat           long       2-bit interleave
---------------------------------------------------------
W. Europe               080000  :  000000  ->   1080:0000:0000
S. Africa               260000  :  000000  ->   1848:0000:0000
NE Africa               030000  :  030000  ->   100F:0000:0000
E. Europe               080000  :  060000  ->   1092:0000:0000
C. Asia                 030000  :  0C0000  ->   103C:0000:0000
E. Asia                 060000  :  180000  ->   1168:0000:0000
Australia               260000  :  180000  ->   1968:0000:0000
Alaska                  0C0000  :  240000  ->   12D0:0000:0000
NW US                   080000  :  2B0000  ->   12A3:0000:0000
Central America         030000  :  2E0000  ->   123E:0000:0000
SE US                   060000  :  300000  ->   1348:0000:0000
South America           260000  :  300000  ->   1B48:0000:0000
NW Africa               000000  :  3D0000  ->   1331:0000:0000

Airport location examples:

MIA -    25.78 n    80.28 w             1341:A766:517A
ATL -    33.63 n    84.42 w             1344:FFB9:B387
IAD -    38.93 n    77.45 w             134A:CBAF:8EEE
JFK -    40.63 n    73.77 w             134E:3E86:26D5
ORD -    41.97 n    87.90 w             134C:5D7B:2586
DEN -    39.85 n   104.70 w             127D:1646:B7F8
SFO -    37.62 n   122.37 w             126A:8F32:3832
LAX -    33.93 n   118.40 w             126A:3383:1F34
SAN -    32.73 n   117.18 w             1267:C627:8442
ANC -    61.16 n   150.00 w             1299:D5DD:5D55
SYD -    33.97 s   151.17 e             185A:239B:332E
NRT -    35.75 n   140.37 e             105A:47BD:0165
DEL -    28.55 n    77.01 e             1047:163C:474F
CAI -    30.10 n    31.40 e             1045:5695:D80B
CPT -    33.95 s    18.60 e             1848:3187:2688
CDG -    49.00 n     2.53 e             1080:8D78:30AD
LHR -    51.47 n    0.350 w             13B7:3B48:4D42
GIG -    22.80 s    42.23 w             1B60:13F6:894C
SCL -    33.38 s    70.78 w             1B47:DAEE:2BA5
MEX -    19.43 n    99.07 w             123E:5E43:435E
N Pole - 90.00 n     0.00 e             1400:0000:0000
S Pole - 90.00 s     0.00 e             1C00:0000:0000

Routing protocol should only announce a short prefix if the router can get
to the entire concatenation, if not it will need to announce specifics.

The result is that at some point in the nibble hierarchy all service
providers in a region have to share routes, and it becomes an engineering
tradeoff between the size of the routing table, and the number of points
where peering occurs. Basically expect tier-1's to run their core routers on
a sparsely populated 8 bit table, their regional routers on a full
population of the next 8 bits, with tier-2-3's looking at moderately
populated 20 bit tables. Since 20 bits is nominally what tier-1's do today
on a global scale I don't think this is out of line for scale or
performance, and it bounds the problem to the set of providers where the
multi-homing occurs.

Site-Level Aggregation Identifier

The SLA ID field is used by an individual organization to create its own
local addressing hierarchy and to identify subnets.  This is analogous to
subnets in IPv4 except that each organization has a much greater number of
subnets.  The 16 bit SLA ID field support 65,535 individual subnets.

Organizations may choose to either route their SLA ID "flat" (e.g., not
create any logical relationship between the SLA identifiers that results in
larger routing tables), or to create a two or more level  hierarchy (that
results in smaller routing tables) in the SLA ID  field.  The latter is
shown as follows:

   |  n  |   16-n     |              64 bits                |
   +-----+------------+-------------------------------------+
   |SLA1 |   Subnet   |            Interface ID             |
   +-----+------------+-------------------------------------+

         | m  |16-n-m |              64 bits                |
         +----+-------+-------------------------------------+
         |SLA2|Subnet |            Interface ID             |
         +----+-------+-------------------------------------+

The approach chosen for structuring an SLA ID field is the responsibility of
the individual organization.

The number of subnets supported by this address format should be sufficient
for all but the most densely packed spaces. When the number of subnets
exceeds 2 ^ 16 per 10 meter square of the earth's surface, alternative
allocation mechanisms may be required.

Interface ID

Interface identifiers are used to identify interfaces on a link. They are
required to be unique on that link.  They may also be unique over a broader
scope.  In many cases an interfaces identifier will be the same or be based
on the interface's link-layer address.
Interface IDs used in the aggregatable global unicast address format are
required to be 64 bits long and to be constructed in IEEE EUI-64 format
[EUI-64].  These identifiers may have global scope when a global token (e.g.
, IEEE 48bit MAC) is available or may have local scope where a global token
is not available (e.g., serial links, tunnel end-points, etc.).  The "u" bit
(universal/local bit in IEEE EUI-64 terminology) in the EUI-64 identifier
must be set correctly, as defined in [ARCH], to indicate global or local
scope.

The procedures for creating EUI-64 based Interface Identifiers is defined in
[ARCH].  The details on forming interface identifiers is defined in the
appropriate "IPv6 over " specification such as "IPv6 over Ethernet" [ETHER],
"IPv6 over FDDI" [FDDI], etc.

Technical Motivation

The design choice for the size of the fields in the geographic address
format was based on the need to separate the address allocation from the
service provider (to address the scaling problems that mechanism creates
when sites connect to multiple providers), and the need to preserve the
subnet structure defined in [Aggregatable]. An additional benefit of
separation is the ability of the site to switch providers without
renumbering.

Multi-site networks would internally advertise all the natural prefixes and
let the [addr-selection] rules sort it out. This would result in systems
selecting a source address that most closely matches the destination. Thus
return traffic would naturally be directed toward the site boundary closest
to the destination site (ie: traffic would traverse the public network as
little as possible).

Security Considerations

<Every draft should have a security section.>

Appendix

Location measurements based on WGS84
World Geodetic System 84 provides a common geodetic reference  : surface of
an ellipsoid approximating the true shape of the Earth geoid.
Origin = Earth's center of mass
Z-axis = Conventional terrestrial pole - Bureau International de l'Heure
X-axis = Intersection of the reference meridian plane and the equator
Y-axis = right-handed Earth-fixed orthogonal coordinate system measured in
the plane of the equator east of the X-axis

equatorial radius = 6378137 m
flattening = 1/298.257223563 ( f = (a-b)/a  or  b = a - (f*a) )
pole radius = 6356752 m
equatorial circumference = 40075016 m
pole circumference = 39940650 m
pole is .33% smaller than equator

References

Significant portions of this text are directly copied from RFC 2374 for
consistency.

< Your references will be listed here. View "Page Layout" if they are not
currently visible. >

Acknowledgments

<Add any acknowledgements>

Author's Addresses

Tony Hain
Cisco Systems
500 108th Ave. N.E. Suite 500
Bellevue, Wa. 98004
Email: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 8 Jun 2001 12:35:55 +0200 (West-Europa (zomertijd))

> try putting the font in Courier 12.  Comments please.

- you may want to cut some text that isn't specific to this proposal
- integer math would be easier than floating point math with 15 digits
- if you move the 0 meridian to 30 deg west it won't cut through densely
  populated areas in Europe and Africa
- why 2 bit interleave? one bit makes it possible to use arbitrary boundaries

I made a small program to calculate the geographic address for any given
location, but I got very different addresses for most things, although some
worked. Have a look at http://www.muada.com/ipv6geo.php

But the real question is: do we really want to use such a very direct
relationship between addresses and geography?

I see three major drawbacks:

1. This proposal uses 6.25% of the IPv6 address space and still some areas
may have too few addresses. It is especially wasteful closer to the
poles. There are only a few cities above 60 deg north or below 40 deg south,
and these two areas use 44% of the address space in this proposal and 2.77%
of the IPv6 address space if it is deployed.

2. The strictly geographic aggregation boundaries in this proposal won't fit
current network topologies. So either the networks will have to be changed or
the aggregation will be less successful.

3. Lots of renumbering: if strictly applied, this proposal means that moving
a workstation from one end of a hallway to another implies renumbering. While
the support for automatic renumbering are better in IPv6, it is still not
something to take too lightly. Even if the renumbering itself is completely
transparent to the user and applications, there is still the matter of the
DNS.

But what about this: in stead of using individual routes, we could encode
routing information in bitmaps. A 150 km routing precission would take 2^16 =
64k bits = 8 kilobyte to encode. A reachability bitmap for all neighborhoods
within a region would also take only 8k. But a 20 bit prefix would take 128k.

So core routers would take 150 km precission bitmaps of the whole world from
their peers. The next routing level would be the zone level, where 2.5 km
precission bitmaps for a number of adjacent 600x600 km zones are 
exchanged. The next level would be able to handle the 10x10 m sites.

This would also permit very fast routing updates because reachability
information can be updated with just a few AND and OR operations on the
bitmaps.

---

From: Sean Doran <[email-masked]>
Date: 08 Jun 2001 16:09:54 +0200

Iljitsch van Beijnum <[email-masked]> writes:

> their idea of the region.

So what happens in the case where a site connects to a
network which does not actually connect to the local
exchange point at all?  

X-Corp acquires geographically-assigned addresses from 
a local registry, then buys transit from ANet and BNet; 
ANet is connected to the local IX but BNet is not.  
How shall BNet advertise reachability to X-Corp?

ANet and CNet, both present at the local IX, have a
commercial falling-out.  Or a fibre cut.  Or the IX fails.
Or something.  This leads to a long-term outage in
_direct_ local connectivity between ANet and CNet; however
ANet purchases backup connectivity from DNet, one of
CNet's peers.  Y-Corp, a customer of CNet in another city,
now wants to send traffic to X-Corp (and vice-versa).
How can this happen?

The question in a nutshell, is: how does one deal with
"exception routing" in the event one cannot guarantee a
always fully-interconnected geographical area?

That is, if one draws an addressing abstraction boundary
around a geographical area rather than a topological area,
must one/can one/how can one guarantee that the enclosed
area can always be abstracted?

This is the riddle of the CIDR Sphinx.

        Sean.

---

From: Sean Doran <[email-masked]>
Date: 08 Jun 2001 16:48:38 +0200

"Tony Hain" <[email-masked]> writes:

Tony, thanks for the first rev of a draft!  I have some
comments and questions that I hope may help improve it.

> sites that connect to metropolitan scale exchanges. 

Do such exchanges exist?  I'm curious, since I haven't run into any,
even in Stockholm, where fibre is very close to free.

> Sites will have the choice to connect to either type of
> aggregation entity.

Can sites connect to both?  If no, is that a feature or a drawback?

> Any provider announcing a short prefix SHOULD be able to
> deliver packets to anywhere in the region, either
> directly or through other arrangements.  In the case
> where a service provider does not interconnect with
> others in its region it MUST advertise the longer
> prefixes associated with its customers.

What if the provider is connected and fully peered with
all the other networks using addresses from the same
aggregate, but is partitioned from some or all of them for
a period of time?

(An interesting thinking exercise is trying to figure out
how networks multihomed at other geographical exchanges,
and having multiple transit arrangements across those
exchanges, can determine which long-haul provider should
be used to reach a network that is ordinarily abstracted
behind an aggregate covering all the networks in a given
geographical area/surrounding a given IX.  You have
discovered one of the hard questions already, viz.:

> Another issue is the business model being flipped from
> the current destination's ISP choice determines sources
> routing; to one of source's ISP choice determines at
> least its first hop.

In other words, "how does the source make a correct
choice of next-hop?".

Let us know what you come up with, or if someone else has
properly solved this á la GSE or Ohta-multi-prefix.)

> through provider based allocations consistent with Aggregatable [RFC 2374].

Why not?  

How do multihoming entities who offer both fixed-line and dial access
accomodate this?

How far does this reach?  Does this include a dialup pool
in a site singly-connected to a provider?

>         dest lec would dest route within region

IXC and LEC are Americanisms, and moreover are an artefact
of a regulatory regime which is NOT global.  It's probably
a good idea to avoid terms like these in a document which
is designed to work for the whole Internet.  :-)

- --

If a large U.S. network has a number of peers and
paying transit customers in W. Europe (for example),
and each of these networks have customers that are using
both provider-assigned and IX-assigned addresses,
how should large U.S. network decide which of the
customers to send traffic to, if they are announcing only

> W. Europe               080000  :  000000  ->   1080:0000:0000

or

> LHR -    51.47 n    0.350 w             13B7:3B48:4D42

?

> to the entire concatenation, if not it will need to announce specifics.

mean that the U.S. network's x-Atlantic customers must
announce the individual customer prefixes learned at the
LHR exchange, and not announce the aggregate for LHR or
for W. Europe?

If this U.S. network has several competitors for transit
sold to networks across the Atlantic, as is the case today,
what becomes of the idea of announcing 1080:0000:0000 to anywhere?

(Think of what they would do to be able to announce 1080:0000:0000 to 
        -- competitors with no European customers
        -- customers who are multihomed to competitors
           with European customers
        -- customers who are multihomed to European networks
        -- customers who ARE European networks, but who
           operate in only one part of W. Europe
        etc.
Then think of what happens when the connectivity to one or more of
their trans-Atlantic customers fails.  This happens sometimes...)

BTW, if you are doing updates to your draft, this is not
very draft-y-language:  :-)
> Since 20 bits is nominally what tier-1's do today

        Sean.

---

From: Sean Doran <[email-masked]>
Date: 08 Jun 2001 16:55:34 +0200

Iljitsch van Beijnum <[email-masked]> writes:

> routing information in bitmaps

It would be nice if you would write up a draft proposing this.

There are theoretical strengths in map-exchange routing
systems, and such systems benefit from well-designed
packet-header encodings which express a path through a
topology discovered through the exchange of maps among routers.

Do you think that a scheme to encode physical-proximity
can coexist with a scheme to encode topological-proximity?
That could be a handy feature...

        Sean.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 8 Jun 2001 17:01:20 +0200 (West-Europa (zomertijd))

> It would be nice if you would write up a draft proposing this.

Ok.

> That could be a handy feature...

Do you mean both the physical and topological proximity of the same entity,
or just physical proximity for some entities and topological proximity for
others?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 8 Jun 2001 17:43:51 +0200 (West-Europa (zomertijd))

> How shall BNet advertise reachability to X-Corp?

Just as I said: both ANet and BNet announce the route to X-Corp on every
exchange point anywhere in the world where they are present.

However, other networks will probably only accept these routes at the
regional exchange point and a few others in neighboring regions. So if BNet
isn't present at these exchange points other networks will have to accept
those routes elsewhere, which doesn't help the whole aggregation idea but
guarantees connectivity.

> now wants to send traffic to X-Corp (and vice-versa).

Since X-Corp is also a customer of DNet (through ANet) DNet will also carry
the route everywhere. Also, if BNet sells full connectivity there will be
some point where traffic from CNet can reach BNet. So X-Corp is still fully
connected and can receive traffic from Y-Corp over Y-Corp -> CNet -> DNet ->
ANet -> X-Corp or Y-Corp -> CNet -> ??? -> BNet -> X-Corp.

> always fully-interconnected geographical area?

The answer is that the geographical area MUST always be fully
interconnected. This is easily accomplished by just increasing the area until
it is.

> area can always be abstracted?

I think you assume a fixed relationship between the area where the addresses
are used and the area where the routes are known. The only relationship
necessary is that the former falls within the latter.

Obviously, the geographic region in which the addresses may be used needs to
be well-defined and must be observed by everyone. But, every network should
be free to decide where specific routes for a region may live. This can be
just the region where the addresses are used and one other for redundancy, or
the whole continent or even the whole world.

Since all networks carry customer routes everywhere, there is no need for
networks to connect within the target region. A network may pick up routes
for a multihomed New York business in Sydney if it so desires. So even if
this network only connects to the transit networks for the New York business
in Sydney, there is still connectivity. But if for some strange reason the
network in Sydney has a customer in New York, the other networks will very
likely ignore this route in Sydney, because it falls outside their idea of
the area where specific routes to New York addresses are needed. This is a
somewhat unlikely situation, but it can still work if the other networks make
an exception and accept the New York route in Sydney from this network.

It all gets somewhat complex but the good thing is it should be possible to
deploy this type of aggregation within IPv4/BGP4 without breaking anything as
long as multihomed addresses are assigned geographically.

The only real problem is that of transit networks that are so large even the
number of routes from customers and customers of customers becomes too large
for the routers.

Iljitsch van Beijnum

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Jun 2001 10:43:00 -0700

This proposal is not attempting to provide the optimal 'one and only'
solution to addressing in the global Internet, and I specifically don't care
about waste since I know off the top that ~ 2/3 is unusable. What it is
trying to do is provide a specific tool for addressing the impact on routing
by multi-homed sites. It does not require renumbering as devices move,
unless the public demarcation at layer 1 changes as a result. It may not map
well with current topologies, though I would like to have some operators
show specifically where it breaks down.

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Friday, June 08, 2001 3:36 AM
To: Tony Hain
Cc: [email-masked]
Subject: RE: Regionally aggregatable address space for multihoming

- why 2 bit interleave? one bit makes it possible to use arbitrary
boundaries

2. The strictly geographic aggregation boundaries in this proposal won't fit
current network topologies. So either the networks will have to be changed
or
the aggregation will be less successful.

a workstation from one end of a hallway to another implies renumbering.
While

But what about this: in stead of using individual routes, we could encode
routing information in bitmaps. A 150 km routing precission would take 2^16
=
64k bits = 8 kilobyte to encode. A reachability bitmap for all neighborhoods
within a region would also take only 8k. But a 20 bit prefix would take
128k.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Jun 2001 13:20:14 -0700

> comments and questions that I hope may help improve it.
The more the merrier.

>even in Stockholm, where fibre is very close to free.
That wording was directly out of the aggregatable draft and I didn't have a
good reason to change it. In some ways I would consider at least the MSN-UK
& MSN-ASIA sites as directly connected to exchanges. At least the last I
knew they were co-lo with the exchange but may have had a telco fronting for
the physical exchange port.

>Can sites connect to both?  If no, is that a feature or a drawback?
There should be no problem with connecting to both. As I worked through this
their inbound traffic would take whichever path was shorter from any given
source, and it would be up to them which direction they sent the outbound.

>aggregate, but is partitioned from some or all of them for
This would require the obvious; either longer prefixes need to be announced,
or there will be black holes. This is no different from today where someone
announces access to a partitioned network.

>discovered one of the hard questions already, viz.:
Yes this is an area that needs much more detail. At a crude level it can be
viewed in the context of the PSTN where the transit provider is 'managed' by
the originator. Basically it would be up to the site network manager to
decide which transit provider he would be sending traffic to for various
parts of the world. If something partitions the result is no different than
today. Either the network that can't get there anymore has alternate
arrangements for transit, or the traffic is black holed.

>In other words, "how does the source make a correct
What does 'correct' mean? If I have transit agreements with ISP-ABC &
ISP-XYZ, I am either getting default service from them, or the global
default-free table. If I have the table and they both claim they can get to
the destination region, or I am simply have default, then it is up to me as
the source where I send the bits. With provider-based addresses the routing
system will shunt me to the shortest AS path to that destination, but with
this scheme the provider I hand the bits to would send them along its
preferred path to the region IX before deciding which local provider to
deliver them through.

>properly solved this a la GSE or Ohta-multi-prefix.)
The question I keep coming back to is 'who is deciding what is right, the
service provider or the site manager as the customer?' It clearly has to be
one of those two and not the protocol designer, but individual perspective
has a big impact here. I would argue that the customer would ultimately vote
with his wallet to define 'right and proper', so the service providers will
in turn beat on the protocol designers to get the tools to deliver that.
Minimizing the operational costs of the service provider is certainly one of
the components of 'right', but each scheme has to be balanced against the
costs it imposes back on the customer site.

>> network pop, as scaling routes to sites attached this way are best
>> addressed through provider based allocations consistent with
>> Aggregatable [RFC 2374].
>
>Why not?
For one the location of the endpoint is unknown. For another if a dial-pop
were scaled to handle 10,000 sites it would have to subsume the neighboring
addresses in the 2.5km square. Since dial-pops tend to be located in dense
areas using them with geo addresses would have the maximum negative effect.

>How do multihoming entities who offer both fixed-line and dial access
I struggled with this one until I realized that it doesn't matter in
practice. If the dial path were really just an intermittent connection
between routers at the same service provider then it would be reasonable and
expected that the geo prefix would be used on both and the site would simply
announce that as its prefix upstream. Interface metrics would bias the
providers IGP to do the right thing.
If the multi-homed site has both fixed-line and dial to different providers,
they would get one of these prefixes for the fixed-line, and a provider
aggregate prefix for the dial. I would expect local policy to prefer the
fixed-line prefix, but there is no protocol issue with having both. The
place this differs from today is that if one of those paths failed the hosts
would have to initiate mobile IP to maintain any existing connections.

>in a site singly-connected to a provider?
I would argue that it applies to anything where the real site location and
its topology is unknown. At first I had mobile systems in this same category
until I decided that the number of active nodes on a cell is low relative to
a dial-pop, and that providers are more likely to allocate a /56 in the
mobile device environment. In that case it would be feasible for the cell to
hand out prefixes based on the tower location, where the large dial-pop it
would not. If my assumption is wrong then I need to move mobile back to the
provider allocation side.

>> for layer-3 exchanges to work there has to be a way to do source
>>  routing within a region to select ixc : rest of the system dst based
>>  routing simple directory lookup on flat 48 bit site id
This is an artifact of the drafty nature of random thoughts. I welcome more
appropriate terms since transit would apply in both the local and long haul
cases. I am not sure how applicable this text is to reality though, as it
resulted from a conversation about layer-3 exchanges. If all the exchanges
are layer-2 there is no magic required, but for a site to influence policy
at a layer-3 IX there would have to be something like source routing.

- --

>> LHR -    51.47 n    0.350 w             13B7:3B48:4D42
This is an artifact of trying to use location info that would be easy for
the layer-1 installer to obtain mixed with text strings that have political
context. There would have to be at least 2 prefix announcements for the
political entity known as W. Europe to cover each side of the meridian.
Clearly the text before that table needs to make it clearer that they are
conceptual examples rather than entries that cover the entire named region.
In fact one of the things I was trying to do in the table preceding that one
was to come up with names for the scopes that had no political meaning.

>> Routing protocol should only announce a short prefix if the router
>> can get to the entire concatenation, if not it will need to announce
>> specifics.
>
I am not sure I understand the question, but for example if a site west of
LHR was accessible via both its geo and provider addresses, the announcement
toward the US would include the prefix for its provider and the prefix that
covered W. Europe west of the meridian (without doing the math, probably
1380::).

>what becomes of the idea of announcing 1080:0000:0000 to anywhere?
I need a picture to understand the question. Basically today's business
models are built around the concept that a site works with ISPs to arrange
traffic preferences toward itself. With this scheme the business model would
flip so that a site arranges for best carriage of its outbound traffic into
a region. If the network the site subscribes to does not have direct access
to 1080:: it needs to subscribe to a transit that will get there.

>their trans-Atlantic customers fails.  This happens sometimes...)
Again I am missing some context here. If a network were providing transit to
1080:: it would need to announce that, but if it only had a specific
customer set and didn't intend to provide access to all of 1080:: then it
would need to announce the specifics. I am getting a feeling that this
question is wrapped tightly around a business model where a site would
arrange for transit services toward itself via a specific provider. There is
nothing wrong with that, but in that case provider based addresses make more
sense. With IPv6 there is no reason a site is restricted to a single prefix
so there is no problem with having prefixes from a US-based and a
European-based provider as well as the location-based one. Address selection
rules will cause the longest match src/dst pair to be used.

>> performance, and it bounds the problem to the set of providers where
>the multi-homing occurs.
More random thoughts that need to be cleaned up before this goes in as an
I-D.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Jun 2001 14:50:17 +0200 (West-Europa (zomertijd))

> show specifically where it breaks down.

Ok, lets not dwell on the wasted address space or incidental renumbering. The
most important problem is the bad fit with existing topologies. What we
really need to eveluate this is a map with all the prefixes drawn in. In the
mean time, I believe there WILL be problems, the only question is how big
they'll be.

Since it is impossible to route strictly on geography alone (even if this
were a possibility, then there would only be one route so this would defeat
the purpose of being multihomed), my question is: why use such a strict
relationship between prefix and geography?

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 11 Jun 2001 09:23:21 -0700

> I believe there WILL be problems, the only question is how big
> they'll be.
I absolutely believe there will be work required to match what gets passed
in the routing tables with the desired traffic flows over the current
topology, or to modify the topology to align with this. If doing work
constitutes a problem then I guess your statement covers it.

> Since it is impossible to route strictly on geography alone (even if
> this were a possibility, then there would only be one route so this
> would defeat the purpose of being multihomed), my question is: why
> use such a strict relationship between prefix and geography?
Just like it is impossible to run dial modems faster than 1200bps, TCP
faster than 2 Mbps, or voice over a packet infrastructure. It is not
possible until we figure out how to do it. Note I am not proposing that
routers know about geography, but that a prefix they know how to deal with
be constructed out of something a telco installer can use to uniquely
identify a demarc.

For any given flow today there is only one route, the one defined by EGP/IGP
metrics. The fact that others exist is irrelevant until this one goes away
and a recomputation is done. With this prefix scheme (just like any existing
IPv4 one) there can be an unlimited number of parallel paths to the
destination and whichever one the source chooses is 'the only one' until the
source (or some intermediate router) chooses a different one. The difference
with this scheme is that the prefixes are structured on a global scale so
they aggregate well outside the scope of local provider interactions.

The only question I see as a sticking point is; will transit providers be
willing to charge for ingress offered loads in addition to the egress they
charge for today? If so they will be happy because they are getting paid to
carry traffic, if not they will really be against this since it would cause
them to carry traffic they are not getting paid for.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jun 2001 11:56:30 -0500

...
> interconnected. This is easily accomplished by just increasing the area until

This is my problem with this proposal, as it has been with every geo addressing
proposal over the last 5 years.

Because of this fact (you have to increase the area covered until it is
big enough to be flat-routable), I think that every geo area would
reproduce exactly the problem of entropy and default-route-table bloat
that we have in today's tiny little Internet. So I have little confidence
that this solution is scaleable to the 10 billion node Internet.

I think the only geo solutions that scale will be ones that involve
either encapsulation or goop-rewriting.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Jun 2001 21:30:24 +0200 (West-Europa (zomertijd))

> that we have in today's tiny little Internet.

When the number of routes per area grows, it is likely that the areas
themselves shrink, if only for this very reason. I'm not saying geographic
aggregation will magically make all the problems go away. However, it will
buy us two or three orders of magnitude, which is nothing to sneeze at.

> So I have little confidence

The number of nodes is not very relevant: you can fit 10 billion many, many
times inside the /48 a single customer would get. All that matters is the
number or routes and the resources needed to transmit, process and store each
route. In IPv4 aggregation isn't used to its full potential, for historical
and address depletion reasons (besides some ignorance) and because of
multihoming. In IPv6 it will be much simpler to agressively aggregate,
because there is little need to give ISPs only small blocks of address space
and have them come back for more as they grow.

So the main threat to the routing table are the multihomed networks. It would
be nice to know how many people or business will be multihomed in the future,
but there are no real figures. We only know that the number is still
relatively small but rising fast. I think we can get away with assuming an
upper limit on multihoming of 1% of the population. This is something like
10% of all businesses. Obviously anything that does better than 1% would be
great, but if we can achieve 1% we'll have bought a lot of time to think
about the other 99%.

With a world population of 10 billion looming, this would be 100 million
routes to multihomed networks. This is too much for any single router.
However, if we can break up the world into 100 regions, this would only be 1
(or rather 2) million per region, which is still a lot but managable, if not
now at least in the near future.

Combined with more efficient ways to store and transmit routes, this should
work for a long time to come.

The current routing paradigm is to store a lot of information about each
individual route, since aggregation makes sure there aren't very many similar
routes. But in a few years (decades) when 1% of New York City is multihomed,
this means more than 200k routes (to 100k destinations) within a fairly small
geographic region. If this market is serviced by 20 ISPs this means 10,000
routes per ISP, each taking more than 100 bytes of memory, even though these
routes are likely to be nearly identical.

If we assign all these addresses out of a single 131072 * /48 block and then
each ISP uses a bitmap attached to the aggregated /31 to announce whether any
of those /48's is connected to them, it only takes somewhat over 100 bytes
for the /31 + a 16k bitmap for a total of ~16500 bytes in stead of more than
a megabyte. Another ISP that peers with all of them will only get some 330
kilobyte of routing information in stead of 20 MB.

My idea for geographical aggregation can be deployed in the current IPv4/BGP4
Internet without breaking anything. The only thing that has to be done is
divvy up the world in regions and assign address space to multihomed networks
within the same region from an aggregatable block. Then networks can start to
filter out routes from blocks far away without the risk of suboptimal routing
to multihomed networks closer by if and when they want, with potential
benefits of new route storage paradigms in the future.

Iljitsch van Beijnum

---

From: Daniel Senie <[email-masked]>
Date: Mon, 11 Jun 2001 16:16:46 -0400

At 03:30 PM 6/11/01, Iljitsch van Beijnum wrote:
>but there are no real figures.

Assume somewhere approaching 100%. Businesses are relying on the Internet 
for mission critical applications. They want ways to not be out-of-business 
in the event of anything from a failure within the cables running down the 
telephone poles to a routing architecture or peering collapse at one of 
their upstreams (e.g. PSI and C&W snipping ties with each other).

Whatever solution, we need to find methods that at least PERMIT every 
business to be multi-homed. Yes, this is a hard problem to solve. I believe 
that's the scope of the problem, though, and we need to find a better 
answer than trying to convince people they should not multihome.

-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jun 2001 15:37:27 -0500

> buy us two or three orders of magnitude, which is nothing to sneeze at.

We are not communicating. You deleted the text that my initial "this"
refers to, but I think the exact opposite is true: the areas will have to
grow, since ISP interconnections are essentially random with respect to
geography. Also the cost pressure is going to be against local
exchanges and in favour of large regional exchanges. Given this (and
other points noted below) I don't see that geo addressing buys us
anything much at all, certainly not orders of magnitude.

> route. 

Ignoring household subnets, we can expect several orders of magnitude more
business subscribers than today - that's the significance of the total size
of the network. 

> In IPv4 aggregation isn't used to its full potential, for historical
> So the main threat to the routing table are the multihomed networks. 

Agreed.

> ...It would
> 10% of all businesses. 

The only safe design target is 100% of all businesses, i.e. several orders of
magnitude bigger than today's Internet. I see nothing that would limit it
to 10% or any other particular level; it is likely that multihoming just becomes
the normal thing to do.

> Obviously anything that does better than 1% would be

Not if the solution is worse than the problem. I believe that geo addressing
simply reproduces pre-CIDR IPv4, since it is based on unrealistic
assumptions about inter-ISP connectivity.
> now at least in the near future.

It would, if such a scenario was plausible, which I don't believe. 

> kilobyte of routing information in stead of 20 MB.

Perhaps, but every time there is a change they will get it all again instead
of just one item. There are multiple tradeoffs here. I'm all in favour of
summarisation but that is not the only performance issue.

> benefits of new route storage paradigms in the future.

Only if you revolutionise ISP interconnection strategies and find some way
to change the underlying economics.

Don't misunderstand me - we need a radical solution. I just don't think that
geo addressing, which is fundamentally the telephone solution, is radical
enough.

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 11 Jun 2001 16:44:46 -0700

Brian E Carpenter wrote:
> Also the cost pressure is going to be against local exchanges
> and in favour of large regional exchanges. Given this (and
Take the example of just an 8-bit prefix using my proposal. The globe
divides into 128 regions, with 68 unusable (32 are polar, 36 are basically
water). Of the remaining, I count 16 that map into current
telecommunications centers. While some neighboring regions may find it
advantageous to leak full routes between themselves, there should be at
least 12 that end up summarized. Yes a region has flat routes, but it
doesn't need more than 3/4 of the table, and will probably do better than
that. The interconnection robustness at this scale is fairly high, so we
could get some gain. Within the regions, it becomes a mater of local
politics and business practice as to how much further the plan can go.
Certainly it will be more difficult in either Europe or the US than all the
others combined, but if you write off those 4 regions as hopelessly
intertwined there is still an opportunity for significant gain in the rest
of the world.

> The only safe design target is 100% of all businesses
With a geo plan you get 'all sites', and don't need to worry if it is a
business or not.

> Not if the solution is worse than the problem. I believe that
> geo addressing simply reproduces pre-CIDR IPv4, since it is based
> on unrealistic assumptions about inter-ISP connectivity.
Only over a given scope. The CIDR roll out effort also showed what
backpressure from the top could do to constrain entropy. It also showed what
happens if you push too hard. When you try to over-engineer and enforce
controls for maximum optimization you will loose control and be back where
you started. This is where the rewriting the goop plan falls flat, because
they are targeted at absolute optimization in the middle, without concern
for systemic impact.

> Only if you revolutionise ISP interconnection strategies and
> find some way to change the underlying economics.
Geoff Huston should be stepping up to this one. There is no need to change
human nature, just provide a reasonable tool for aggregation then charge for
carrying explicit routes when people insist on them. Match the economics to
human nature rather than trying to invent a technological restraint system.

> Don't misunderstand me - we need a radical solution. I just
> don't think that geo addressing, which is fundamentally the
> telephone solution, is radical enough.
It may not be for the long run, but we need something to get IPv6 off the
ground in the mind of ISPs. So far they are complaining that it offers
nothing to solve the immediate scaling problem with provider based
addressing; so the obvious step is to remove all reference to provider from
the address. Other than cases of enforced portability, this is not the
telephone model. There, as the address space was divvied up, the provider
boundaries happened to align with a political notion of geography. A WGS-84
based plan is even devoid of political boundaries.

Tony

---

From: Geoff Huston <[email-masked]>
Date: Tue, 12 Jun 2001 16:50:59 +1000

>human nature rather than trying to invent a technological restraint system.

Ok - I'll step up to this.  The theory is fine, but the practice is harder 
to identify.

I find it hard to conceive as to what a 'geography' may be when its cheaper 
to cross the Atlantic by submarine cable, station to station, than it is to 
do last mile at either end. We had this model in our collective industry 
heads that "distance = cost" and that local geographies see some cost 
benefit in locally interconnecting. In the current communications 
environments the cost of local regulatory regimes appears to be greater 
than the cost of distance, and a least cost community of common benefit has 
no geographic counterpart.

We are certainly on the horns of some form of dilemma - conventional 
routing wisdom indicates that some form of hierarchy is one of the few 
tools that address route scaleability - through hierarchies fine detail is 
obscured at a distance, and these details only become visible at a local 
level. However, the cost of circuitry is inexorably dropping - customers 
find it cost effective to drag two or more local circuits to two or more 
upstreams as the most cost effective response to resiliency requirements. 
Providers find it cost effective to drag long haul circuits all over the 
place as a means of bypassing various components of a locally-provided 
upstream transit service. At what point in the long haul over-supply market 
will the long haul providers start to look at end customers as a potential 
long-haul customers, and at what point will multi-homing become a non-local 
problem? What appears to be happening is that "geographic" locality and 
"least cost" locality don't match all that closely. (Yes this "long 
distance is cheaper" sounds far fetched, but its also far a far fetched, 
but current, reality which makes a Tokyo - LA circuit cheaper than a Tokyo 
- Osaka circuit.)

So inside all this I see and understand that IF we had a pretty solid 
"distance = cost" dominant cost model then there would be a fair incentive 
for local interconnection - to some extent. If we _also_ had a different 
inter-provider settlement model where every packet was purchased from its 
originating provider and on-sold to its terminating provider (to borrow 
some PSTN settlement terms with a reselling margin equal to the marginal 
cost of transit), then there would be an even stronger case for local 
interconnection, and, furthermore if the packet accounting settlement rates 
were fixed according to some imposed industry model, then the case for 
regionally aggregateable addresses would be pretty solid.

Needless to say, by this stage you are pretty close to the PSTN original 
interprovider settlement model and about 1,000,000 miles away from the 
Internet of today.

There are a number of theoretically stable inter-provider economic models 
that could support an Internet. There are very few models which also allow 
a transition from today's reality to an end point of universal adoption of 
the particular model. I have this depressing view (*) that metro routing 
aggregation is one of these models which could work, but the path from here 
to there is not visible to me at any rate.

(*) depressing to me at any rate, because most of the routing scaling tools 
infer the use of hierarchies, which in turn require a pretty substantial 
shift of current operating practice.

There may be some other approaches: if you concede that a full routing 
table at some point in the future will have some considerable cost in terms 
of specialized support machinery, then the market will sort itself out 
through the use of different route filters applied to peers, customers and 
upstreams. The implied route scaling cost of multi-homing would become as 
explicit cost of protocol scaling, and there would be a solid economic 
incentive to single-home. But, that's a big concession, and one which has 
no basis in what we are seeing today. Today its the protocol which is 
showing signs of scaling stress, not the routing engines, and attempting to 
work out an economic model which applies local pressure for a greater 
common good of protocol stability is a tough ask.

    Geoff

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Jun 2001 12:43:50 +0200 (West-Europa (zomertijd))

> no geographic counterpart.

I think you are painting too bleak a picture. Let me tell you a story. Five,
six years ago the Internet business was in its infancy here in The
Netherlands. We were connected to the net over British Telecom with a frame
relay line to the UK over a leased line to Amsterdam. So if we wanted to
connect to someone else in Holland, the first hop would be London and then
the packets would take a tour of Europe over Geneva or Stockholm and back to
The Netherlands (99% of the time Amsterdam). Or the traffic would flow over
New York, Washington and/or New Jersey. The reason for this was
simple: everybody needed a good connection to the US and the large networks
wouldn't interconnect with the smaller ones at the local exchange. There
wasn't enough European traffic to justify many links between European
countries. (I did some counting back in those days and 45% of the traffic was
to Dutch destionations, 45% to US destinations and only 10% to other European
destinations.)

Today the situation is completely different. Large networks such as
UUNET/MCI/Worldcom have pan-european networks so in many cases traffic takes
the shortest route to other European destinations. Transatlantic capacity is
very cheap, but not as cheap as housing a router at the Amsterdam Internet
Exchange and exchanging tens or hundreds of megabytes without any traffic
charges. Some of the really large networks still don't want to interconnect
with the smaller ones, but even the traffic between the small networks is
enough to make it worth connecting.

> but current, reality which makes a Tokyo - LA circuit cheaper than a Tokyo 

You have convinced me at least to the point where I have to admit that just
assuming that interconnectivity will become more and more local in the future
is a dangerous assumption.

But rather than invalidate the argument for geographic aggregation you merely
weaken it. Even if it's cheaper to connect to LA than to Osaka for someone in
Tokyo, it's still cheaper to connect to LA than to New York or
Johannesburg. To put it more generally: even if long distance is cheap, it
still doesn't make sense to bypass one hub and connect to one further
away.

Also, there are other reasons why long distance isn't fun. First of all,
there is the delay. Some applications just can't tolerate an extra 80 ms
round trip time. Another problem is that if you get traffic for a very large
region together at one point, it is much harder to handle. Today's routers
can maybe do 10 Gbps. So if you have 1 Gbps worth of customers in a city, it
doesn't make much sense to aggregate traffic for 25 cities.

> upstreams.

Yes. Combined with the current practice this is a very bad thing: if I run
defaultless and I start to filter out routes to multihomed networks, I can't
reach them at all. If there is a regional aggregate at least there is a
fighting chance.

> The implied route scaling cost of multi-homing would become as 
> incentive to single-home.

Not really. The people paying for the bigger routers aren't the same ones
that are deciding to multihome. But that doesn't mean we can't create such an
incentive. If a scalable way to do multihoming costs the networks more money,
they can charge their customers more for the service. Just as long as the
people who make the costs are also the people sending the bills, unlike the
current situation.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Jun 2001 13:49:06 +0200 (West-Europa (zomertijd))

[Problem with geo addressing: regions are big]

> geography.

I guess this is true for the really large networks. Maybe this is because
they've lacked a good incentive to interconnect at more locations. Geographic
aggregation could be the necessary incentive. They are already present in
many locations and local fiber is cheap, so it could happen. On the other
hand, it may not.

> Also the cost pressure is going to be against local

I'm inclined to believe that there will be more local interconnection, but of
course everything has to work regardless of what we believe.

Do you agree that it would buy as at least one order of magnitude? That means
three regional exchanges for North America and Europe and one for every other
continent.

> to 10% or any other particular level; it is likely that multihoming just becomes

100% would be something like a billion. I think there is a natural limit
because connecting to two ISPs is twice as expensive as connecting to one.

A billion routes means we absolutely have to aggregate on something, probably
on more than one thing at a time.

> geo addressing, which is fundamentally the telephone solution, is radical

Hey, I'm just as radical as the next guy. But if we can't come up with a way
to make a billion routes work before there are a million, the routers will
choke and we don't have an internet anymore.

I think I'll write up a draft on introducing geographic information into the
current routing architecture. In BGP this could be a community, in IPv6 it
could also be the top 8 bits in an end user /48. Then every user can decide
for herself to implement it or not.

Maybe it would help to make it possible to aggregate on other things than
just the beginning of the address. IPv6 addresses are large enough to hold
lots of good stuff we can potentially aggregate on. For instance, we could
use two 16 bit field that hold the AS number of the two ISPs for a multihomed
network. Then an ISP would simply announce aggregates like:

4567:ISP::   mask ffff:ffff::
4567:0:ISP:: mask ffff:0:ffff::

With every kind of aggregation there is the problem of holes. If the customer
is disconnected from ISP 1 and ISP 1 still announces the aggregate, ISP 1 has
to know it has to forward the traffic to ISP 2 at some point. With just two
ISPs this can be done without exchanging any more specifics by just dumping
the traffic at the other network if there is no local (= this network) more
specific route to the customer.

Iljitsch

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 12 Jun 2001 07:29:22 -0700

At 06:43 12/06/01, Iljitsch van Beijnum wrote:
>UUNET/MCI/Worldcom have pan-european networks so in many cases 
>traffic takes the shortest route to other European destinations. 
>Transatlantic capacity is very cheap, but not as cheap as housing 
>a router at the Amsterdam Internet Exchange and exchanging tens 
>or hundreds of megabytes without any traffic charges. Some of the 
>really large networks still don't want to interconnect with the 
>smaller ones, but even the traffic between the small networks 
>is enough to make it worth connecting.

        It is still the case that metro circuits within most major
European cities are most often *more* expensive than equally
sized circuits that run between countries.

        Further, Amsterdam, London, and Stockholm are exceptions
in that each is both a major European city and each has a plausibly
health IP exchange point.  There are a much larger number of
major European cities.  Most have no exchange point at all.
Some have a very small one that isn't really viable at present.

        However, let me suggest that giving and disagreeing
about examples aren't really the focus here, because the world 
is a much larger place than the EU (or the US or AU for that 
matter :-).

        We need a routing/operational/business model that supports
multi-homing globally, not just regionally, and that supports
widespread multi-homing of end users in a manner that does not
adversely impact the health of the global routing system.

        The mere fact that in many places (not all, just many)
local-loop charges are higher than long-distance charges means
that the model we need must be economically sensible when the
long-distance is less expensive than the local loop.

Regards,

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 12 Jun 2001 07:31:15 -0700

At 07:49 12/06/01, Iljitsch van Beijnum wrote:
>I guess this is true for the really large networks. Maybe this is 
>because they've lacked a good incentive to interconnect at more 
>locations. Geographic aggregation could be the necessary incentive. 
>They  are already present in many locations and local fiber is cheap, 
>so it could happen. On the other hand, it may not.

        Local fibre is cheap in some places, expensive in others.
In some places, long-haul connectivity is much less expensive
than local connectivity.  In other places, the inverse is
probably true.  When designing a global system, few generalisations
can be accurate.

        If we boil the above down, ISPs are incented to connect
over low-cost links, with regards to the distance of the link.
At the end, economics will dominate those business decisions.

        Given that, I don't see how trying to force a local
exchange system will be effective anytime soon.  And I don't
necessarily think that forcing such will actually provide
significant improvement.  I'm open minded about the latter,
but would need to see more substantial explanation of how
such actually improves the health of the global routing
system (something notionally similar to a paper in ACM CCR
describing the reasons for improvement in global routing system
health would be a nice start :-).

Cheers,

Ran

---

From: Tony Li <[email-masked]>
Date: Thu, 14 Jun 2001 14:04:35 -0700 (PDT)

| Don't misunderstand me - we need a radical solution. I just don't think that
 | geo addressing, which is fundamentally the telephone solution, is radical
 | enough.

Here's a radical idea:

How about we stop trying to repeat the decade-old debate about routing
architectures and focus on getting multihoming into IPv6?

We decided a long time ago, for better or for worse, that we were not going
to introduce a new routing architecture with IPv6.  We need a multihoming
solution that at the very least halts the global routing table explosion.
If we can't find one, then we have a bigger problem to be sure, but let's
focus on trying to converge on something.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Jun 2001 13:47:43 +0200 (West-Europa (zomertijd))

> focus on trying to converge on something.

Let's see if we can agree on the problem:

The large number of multihomed network is responsible for growth of the
routing table, which we don't want because:

- it takes too much CPU power to process routing updates
- it takes too much memory to store the table
- it takes too much CPU power to look up routes when forwarding packets

Is stopping the routing table growth the best way to address these
problems? If so, the next step is to choose an approach, such as:

- not allowing or restricting multihoming the way it is done now
  This means we need alternatives, such as a good way to select the best
  address when a host has more than one and ways for higher layers
  to survive address changes.

- find a way to aggregate multihomed routes
  On what should we aggregate? Topology, geography?

- ???

I think the discussion so far shows that each approach has serious drawbacks,
but just waiting until the perfect solution comes along doesn't seem to work
either. So we need a way to select a best approach in lieu of a perfect one.
What do we value more? Effectiveness? Efficient operation? Simplicity?
Compatibility with current practices? How can we evaluate all of this if we
don't make assumptions about the future of the Internet?

---

From: "Alec H. Peterson" <[email-masked]>
Date: Fri, 15 Jun 2001 11:34:31 -0600

----- Original Message -----
From: "Iljitsch van Beijnum" <[email-masked]>
To: "Tony Li" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; <[email-masked]>
Sent: Friday, June 15, 2001 05:47
Subject: Re: Regionally aggregatable address space for multihoming

>   to survive address changes.

Well, multi-homing nowadays doesn't necessarily involve selecting the 'best'
route, it just selects a valid route (the lack of any QoS makes trying to
select the best route on a wide-area scale futile IMO).  So, until inter-domain
QoS becomes a reality, making finding the best route (or in this case, the best
address) a requirement probably won't help.

With this in mind, I think we can more easily come up with a valid multiple
address solution by simply stating that the network needs to find 'a' route
between the two end-points.

Alec

---

From: Tony Li <[email-masked]>
Date: Fri, 15 Jun 2001 14:44:46 -0700 (PDT)

| Let's see if we can agree on the problem:
 | 
 | The large number of multihomed network is responsible for growth of the
 | routing table, which we don't want because:
 | 
 | - it takes too much CPU power to process routing updates
 | - it takes too much memory to store the table
 | - it takes too much CPU power to look up routes when forwarding packets
 | 
 | Is stopping the routing table growth the best way to address these
 | problems? 

Some fine points:

- We will never actually 'stop' routing table growth.  It will continue.
  The question is the rate.
- We would very much like to keep that rate below Moore's law.  It will
  become exceedingly painful if and when it exceeds Moore's law.  The
  hardware will simply fail to keep up.

 | If so, the next step is to choose an approach, such as:
 | 
 | - not allowing or restricting multihoming the way it is done now
 |   This means we need alternatives, such as a good way to select the best
 |   address when a host has more than one and ways for higher layers
 |   to survive address changes.
 | 
 | - find a way to aggregate multihomed routes
 |   On what should we aggregate? Topology, geography?
 | 
 | - ???

We already have a unicast routing architecture for V6 that dictates how
aggregation is to be performed.  The goal of this WG is to decide on a
strategy for how do deal with multihomed sites in some way other than what
we do today (global visibility of all multihomed sites without any
aggregation).  

There are two proposals on the table:

      - GSE
      - multiple addresses

The goal of this WG is to decide on one, without bloodshed, in less than an
epoch.  So far, things aren't looking good.

 | I think the discussion so far shows that each approach has serious
 | drawbacks, but just waiting until the perfect solution comes along
 | doesn't seem to work either. So we need a way to select a best approach
 | in lieu of a perfect one.  What do we value more? Effectiveness?
 | Efficient operation? Simplicity?  Compatibility with current practices?
 | How can we evaluate all of this if we don't make assumptions about the
 | future of the Internet?

This is supposed to all be captured in the (alleged) requirements document.

Tony

---

From: Joe Abley <[email-masked]>
Date: Mon, 18 Jun 2001 16:07:26 -0400

> even in Stockholm, where fibre is very close to free.

Sorry about the late comment, but there's one in Wellington, New
Zealand, which has been in operation for some time. It is run
by Citylink (see http://www.citylink.co.nz/).

For what that's worth :)

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 18 Jun 2001 17:35:45 -0400

> routing table, which we don't want because:

Is it just multi-homing that is at the source of the issue? What
about the prefix-based inter-AS traffic engineering that Geoff
alluded to in Minneapolis?

What I mean is: suppose the multi-homing problem could be solved
such that the the pervasiveness of multi-homing had no impact on
the amount of state held in the DFZ. Would there still be a state
problem to solve?

To what extent can we deduce the problems that edge sites are
trying to solve?

The analysis I have seen to date tries to make deductions from
snapshots of the state in the DFZ, as viewed from various
different angles. It occurs to me that there is a limited toolbox
available for edge sites to accomplish a number of things. Being
able to hear someone hammering in the distance doesn't tell you
what they are trying to build :)

Joe

---

From: Tony Li <[email-masked]>
Date: Mon, 18 Jun 2001 14:39:18 -0700 (PDT)

| > The large number of multihomed network is responsible for growth of the
 | > routing table, which we don't want because:
 | 
 | Is it just multi-homing that is at the source of the issue? What
 | about the prefix-based inter-AS traffic engineering that Geoff
 | alluded to in Minneapolis?

That is certainly a problem that needs to get solved.  However, that is far
outside the charter of this WG.

Tony

---

From: Randy Bush <[email-masked]>
Date: Mon, 18 Jun 2001 14:52:40 -0700

> alluded to in Minneapolis?

that is the ptomaine effort, yes?

randy

---

From: Joe Abley <[email-masked]>
Date: Mon, 18 Jun 2001 17:54:54 -0400

> that is the ptomaine effort, yes?

It is. Sorry about the noise; I have too many lists being filtered
into a single folder, and I had become confused over which list
this thread belonged to.

Joe

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 19 Jun 2001 15:06:41 -0700

> There are two proposals on the table:

I no longer have a copy of the original GSE proposal.  Does anybody have a
good pointer to it?

PF

---

From: Andy Heffernan <[email-masked]>
Date: Tue, 19 Jun 2001 17:06:57 -0700

> I no longer have a copy of the original GSE proposal.  Does anybody have a

ftp://ftp.uu.net/pub/mo/draft-ipng-gseaddr-00.txt
ftp://ftp.uu.net/pub/mo/draft-ipng-gseaddr-00.ps

---

From: Geoff Huston <[email-masked]>
Date: Wed, 20 Jun 2001 10:08:34 +1000

>that is the ptomaine effort, yes?

no - the ptomaine effort attempts to say that lets continue to use the 
inter-domain routing protocol as connectivity + policy + TE and lets work 
how to identify the 'noise' associated with policy + TE and limit its 
promulgation with the routing fabric to some loosely defined boundary.

This strikes me as a stop gap rather than an enduring scaleable solution, 
in my humble opinion. I dont mean to devalue ptomaine as I think that 
buying time is good if you have a problem, but my cautionary note is along 
the lines of not mistaking the band aid for the cure. :-)

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Wed, 20 Jun 2001 10:05:41 +1000

>alluded to in Minneapolis?

Obviously the two are associated in some way.

Once you have multiple connections the next motivation is to increase your 
efficiency - having one circuit packed to the brim with data and the other 
idle is not very efficient - if there is minimal incremental additional 
cost involved, the next step is to attempt to balance your normal inflow 
and outflow across the multiple circuits. Because there is no direct cost 
associated with advertising prefixes into the global routing table, and 
because advertising fine-grained prefixes selectively down particular paths 
achieves the objective of incoming traffic engineering, folk do it.

>the amount of state held in the DFZ. Would there still be a state

The problem of traffic engineering is quite a challenging one: what you are 
attempting to do is to force remote systems to make a particular choice as 
to what paths are used to reach _you_  - its the reverse of the normal TE 
process. Now how do you communication that information to the remote system 
in a way that manages to constrain the choices available to the remote 
system to match your desired policy? Somehow theres an information transfer 
that has to happen. If its not the routing system then another information 
passing architecture is needed in addition to routing. i.e. you cannot 
'solve' this problem by attempting to finesse thelast mile in a regional 
space - there remains a larger issue that must also be addressed.

>what they are trying to build :)

The bgp architecture draft I wrote and the March IETF plenary presentation 
attempted to highlight this. There is the constant sound of hammering and 
the BGP tables reflect this. If you want the routing system to deal in only 
AS-based connectivity then you can limit the stress in the routing tables 
BUT you also have to work out how to overlay policy / TE onto of this 
connectivity fabric, and thats the bit which I believe is the tricky one.

   Geoff

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Jun 2001 03:47:46 -0700

> the lines of not mistaking the band aid for the cure. :-)

i think we're actually in agreement on what is in multi6 and what in
ptomaine, and that promaine is an attempt to stall until there is a cure.
and this was fairly clearly set out in ptomain's original statements.

i suspect where we may disagree is the etiology of the disease.  i suspect
that this may be one of those viruses where those infected think that they
are healthy as it is only their neighbors who suffer from the symptoms.

randy

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 10:23:12 -0700

I've been tossing around the following basic approach to the
multihoming/renumbering problem, and am wondering if folks think it is worth
pursuing.

Like GSE, the basic idea is to isolate site numbering from global numbering
by allowing site border routers to rewrite prefixes as packets pass in and
out of a site.  Unlike GSE, however, the ID is not the sole identifier of
the host.  The full address is still the identifier, but multiple (full)
addresses are used to identify the host.  A packet received with any of the
set of addresses identifies the host.  In this sense, the idea is like
SCTP's use of multiple addresses.

I call this approach GxSE, to convey the idea that like GSE the address has
global, site, and end-system address elements, but unlike GSE, addresses
with multiple globals are used to identify a host (thus the 'x' after the G
conveys a multiplier).

There are multiple ways one could design GxSE.  Here are the primary aspects
of what I have in mind:

Every host knows at least one (and typically only one) address for itself,
called the self-known address (SK address).  The SK address may or may not
be globally routable, but must be globally unique.

In addition to the SK address (from here on I talk as though there is only a
single SK address---it should be understood that there can be multiple of
them), there is a set of one or more globally routable addresses (GR
addresses) for every host.  The host does not need to know its GR addresses
(nor do site-internal routers).  All of the addresses (GR and SK) for a host
have the same "site" and "ID" parts, but different "global" parts (aka
"prefix").  An SK address may also be a GR address.  The (publicly
reachable) DNS entry for a host will typically contain all of the hosts' GR
addresses.

Each of the GR address prefixes of course represents that assigned by an
ISP.  There is a site border router attached to that ISP with that GR
prefix.  The site border router knows the SK prefixes for the site.  (All
hosts in a site do not necessarily have the same SK prefix, but if they
don't then the site border router must know the SK prefix for every host.)
The site border router knows all of the GR prefixes for the site, not just
its own.  (Again, all hosts in a site do not necessarily "have" the same GR
prefixes, but if they don't then the site border router must know the GR
prefixes for every host.  Clearly it is better if all hosts have the same SK
and GR prefixes, and this should be normal operation.)

For every "connection" (where a connection is defined as a distinct
address/protocol/port 5-tuple), the host keeps a list of (globally unique)
addresses of the destination (or partner) host.  It knows which of these is
the SK address, and whether theSK address is routable or not.  This full
list identifies the host (not just the SK address).  Two connections with
partner hosts with different lists, even if they use the same SK address,
are considered to be different hosts.

Packets transmitted by a host contain its SK address as the source address,
and one of the GR addresses of the partner host as the destination address.
Typically the destination address will be that of the most recently received
source address, but not necessarily.  When the packet passes through the
site border router, the router replaces the global prefix part of the SK
address with that of the ISP to which it will route the packet.

When a packet is received by a site border router incoming, the site border
router replaces the GR prefix with the SK prefix of the destination host,
and forwards the packet into the site.

The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6
extension header---the address-list extension.  This header is typically
added by the site border router as the packet exits the site.  (It could
also be added by the source host, but this would require the host to know
its GR addresses which is the thing GxSE is trying to avoid.  Nevertheless,
a site could choose to operate this way.)  The header is added typically
only for the first packet sent in either direction (with the return header
indicating whether the forward header was received).  A GxSE-aware host
would tell the site border router to add the address-list extension by
attaching a different extension header (the "please add the address-list
extension" extension, or address-list-trigger extension).  Both extension
headers are of the "if unknown, skip over this option and continue
processing the header" type.

The typical exchange would go like this:

SH-->SSBR: |IPv6 head|ALT ext head|transport|
SSBR->DH:  |IPv6 head|ALT ext head|AL ext head|transport|
DH->DSBR:  |IPv6 head|ALT ext head (acks first ALT)|transport|
DSBR->SH:  |IPv6 head|ALT ext head|AL ext head|transport|
SH->DH:    |IPv6 head|transport|
DH->SH:    |IPv6 head|transport|

(where SH=source host, SSBR=source site border router, DH and DSBR are same
for destination, ALT=address-list-trigger, AL=address-list)

This is the basic idea.  Lots of unworked details....

For API, I imagine that the full list of addresses (GR+SK) gets handed up to
the upper layer, if it cares to know.

Pseudo-header checksums and IPsec would I suppose be based on the SK address
only (not the GR addresses).

Not sure how to deal with IPsec regarding the extension headers---due to
inadequate understanding of this stuff.

The extension header "handshake" needs to be worked through...might need to
be 3-way etc.

There are some destination address selection issues, to deal with the fact
that SK addresses work within a site but not necessarily outside the site.
Two hosts in the same site would want to use the SK address, not a GR
address, when talking to each other.  One approach is two-faced DNS.
Another might be to go ahead and have DNS return the GR addresses, but after
the address-list extension headers are exchanged, the hosts would recognize
that they share the same SK prefix and could start using that (and
subsequently bypassing the site border router).  Note that IPv6 with
site-local prefixes has the same sorts of issues.

As for transition, site border routers need to know which hosts are GxSE
aware and which aren't.  For those that aren't the baseline behaviour would
be for site border routers would agree to all use the same GR prefix on
outgoing packets for each host.  Obviously if the site border router with
that GR crashes, then communications breaks, but this is no different from
today's situation.  The site border routers could potentially also try to
proxy GxSE on behalf of the non-GxSE aware hosts (for the case where the
partner host is GxSE aware).  In this case, the site border router would
need to keep enough state to know to attach the address-list extension on
the initial packet only. (An address-list extension minus the
address-list-trigger extension would convey to the destination host that the
source host is non-GxSE aware, but the site border router is.)

As for the issues brought up by draft-ietf-ipngwg-esd-analysis-05.txt, they
largely don't apply because GxSE uses fully overloaded addresses, just more
of them.  For instance, there is no ID-to-address mapping issue because the
ID is never used alone as the identifier.  A host cannot pretend to be
another host, in essence because the full set of addresses is what
"identifies" a host, not a single address (and certainly not an ID alone).
So, for instance, if a rogue host tries to pass itself off as having another
host's SK address but its own GR address, it won't matter because the
"identity" of the rogue host would be considered to be the whole list of
addresses, and so wouldn't be confused with the "true" host (with the same
SK address but the correct GR address).

Note that GSxE doesn't prevent renumbering altogether---it would still be
required when two sites merge.  But renumbering would not be necessary
because of changing providers.

Comments?

PF

---

From: Alain Durand <[email-masked]>
Date: Wed, 20 Jun 2001 11:16:14 -0700

>be globally routable, but must be globally unique.

How can you build an SK with such properties?

         - Alain.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 11:21:51 -0700

> How can you build an SK with such properties?

Simplest thing would be to get a prefix assigned from your ISP, but on a
permanent basis.  In other words, the ISP would leave that address assigned
to you forever, even after you change ISPs.  If you changed ISP, the prefix
stops being routable, in the sense that a packet routed to that prefix would
reach the ISP but then get dropped.  As far as I know, there is no reason to
need to independently distinguish a non-routable SK address from a GR
address.

If you object that ISPs won't do this...then have some other registry do
it...

PF

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 20 Jun 2001 11:55:15 -0700 (PDT)

Paul,

TCP endpoint being associated with multiple addresses was
discussed in draft-nikander-mobileip-homelessv6-01.txt.
Isn't renumbering equivalent to a mobile node moving to
a new foreign link ? In that case why can't renumbering
event trigger all the TCP connections to generate a
new secure message (known as binding update in mobile IPv6)
to tell its peer about the new address ? After sending
this message, TCP connections start using the new address.
Why wouldn't this work ? 

If we are looking for a solution that would not change
the end host's implementation, then the above is not
suitable. So, is the requirement that the
renumbering event should be completely transparent to
the end hosts ?

-mohan

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Wed, 20 Jun 2001 15:14:11 -0500 (CDT)

Mohan, Paul-

Unless I'm really misunderstanding something here, I was under the
impression we're talking about fixed-site multihoming and address space
change renumbering - the bane of every large site's existence.  As such, I
think we're not talking about mobility.  We're talking about the v4
equivalent of a site moving from one /?? to another.  Or, the BGP
equivalent of changing your AS Path completely.  Possibly millions of
connections simultaneously moving.  In this case, you really don't want a
whole bunch of superfluous packets if you can avoid them.

Now, this also happens to address transparent multihoming in the failover
case, similar to how SCTP handles it, except instead of failing over to a
new address, the GR prefix only changes.  In plain terms, you're binding a
socket between the SK addresses only, the rest is smoke and mirrors.  
Routing changes wouldn't really have a large impact, since the border
routers are essentially rewriting the headers.  Think of it as NAT with a
1:1 translation combined with the equivalent of a set of BGP announcements
via several different AS's.  If one route goes down, the GR prefix would
change on one end of a connection, but the SK address would stay the same,
and you're connected between SK's.  BGP for hosts :)

Again, that's how I'm reading this, I could very well be FAR off-base
here.  I was thinking about this, though...this could tie into BGP where
you're announcing valid GR and SK prefix pairs.  This sort of comes closer
to the idea of landmark routing, where you basically are routing to a
point closer to the destination without knowing where the destination
really is, and then letting the landmark routers (the SSBR and DSBR) route
you as it sees fit to go the rest of the way.

In the event of a routing mishap, a specific GR/SK pair of an active
connection would become invalid, forcing a change of GR mapping at the
SSBR on the packet on the way out, transparent to the host.  Furthermore,
if a host was experiencing high packet loss, latency, or jitter, it might
ask the SSBR to try a different GR prefix.  It might be useful to allow
the announcement of GR prefixes to declare certain QoS properties, so a
host could request a GR that's designed for low latency or low jitter, for
example.  I digress, though.

Just my $.02 and my interpretation.  Always interested to know if I'm
being silly.

-Taz

On Wed, 20 Jun 2001, Mohan Parthasarathy wrote:

> Date: Wed, 20 Jun 2001 11:55:15 -0700 (PDT)
> From: Mohan Parthasarathy <[email-masked]>
> To: Paul Francis <[email-masked]>
> Cc: [email-masked]
> Subject: Re: An idea: GxSE
> 
> Paul,
> 

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 13:16:26 -0700

> this message, TCP connections start using the new address.

Strictly speaking it would work.  The need for secure messages makes it
expensive, as does the need to explicitly renumber hosts.

> renumbering event should be completely transparent to

GxSE obviously changes the host implementation (though there is a migration
path).

But yes, the requirement here is that the renumbering event be transparent
to end hosts (and also to internal routers).  I think this is important for
the same reasons that O'Dell expresses in GSE.  I think that sites will not
want to renumber, and will look for cheaper alternatives, of which there are
two:

1.  Convince the ISPs to advertise its prefix across the default-free
routing zone (i.e., what we do today with IPv4)
2.  Use NAT (also what we do with IPv4 today).

The goal of GxSE is to provide a solution that is about as easy as NAT, but
provides better functionality (mainly, connections survive in the face of
the site border routing crashing).

PF

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 Jun 2001 22:32:59 +0200 (CEST)

On Wed, 20 Jun 2001, Paul Francis wrote:

> out of a site.

[...]

> Comments?

Well, I'm new here so I don't know to what extend all of this has been
discussed before.

But if we're going to push this problem to the end systems, aren't there
any easier and more compatible ways to do it?

Making a TCP session use multiple addresses would be a possibility. An
option to negotiate extra IP addresses for a stream would certainly make
TCP more complex but this could be reasonably backward compatible, it
wouldn't require any changes in the IP layer or the routers and as a bonus
it would allow multiple paths to be used concurrently for extra bandwidth.

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Wed, 20 Jun 2001 15:43:30 -0500 (CDT)

> it would allow multiple paths to be used concurrently for extra bandwidth.

Why not just use SCTP?  Why reinvent the wheel?

-Taz

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 13:44:55 -0700

> think we're not talking about mobility.  We're talking about the v4

Right, this is not about mobility.

> socket between the SK addresses only, the rest is smoke and mirrors.

GxSE doesn't bind just the SK address to the socket, it binds the complete
set of addresses (SK and GR) to the socket.

> and you're connected between SK's.  BGP for hosts :)

You are reading too much into the SK.  The purpose of the SK (I should have
said this in my original note) is so that one end knows what the other end
originally sent.  Waving my hands a bit, this means that, if the host put
the SK address in the application, the application at the other end would be
able to interpret that SK as "the whole list of addresses bound to this
connection".

The NAT comparison is (sadly) appropriate.  In particular, the site border
router would have to go in and change application headers, for instance the
SIP SDP, in order to change an SK address on the inside to a GR address on
the outside.  (Or I suppose I can imagine a sockets call in the host like
getcurrentaddresslist() that sent a ping to the site border router or the
partner host and got the list of addresses back, so that those applications
that cared could learn it...though it begs the question what is the
difference between this and renumbering...)

Your BPG/landmark routing comparisons went over my head.

PF

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 13:50:49 -0700

> Well, I'm new here so I don't know to what extend all of this has been

I'm not sure either...I imagine a variant has come up in the past and been
quickly stomped down...

> any easier and more compatible ways to do it?

The multiple addresses/renumbering approach currently used by IPv6 pushes
the problem to the end system.  Other approaches that get border routers to
coordinate and tunnel with each other push the problem to the middle.

GxSE is somewhere in the middle...it doesn't push the whole problem to the
host in the sense that the host doesn't need to be renumbered.  But it does
push much of the problem to the host.

PF

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 20 Jun 2001 13:51:54 -0700 (PDT)

> Why not just use SCTP?  Why reinvent the wheel?
In SCTP, i think you have to know all the addresses at the beginning
of the connection. Here, the new address is not known until
renumbering happens.

-mohan

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Wed, 20 Jun 2001 15:57:59 -0500 (CDT)

> set of addresses (SK and GR) to the socket.

Why not bind the SK if it's globally unique?  There is 1 SK, and multiple
GR's.  Why not bind only the SK's and keep a table of valid GR's, so you
know that it is truly valid?  You already know that the GR you're bound to
is wrong, why not assume the same for both sides, simplify the host
software, and use the GR similar to an MPLS label (I hate to say it, but
it reminds me a bit of exactly that...you just can't nest them).

Basically, this would be taking a lesson from both BGP and MPLS, applying
the simplest part to the host, letting the router do what it already does,
changing far less overall, and still getting the same results.

> able to interpret that SK as "the whole list of addresses bound to this

This is the description of an SCTP association.  This is almost exactly
SCTP through NAT.  My suggestion above takes a similar idea, but lets the
network do most of the multihoming instead of the protocol.  Otherwise
you're basically talking about using NAT and SCTP together and calling it
something else, with a few small tweaks and dropping the heartbeat, etc.

This same effect can be generated using SCTP through NAT with ECN and a
small change to allow ECN to trigger instant address switch instead of
backing off first.

> Your BPG/landmark routing comparisons went over my head.

Hrmmm...a shame, because I think that's what would really make this very
useful.

-Taz

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:00:04 -0700

> of the connection. Here, the new address is not known until

Or more accurately, with sctp the source needs to know its own addresses at
the beginning.  This is what GxSE tries to avoid.  Otherwise, though, the
mechanism has a lot of similarities.

PF

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Wed, 20 Jun 2001 16:01:39 -0500 (CDT)

> of the connection. Here, the new address is not known until

Actually, here the address is known as a possibility all along, just isn't
used, from my understanding.  Furthermore, you learn all of those on the
ACK to the first packet.  SCTP uses a 4 way handshake and starts between 2
addresses, doing the about same thing...giving the other valid addresses,
and learning the other side's other valid addresses.  Also, with Add IP,
you can add an address while the association is up.  Basically, there's no
advantage in that case, as I understand it.
-Taz

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Wed, 20 Jun 2001 16:04:12 -0500 (CDT)

> mechanism has a lot of similarities.

This is accurate.  However, you can add IPs with the Add IP extension
(that really is needed anyway, this is just more fuel for the fire, so to
speak).

-Taz

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

> know that it is truly valid?

We may be talking at cross purposes.  What is the difference in your mind
between binding to the SKs and GRs versus binding to the SK and keeping a
table of GRs?

> SCTP through NAT.

Yes.

> My suggestion above takes a similar idea, but lets the

Could you give me a clear explanation of your suggestion?  I don't
understand it.

Also, regarding Add IP (another message from you about SCTP came in while I
reply to this one...), you can't do this securely unless there is a trust
relationship.  Otherwise any spoofer can send a packet out of the blue with
its GR and somebody else's SK and hijack the connection.  Maybe this is what
you mean by "bind to the SK only"---allow any GR to be used once the SK is
established?

The reason GxSE binds the whole list of addresses from the beginning is to
prevent spoofing.  If we have the luxury of establishing a secure
relationship between both ends, then may as well use HIP.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jun 2001 16:14:19 -0500

Not all applications are TCP or SCTP. UDP applications don't
(in principle at least) have enough state to respond to
an address update, do they?

   Brian

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:36:22 -0700

> >
> I don't understand how you would know about the whole list of addresses.
> I assume that the trigger to add the list of addresses happens during
> the beginning of the connection. Renumbering can happen always after
> that so that your peer does not know your new address. Am i missing
> something ?
>

yeah.  GxSE does not try to bind to new addresses that appear after a
connection is already established.  New prefixes cannot be used by old
connections.  I don't think maintaining connections in the face of new
prefix assignments is a very important problem to solve.  It won't happen
*that* frequently, and overlapping being-added prefixes and being-deleted
prefixes for a time will suffice for all but the longest-lived connections.

PF

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 20 Jun 2001 14:26:42 -0700 (PDT)

<snip>

-mohan

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Jun 2001 14:25:22 -0700

> how do you communication that information to the remote system in a way
> that manages to constrain the choices available to the remote system to
> match your desired policy?

when 'remote' means they have no technical or financial incentive to do you
the favor, then 'constrain' seems far too strong a term.

> connectivity fabric

i have an arch-capitalist friend who i would normally expect to step in
here and observe that it is not clear that you HAVE TO.  in fact, it might
be in the interest of only a few.  perhaps, when it comes to traveling this
road, he has fallen arches, or maybe it is feet of clay, or fear of capital
punishment. :-)

randy

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 20 Jun 2001 14:38:33 -0700 (PDT)

> an address update, do they?
Some UDP applications do a connect(). In this case there is state
in the kernel which can react to an address update. In other
cases it would be a problem. Do you mean to say that UDP
applications might remember about destinations it needs
to communicate with, for a long time ?

Most of the documents about renumbering talks only about
TCP connection surviving and so we are a bit carried
away here i guess..

-mohan

o

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Wed, 20 Jun 2001 16:51:32 -0500 (CDT)

> prefixes for a time will suffice for all but the longest-lived connections.

To reiterate for you, Mohan, we're not taling about mobility.  We're
talking about large-scale changes, not one or two hosts, but thousands of
hosts.  If a new prefix is added, it doesn't affect a few hosts, it
affects a large subnet.

I'm hoping Paul and Alain remember who I am, but I don't think I've ever
met you, Mohan.  I'm Jon Mischo (nickname is Taz) from Motorola's Advanced
Network Technologies group.  Anyway, I'm involved in ROHC, somtimes in
TSVWG (for SCTP) and used to be involved in Seamoby and Sigtran (also for
SCTP).  Mobile IP greatly impacts my world (for better or for worse) due
to the nature of our work.  I'm also a fan of Nuclear War :P Oh, and Alain
gets mad when I read and edit drafts in the back of his WG meetings, so
don't do that, he doesn't like it ;)  Introductions out of the way.  As
usual, I digress...so back to the point.

Mobile IP handles the case of a host moving around on a network.  Here
we're addressing the issues of a network moving around on a backbone and
in address space.  What we're trying to solve for here is how to keep a
host unaware that there have been sweeping network changes, including its
own address, while still giving it the ability to operate as if nothing
happened, with confidence that its sessions aren't being hijacked.

And Paul...I'm working on a reply to your previous email...just have to
think about how to say it best.

-Taz

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 20 Jun 2001 15:16:05 -0700 (PDT)

> hosts.  If a new prefix is added, it doesn't affect a few hosts, it
Sure. I was only trying to draw an analogy i.e Mobile IPv6 which i am
familiar with. Are you saying that we are not interested in solving
the above mentioned problem ?
 
> in address space.  What we're trying to solve for here is how to keep a

When you are moving around, you are getting new prefixes and the old
prefixes will not be valid after sometime. (The difference between
this and mobility is that the old prefix is considered to be valid
in mobility)

> happened, with confidence that its sessions aren't being hijacked.
What do you mean by keeping the host unaware ? Does it mean that
you don't want the renumbering event to be known to the end hosts ?
It will be known without which it can't configure new addresses.
So, i am missing something.

-mohan

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Wed, 20 Jun 2001 17:09:18 -0500 (CDT)

This is a good argument for what I was talking about, actually.  Either
way, though, with UDP you'd just use a tunable timeout parameter.  There
are MANY UDP applications that remember about their destinations for a
long time.  This is the idea behind using RTP for VoIP, as well as how
many network video games, etc work, to give some examples.

UDP doesn't mean short connections, it just means more loss-tolerant or
more time-sensitive connections.  The key difference is that the vast
majority of state for UDP is kept in the client.  In the case of GxSE,
you'd need to implement something closer to what I was talking about for
UDP to work effectively, since the host would not be keeping state, and
you'd have to have the DSBR rewrite the headers since the host wouldn't be
maintaining a list of valid GR/SK pairs.  Again, this is where SK binding
comes into play.

Really, here you would have a lookup that returned the GR addresses and
you'd have your SK address.  One of the GR addresses would then be chosen
to attempt the connection.  Once you reach the far host, you'd request the
SK for that host.  You'd then reference that SK in your packets, with
confidence that your SSBR would map both your SK and his SK to their
appropriate GR/SK pairs.

It may even be appropriate to use the GR returned by the lookup to query
your SSBR for a local SK style address it knows about.  Then you are
sending packets between an SK address and a virtual SK (basically you're
doing reverse NAT here).  The SSBR is then doing all of your remapping.

I think this is right...I really think we're approaching the point where
we should start writing a draft or two just to flesh out the ideas, so we
can all understand them.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 21 Jun 2001 08:26:24 +1000

>the favor, then 'constrain' seems far too strong a term.

Indeed when favours run out, then constraining choices is precisely what is 
going on. i.e. there are no technical or financial incentives for the party 
who is sending the traffic to take the destination's preferred path, but 
there are financial incentives for the destination to coerce the sender to 
make a particular choice. Interdomain traffic policy always struck me as a 
variant of the Dyjkstra (sp?) brides problem - the starting case is that 
the sender has unilateral choice as path choice to the destination, and the 
destination responds to this by attempting to constrain the sender's choice 
set. This game is being played out in the inter-AS space because, like the 
commons, there is no impediment to abusing this common space.

>road, he has fallen arches, or maybe it is feet of clay, or fear of capital

If you want the interdomain connectivity protocols to scale then separating 
out policy / TE 'negotiation' into a distinct protocol interaction would 
address some of the concerns regarding scaling of the inter-domain space as 
a connectivity protocol convergence issue. The imperative of "HAVE" comes 
for broader issues surrounding the integrity of the whole, as represented 
the sum of all these individual policy-based transactions.

As an addendum to this posting I would have to say that I think I'm abusing 
the tolerance of the multi6 list with this topic, and I promise that I'll 
stop. Please accept my apologies if you already think I've gone well out 
into the weeds topic-wise. As interesting as these topics are to me, I 
think that I've taken up more than enough of the multi6 crew's time, and I 
try and stay focused on multi6 in further postings to this list.

Randy, Do you have any suggestions as to an appropriate list to continue 
this discussion? Is ptomaine willing to tolerate a continuation of this 
discussion?

thanks,

   Geoff

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Jun 2001 15:36:33 -0700

> this discussion? Is ptomaine willing to tolerate a continuation of this 

i suspect 'encourage' would be a more appropriate word.

randy

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Wed, 20 Jun 2001 18:08:05 -0500 (CDT)

> the above mentioned problem ?

Understandable.  But yes, that's what I'm saying.  What we're discussing
here isn't mobility, and we're not designing for mobility.  However, it
does have some good benefits for mobility.

> this and mobility is that the old prefix is considered to be valid

You're not moving around a lot.  Again, this isn't mobility.  This is
often the result of a circuit or router going down in the case of
multihoming.  In thse situations, the prefix is never invalidated, it's
just useless for a while.

In the case of renumbering, if you have a protocol that does a good job of
distributing the prefix information, it is pushed far enough out that you
don't have to worry.  Furthermore, we're talking about address space
that's unique but doesn't have to be routable.  This way you know it will
be rewritten, but the host doesn't really care about that.  In some cases
the space may be routable and you may still own it, but you aren't using
it anymore, in favor of better aggregation and routing.

One of the biggest nightmares in the service provider field (I know,
before I was in R&D I was a network engineer for a very large ISP) is
renumbering because you have a region that's grown and you either have to
add a new subnet and grow your tables due to the aggregation you've lost,
or renumber that region into a larger subnet you have.  In this scenario,
you would just change the GR the space fell into, keeping the same SK, so
the host doesn't know it's somewhere else in the network.

> So, i am missing something.

That's exactly what it means.  The host doesn't configure new
addresses.  In SCTP it can, but we're talking about GxSE, where there are
routers further upstream that are doing the remapping/rewriting for
you.  The host doesn't have to know.  Of course, Sean's point of this
requiring a different checksum scenario is very true.  We'd have to move
to a checksum scenario closer to what UDP-lite uses, where you don't have
a single checksum for the entire packet, but actually break the packet up
into portions that are reliable and unreliable.  Obviously the addresses
in a packet are completely unreliable for checksum purposes in this
scenario, and need either to have their own simple checksum that's
verified and recomputed at every rewrite, or you just checksum as many
bytes from the header as will stay the same regardless, and pray what you
get at the other end makes sense.  Of course, if it doesn't, it'll likely
be rejected anyway.

-Taz

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 20 Jun 2001 19:15:43 -0700

Not to extend the discussion, but this is the point I was trying to make
(clearly less eloquently):

> ...the starting case is that the sender has unilateral choice as
> path choice to the destination, and the destination responds
> to this by attempting to constrain the sender's choice ...

The question is why does the destination care? Answer: because the current
business models are built around optimizing inbound costs for the
destination. If the business model were traffic origination based rather
than termination based, the destination would not care where the originator
inserted the bits. While changing business models is not a function of
protocol design, existence or lack of appropriate tools may have some
influence.

Tony

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Thu, 21 Jun 2001 07:58:55 -0700

>
> 1. Somebody asked how to allocate the SK prefix. This is easy enough to
> do in several ways, but a painless way is to use the site's RFC 3056
> prefix, at least for the first ten years or so of allocations.

This works too.

>
> 2. Paul says that sites would have to renumber when they merge. I'm not
> convinced that is a requirement. If two sites with different SK prefixes
> merge, it seems to me they can simply route between those two prefixes
> internally. Even if renumbering turns out to be a good idea in the long
> term, it can be done piecewise - no flag day needed.

The problem is not internal routing, but external.  If you continue to use
different GR prefixes for the two merged halves after merge, then you don't
have to do anything...just leak internal prefixes into the opposite half as
you suggest---so at least you avoid the flag day.

If you do want both halves to use the same GR prefixes, which sooner or
later you might, then the site border routers need to know how to translate
incoming packets.  If both halves use the same SLA's, then the only way the
border router can know how to do that is by keeping a list of individual
hosts and thier prefixes.  Still kindof doable---the site border router can
get a dump from DNS or something---but not what you'd want.  So eventually
you do have to do some renumbering when sites merge.  But at least this is
not at the whim of your ISP...

>
> Apart from that I am worried about the amount of complexity you are asking
> hosts to implement. For some types of host (e.g. handhelds) this will be
an
> issue. I think there could be a simplified version of GxSE lurking in
there
> somewhere.

There is a tradeoff here.  If you did GSxE, then you might be able to avoid
some of the existing multiple addresses complexity in the handheld...i.e.,
one SK address instead of several global addresses.  Obviously too early to
know the trade-offs.

PF

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2001 09:22:43 -0500

Another couple of points:

Apart from that I am worried about the amount of complexity you are asking
hosts to implement. For some types of host (e.g. handhelds) this will be an
issue. I think there could be a simplified version of GxSE lurking in there
somewhere.

   Brian

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 22 Jun 2001 11:53:37 +0200 (CEST)

> be globally routable, but must be globally unique.

I think that today there are distributed (multi-party) applications
that depend on an application being able to extract a globally routable 
IP address of the box (so that it can be passed to peers etc).
It would be good to run the idea of apps not knowing their GR addresses
passed folks with better application knowledge.

It the applications need to know the GR addresses but the host itself 
doesn't know them then it seems like you need a way to map from SK 
to GR addresses.

> added by the site border router as the packet exits the site.  (It could

Having intermediate nodes change the length of the packet does cause some
issues with path MTU discovery. That's why encapsulation is normally used
(e.g. in mobile IP) to deal with this.

> only (not the GR addresses).

It would be good to look at the effects of bit errors in the source GR address.
With no IPv6 header checksum and the GR address not being part of the
pseudo-header checksum means that it is unprotected. (Perhaps having a
checksum on the address-list extension can catch this.)

   Erik

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Fri, 22 Jun 2001 09:44:43 -0700

> doesn't know them then it seems like you need a way to map from SK

I think you are mis-understanding the model a little here (cause I wasn't
clear about this aspect in the original message).  Applications should
operate in terms of passing the entire list of addresses around.  SK
addresses should not be thought of as some magic token that can be used by
applications to learn GR addresses.  Applications should know the GR
addresses from the start.  So here is the basic model:

1.  A DNS lookup on the FQDN will return you the GR addresses (if you are
outside the target's site), suggesting that at least for the initial
contact, the application should be aware of the FQDN not the addresses.
2.  Applications should be aware of the complete list of addresses, not just
the SK address.  Obviously this is tricky if a host doesn't know its own
complete list of addresses.  But what I have in mind is this:

The socket API has a set of calls like this:

    getcurrentaddresslist1(sock_id)
    or
    getcurrentaddresslist2(sk_address)
    or
    getcurrentaddresslist3(fqdn)

When host A talks to host B, host B learns the list of addresses by making
one of the above calls.  Ideally host A never "identifies" itself to host B
in the application, host B simply does the first call while the socket is
still up, learns the whole list, and uses the whole list whenever it
identifies A, either internally or when talking to a third application at
host C.  If for some reason it is necessary for host A to send its identity
to host B in the application layer, host A should preferably use its FQDN,
but could also use its SK address.

The second or thir call could be then used by host B if the socket has
closed.  If host B's "network layer" (kernel or whatever) has forgotten the
list, then both the FQDN or the SK address could be used by DNS to obtain
the list, but the third one is more likely to succeed (and requiring that
reverse lookups on SK addresses work even if they are not globally routable
is possible but puts more constraints on SK addresses).

Ideally the first call would be used wherever possible.

Anyway, once host B's application gets the whole list, which it can do
without host A knowing what the list is, it can send the whole list to host
C so that subsequently host C can access host A without resorting to DNS.

I don't think the above is real pretty---it is the cost one pays for
isolating site addressing from global addressing and getting rid of the
renumbering burden.

> (e.g. in mobile IP) to deal with this.

An alternative approach would be to have the host attach a syntactically
correct address-list extension, but with empty place-holders for the GR
prefix list (instead of the "address-list trigger" extension I suggested
before).  There would be a learning mechanism, whereby address-list
extensions would have a field indicating the number of GR prefixes, and this
field would be set on incoming packets.  So if the host doesn't know the
number of prefixes, it would use a default, say 4.  If it chooses too small
of a number, then it would learn that in a subsequent return packet.  Of
course now the partner host would not have the complete list, but this would
not be a disaster.  (Alternatively the sending host could always add one
more GR prefix placeholder than it thinks it needs, to catch the case where
a new prefix has recently been added.)

Of course one could take this one step further, and simply have the
destination host return the source host's list of GR prefixes in the return
packet, so that the source host knows it too (on a connection by connection
basis---this would not be something the source host could generalize about
once the connection was closed).  This could be an option selectable by the
application...(ah, the complexity creeps in!!!!)

> checksum on the address-list extension can catch this.)

Thinking about it a bit more, pseudo-header checksumming the SK address,
when in fact it isn't even sent end-to-end, sounds kind of stupid...maybe
better to cover just the ID part of the source address (and the full
destination address, which doesn't get translated), and let it go at that.

PF

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Jun 2001 10:32:45 +0200 (CEST)

> addresses from the start. 

How does an application learn its own GR addresses?

> contact, the application should be aware of the FQDN not the addresses.

For the peer this is fine. But what about itself?

> but could also use its SK address.

I see how that can be made to work.
The point is that I think this is a significant change in the way applications
deal with their own addresses. Today they can just use getsockname(int
sock,...) and pass this to peers.

Thus whatever the new architecture needs to be for applications (handling 
addresses) the ramifications of this is best understood by folks with
apps clue. I don't know how many of those we have on this list.

BTW: Working out how IKE would work in the GxSE architecture would be
a good test. (Even though IKE isn't a multi-party application it passes
IP addresses around.)

> a new prefix has recently been added.)

I had the same idea. At least it works better than changing the length
of the packets in the border routers.

> application...(ah, the complexity creeps in!!!!)

In a sense your moving the complexity of the routing system to handle 
scalable multihoming to the transport and applications layers.

  Erik

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Jun 2001 10:37:01 -0400

>scalable multihoming to the transport and applications layers.

        It would be sensible to move the complexity of multihoming
into the set of systems that actually are using multihoming.  Right
now sites that aren't multihomed have to pay the operational costs
caused by multihomed sites.  

        If this meant moving some multihoming complexity into the 
transport layer (compare with SCTP), that would seem entirely reasonable, 
to me at least.

Ran

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 25 Jun 2001 23:52:32 +0900

sorry if i missed something, but why are we designing a new protocol
	in this working group?  it was chartered that it won't.

itojun

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Jun 2001 17:01:55 +0200 (West-Europa (zomertijd))

Going back a bit...

> 2.  Use NAT (also what we do with IPv4 today).

Renumbering is a pain, but running BGP or NAT is too. I'm not convinced
people are as desperate to avoid renumbering as you say. And this is in IPv4.
In IPv6 it somewhat unlikely that workstations that do not run any services
will be configured manually, and both prefix advertising and DHCP can handle
renumbering without too much of a hassle.

The only systems that are hard to renumber are those that others frequently
connect to. Since you wouldn't want your web server to magically get a new IP
address and become unreachable when it gets a new MAC address or someone else
uses the same MAC address these are configured manually. But how many web
servers do most organizations run?

> the site border routing crashing).

Ok, but why try to do both at the same time?

There are quite a few things we can do to improve NAT:

- make it stateless so there is no longer a single point of failure and
  scalability is improved
- add a "NAT control protocol" so applications can instruct the NAT box to
  enable/disable certain features and find out what their "real" address is

There is one thing that NAT has going for it that will kind of break in GxSE:
the hosts don't need to do or know anything special. But both the host and
the router have to support GxSE. Obviously, when every host runs GxSE this is
no longer a problem, but this is not something that is going to happen any
time soon.

And the same thing goes for using multiple addresses concurrently: if we can
implement this without requiring cooperation from the router, it becomes much
more usable. Many organizations have their routers supplied by a service
provider and are not in the position to update the software or even change
the configuration. If they can get a second router from a second ISP and the
hosts can use both connections at the same time and use each as a fallback
for the other, this would be a very good thing.

I've looked at the SCTP RFC some people mentioned, but this is a completely
new transport protocol. I don't think this is the way to go: this
functionality should be added to TCP or to IP.

A good all-purpose solution would be to implement a protocol in IP that
monitors connections (yes, even UDP "connections") and negotiates fallback IP
addresses with the other host when it detects that the connections stay up
for more than a certain time. (It makes no sense to do this for short DNS or
HTTP transactions: these benefit more from trying the different addresses
for a hostname and caching the unreachability information.) Then if an ICMP
unreachable message comes in the destination address for every connection is
changed to one of the fallback addresses.

The protocol for negotiating more addresses could be fairly simple: the
receiving system sends a challenge with a simple one time identifier and the
sending system responds to the challenge by returning the identifier and the
addresses to be used along with an indication of which is preferred. More
complex authentication schemes can be implemented as options.

Of course there should be an API so applications can see and control which
addresses are used.

The next stage would be to adapt TCP to use multiple addresses at the same
time. This way it is possible to optimize for delay, packet loss or bandwidth
or to use the full bandwidth of the combined connections.

A "source addresses a:b:c::/d are now unreachable" broadcast from the routers
might also help but is not really necessary.

Iljitsch van Beijnum

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Jun 2001 11:11:12 -0400

>        in this working group?  it was chartered that it won't.

        I don't see a new protocol being designed yet.  I
do see that various approaches to handling IPv6 multihoming
are being discussed.  Discussion is a fine thing.

Ran

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 25 Jun 2001 11:45:07 -0400

> 	there are a lot of IPv6 implementation already out of the door.
> 	we need to concentrate ourselves to *operational* solution that are
> 	deployable on implementation that are available today (= NO NEW CODE).

i do not believe that we will be able to produce a satisfactory
multhoming solution without new code.

					- Bill

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 26 Jun 2001 00:30:59 +0900

>are being discussed.  Discussion is a fine thing.

	i agree discussion is a fine thing, but when we have a goal to settle,
	sometimes we need to limit ourselves to achieve that goal.  multi6
	charter clearly says that, i believe...

	you guys are now talking about, under "GxSE" discussion:
	- new site board router implementation that would rewrite topmost
	  bits in the packet
	- new host implementation that would recognize peer as a set of
	  addresses
	why are they not "new protocol design"?  if they are not the new
	protocol design, there's no such thing as "protocol design".

	there are a lot of IPv6 implementation already out of the door.
	we need to concentrate ourselves to *operational* solution that are
	deployable on implementation that are available today (= NO NEW CODE).
	of course, it is just my opinion.  thanks.

itojun
PS: i have not been too vocal (sorry about that), but i have submitted few
drafts, running experiment with others, and such.  i would like to
report again about RFC2260-ish multihoming with operational results.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Jun 2001 18:36:33 +0200 (West-Europa (zomertijd))

> multhoming solution without new code.

I don't think the geo solutions need new code. (At least mine doesn't.)

Obviously, if new code is not an option, the solution is very likely to be
less effective. Also, new code is not really a problem, as long as each site
can implement it at their own pace.

Unless I overlook something there are basically four ideas to keep the growth
of the routing table as a result from multihoming to a minimum:

1. NAT and other address rewriting ideas. Pro: works today. Con: NAT box is
   a single point of failure, sessions don't survive address change.

2. Layer 4 mobility. Pro: implemented in the hosts, support for
   multihoming at the NIC level. Con: a lot of new software.

3. Geo addressing. Pro: no (new) software necessary, works in IPv4. Con:
   routing table effect may be as little as one order of magnitude.

4. More efficient routing information encoding (such as bitmaps). Pro: same
   hardware can accomodate several orders of magnitude larger routing table.
   Con: many things: new protocol versions, new software, etc.

Obviously, a single solution can implement more than one idea, such as 1 and
2 for GxSE.

I think all of these ideas have enough potential to warrant further
investigation, even if the time scales for implementation are very
different.

Iljitsch van Beijnum

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Daniel Senie <[email-masked]>
Date: Mon, 25 Jun 2001 12:45:33 -0400

>- make it stateless so there is no longer a single point of failure and

This is not necessarily a stumbling block for NAT. There are many NAT 
implementations out there which handle redundancy through the use of 
duplicate, cooperative hardware, just as well as the web load balancers 
which can't be a single point of failure. There are also some which handle 
multi-homing without the use of BGP by using address blocks from separate 
links and managing load and failover.

>   enable/disable certain features and find out what their "real" address is

Please go read the RSIP documents. There are a LOT of problems with this, 
not the least of which is there may be multiple layers of NAT between a 
workstation and the global address space. It is quite problematic to deal 
with these cases, and they ARE common.

>no longer a problem, but this is not something that is going to happen any

And since NAT doesn't provide a reliable end-point address in some cases, 
there's no way to put servers behind it. Or peer-to-peer neworking 
applications.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Jun 2001 12:39:10 -0400

>        charter clearly says that, i believe...

        Limiting ourselves so that we rule out possible solutions
pre-maturely is not helpful to actually achieving the goal.

>        of course, it is just my opinion.  thanks.

        It is also not required by the charter that only "no new code"
approaches be discussed here.  It is also the case that, compared with
IPv4 deployment, IPv6 deployment is quite small.  As a vendor, I can't
find *any* potential IPv6 customers that aren't members of the set 
{Japan, GSM/WCDMA operators, GSM/WCDMA systems integrators}.  I hope
this will change, but that seems to be today's reality for paying
customers.

        Myself, I doubt that any approach that is operationally
practical and resolves the IDR routing table issues caused by
multi-homing can be found that requires "no new code".  I'd be
tickled pink if someone demonstrated such an approach, but haven't
heard about one here so far...

Yours,

Ran
[email-masked]

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 26 Jun 2001 01:47:40 +0900

>heard about one here so far...

	well, there are at least two.
	draft-yu-simple-ipv6multihoming-01.txt
	draft-ietf-ipngwg-ipv6-2260-01.txt

itojun

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2001 12:02:54 -0500

> multhoming solution without new code.

The text I suggested weeks ago for the requirements draft was
intended to specify very precisely what is and is not acceptable
in the way of new host code. When we get the requirements agreed,
we can decide which solutions are worth exploring.

   Brian

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Mon, 25 Jun 2001 12:48:41 -0500 (CDT)

Itojun-

I understand how you feel, however, I feel rather strongly that we should
do this the right way from the start.  One of the biggest problems with
NAT is that it was an afterthought, thus broke many things.  We're not
designing a protocol here, just ways to handle certain situations.

Furthermore, we're discussing technology in its infancy.  There is no
reason not to explore the possibilities.  Remember, WE make the rules, so
we might as well look at all the options to the good ones.  These
decisions will be with us for at LEAST a decade, let's make decisions we
can deal with.

-Taz

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Randy Bush <[email-masked]>
Date: Mon, 25 Jun 2001 10:31:41 -0700

as we have no running code, i suggest we try to understand the needs, then
how they might be achieved, and then, and only then, can we say whether code
will need to change or not.

considering the vast and pervasive v6 deployment to date as compared to its
expected lifetime, i suspect we can afford to get it right.

randy

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Mon, 25 Jun 2001 12:44:40 -0500 (CDT)

Well said, Randy.

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 26 Jun 2001 02:56:42 +0900

>designing a protocol here, just ways to handle certain situations.

	i disagree about the "from the start" part.  the deployment is already
	started here and there.  maybe this is because i'm in Japan, but
	i feel it way too late to make any changes to the way routers/hosts
	work.

	also, remember why GSE proposal was not integrated into IPv6 - 
	IPv6 is designed based on IPv4 experiences, and tries to benefit
	from the success of IPv4.  if we add too many fundamental design
	changes into IPv6 (like 8+8 address rewrites on routers)
	we may not be able to success in IPv6, like IPv4 did.

>decisions will be with us for at LEAST a decade, let's make decisions we

	well, IPng effort was started year 1992 and now it's year 2001.
	i don't really agree with the "infancy" argument.
	you may notice that the email have went through IPv6-to-IPv4
	translator to the mail list server (it may show the evidence on
	Received: lines).

itojun

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 20 Jun 2001 14:15:15 -0700

Yes.

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Mon, 25 Jun 2001 12:57:04 -0500 (CDT)

> 	draft-ietf-ipngwg-ipv6-2260-01.txt

We appreciate the reiteration of existing drafts, however, please keep in
mind we are a young working group and want to do things RIGHT.  Our
charter is only our first charter, this may very well change.  I would
respectfully request that we stop talking about limiting the scope of the
conversation, and wait until after the requirements phase to do so.  The
beauty of the requirements phase is that open discussions like these can
produce new requirements we hadn't thought of before.

Thank you,
-Taz

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Mon, 25 Jun 2001 13:13:58 -0500 (CDT)

> 	i feel it way too late to make any changes to the way routers/hosts

I work for Motorola in Advanced Network Technologies.  We are painfully
aware of v6, both in Japan and in cellular IP.

> 	we may not be able to success in IPv6, like IPv4 did.

Yes, I understand this, but a lot of things have changed in v4, and what
we are trying to do here is make v6 better.  v6 is not widely deployed.
We are trying to design things that will work seamlessly, so it is a
choice of whether or not to implement/when to implement.

> 	translator to the mail list server (it may show the evidence on

This is multi6, not IPng, and multi6 is young.  Furthermore, we have the
chance to do things right instead of kludging them as we go along.  My
vote is for doing it right ahead of time.  v6 is still very young.  Anyone
deploying it already knows there is still work being done on it and that
some of this work may affect the future.

-Taz

---

From: Tony Li <[email-masked]>
Date: Mon, 25 Jun 2001 11:13:28 -0700

| 	also, remember why GSE proposal was not integrated into IPv6 - 
 | 	IPv6 is designed based on IPv4 experiences, and tries to benefit
 | 	from the success of IPv4.  if we add too many fundamental design
 | 	changes into IPv6 (like 8+8 address rewrites on routers)
 | 	we may not be able to success in IPv6, like IPv4 did.

One of IPv4's biggest failures is its 'success failure' scenario.  It is
failing precisely because it has been so successful.

If IPv6 does not address the routing architecture issues in IPv4, it is
doomed to the exact same fate, at the exact same time.

Change or die.  It's that simple.

Tony

---

From: Steve Deering <[email-masked]>
Date: Mon, 25 Jun 2001 11:45:48 -0700

I don't think it's useful at this stage to be arguing about whether or
not this group can impose changes on existing IPv6 implementations.
Rather:

	first, let's get the requirements and desirements agreed to,

	second let's identify solutions that would satisfy the
	requirements, and

	third, assuming there is more than one such solution,
	let's understand the nature and degree of change required
	by each solution (e.g., does it require changes to all
	routers? edge routers?  host IPv6 layers?  applications?
	nothing?), as an important input to the process of choosing
        a particular solution (or set of solutions).

I thought we were supposed to be moving quickly to resolve the first
step, but most of the email seems to be trying to prejudge the outcome
of the second and third steps.

Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2001 13:40:52 -0500

> expected lifetime, i suspect we can afford to get it right.

Randy, I suggested some very precise requirements text to take account of the
fact that there is a lot of running and shipped code in existing products that 
is simply not going to get rewritten that quickly. Like it or not, multi6
has to coexist with vanilla IPv6, and that generates its own set of
requirements.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Jun 2001 21:22:01 +0200 (West-Europa (zomertijd))

> Please go read the RSIP documents.

A pointer or the full name would be helpful.

> There are a LOT of problems with this, 

I'm very tempted to say that people with such a setup are asking for whatever
problems they are getting... But I'm not.

If NAT is ever to become a serious alternative to real connectivity, there is
a lot to be done. If a control protocol makes things better for a lot of
people, I think it's a good thing. Too bad for those who use setups that are
even more complex. They should just keep doing things the way they are now.

> there's no way to put servers behind it. Or peer-to-peer neworking 

Obviously that would be just about the first requirement for any serious
multihoming alternative. I don't think it's worth the effort to think about
outgoing-only multihoming.

Iljitsch

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Mon, 25 Jun 2001 14:22:58 -0500 (CDT)

> has to coexist with vanilla IPv6, and that generates its own set of

Brian, if we can make something like GxSE work with vanilla v6, however,
that should satisfy everyone.  Instead of clobbering the discussion, I
think we should expand it.  There must be a happy medium.

-Taz

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Jun 2001 15:26:21 -0400

At 12:36 25/06/01, Iljitsch van Beijnum wrote:

>Unless I overlook something there are basically four ideas to keep the growth of the routing table as a result from multihoming to a minimum:
>

Also Con:
        ESP/AH don't work through the NAT.
        Transparency is visibly below desired levels.

>   routing table effect may be as little as one order of magnitude.

        It isn't clear to me that this works in either IPv4 or IPv6.

        If the IDR scaling improvements are not significant, 
it isn't a sufficient improvement (IMHO).

>   Con: many things: new protocol versions, new software, etc.

        If this were sufficient by itself, then at least some of the
vocal routing folks here would not be as vocal as they are being,
IMHO.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Jun 2001 15:27:55 -0400

>        draft-ietf-ipngwg-ipv6-2260-01.txt

        Have read those.  I don't believe either of these drafts
"resolves the IDR routing table issues caused by multi-homing",
and that's just for openers. 

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Jun 2001 15:33:41 -0400

At 13:56 25/06/01, Jun-ichiro itojun Hagino wrote:
>        also, remember why GSE proposal was not integrated into IPv6

        GSE was not integrated due to politics, pure and simple.  Lets 
please try to make technical decisions over here in multi6, rather 
than repeat past political mistakes.

>        we may not be able to success in IPv6, like IPv4 did.

Itojun,

        8+8 rewrites in a border router at 1/10 Gbps line speed aren't 
worrying the major router vendors, AFAIK.  Certainly it doesn't cause me 
to lose sleep at night.  However, we haven't yet decided whether we
want to take that approach or not.

        It IS sensible to try to sort out what problem(s) we are trying
to solve up front, without closing doors.  Then we can try to sort things
out among various alternative approaches.  Stopping the discussion
prematurely will guarantee failure, however.

Ran
[email-masked]

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 26 Jun 2001 04:36:59 +0900

>and that's just for openers. 

	they don't require us to inject more-specific routes to worldwide
	routing table, so they should be more routing-table-size friendly
	than currently practiced IPv4 multihomnig.

itojun

---

From: Vijay Gill <[email-masked]>
Date: Mon, 25 Jun 2001 15:47:27 -0400

> 	than currently practiced IPv4 multihomnig.

This one at least, has been extensively commented upon in the IPNG wg
mailing list by myself and ben black, among others.

A check on the ipng archives might prove to be useful.

fyi

/vijay

---

From: Daniel Senie <[email-masked]>
Date: Mon, 25 Jun 2001 15:35:02 -0400

>A pointer or the full name would be helpful.

Go read all the NAT stuff at:

http://www.ietf.org/html.charters/nat-charter.html

all of the documents are listed out there. The RSIP documents are, I 
believe, going to be published as Experimental. I'm not sure why they 
haven't already been published as such.

>even more complex. They should just keep doing things the way they are now.

There are many ISPs in the world who are using NAT to cover all their 
customers. Any customer who then needs to hook up more than one computer 
gets to do another level of NAT. Is this a bad idea? Sure. However, if RSIP 
or similar go forward, it will likely be in that environment. Will this 
happen again in the IPv6 world? Unclear. I suspect, though, that having NAT 
at multiple levels will not disappear.

>multihoming alternative.

Agree.

>  I don't think it's worth the effort to think about

Agree again. There are already products in the marketplace for IPv4 which 
handle outgoing-only multihoming without the involvement of upstream ISPs. 
These are useful products for those users who can live with the 
limitations, but not worth considering for multi6.
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:41:40 -0400 (EDT)

In the spirit of fairness to Itojun.  How can we ask him to not use the
charter as a guideline?  Is that not telling the chairs and ADs we are
ignoring him.  I do think we need to keep an open mind and very open ears
and I personally think GxSE has merit.  But we do need some guidelines if
we are to ship an initial recommendation within a reasonable time for the
IPv6 market, where deployment is going to happen even with the bad
economic news, except in the U.S. in the commercial sector for awhile.
The rest of the world wants it yesterday.  So we do that that immediate v6
multihoming to deal with immediately if we can.  Itojun has proposed some
ideas and I think Ohta San that I think we could do to alleviate some of
the pain for that early deployment.

So I think we need to check out Itojun's and others work where it can
solve a problem in the short term per the charter.

/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:51:33 -0400 (EDT)

could you or Paul take a stab at taking GxSE and extracting the reqs its
solves and we an put those in our reqs definition with other reqs.

I do think it wise we have reqs and then solutions.

/jim

On Mon, 25 Jun 2001, Jon (Taz) Mischo wrote:

>       and conservative in what you send.."

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:58:09 -0400 (EDT)

Ran,

Excuse me but I was at the GSE meeting and the issue was no one felt it
was technically feasible at the actual 8+8 meeting.  Part of of the
technical problem was we did not have the operators in the room as we do
on this good wg mail list.  The other problem was we had no notion of SCTP
and did not get to the point Ohta San did by taking some of of the pain
away.  We also did not have the value of scoping quite down yet and that
may help but I am not sure.  But in the actual 8+8 meeting it was not
political.  Mike presented his case it was discussed and then an extended
case from that was presented by ISI folks, close to where we are no on
this list but it was not as clear as what we see now.

If politics happened it happened after the 8+8 meeting and after the next
IPng IETF meeting.  Steve and Bob do a pretty good job of keeping the
politics out of IPv6 for the most part.

I don't recall you were at that meeting but my age may be playing tricks
on me and if you were I apologize.

/jim

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Tue, 26 Jun 2001 03:07:19 -0500 (CDT)

It was Paul's idea, so initially, I'd say it would be appropriate for him
to.  I had some ideas I kind of tossed into the ring that I'd be happy to
work on, but I must defer to Paul, as it's his brainchild :)

-Taz

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 26 Jun 2001 08:55:16 -0700

Agree with all your points.  yes, this moves complexity out of routing and
into the application.

Also, the multi-party application scenario I gave (A inside a site, talks to
B outside a site, B learns A's GR addresses from the socket interface, then
conveys them to C) is the easy case.  A harder case is A inside the site,
talks to B inside the site, then B wants to convey A's GR addresses to C.  B
won't know A's GR addresses because they are in the same site, so when A
tells C about B's SK address (the only address B knows), C would have to
deduce A's GR addresses from A's SK address combined with B's GR address
prefixes learned from the socket.

This in turn places constraints on A's and B's GR prefixes...i.e., they must
be the same.

Yuck.

PF

----- Original Message -----
From: "Erik Nordmark" <[email-masked]>
To: "Paul Francis" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; <[email-masked]>
Sent: Monday, June 25, 2001 1:32 AM
Subject: Re: An idea: GxSE

I see how that can be made to work.
The point is that I think this is a significant change in the way
applications
deal with their own addresses. Today they can just use getsockname(int
sock,...) and pass this to peers.

  Erik

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 26 Jun 2001 09:00:32 -0700

> renumbering without too much of a hassle.

You may be right.

PF

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Jun 2001 12:39:52 +0200 (MEST)

> This in turn places constraints on A's and B's GR prefixes...i.e., they must

I wonder if it makes sense exploring the case when applications
(as well as transports like SCTP) can easily find out the GR addresses
of their own node, but those addresses are not used in the IP packets.

You'll have issues like the applications discovering potentially stale 
information but conceptually I don't think that is much different
than getting stale DNS information when looking up the peers
addresses in the DNS.

   Erik

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 27 Jun 2001 08:12:52 -0700

> of their own node, but those addresses are not used in the IP packets.

I was wondering about this myself.  Like an anycast ping to the nearest site
border router...

PF

---

From: "Paul Francis" <[email-masked]>
Date: Fri, 29 Jun 2001 12:07:18 -0700

I'll do it.

PF

----- Original Message -----
From: "Jon (Taz) Mischo" <[email-masked]>
To: "Jim Bound" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; "Randy Bush"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 26, 2001 1:07 AM
Subject: Re: An idea: GxSE