[ppml] 2005-1 alternatives
Jeff Williams
jwkckid1 at ix.netcom.com
Wed Apr 20 06:29:58 EDT 2005
Owen and all,
By golly I agree with just about everything you said below. I would
add a couple of caveats.
1.) It is likely and in process/progress that Ipv6 will be supplanted
by more advanced and more secure Ip protocols...
2.) Concerns regarding privacy and security are becoming more and
more broad reaching. With Ipv6's shortcomings in this area, and
Ipsec still a mess, there is a good chance that Ipv6 may loose any
attractiveness it could have now...
Owen DeLong wrote:
> > But then the duality and implicit tensions of routing scaleability and
> > addresses utility goes back a very long way - the Routing and Addressing
> > Group of the IETF in the early 1990s was an early incarnation of the same
> > set of tensions relating to what makes routing scale vs what makes
> > addresses truly useful and convenient to use.
> >
>
> That is why I am becoming progressively more convinced that we need
> to separate these two functions. Addressing primarily provides an
> end-system identifier function. Unfortunately, because we have chosen
> to also use a portion of this Address to provide routing information as
> well, we have painted ourselves into a corner on these issues, repeatedly.
>
> I think it is time to take a step back and consider a more radical approach
> to separating these two functions. In the long run, I think we would do
> well to consider the possibility of eliminating prefixes from interdomain
> routing, and, instead, build a facility for looking up the origin-AS for
> a given prefix, and, routing strictly on origin-AS. WIthin a given AS,
> routing would occur as it does now, but, Interdomain routing is where
> we face table overflow, not intr-as routing.
>
> The bottom line is that IPv6 doesn't provide any benefits over IPv4 to
> most adopters today. IPv4 has provisions for getting PI space, and,
> people are using them because there are lots of things that just don't
> work right or sufficiently without it. IPv6 has not solved ANY of these
> problems.
>
> There are, as I see it, two solutions on the horizon for this situation in
> IPv6. The first is ULA, which, has most of the drawbacks of RFC-1918
> address space, but, lacks the self-enforcing limits of RFC-1918 IPv4
> address space. The reality is that absent a forcing function to keep
> ULA from getting routed globally (such as the inherent overlap issues
> with RFC-1918 space), market demands will become a forcing function
> driving more and more ISPs to route more and more ULA space. Absent
> this policy, or, one like it, there are three possible outcomes:
>
> 1. IPv6 adoption will continue to be delayed until such
> time as IPv4 space is virtually exhausted and there is
> no further possibility to limp along with IPv4.
>
> 2. IPv6 adopters will drive the global routing of ULA
> over time.
>
> 3. Most IPv6 adopters will find or fabricate a way to
> act as an LIR out of desperation to obtain PI space
> under existing policy.
>
> 4. All of the people who have very legitimate and well thought
> out needs for PI address space will simply fade into the
> woodwork and accept IPv6 as is with PA space and renumber
> whenever they have to.
>
> Of the 4, I can see any or some combination of all of the first 3 as being
> likely. I think that the fourth is what the current IETF proposals are
> banking on, and, I think that any real-world perspective will clearly
> show that there is absolutely no historical precedent or reason to believe
> that it is at all likely.
>
> Owen
>
> --
> If this message was not signed with gpg key 0FE2AA3D, it's probably
> a forgery.
>
> ------------------------------------------------------------------------
>
> Part 1.2 Type: application/pgp-signature
> Encoding: 7bit
Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
Pierre Abelard
"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng. INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
Registered Email addr with the USPS
Contact Number: 214-244-4827
More information about the ARIN-PPML
mailing list