[ppml] 2005-1:Business Need for PI Assignments

[Owen DeLong]

>> The decision to make every subnet a /64 and issue /48s or more to every
>> end site (for a very strange definition of the term site) that requires
>> more than one subnet was made in the IETF.  If you want to change that,
>> you need to get involved in the V6 Working Group.
>
> I don't want to change it.  I want to know why the decisions made in the
> IETF are driving the policy here.  Color me skeptical.
>
Uh, because the IETF is the body that makes design decisions for internet
protocols, and, policy must, at some level, reflect those decisions.

>> Policy 2005-1 is about trying to get provider independent allocations for
>> organizations which would not otherwise qualify as LIRs.  While, to some
>> extent, the current rules were specified by the IETF, that is, in my
>> opinion, more in the realm of policy than design.
>
> We have "PI space" in IPv4.  Why not have it in IPv6?  That is, if there
> is no difference between IPv4 and IPv6 when it comes to resource
> management.
>
> But then I hear that v4 and v6 are vastly different.  How so?  Should we
> take a hard line and prevent "PI space" in IPv6 to force correctness?
>
Vastly different is one very vocal person's viewpoint.  The reality, in
my opinion (and I think the majority of those present) is that there is
not a lot of difference other than the size of the pool.

There are those that believe a hard line to prevent PI space is necessary
because they fear that if we do not take said hard line, we will again face
the problems which led originally to the CIDR hack, and, which provided
some of the impetus for the NAT hack.

Frankly, I think that it is appalling that v6 has come full circle.  There
were, originally, two proposals for v6.  I forget the original name of the
one which was pursued, but, the one which lost early on was called TUBA
(Tcp/Udp with Big Addresses).  The reason TUBA was discarded early on was
because of belief that we needed to do a better job of addressing a number
of issues and not simply create a protocol with bigger addresses.  The
issues that were deemed so critical were:

	+	Autoconfiguration
	+	Easy Renumbering
	+	Mobile Computing
	+	Security

Of everything on this list, the current V6 proposal is marginally better
in terms of security, and, fails to in any way provide an advantage over
IPv4 in any of the other areas.

Worse, V6 has no PI, while V4 has PI space readily available.  This makes
it a no-brainer to not adopt V6.  Now V6 is proposaing ULA.  ULA is like
PI, but, you're not supposed to route it, nudge nudge, wink wink, and, you
don't need to register it in any central database.

>> While the /48 and /64 decisions could be policy, given the current
>> constraints and assertions in the V6 protocol specifications, it is not
>> a policy decision, but, a design decision.  Design is clearly in the
>> realm of IETF.  Policy has some overlap, but, I believe in the long run
>> that the RIRs must be the ones with the majority of influence over
>> policy.
>
> 2005-1 is a policy, and that is in the subject of the message.  Is it a
> good idea or not?  That is a policy question.
>
Well... I feel that the /48, /64, etc. discussion has wandered far afield
from the topic of the 2005-1 policy proposal (whether or not to issue PI
space to end users of V6 that can justify it).  I just don't see how a 
debate
of minimum prefix sizes overall for V6 is part of this discussion.

>> As such, let's focus here on what we can do within the realm of policy.
>
> The IETF focuses on design, not on education.  PPML focuses on policy,
> not on education.  Where should people go to get educated on the design
> to offer informed opinions on policy?  If the PPML is not for education,
> is it for "stumping"?  How do we reach consensus if there is no arena in
> which to hear and consider differing opinions and viewpoints.
>
Start by reading the RFCs.  Then, there's the IETF Mailing List archives.

I'm not saying that PPML is not for hearing and considering different 
opinions
or viewpoints.  If you want to debate prefix sizes on PPML, I don't have
any problem with that.  Either find, or, propose a policy that deals with
that issue, and, have that discussion within that thread.  I'm just saying
that it isn't what 2005-1 is about.

Owen


-------------- 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/20050425/9537c596/attachment.sig>