[ppml] 2005-1 status

Owen DeLong owen at delong.com
Tue Jan 31 15:10:38 EST 2006


> Please forgive me if I'm not doing this "correctly", but even though
> I've lurked on this list for a while I have never participated in any
> policy development processes.
> 
You're doing just fine on the process.

> What I see distinctly under-represented here is the
> corporate/enterprise IT view, and as a result I think the vagueness of
> the "large/complex" will lead to problems. In my view, the direction
> this policy is taking will lead to even a lower rate of corporate IPv6
> adoption than the pessimists here think. In today's environment, an
> organization does not have to be particularly "large" or "complex" to
> have legitimate need for PI space and real multi-provider multi-homing.
> A policy which makes that more difficult than it is today is doomed.
> 
The current IPv6 policy is that there is no such thing as PI space, so,
currently, it is impossible.  This policy is an attempt to make it
easier, but, we still have to compromise with the portion of the ARIN
constituency that believes fully opening this up will cause an
uncontrolled explosion of the global routing table which will melt
down the internet.

Their concerns are, in my opinion, overstated, but, not without merit.

> Keep in mind, please, that network architecture decisions in the real
> world are increasingly not being made on the basis of technical (i.e.
> protocol-level or routing-policy-level) factors. Network architecture
> decisions are being driven by what can be justified to compliance
> officers, internal auditors, third-party review (audit or otherwise),
> data security officers, etc. These may be people who know just enough
> about networking to pass a CISSP or CISA or CIA exam but have no idea
> what BGP is. There are many, many organizations that are large enough to
> have an IT staff and an internal audit or compliance staff but not large
> enough or old enough to have a legacy /16. Many of these organizations,
> publicly, maybe are only a couple of /30's, but behind that could easily
> be a /20's or a /19's worth of devices. Under current policy, the only
> way to get PI space for such an organization is to renumber to non-1918
> space or to stretch the truth with ARIN (which seems to be the
> nudge-nudge-wink-wink sort of advice that one occasionally gets). Yet to
> an IT Director or above, who asks why we can have telephone number
> portability but not IP address portability, what's the answer?
> 
Well, the first answer is that the structure of the internet is quite
different than the structure of the telephone network.  The telephone
network differs in the following meaningful ways:

	+	The telephone network is a switched virtual circuit
		network.  Routing decisions are made once per call
		at the time of call origination.

		The internet is a packet switched network.  The
		routing decisions are made independently on a packet
		by packet basis at each router along the way.

	+	In the telephone network, there is a level of indirection
		that doesn't exist in the IP world, at least not yet.  Your
		"portable" telephone number is not the number which
		is used to route the call.  Instead, that number is looked
		up in a global database (SS7) to determine the actual
		destination.  The call is then routed to that destination.

		In the internet, the destination IP address is used both
		to identify the end recipient, and, for all routing
		decisions along the way.

> I saw this come up on the list a bit around a week ago, but have the
> feeling that the provider community, which dominates this process, isn't
> listening. Policies which are predicated on providers' statements (as
> I've seen here) of what an AS "needs" without listening to what those
> ASes want and why don't make for a sustainable business model, IMO. It's
> not that we (the customers) don't trust you, it's that in today's
> regulatory/business environment we no longer are permitted to trust you.
> If I don't have a solid plan for what to do quickly and painlessly to
> switch ISP's, I lose my job or our customers or both. For better or for
> worse, PI space and multi-homing are the answer du jour.
> 
Both constituencies are somewhat represented.  I do agree with you that
the end-user constituency is underrepresented compared to the provider
constituency.  However, both sides have legitimate concerns, and, I
believe both sides do, by and large, understand the needs of the other.
The real task here is to find the compromise between the two sides
that makes the internet most useful for the largest portion of the
constituency.

On one side, if we do allow PI addressing to get out of hand, current
routing technology cannot scale to support it, and, the internet will
be incapable of maintaining a routing infrastructure.  A non-functional
internet or one in which some significant portion of addresses are
unreachable or unstable does not serve the end user or provider
constituencies.  This is the extreme of one side of this issue, and,
the source of most of the anti-PI statements.

On the other side, if we do not allow PI addressing at all, then there
is a significant portion of the end-user constituency that is not well
served.  This is the opposite extreme, and, one of the reasons that
there is a policy proposal to try and change this fact.  The IETF
intent was that there would be no PI space issued in IPv6 to anyone
other than providers.  I believe that intent was flawed and that is
one of the reasons I wrote the first version of this policy and have
continued working with Kevin and Lea and the list on improving it.


> Off to don my Nomex.
> 
Hopefully you won't get too many flames.  I, for one, as one of the
policy authors, appreciate your comments.

Owen
-- 
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/20060131/faffa405/attachment-0001.sig>


More information about the ARIN-PPML mailing list