[ppml] 2005-1 alternatives

[Owen DeLong]

Agreed.  However, I think we need to stop trying to address security
or privacy at the internetwork layer.  For security or privacy to be
meaningful or scaleable, it has to be end-to-end, or, very close to
that.  Transport is, in my opinion, one level below the lowest point
where it should really occur.

Transport and Internetwork integrity is one thing, but, real security or
privacy depends on end-to-end authentication, encryption, and verification.
We're a long way from having that in a widely adoptable form.  X.509 is
proof of how easy it is to screw that up.  Verisign is proof that even
large organizations with a huge vested interest in making something work
can't always (or often) get it right.

However, since this is a Public Policy discussion, let's stick to what
we can do within the context of ARIN policy.  Until IETF has something
with which to replace IPv6, we have to consider it the current vision
for the future of IP.  Anything further out is more appropriately discussed
in the IETF.  As such, give the current realities, I think that what was
proposed in 2005-1 was about as good as we can make IPv6 assignment
policy given current constraints.  I'd like to hear from the people
who opposed 2005-1 on what would make it more palatable.

Owen


--On Wednesday, April 20, 2005 3:29 AM -0700 Jeff Williams
<jwkckid1 at ix.netcom.com> wrote:

> 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
> 
> 



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050420/4368f66a/attachment.sig>