Subject: RE: Bad routes update

From: Richard Draves <[email-masked]>
Date: Tue, 20 Jul 1999 22:25:37 -0700

> > I think giving the multi-homed host two addresses (one for 
> each part of the
> > tree) is the beginning of a "yes" answer. It shifts the 
> problem from the
> > network backbone (routing scalability) to the network 
> periphery (when to use
> > which address).
> 
> It won't work. It means that if the network routing to one of the
> addresses dies, the TCP connections die.

There are two answers to that. The short-term answer is an RFC 2260-style
solution. The long-term answer is to change TCP so you can change endpoint
addresses, for survivability and renumbering.

> Right now, I can happily leave a "cvs update" that takes 
> several hours 
> running over the nice v4 internet and feel happy knowing that no
> matter what happens, the connection will keep on trucking.
> 
> If the new v6 internet doesn't work that well, it is broken from my
> point of view. I didn't sign up on this to see my internet work less
> well than it does right now.

The v4 internet often doesn't work that well. How often has one of your "cvs
update" operations actually survived an ISP failure?

Sure, there are some applications for which TCP survivability is important.
See the short-term and long-term answers above. But for the business uses of
the Internet (the reasons for which sites are willing to pay multiple ISPs
to be multihomed), TCP survivability is not nearly as important as
availability for new connections.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Perry E. Metzger" <[email-masked]>
Date: 21 Jul 1999 10:08:58 -0400

> addresses, for survivability and renumbering.

None of this will work today.

v6 has been debated for seven years. We have existing implementations, 
none of which do any of the proposed magic. Unfortunately, if we are
*ever* going to have v6, we have to start deploying *now*. If you want 
to wait another three years and see v6 die, well, fine, but
unfortunately, right now, our stacks do not have a way to deal with
this and we need to deploy *now*, which means we use the solution
we've got.

> update" operations actually survived an ISP failure?

At least every few days. It happens all the time.

Maybe you don't notice this much because you work at Microsoft which
has multiple diverse routes, and you haven't been spending a lot of
time doing extensive work over the net. As a consultant, I routinely
spend hours logged in to systems across the net, so I'm fairly acutely 
aware of the reliability issues. I often lose effective connectivity
for a minute or so, but it is rare when dealing with multi-homed
clients that I lose connectivity completely.

> Sure, there are some applications for which TCP survivability is important.

The net doesn't exist only to provide http connections. Anyone
establishing a remote tunnel so they can work from home has to deal
with the same problem I do. In the scheme you are proposing, such
users will get very mad indeed.

> availability for new connections.

This is a generalization that just won't wash. You're making lots of
assumptions, many of which aren't warranted under the
circumstances.

Right now, people pay lots of money for diverse providers for a good
reason. It isn't that they love wasting money. They *need* the
reliability. You're telling us that they don't exist -- but of course, 
if they didn't exist, why would you be worried about them exploding
the routing tables?

As I've said, we had seven years to come up with a solution for these
people other than diverse route announcements and we did not come up
with one. Given that, I think its time that we accepted that we're
going to have to deploy with the same solution we had in v4.

Perry

---

From: Alain Durand <[email-masked]>
Date: Wed, 21 Jul 1999 16:34:34 +0200

>going to have to deploy with the same solution we had in v4.

This solution (advertising prefixes through different
ISPs)  works fine in v4 mainly because of the limited number
of multi-homed sites.
Imagine multi-homing become the standard de-facto practise.
CIDR will stop working and the default free routers will not have
to carry about 50000 routes but zillions.

This was a serious problem in 1993 when memory on routers
was VERY expensive, and multiplied by the number of default free
routers this was going nowhere. The other issue was the time to go
through the routing table to select which interface to send packets to.

I'm not a router hardware specialist. If one is listening to this thread,
could he elaborate on this issue?

         - Alain.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 21 Jul 1999 10:56:31 -0400

> to carry about 50000 routes but zillions.

Well, it appears that the v4 internet has not had it become standard
practice, so why do we assume the v6 internet will be different? If we 
replaced v4 with v6 on every host on the net tomorrow, we'd only have
the current problem, not a new one. Why must v6 solve *this* problem?
The problem has to be solved regardless of whether we are running v4
or v6.

My long term answer continues to be this: this is an economics
issue, not a technical issue.

We have a classic "commons problem" in economic terms -- people are
able to use a resource without paying for it, resulting in a "tragedy
of the commons".

People adding routes are not forced to pay for the incremental cost
those routes impose on the owners of the routers in the default free
zone. This results in overconsumption of the resource. Being forced to 
pay some arbitrary fee would not work either -- that would result in
the resource being either over or underconsumed without regard to the
proper market clearing level.

In the long run, the solution is the same as that for all "commons
problems" -- if you develop a market in routing announcements, then
the market can set a cost for route injection, and then the desire to
inject new routes will be balanced by this cost.  The supply and
demand curves will then cross nicely, and people will make reasonable
decisions about whether to inject new routes, properly balancing their 
need for added reliability against the cost that that reliability has
for them.

I only hope that if I keep on saying this for about five more years,
someone out there who's taken an econ class might actually understand
what I'm getting at and agree that this is probably the only
reasonable long term solution, short of inventing a technology that we 
don't have yet and may very well never have.

Perry

---

From: Robert Honore <[email-masked]>
Date: Wed, 21 Jul 1999 11:51:32 -0400

Dear Perry,

"Perry E. Metzger" wrote:
> practice, so why do we assume the v6 internet will be different? 

It might not be different but it is possible.

> If we

I agree that IPv6 does not need to solve this problem right now and we should
deploy nonetheless, but the problem is an issue that will come up to catch us
later.  Perhaps we better try to figure what can be a solution right now and
hopefully set things up to accommodate the solution later.

> issue, not a technical issue.

It is both.  Even if you were to compel people to pay the cost of adding more
routes, what are you going to do when a large mass decide they are willing to
pay whatever price necessary?  If a resource is over-subscribed and you have no
way to extend or increase it, you will have no progress.  In fact you will have
a large mass of unsatisfied consumers who will go looking for something else.
 
> need for added reliability against the cost that that reliability has

I agree that it is not a good idea to fix the number of routers in the
default-free zone, but it is necessary to constrain the growth of the number of
routes that must be propagated at that level to a rate that is less than the
existing capacity to add resources to accommodate the additional routes.
 
> don't have yet and may very well never have.

Having the users of the network pay the costs associated with adding the new
routes **is** the only reasonable long-term way to ensure that we can continue
to accommodate that kind of behaviour, but I believe that by the time we have
figured out the full cost of injecting additional routes like that we would have
gone a long way to solve the technical issue as well.

Yours sincerely,
Robert Honore.

---

From: [email-masked]
Date: Wed, 21 Jul 1999 08:52:58 -0700 (PDT)

> to carry about 50000 routes but zillions.

	closer to 60K routes these days.

	More providers are multihomed today than in 1993.
	The popularity of legecy delegations sometimes called
	swamp space is that they are generally globally routable
	w/o provider aggregation. The other tactic that people are
	using is MPLS and tunnels. 

> could he elaborate on this issue?

	Its not a memory issue.  See the discussions from the bigi archives,
	the nanog archives, the end2end archives, the cidrd archives, pier 
	archives and perhaps other places as well. 

-- 
--bill

---

From: Joe Abley <[email-masked]>
Date: Thu, 22 Jul 1999 04:24:26 +1200

Hi Bill,

> 	using is MPLS and tunnels. 

It seems to me that at least some of these tactics would apply to IPv6
as well as IPv4, and provide an alternative approach to routing collapse
in the core. (cf remarkabable similarity between Peter Tattam's home-grown
"routing ID" based core and MPLS).

Is it a reasonable approach to consider the issue IPv6-independent? Can we
leave it to backbone providers to deploy suitable solutions (such as those
you mentioned) to fix the problem as it arises, rather than preventing it
from ever happening?

Doom and gloom merchants have been predicting the collapse of the core
due to an explosion of route prefixes for a long time now, and exercises
such as increased efforts in aggregation have always kept the issue
under control. Is the alleged explosion under IPv6 any different from
these previous alleged explosions? Or am I blissfully unaware of *real*
problems in the IPv4 core today?

Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 22 Jul 1999 04:38:06 +1200

> assumptions, many of which aren't warranted under the

There seems to be a prevailing idea in some quarters that some protocols
are of business interest, and others aren't.

We (CLEAR) are in the business of selling extremely reliable wholesale
internet connections to ISPs, and those ISPs are just as demanding as
corporate clients (more so in most cases).

To these demanding business customers, protocols which require long-lived
TCP sessions like IRC are business-critical, no matter how trivial these
protocols seem from a corporate perspective.

A significant proportion of multi-homing activity here in New Zealand is
with tier-3 ISPs, and not yet with corporate accounts (who are currently
more likely to forego the complexities of BGP and multi-homing for a nice
SLA which gives them penalty payments).

Joe

---

From: [email-masked]
Date: Wed, 21 Jul 1999 11:36:59 -0700 (PDT)

> you mentioned) to fix the problem as it arises, rather than preventing it

	I see two distinct threads here.

	- routing system "containment"
	- session stability

	some off the cuff thoughts on each.

	- routing systems are dependent on a couple of things, agreement between
	  transport agents to exchange client prefix and path data is one. the
	  ability to do this depends on technologies for managing entries in
          a routing table. I've not yet seen a real good way to track the value
	  here. It seems to hinge on two points, the number of "slots" to keep
	  the data and the time each slot is occupied.  These assumptions seem to
	  hold true, regardless of network protocol. IPv6 is "scary" because the
	  potential for killing existing designs is so high and the business/political
	  alternatives lead down the path of collusion between providers and 
	  restraint of trade.  Hence the desire to use psudo-technological arguments
	  about the limitations of existing technologies to build crippling 
	  addressing architectures and archane delegation procedures. (yes, I
	  am biased here.. :)

	- session stability has been thought of in the not too recent past. Christian
	  H. had an interesting idea that had a brief proof-of-concept done at UCLA
	  a couple years back. He argued for the replacement of the IP address inthe
	  PCB with a host unique ID.  I had a more hairbrained scheme to use the
	  FQDN in the PCB. The general idea is to decouple the node identifier from
	  the topology label, allowing things to move in the topology w/o changing 
	  the host id.  There was some preliminary thought about casting this
	  as TransportV6.  See the Nimrod work and Noel C., Steve K. and others
	  for the last decades discussion on this.  For me, its always boilded down
	  to developing support for variable length addressing, which has has been
	  rejected as far back as the last two decades. (at least according to the
	  IEN copies that I have here, predating the RFC series.)  The IRTF and
	  IAB have consistently tossed the idea as too disruptive. (Hey, bill is 
	  biased here too!)

--bill

---

From: Robert Honore <[email-masked]>
Date: Wed, 21 Jul 1999 18:25:50 -0400

There are two distinct threads here: Route Containment and Session Stability. 
Now that I mention it, I do think we need to visit that question of session
stability yet again.  

My objection to Peter Tattam's document titled "Routing Idea - A variation on
GSE ", I will refer to it [GSE+], is that it still requires making changes to
the IP header as it traverses a site's border routers and travels across the
network.  Additionally, it requires what seems to me to be radical changes to
the behaviour of routers.  Otherwise, [GSE+] does cover an important point about
session stability, that is, the need to provide a unique number for a node to
identify its transport connection peer despite any changes to the actual IP
address of either peer of the connection.

I wish to submit that that need is **not** a routing issue.  It is not even a
network issue.  What we need is a means of associating a number unique within
the node with the peer connection end-point.  The number does not need to be
globally unique.  It does not need to be valid forever.  The number **does**
need to be securely associated with the peer end-point IP address and maybe the
peer end-point transport protocol port.

Together with such an association we need some kind of agent that keep that
association up-to-date for the duration of the connection.  The number can be
discarded or recycled at the end of the connection.  This whole scheme is, I
think, similar to the concept originating from C. Huitema.

Here is the scheme. Perhaps we can use either a random number or a number
otherwise generated when initialising the connection. This number will have the
same number of bits as an IP address.  We can then use that number in the Protol
Control Block.  That number will serve as a lookup index within the host to some
association with the peer's real IP address.  That IP address will then be what
is placed in the IP header as the destination address for all packets that will
be transmitted until the peer node needs to renumber or choose a different
interface or address.

When either of the peers needs to change its IP address, the node whose IP
address is changing will then activate its agent to send out a request of some
sort to change the peer address association.  This request will contain the old
IP address, the new IP address, together with the two end-point transport
protocol port numbers and some kind of signature.  

The peer that receives such a request should then have its agent acknowledge
that request if it accepts the request.  Otherwise the peer can either ignore
the request or kill the connection.  The acknowledgement must also be signed.

I know this would probably require the creation of yet another protocol with
which to implement the agent, but to me this is more comfortable than altering
an IP header in transit.  A protocol that could support the agent would probably
sit between IP and the transport protocol.  Still one should note that this
protocol **does not** require transmitting an Agent header (or whatever else you
will call it) for every packet.

Of course the communicating peers would need to form some kind of security
association before this becomes possible, but in the case that either of the
peers does not support either the agent or the security, the performance is no
worse than what obtains at present.  A scheme like this seems to make more sense
to me, since it does not depend too much on cooperation from any nodes other
than the two peer nodes and the burden remains with these two nodes to maintain
the connection.  

Do remember this is just one way to address the session stability problem.

Yours sincerely,
Robert Honore.

---

From: Steve Deering <[email-masked]>
Date: Wed, 21 Jul 1999 16:54:29 -0700

I am getting *really* tired of messages of the form "If IPv6 doesn't do
foo, it will be dead on arrival!", usually accompanied by someone else
saying "If IPv6 *does* do foo, it will be dead on arrival!", and usually
written in an authoritative/threatening tone of email that implies that
anyone who doesn't agree is an utter fool and if the writer doesn't get
his (for some reason, it's always a "he") own way, he will take his ball
and go home, and maybe tell the whole world what nincompoops the IPv6
designers are, too!

Look, folks, these are tough issues, with no easy or painless solutions.
In many cases, solutions involve making not just technical tradeoffs,
but also economic and political tradeoffs, and where one stands on a
specific issue often depends on where one sits (i.e., the valid concerns
of implementors, providers, users, managers, consultants, architects,
academics, legislators, et al are often at odds with one other).  If we
are going to succeed in this effort, we need to have a lot more respect
for differing opinions, and more flexibility in accommodating solutions
other than our first choices.

(End of rant.)

Regarding the specific issue of site multihoming vs. route aggregation,
I don't think we ought to just dismiss the concerns about route
aggregation with appeals to Moore's law or Adam Smith's invisible hand.
I would prefer to not rule out a possible IPv6 future in which many
millions of sites (e.g., many households) are connected to multiple
service providers (whether for robustness or for different grades of
service at different prices or whatever), and those sites don't each
have to send a cheque for $0.00001 to every service provider in the
world to pay for the extra memory, bandwidth, and CPU cycles required
to support one more prefix in the providers' routers, in order to get
the benefits from multihoming.  Perhaps route aggregation will become
less of a concern due to technological advances, but I think it is
(a) premature to count on it, and (b) clearly a very hard sell in much
of the current ISP community, for whatever reasons.  (A number of vocal
members of that community have loudly proclaimed that, if IPv6 doesn't
fix the route aggregation problem, all it will do is make the routing
tables four times larger for absolutely no benefit [dismissing the
benefit of global addressing], and so we should all just wait for
something that *does* solve the route aggregation problem.)

Therefore, I suggest that it is prudent and worthwhile to continue to
work on other ways to support multi-homed sites well, other than
injecting their prefixes into the top-level routing, such as:

	- better end-host support for multihoming, with the goal
	  of making transport protocols tolerant of changes of
	  address availability/reachability, just like they are
	  currently tolerant of packet loss, reordering, delay,
	  and duplication.  (This is the "don't trust the network"
	  philosophy of TCP, which was the fundamental key to its
	  success.)

	- RFC2260-style or mobile-IP-style tunneling approaches
	  to allow continued use of addresses when the "native"
	  routing for those addresses isn't working or isn't
	  the best.

	- schemes like metro-based addressing which reduce the need
	  for a multi-homed site to have multiple address prefixes
	  by "flattening" the routing in a local region, rather than
	  flattening the routing globally).

	- schemes that add another level of naming above or below
	  the IP addressing layer to allow the routing system to
	  operate on different names than the transport protocols,
	  like map-n-encap or GSE+ or something that takes advantage
	  of the EUI64-based node IDs embedded in IPv6 addresses.

Most of these directions can be pursued without holding up implementation
or deployment of IPv6, i.e., they would be additional capabilities that
could be implemented and deployed in a backwards-compatible manner over
the next few years if they looked good.  (That's probably not true of
the GSE+ type of schemes, which is why I personally am less than
enthusiastic about those approaches.)

(With regard to holding up deployment, there were some messages
recently that expressed concern that changing the API to support,
e.g., passing a DNS name rather than an IPv6 address in a "connect"
call, would set us back years in development and deployment.  I think
there is a misunderstanding there.  Any such change would be an
*addition* to the API.  The current API would continue to be supported.
Applications could be upgraded to support the new API over time,
and applications using the new API could co-exist with, and interoperate
with, those using the current API.  No need to hold up anything at this
point.)

Finally, on top of the depression I feel at reading all the inflexible
bickering and posturing on the IPv6 lists, today brought the good news
that Apple is going to make wireless Ethernet (IEEE 802.11) base-stations
affordable at last (see <http://www.apple.com/airport/>), but the bad news
that a major selling point of Apple's new device is its built-in NAT
capability.  Sigh.

Steve

---

From: Justin <[email-masked]>
Date: Thu, 22 Jul 1999 14:13:51 -0400 (EDT)

> something that *does* solve the route aggregation problem.)

If there's no good current solution for massive amounts of multihoming,
ISPs should tell Joe User, who wants to give his dog's dog collar, his TV
remote, and his toaster global ipv6 addresses AND who wants multiple
ISPs, to go away.  Just because ipv6 has the theoretical ability to allow
more devices to be connected, doesn't mean that has to be encouraged, or
even allowed, until problems with it are fixed.  Exactly why does a 
toaster need a global ip, anyway?

Do all the ISPs for a multihomed site have to announce the route?
Couldn't only one announce, and when the others see a withdrawl of that
route, they compete (intelligently) to decide which next advertises it?  I
don't see this as an issue with ipv6 at all, I think it's an issue with
BGP4+.

Plus, a solution to this could be made to solve renumbering as well; why
not have the customer use the same ips with both ISPs, then renumbering is
not necessary.  ISP2 can pick up the withdrawn route for ENTITY through
ISP1 since it knows ENTITY is a customer.  Routing updates propegate.  No
lost tcp connections.  "But this will cause massive routing churn!"  I
would think even a significant increase in route churn is much more
acceptable than requiring that all routers with global BGP views have 32GB
of memory or some other rediculous amount when ipv6 is deployed.  ...and I
would hope that anyone who wants to be multihomed would ensure that their
links are reliable, which would mean not many extra routing updates for
failed links.

Just my $.019 (not redeemable for cash)
Justin

---

From: Robert Honore <[email-masked]>
Date: Thu, 22 Jul 1999 18:08:13 -0400

Dear Brian,

Brian E Carpenter wrote:
> 
> Robert,
> 
> What is your objection to altering an IP header in tranist, as
> long as the altered part is not included in any checksum?
> 
>    Brian

Let me say this at the outset.  I would hate to see deployment of IPv6 delayed
over the Multihoming and Session Stability issues when we can get them fixed
later without any adverse effects right now.

My objection to altering an IP header in transit stems from what I understand
the IP end-to-end model to be. It is probably more a philosophical bias on my
part than anything else.  I may be wrong, but I believe the end-to-end model
essentially advocates that the packets will not be altered in transit.  Also, I
do not see any compelling need to alter packet headers in order  to provide for
session stability.

My last message also dealt primarily with the session stability idea in [GSE+]. 
I still think [GSE+] does not do enough to remedy the drawbacks of [GSE]. 
Besides, such a radical change to the addressing infrastructure and the
behaviour of routers probably are not required to solve the multihoming problem,
but as I said before that was not the issue I really want to deal with.

I believe that work to solve the question of transport connections surviving a
renumbering event or topology change is worth the effort, hence my clumsy
attempt at presenting a mechanism.

Yours sincerely,
Robert Honore.

---

From: Robert Honore <[email-masked]>
Date: Thu, 22 Jul 1999 18:43:18 -0400

Dear Shane,

Shane Kerr wrote:
> 
> Warning: I've not ready any of the literature presented in this e-mail.

-------------------SNIP----------------------------
 
> I would suggest such a number be created by combining a unique number from
> the session initiator with one from the other side.  Such a number, while
> not unique globally, would be unique for connections on both ends of a
> session.  By "unique", I mean one that is unlikely to be used again in
> quite a while.  Whether this should be simply an increasing integer value
> or a CRC or a hash or what, I can't say.  Personally I don't see any
> problem with an incrementing integer, but I might be overlooking
> something.

An incrementing integer could be a problem.  It could make it easy to highjack a
session. I was just talking about a number that can be used for mapping to the
IP address and can be used in place of the IP address in the Protocol Control
Block.

> 
> Is it possible to add this to a TCP connection handshake without adding an
> extra packet transmission?  Without looking at the RFC's in detail my
> initial reaction is to say "yes".
> 

What I am proposing does not require alteration of TCP.  In fact I am not even
advocating making any changes to the protocol.  Also if you avoid the need to
negotiate the number mutually between both parties, which I do not believe is
really necessary, it is also possible to avoid an extra packet transmission
except in the case of a renumbering event or topology change.

> Which kind of brings us to the next question:  is it possible to attain
> any kind of session survival with a UDP session?  Certainly the concept of
> a UDP session has meaning (e.g. TFTP), but this is kept strictly at the
> application level.  I think it would be fairly difficult, if not
> impossible, without some sort of protocol-level support (visions of NAT
> dance through my head).  But perhaps that's not such a big deal, as long
> as it is agreed that this is a TCP-only proposition.
> 

What I am proposing is independent of the specific transport protocol in use. 
It will work for both TCP and UDP.  What I propose is code to perform the
mapping to the IP address from the identifier used in the protocol control block
and an auxiliary protocol to negotiate an update to that mapping when either
peer needs to renumber or select a different interface.  This combination of the
mapping code and a protocol to negotiate the update I am calling an Agent.

Yours sincerely,
Robert Honore.

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Jul 1999 11:12:30 +1200

On Thu, Jul 22, 1999 at 06:08:13PM -0400, Robert Honore wrote:
> I believe that work to solve the question of transport connections
> surviving a renumbering event or topology change is worth the effort,
> hence my clumsy attempt at presenting a mechanism.

I am not trying to evangelise a particular solution, nor second-guess
the forthcoming minutes from the Oslo meeting.

However. :)

Steve mentioned that an important requirement raised by carriers and
ISPs in the initial design of IPv6 was that the routing complexity
in the core should be minimised.

However, this was some time ago. Since then, I think several important
things have happened:

 o  Providers have found other ways to reduce complexity in the core,
    using techniques like building out ATM switched cores to concentrate
    the routing load in fewer places (near the edge), and MPLS.

 o  Routers have become capable of holding fantastic-sized BGP tables in
    the default-free zone, and performing hardware-assisted lookups on these
    huge tables at wire-speed.

 o  The number of organisations multi-homing has increased, and the use
    of BGP has also increased. People are now using BGP to do all kinds
    of weird and wonderful things, and it will be difficult to characterise
    them all and build them into a brand new multi-homing scheme.

 o  Perhaps most importantly, the Internet backbone is not the wild west
    it once was.

The last point is important. Some of the largest IP networks on the planet
(and ones on which the stability of many visible service now depend) have
sprouted design and operational procedures that weren't in evidence
seven years ago. These are clearly not as elaborate as the various Books of
Telco that describe tried and tested procedures in the switched voice
network, but they exist nonetheless. Procedures, and engineers who do things
based on recipes rather than first principles, lead to inertia.

My question, then is this:

  Do the original requirements of ISPs still make sense today? If the
  largest backbone networks were canvassed again today, would they have
  the same priorities in a new Internet architecture?

CLEAR is small enough (and has a sufficiently low number of connection
points to other networks) to accommodate any consensus approach to
multi-homing, route aggregation and session stability, at least as far
as the carrier requirements are concerned.

I wonder whether larger ISPs will find a radical change in operational
procedure so easy to swallow.

Joe

---

From: Bill Manning <[email-masked]>
Date: Thu, 22 Jul 1999 16:31:54 -0700 (PDT)

> IP address and can be used in place of the IP address in the Protocol Control

	This has been coded and tested already. Christian Hutiema
	had a group of UCLA students do this about three years ago.
	Based on a long-expired ID. There is code around someplace.
	
> > as it is agreed that this is a TCP-only proposition.

	There are a couple of ways to do this, but they require some
	extra cruft on the side (adding limited state).  Some code
	exists here as well.

> mapping code and a protocol to negotiate the update I am calling an Agent.

	Don;t think you need to do that much if designed properly.
	It really would be worth your time to review the e2e and 
	bigi list archives.  Most of this is old ground.

---

From: "Ben CROSBY" <[email-masked]>
Date: Fri, 23 Jul 1999 00:50:28 +0100

>later without any adverse effects right now.

I'd echo these comments. We appear to be trying to get people to take up IPv6
and part of the reason why take up has been so slow is because of continued
tweaking. However, this is a major point. It is a pity not more notice was 
paid a
few years ago when we first discussed it in Washington.

>do not see any compelling need to alter packet headers in order  to 

Not necessarily philosophical. We learnt from v4 that applications exist 
which need
to pass IPaddresses within the datagram, rightly or wrongly. This is the 
reason why
NAT breaks some applications. Do we really want to deploy a protocol which 
has the
same flaws from day one ?

>attempt at presenting a mechanism.

It has the potential to be one of the most useful features of the protocol.

Ben.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 1999 08:38:18 -0500

Robert,

   Brian

---

From: Shane Kerr <[email-masked]>
Date: Thu, 22 Jul 1999 16:30:34 -0400 (EDT)

On Wed, 21 Jul 1999, Robert Honore wrote:

> Here is the scheme. Perhaps we can use either a random number or a
> number otherwise generated when initialising the connection. This number
> will have the same number of bits as an IP address.  We can then use
> that number in the Protol Control Block.  That number will serve as a
> lookup index within the host to some association with the peer's real IP
> address.  That IP address will then be what is placed in the IP header
> as the destination address for all packets that will be transmitted
> until the peer node needs to renumber or choose a different interface or
> address.

--
Shane Kerr <[email-masked]>
Software Engineer
American Registry for Internet Numbers

---

From: Jeff Williams <[email-masked]>
Date: Thu, 22 Jul 1999 17:53:57 +0100

Ben and all,

  Couldn't agree with you more on this point Ben....

> It has the potential to be one of the most useful features of the protocol.

Regards,

--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 1999 20:51:29 -0500

Robert,

Thanks. I asked the question because this was part of the discussion
at the recent IAB workshop, and one of our recommendations was to
study further the concept of separating endpoint names from endpoint
locators. Your comments are relevant.

However another of the recommndations was to actively pursue
IPv6 deployment based on TLA addressing, and not hold this up
due to such studies, and I'd be glad to see that happen
(i.e. let's figure out simple TLA-based multihoming first).

  Brian

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 23 Jul 1999 09:50:09 -0500

> ...
> My objection to altering an IP header in transit stems from what I
> understand the IP end-to-end model to be. It is probably more a
> philosophical bias on my part than anything else.  I may be wrong, but I
> believe the end-to-end model essentially advocates that the packets will not
> be altered in transit.  Also, I do not see any compelling need to alter
> packet headers in order to provide for session stability.

You fell into a trap, although Brian's so un-devious he probably didn't
set it intentionally.  There are several IPv4 header fields that are
always modified en route, and several more that are sometimes modified.

Given that, where do you draw the line between what MAY and what MUST
NOT be modified, and how do you justify it?

			Matt Crawford

---

From: Steve Deering <[email-masked]>
Date: Fri, 23 Jul 1999 08:20:10 -0700

>NOT be modified, and how do you justify it?

The line is drawn between those fields that the IP spec specifically
identifies as modifiable en route, and those it does not.  If the spec
does not say a field is modifiable, then the routers cannot assume they
can safely change it because there may be upper-layer dependencies on
that field remaining unchanged (unknown and unknowable to the routers).
Nor can they add fields or delete fields (e.g., options or extension
headers), for the same reason.

Of course, the routers can make any changes they want to an IP header,
including compressing it, encapsulating it, shredding it, or translating
it into Swahili, as long as those changes are undone before delivery to
the destination(s) (and before reaching any intermediate devices like
firewalls that might also depend on the constant fields of the header
remaining constant).

Steve

---

From: Robert Honore <[email-masked]>
Date: Fri, 23 Jul 1999 11:59:18 -0400

Dear Matt,

> firewalls that might also depend on the constant fields of the header

I have nothing I can add to this.  You have to give me very strong justification
if you advocate modifying IP headers outside of the protocol specification.

Yours sincerely,
Robert Honore.

---

From: Jim Bound <[email-masked]>
Date: Sat, 24 Jul 1999 10:21:02 -0400

Brian,

As you know I agree with Robert very strongly.
Also if some want to break the e2e model as I define it and most of
my customers (they know its broke but would like it fixed I hear so
don't inject that reality or we can have a discussion of whose customer
is smarter yours or mine and I don't think that useful).

>locators. Your comments are relevant.

We have been studying this for years it could be like trying to prove
the 4th dimension of Einstein in fact exists within time and space.

From an implementation and **performance** view having nodes find
addresses from identifiers is very bogus IMO and the wrong way to solve
the problem.  It will cause additional cycles on any platform and
unneccessary IMO.  It could be that IPsec discussions of identifiers is
worth pursuing but I am not even convinced of that because the address
is only part of the identification process.

>(i.e. let's figure out simple TLA-based multihoming first).

Thank god for that wisdom judgement it would have caused so much battle
in the IETF and gridlock we would not get anything else done as there is
a strong faction of us out here who want to deploy IPv6 and if opposing
got in the way of that now the market and that lets-deploy-ipv6-faction 
would be a joint debate from that side of the belief system.

As far as altering IP heaeders in transit I think its time I put out
before wash d.c. my view of IP Transparency.  This is a very bad idea
for certain fields in the IP header.  I provide below mail I sent
sometime ago to the IPv6 deployment list that came out before the IAB
transparency draft.  I will delete the headers and some other text not
relative to this conversation.  And yes it is a legal issue too.
I do agree that NAP/ISP SLAs with subscribers  could permit such behavior 
but I believe that is the only way.

--------------------------------------
Excerpt from Mail on IPv6 Deployment List Thurs Feb 25, 1999 at 13:32:

[DISCLAIMER]
This is not a Compaq supported activity and nothing said reflects the view 
of my employer, this is an individual analysis by me.

For discussion Node X and Node Y (defined as Nodes here) are communicating 
in a bi-directional means using TCP/IP the nomenclature.  Whether it is an 
Intranet or on the Internet is not a disguishing characteristic for this 
discussion.  Also none of the terms used from RFC 2119 apply to this
discussion they may mean different things than 2119, it is not a spec
but a set of principles.

-  The Nodes users data is not altered during communications.

   o  The Nodes user data is not added to or reduced by 
      any Node on the Network or by any Service on the Network.
      User Data is determined prior to communications between the 
      Nodes.

-  The Nodes packet exchanges are their packets as ownership
   and the Nodes have a legal and moral right to not expect 
   their packets IP header to be altered by any other Node along
   the path; except to have those packets forwarded by intermediate
   Nodes on the path.

-  The Nodes may permit along the communications path for other
   Nodes thru aggreement to use defined fields in the IP header
   which are classified as public domain to provide a level of
   service based on the marking of such fields by an intermediate
   Node or set of Nodes.  This does not and should not include
   the alteration of the source or destination addresses of
   the orginating Nodes.  

-  The Nodes have the capability to secure their communications
   path between them using the result of all the bits contained
   in the packet as a result for identification to each end, except
   for the services public domain fields and any field which is 
   needed to assist the forwarding of the packet for metrics
   retained to avoid congestion or a packet that has exceeded 
   its range for the function intended (e.g. Hop Limit, TTL,
   ECN bits).  This should include the source and destination
   addresses in the packets, for identification.

These principles state in essence that each end-user that generates a
packet on a Node owns and defines the content of such packet sent to
another Node, and alteration of that packet is only done to route
that packet thru a network, provide a service for that packet, prevent
that packet from causing congestion to other packets, or to set and
reset metrics in the packet to determine if the packet can be delivered
within a diameter defined by the end-user of the orginating packet.

The IP architecture and TCP/IP protocol suite support this model. But
because of the shortage of IP address space a new mechanism was
introduced into the use of IP called Network Address Translation 
(NAT) where the source and destination addresses can be altered from 
private addresses behind such intermediate Nodes that perform this 
function.  

From this change their is now discussion of not only NAT but that the
packets from end-users can be altered within the network to provide
benefits to the users by giving them their data from within the network
and altering their packets to help them!  Also that end-users can trust
the Nodes in the middle between them.  These are very bad ideas that will
take the control out of the end-users hand for their packet and place it
in the hands of the network.  It also affects both de-centralized and
centralized existing practice for distributed computing within the
client/server model.  The client no longers obtains its data from the
server to do its economic business function, but from the network.

The end-2-end model is important to the two Nodes above for: performance,
scalability, security, cost of computing, and the ownership of the Nodes
packets legally and morally.  The end-2-end model reduces the chaos
potential of keeping the network for one purpose and one purpose only
"delivery of a packet between the Nodes in the most efficient means
possible".  The network between sole function should be to route
those packets in tact between the Nodes.  Anything else breaks the
end-2-end model at great cost and opens up networks and the end users
themselves to great chaos, and more importantly control by an unseen 
paradigm of trusting the entity in the middle with the business operation 
of the Nodes communicating.

IPv6 because of its address space can continue to support the end-2-end
model and because it did not do anything of and in itself to alter the
principles of the end-2-end model defined by IPv4 and the TCP/IP
protocol suite.  It has enhanced the necessary fields to assist the
forwarding paradigm with new fields for the public domain between the
Nodes (e.g. Class, Flowlabel (can be used end-2-end too), Hop Limit,
Extension Headers to assist forwarding decisions, TBD ECN bits).

/jim

---

From: Jim Bound <[email-masked]>
Date: Sat, 24 Jul 1999 12:05:19 -0400

Hi Robert,

>attempt at presenting a mechanism.

This as you know is very complex stuff and as Bill pointed out a
proposal and I think an implementation exists from UCLA for one idea.

But I believe any proposal must address both TCP and UDP.  I also
believe that for survival, the actual transport functions in the
implementation must be done at the network layer and notification has to
be done to any transport functions depending on addresses and to the
APIs accessing the transport functions. [I am trying to describe this
without using a particular implementation though I think using the BSD
paradigm is how I would describe the kernel and API changes needed].

I think the trigger for such an event for the network layer is an IPv6
Extension Header and will IMO look very much like the IPv6 Mobile
BINDING update.  

Charlie Perkins, I, and several University researchers started working on 
this from the perspective above but dropped it in favor of more pressing IPv6
activity.  The question is how important is this in the scheme of things
and work we have to do as implementors for IPv6 today.  We certainly do
not need this for IPv6 to begin deployment or even semi-wide deployment
IMO.  But open to hearing why that is not true?

The solution to this problem must address the following IMO:

 1.  Cause the operation to begin of changing the endpoint 
     address at the network layer on an implementation not the 
     transport layer.

 2.  Support both TCP and UDP not doing UDP is not a complete approach.

 3.  An implementation analysis in this case is important to determine
     the standard engineering affects to the transport function and 
     table lookups associated with that function, and the affect to
     APIs.

 4.  It should be an IPv6 DST option to notify expediently the
     Ext Header exists in the packet. This way it can be processed
     via the set up needed at the header.  Some may not like this and
     I am not saying process the Ext headers out of order but rather
     the DST option could tell a Thread on an implementation that
     a change to an endpoint address is going to take place.

 5.  Propogation Delay needs to be taken into consideration once
     a commit to changing the endpoint addresses has taken place.  

 6.  Performance costs of doing this should be measured and health
     warnings issued for RT applications.

 7.  Security is imperative the attacks from this are very bad and 
     could cause major damage.

That is just a start.

But I am still not convinced this is a priority for us and would like to
see the IRTF take this on at this point maybe instead of the IETF and
have its own mail list not e2e or the like.  It would need individual 
focus as a new effort and a Technical Champion to take it on and hear
all the input on solutions for this space.  I think this is even worth
getting a grant to work on and do it diligently.  I think it could even
be a Phd Thesis actually.

I also think this work would permit Hosts to use IPv6 anycast addresses
too which I think would be a good thing esp for Host cluster operations
where they do not want to "act" as routers, which is what we will have
to do today to use anycast addresses in IPv6 in a compliant manner.

/jim

---

From: Shane Kerr <[email-masked]>
Date: Sun, 25 Jul 1999 19:12:00 -0400 (EDT)

I'm going to go ahead and post this to the list since at least three
people have posted with some interest about renumbering survival.

> 	Based on a long-expired ID. There is code around someplace.

A URL or two would be nice.  I searched on Altavista, Google, Yahoo,
Excite, Lycos, and AskJeeves, as well as the search engine off of
http://www.ucla.edu/, and could find no references to Christian Hutiema.
I went to the UCLA computer science home page, http://www.cs.ucla.edu/,
and couldn't find any references to related material.  Any suggestions on
where to go or who to e-mail?

> 	extra cruft on the side (adding limited state).  Some code

Again, a URL or two would be most helpful.  Or a name, or something.

> 	bigi list archives.  Most of this is old ground.

Again, some detail would be nice.  I'm not really sure what "e2e" or
"bigi" are.  I'm thinking you mean the IRTF end2end mailing list for e2e.
However, I couldn't find an archive for the mailing list.  At least, there
wasn't one linked to from the IRTF home page, and a few quick searches on
various web engines didn't turn up any hits.  I'd rather not be the guy
who says, "Is there an archive for this?" to the mailing list, but I guess
I can if I have to.  :)  And what is "bigi" anyway?

It seems like you want discussion on this topic ended, or at least moved
off of the ipng mailing list.  This is fine, but I'm not really sure where
to take it from here.  Am I the only one here interested in work on
surviving a renumbering?  It seems pertinent, given the current proposal
on multihoming.

---

From: Alex Soares de Moura <[email-masked]>
Date: Mon, 26 Jul 1999 02:08:06 -0300 (GRNLNDST)

> where to go or who to e-mail?

Try again and look for Cristian Huitema
                                ^^^^^^^
> I can if I have to.  :)  And what is "bigi" anyway?

Archive of the end-2-end mailing list:

ftp://ftp.isi.edu/end2end/

> surviving a renumbering?  It seems pertinent, given the current proposal

Best regards,

--
Alex Soares de Moura
Academic Brazilian Research Network - http://www.rnp.br/index_e.html
NOC - [CO - http://www.rnp.br/co_e/] - Tel. +55 21 5111563

---

From: Alex Soares de Moura <[email-masked]>
Date: Mon, 26 Jul 1999 02:24:15 -0300 (GRNLNDST)

> Try again and look for Cristian Huitema

Sorry, his name is Christian Huitema.

His Homepage:
http://www-sop.inria.fr/rodeo/personnel/huitema/huitema.html

Best regards again,
Alex

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 26 Jul 1999 12:49:47 +0100 (BST)

On Sun, 25 Jul 1999, Shane Kerr wrote:
> > > An incrementing integer could be a problem.  It could make it
> > > easy to highjack a session. I was just talking about a number
> > > that can be used for mapping to the IP address and can be used
> > > in place of the IP address in the Protocol Control Block.
> > 

Bill unintentionally misled you. It's spelt Huitema.
http://www-sop.inria.fr/rodeo/personnel/huitema/huitema.html
http://govt.argreenhouse.com/felix/index.shtml
etc. Dunno where UCLA comes in. List of books in Amazon.

> > > What I am proposing is independent of the specific transport
> > > protocol in use. It will work for both TCP and UDP.  What I
> > > propose is code to perform the mapping to the IP address from
> > > the identifier used in the protocol control block and an
> > > auxiliary protocol to negotiate an update to that mapping when
> > > either peer needs to renumber or select a different interface.  
> > > This combination of the mapping code and a protocol to
> > > negotiate the update I am calling an Agent.
>
> However, I couldn't find an archive for the mailing list.

has everything back to 1984. It would be worth someone-at-ISI's time
to set up MHonarc and a search index on this in the ISI web pages.

> At least, there wasn't one linked to from the IRTF home page,

http://www.irtf.org/charters/end2end.htm
'needs updating... circa 1992' is, oddly, a page last updated March
1999.

Not having a link to the end2end archives there, much less a search
form for the archives, is frankly criminal, even if most of
end2end-interest don't use these newfangled johnnycomelately things
like the web.

Abel, please fix the webpage with a link to ftp://ftp.isi.edu/end2end/
ASAP and begin looking into setting up searchable web indices of the
IRTF lists so that new Internet researchers can get up to speed. It
seems to me to be in the IRTF's best interest.

Bill, since you're at ISI, please organise setting up MHonarc and
search functionality for ISI's end2end archives. That will decrease
the likelihood of you having to tell people that their ideas are old
ground in future - and you'll be able to cite actual specifics easily
if you wish when you do.

Shane, bigi is likely big-internet.
http://metalab.unc.edu/usenet-i/groups-html/info.big-internet.html
I've no idea where the archives for this one, if any, are.

L.

and a pox on people who can't even call things by their True Names.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Robert Honore <[email-masked]>
Date: Mon, 26 Jul 1999 08:42:58 -0400

Dear Shane,

> "bigi" are.

I shall check out the URL's you posted.  I believe BIGI was supposed to be an
internet mailing list for something called "BIG Internet".  I have never been
able to find their archives, though.

Yours sincerely,
Robert Honore.