Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

From: [email-masked] (Noel Chiappa)
Date: Fri, 14 Apr 2006 15:13:35 -0400 (EDT)

> From: Scott Leibrand <[email-masked]>

    > the desire not to pass a "PI for everyone" policy that would explode
    > the routing table.

Interesting that you should mention that, because there's zero technical
differentiation between "PI space" and "portable addresses". So I have to
wonder if this initiative will raise the pressure from users for portable
addresses.

PS: > From: Kevin Loch <[email-masked]>

    > I find this comment extremely offensive. ... Your implication that the
    > participants were either uninformed or diddn't care about the
    > consequences is completely off base.

There's a certain deep irony here, because PI-addresses have been considered
at length in the IETF in at least two different WG's - CIDR-D and Multi-6.
Both rejected them after extensive discussion.

Nevertheless, a policy-making body has seen fit to ignore that, and make an
engineering decision to deploy PI-space. It's hard to read that decision any
other way than to have it imply that the decisions in those WG's were
technically uninformed.

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Apr 2006 15:53:03 -0400

>Both rejected them after extensive discussion.

Can you point to documents that give the results of this?  (Please 
don't cite mail archives, following threads is not very efficient.) 
If the reasons for the rejection are obscure, the uninformed will be 
likely to stay that way.

>other way than to have it imply that the decisions in those WG's were

It's hardly an engineering decision.  The sense was that without PI 
space, IPv6 will remain in a state that will not get it deployment 
experience.  Having (personally) sat through the discussions at ARIN, 
RIPE, and APNIC, and having seen IPv6 grown in the IETF, I wouldn't 
characterize the anything as "uninformed."

The debate between 1) what happens to router tables with PI prefixes, 
2) what happens when the protocol is crimped into a 
comfortable-to-operate fashion, and 3) what customers are will to 
bear, has been raging for more than a year.

It's plain to see that PI space threatens to blow up routing.
It's plain to see that IPv6 is supposed to allow for end-to-end flexibility.
It's plain to see that customers no longer want to be tied to ISPs.

My personal take is that IPv6 answers to a set of requirements 
devised 10 years ago and that no longer captures all the needs of the 
Internet.  Route aggregation is good, but it relies on business 
assumptions that are unrealistic.  Further, layer violations have 
become rampant, even if they are architecturally distasteful, they 
have become part of the operations landscape.

In today's Internet, an "end user" whose cash flow depends on the 
network will be willing to rely on one provider, nor be willing to be 
locked into any set of providers over time.  (Note that providers are 
the least financially stable players in the game.)  Even if you have 
two providers today - what if they merge?  I've known many who 
thought they had redundant paths, only to see that through mergers on 
the other side, all they had was on the same fiber.

Many times customers walk because of business decisions, as in 
disputes over billing practices.  This was added to a comment I had 
made within ARIN some time back.  The moral is that an assumption 
that address assignments/allocations from RIR to LIR to subLIR to 
user isn't universally loved.

Renumbering is not pleasant.  Renumbering IPv6 style (prefix from the 
infrastructure, suffix from something else) isn't as promised thanks 
to things like firewall rules and other in-network beasts that 
configure addresses.  You can say that these middle boxes don't 
belong, but try running an enterprise network without them.  (I 
haven't been without a firewalled and/or NATted address since 1996, 
even through different employers.)

Before IETF'ers start pointing fingers at "uniformed" decisions of 
other groups, it's worth asking ourselves where the misinformation 
comes from and, possibly, whether what has been developed is still 
relevant.  I hear folks saying the IPv6 has bigger addresses and 
there's no other option, so we might as well go to IPv6.  Is that all 
it comes to, 96 more bits than v4 and the only game in town?  (I ask 
rhetorically.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 14 Apr 2006 16:41:59 -0400

On Fri, 14 Apr 2006 15:53:03 -0400, Edward Lewis <[email-masked]>
wrote:

> experience.  
This is a very important point.  Without expressing an opinion on the
proposal itself, I'll note that this answers one very important question:
why should an organization deploy v6?  The ability to secure PI space is a
very powerful answer for some companies.  (Some people will say "and
that's why they use NAT today.  True -- but companies who use 1918 space
and NAT get into trouble when they create private interconnects to other
such companies -- or, worse yet, to a group of other such companies that
are working together on something.  Now, if they could qualify the
locally-unique address with a site prefix it would be easier, but that's
more or less 8+8 which is what IPv6 addressing should have been from the
beginning...  I digress -- that issue was hotly debated when IPv6 was
being created, and though some of us were strongly in favor of it others
were strongly opposed.  There was simply no consensus to do the right
thing.  Hmm, my biases are showing...)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 14 Apr 2006 15:59:56 -0700

> wonder if this initiative will raise the pressure from users for portable

Depending on how they actually get defined and handed out, portability could
be one outcome. Scott & a few others of us are working on the next step
which would put limits on the extent of that portability (ie: it is
manageable to deal with porting between providers within a city, but not
between cities). 

> other way than to have it imply that the decisions in those WG's were

No, those groups couldn't see the forest for the trees. They were absolutely
technically informed, but completely unwilling to listen to the big picture
political reality. This thread is arguing that this policy decision has the
opposite problem, but in fact it does not. It is an attempt to get in front
of what is a growing wave of demand to head off an outright pronouncement
from outside the community which will result in number portability. By
moving first we can put in enough technical structure to contain foreseeable
problems, while if we wait we will be forced into a quick and dirty random
approach that we all know will fail. 

I was not happy with the policy as worded, but willing to live with it for
now as a first step to really fixing the problems facing edge networks. The
locator/id split approach is a nice thing to work on, but it will take more
than a decade to deploy even if people agree to the result. The fundamental
problem is that most of the meager security architecture we do have relies
heavily on those being aligned. If they are split all of the firewall
silicon will have to be rebuilt and new mechanisms for tracking the identity
in flight will have to be developed. Of course none of that work will start
until the non-deployable shim approach has proven itself viable. Add to that
the fact that it moves any semblance of control the ISP thought they had to
the end node and you will find that as they already have said they will do
all they can to block its adoption.

The IETF has consistently refused to acknowledge that prefixes independent
of PA are necessary. The intense focus on maximum aggregation at all costs
is just not viable for end customers. A broken routing system is equally not
viable, but there is a middle ground that gets messy because it does not
have simple solutions without constraining topology. These are all
trade-offs, and the ISPs are demanding unconstrained topology with a minimal
routing table. That set of requirements leads to efforts like shim6. The end
sites are demanding autonomy with a stable routing system. That set of
requirements leads to structured allocations and topology constraints. Both
sides will have to give, but it should be noted that the ones holding the
money are the end sites.

Tony

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 15 Apr 2006 21:54:08 -0700 (PDT)

The end
> requirements leads to structured allocations and topology constraints. ...it
should be noted that the ones holding the money are the end sites.

Which makes a case for concentrating the effort on a stable routing serving
autonomous end sites. Frankly paying for an IP address makes as much sence as buying
a street address (how about the Post Office putting hot street addresses on sale).
It appears that IP address assignment reaches far and beyond Internet engineering
and should be administered by the international politically / economically
independed structure guided through RFC.

[email-masked]

> sides will have to give, but it should be noted that the ones holding the

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com