[address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")

----- Original Message ----- 
From: "Masataka Ohta" <mohta at necom830.hpcl.titech.ac.jp>
Sent: Thursday, June 24, 2004 7:17 AM


> Gert Doering;
>
> >>With your fallacy denied, why do you replay the well known
> >>fallacy of NAT that NAT is transparent to the upper layers?
>
> > Please STOP cc: ing the address-policy working group on e-mails that
> > are purely about protocol design decisions and problems.
>
> It is not protocol design decision but is information that
> Kurt want multi6 not solve the multihoming problem.
>
> I stated it with a well known reason that intermediate entities
> such as layer 3.5 and NAT which perform address rewriting can
> not be transparent.
>
> > Your opinions about the address policy are known by now, and these
> > e-mails do not contribute further to the discussion at hand.
>
> The point of my post is that 8192 is large enough as the
> global routing table size, which is mostly orthogonal to
> multi6 issues (except that failure of multi6 bloat the routing
> table size indefinitely large).
>
> One important factor not explained yet very well is that BGP
> converges slowly as the number of ASes increases, which is
> another reason to limit the global routing table size.
>

You can try but you can't stop the evolution(tm). A number like that or any other number will be just as "fatal" like the 640kb
problem was in the 80's in the long run. The problem with the current IPv6 specification as I see it is purely technical and should
be dealt with by the vendors making the IP routers. There is more than one way to implement routing algorithms, and several of them
could equally give the best performance. Of course it would help if the RIR's tried not to hand out more than 1 prefix per LIR. If a
LIR is multihomed they should be allocated a prefix. If not then people will stick to IPv4 until we really run out of ip's and keep
sticking to it. Then we would have major problems deprecating IPv4. PI allocations doesn't exist anymore with IPv6 so that problem
is solved..?


Joergen Hovland