Subject: Re: getting IPv6 space without ARIN (Re: PAT )

From: Hakikur Rahman <[email-masked]>
Date: Sat, 19 Aug 2000 14:33:07 +0600

I agree with Brian Carpenter,

"We expect millions of those during v6/v4 coexistence."

Hakik.

Brian E Carpenter wrote:

Valdis,
What do you mean?
Firstly "6 over 4" refers specifically to RFC 2529. Do you mean standard
IPv6 tunnels as per RFC 1933 and its pending update?
If so, what's the problem? We expect millions of those during v6/v4 
coexistence.
Why is that a swamp, assuming people get their prefixes from upstream?
Brian

[email-masked] wrote:
...
 > Personally, I see a major swamp of private 6-over-4 tunnels between
 > early implementors just WAITING to happen. It;'s not bad if there's 2 or 3
 > or 5 sites, but it's just a tad more then O(n)... ;)

--------------------------------------------------------------------------------
Hakikur Rahman
Project Coordinator
SDNP-Bangladesh.
Email: [email-masked], [email-masked]
http://www.geocities.com/hakik_2000,  http://www5.50megs.com/hakik
-------------------------------------------------------------------------------

---

From: Sean Doran <[email-masked]>
Date: 21 Aug 2000 02:19:58 +0200

> "We expect millions of those during v6/v4 coexistence."

So back to my original question, which apparently none of
the IPv6-Leaders liked:

  -- if we are doing tunnels which follow a logical
     topology rather than a physical one,
  -- why don't we have support for multihoming to
     different logical topologies
  -- with policy routing done on the host-side with
     respect to selecting which of various address
     combinations to use/allow for traffic exchanges
  -- thus allowing generalized topologically-addressed VPNs
     (with the topologies being virtual, constructed with tunnels)
  -- thus allowing a partitioning of the IPv6 address
     space in a way that is simultaneously both
     topologically aggregatable _and_ policy-based

The missing piece is the control over who gets to
terminate a tunnel into a particular address space.

        Sean.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Aug 2000 10:47:21 -0500

>      different logical topologies

We should. But multihoming is still a hard problem and we are
still working on it in IPNGWG. 

>      combinations to use/allow for traffic exchanges

This is part of the hard part, too complex for a short email.
(I'm not trying to brush it off - it needs to get done.)

>      topologically aggregatable _and_ policy-based

That would be good.
> terminate a tunnel into a particular address space.

Isn't that a business issue? 

   Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 21 Aug 2000 14:11:08 -0400

> >      topologically aggregatable _and_ policy-based

Actually I'm of the opinion that IP addresses exist to name attachment
points (and sets of attachment points) in the network, and this governs 
how they are structured.  They are used to name other things also, and 
this is often a useful optimization.   But any attempt to change the 
structure of IP addresses to do something besides name attachment points 
is likely to compromise this structure.

128 bits is probably enough for naming network attachment points for
quite a long time, especially with due care in how they are assigned.
But if you try to add policy to this structure, 128 bits becomes 
quite a small number.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Aug 2000 15:21:04 +0859 ()

Brian;

> still working on it in IPNGWG. 

Multihoming is not a hard problem.

None the less, IPNG WG have been working on it in vain only to make
protocols complex, because it is working for a wrong direction.

Multihoming does not scale and is not reliable, if it is offered by
intelligent intermediate systems.

IPv4 multihoming does not scale and is not reliable, because it is
offered by intelligent routing systems.

Multihoming scales and is reliable and easy, if it is offered end to
end by intelligent end systems, transport/application protocols on
which directly handles all the multiple IP addresses from DNS
(and mobility).

However, partly because the committee has worked too much to a wrong
direction to offer multihoming by intelligent intermediate systems
and partly because the committee decided to minimize code modification,
it is likely that they can't accept the fact of internetworking that
only end-to-end approach scales and will keep working for the current
direction.

See

	draft-ohta-e2e-multihoming-00.txt

   This memo describes the architecture of end to end multihoming.
   End to end multihoming does not burden routing system for
   multihoming.  That is, even extensive use of end to end multihoming
   does not increase the number of entries in a global routing table.

   Traditionally with IPv4, multihoming capability is offered by an
   intelligent routing system, which, as is always the case with
   violating the end to end principle, lacks scalability on a global
   routing table size and robustness against link failures.

   On the other hand, with end to end multihoming, multihoming is
   supported by transport (TCP) or application layer (UDP etc.) of end
   systems and does not introduce any problem in the network and works
   as long as there is some connectivity between the end systems.

   Because end to end multihoming is performed in end systems, the
   architecture needs no routing protocol changes. Instead, APIs and
   applications must be modified to some extent.

for more details.

						Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 25 Aug 2000 08:49:19 +0100

>>Multihoming is not a hard problem.

to add to this

making multihoming transparent to the application within the IP level
is a hard problem, but is often _besides_ the point - failover and
fault tolerant applications WANT to know in a timely and explicut
manner when a link or interface fails - they do not want transparency
- some networks preople think that the applicatio nbuilders do (and
some naive applioaction writers do) but in any sophosticated realworld
(tm) fault tolerant application, transparency is not what is
wanted...so in that sense, the use of smarts in the appkcation layer
are exactly whats wanted and the problem of trying to do multihomeing
(and multi-provider multihoming) while maintaining address (and other
state) aggregation is a snare, edlusion and chimera...

j.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Aug 2000 17:46:47 +0859 ()

Jon;

> state) aggregation is a snare, edlusion and chimera...

Thank you for the additional explanation. Though the end to end
principle already implies the point (it's surprisng how many good
properties of the internet are reduced to the principle), its not bad
to make it explicite, before someone tries to defend IPv6 hype by
distorting the definition of "end to end".

Anyway, if IPv6 committee people are let alone, they will distort
the definition of multihoming something supported by their complex
protocol but totally useles in the realworld (tm), which was what
happened with IPv6 hype including autoconfiguration and renumbering.

Do you have any idea on how can it be avoided?

						Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Aug 2000 08:13:25 -0400

> which directly handles all the multiple IP addresses from DNS

uh, no.  multihoming done by end systems has a different set of problems
than multihoming done by routers.  end systems have no good way to keep
track of changes to network topology, and the effort and network traffic
that would be required to inform them of such changes makes that approach
to multihoming much less attractive.  also, it is very hard to support
mobility satisfactorily in this manner, especially when multiple 
communicating end systems are moving at the same time.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Aug 2000 08:17:19 -0400

> state) aggregation is a snare, edlusion and chimera...

seems like an exaggeration.  FT apps do want to be explicitly informed 
about network failures so they can adapt, and would like the ability
to make their own decisions about which links to use (given multiple
choices).  but most apps are not FT, and to those that aren't FT,
address stability under changing network conditions is a boon.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Aug 2000 21:51:08 +0859 ()

Keith;

READ THE DRAFT.

> track of changes to network topology,

There is.

READ THE DRAFT.

> also, it is very hard to support

Mobility is no more difficult.

> address stability under changing network conditions is a boon.

Thus, most apps are taken care of by the transport layer.

READ THE DRAFT.

							Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Aug 2000 09:13:01 -0400

> READ THE DRAFT.

Ohta:

GET A CLUE.

I did read the draft.  What's more, I have tried implementing multihoming
in a way very similar to what you are describing, which is what informed
my earlier comments.  Without routing support from the network, it cannot
be made to work well.  Especially if you're also trying to support mobility.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Aug 2000 23:31:36 +0859 ()

Keith;

> I did read the draft.

Huh? You obviously don't.

> What's more, I have tried implementing multihoming
> my earlier comments.

I know "very similar" often means "completely different", especially
when you don't read the draft carefully.

> Without routing support from the network, it cannot
> be made to work well.

Wrong.

With the end to end principle, it is silly to distinguish routers and
nodes and give routers more intelligence.

With end to end multihoming, there is no reason that the global routing
table is large.

So, you can assume a host has full routing table.

However, unless you use host route, exsitence of a route entry means
that there is reachability to some part of an address range of the
entry but not necessarily to the target host.

Thus, routing systems may give you a hint but routing information
can not be fully relied upon.

All the possible addresses should be tried with certain time out.
Applications needing quicker recovery should use smaller time out,
of course.

They are all written in the draft.

READ THE DRAFT.

> Especially if you're also trying to support mobility.

No.

My draft says nothing about mobility, because it is no difficult.

							Masataka Ohta