Subject: Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]

From: Bob Braden <[email-masked]>
Date: Wed, 29 Aug 2007 09:53:52 -0700 (PDT)

In this whole discussion, I find it hard to keep separate the
technical issues, about which the IETF should care a lot, from
the business model and issues, about which the IETF should be
agnostic.  We may personally care a great deal about the business
issues, but we cannot speak as an organization about them.

Bob Braden

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Aug 2007 12:57:44 -0400

> issues, but we cannot speak as an organization about them.
well, mumble.  we shouldn't be biased toward any particular business
model.  but there's nothing wrong with being biased towards flexibility,
or being biased against the RIRs changing IETF decisions to favor a
particular business model.

again, the fundamental problem here is that the RIRs are trying to
second-guess IETF design decisions.

---

From: Ray Plzak <[email-masked]>
Date: Wed, 29 Aug 2007 13:37:58 -0400

If you think that way, then why don't you say so on the ARIN Public Policy Mailing List where such a comment needs to be heard. Discussion about ARIN policy on this list will not influence the policy process.

Ray

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2007 12:58 PM
> To: Bob Braden
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce
> after all]
>
> Bob Braden wrote:

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 29 Aug 2007 14:23:38 -0400

I have to ack Bob ...well stated Bob.
/jim 

> From: Bob Braden [mailto:[email-masked]] 
> Sent: Wednesday, August 29, 2007 12:54 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: IPv6 RIR policy [was Re: IPv6 addresses really 
> are scarce afterall]
> 
> 
> technical issues, about which the IETF should care a lot, 
> from the business model and issues, about which the IETF 
> should be agnostic.  We may personally care a great deal 
> about the business issues, but we cannot speak as an 
> organization about them.
> 
> Bob Braden
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 29 Aug 2007 11:44:44 -0700

I agree and disagree.
 
I agree that we should not be attempting to build business models into the technology. I think that is bad for the technology and bad for business. I beleive that the email encryption market would be much larger today if folk had not tried to build in a particular business model as the only one supported.
 
But I do hink we need to give these issues an airing because the cost of not doing so is that we end up with unspoken agendas driving decisions, agedas that would rapidly unravel if given attention.

So for example Keith's latest claim that I am thinking of the benefit of ISP profits in proposing that virtually every party who is not in the business of providing access to others is likely to find a /64 ample provision in practice. I agree that a default allocation of a /128 would create an issue, but I see no means of extracting functional pricing that is possible with a /64 that is not possible with a /48.
 
In fact Keith's proposition that NAT is evil and must be prohibited in IPv6 makes it much easier for ISPs to impose functional pricing as they can charge according to the number of IPv6 addresses that they see in use. 

A long time ago I worked in the control enginering group at ICI. While I am quite prepared to beleive that in ten years or so I will have 100+ IP addressable devices in the house I do not for a moment accept that they will be externally visible. Telemetry data tends to only have value after interpretation and interpretation is almost always context dependent. Reading the PH meter in the effulent flow is meaningless unless you know the status of the three term controller since a high reading when the controller is offline probably means that someone is washing the PH probe.
 
So no, I don't think that I will have 100+ Internet accessable devices in the house even though they have IP. Instead I expect that communication from the site (i.e. house) will be mediated through a control center in the same manner as for process control. Further I don't think it very likely that even with the highest degree of automation imaginable that I would have more control loops in my house than were necessary to manage a chemical plant in the 1980s, particularly given that control loops have significant management costs.

Keith's issue is real, his solution is bogus. The only way to ensure that ISPs do not impose functional pricing is competition. The way to make competition in the area of broadband provision effective is to comoditize the product by establishing a set of performance metrics for broadband service delivery.

________________________________

From: Bob Braden [mailto:[email-masked]]
Sent: Wed 29/08/2007 12:53 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce afterall]

Bob Braden

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Aug 2007 15:51:32 -0400

> If you think that way, then why don't you say so on the ARIN Public Policy Mailing List where such a comment needs to be heard. Discussion about ARIN policy on this list will not influence the poli…
I think the message needs to come from IETF that this isn't something
the RIRs should consider within their purview. 

I could argue within ARIN that ARIN's policies are harmful etc., but
that's sort of besides the point.  And of course it's not just ARIN that
we should be concerned with.

---

From: Ray Plzak <[email-masked]>
Date: Wed, 29 Aug 2007 16:02:39 -0400

You certainly wouldn't be the first to so argue, and I guarantee you wouldn't be the last. My point is if you don't say something on the PPML then you will be depriving the Internet community in the ARIN region of your insight and technical expertise, a case in which everyone stands to lose -- you and the ARIN community.

As far as the other RIR communities are concerned, persons in all 5 RIR service regions tend to be observant of the discussions in each other's community, so you would be reaching more than just ARIN.

The choice is yours,

Ray

> Sent: Wednesday, August 29, 2007 3:52 PM
> To: Ray Plzak
> Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked]
> > If you think that way, then why don't you say so on the ARIN Public
> Policy Mailing List where such a comment needs to be heard. Discussion
> about ARIN policy on this list will not influence the policy process.
> >

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Aug 2007 16:36:51 -0400

> 	"the" RIRs are membership organizations, with members
> 	consisting of the operational community.  they have to
> 	try and work with whatever the IETF gives them.. and when
> 	what the IETF provides is not operationaly feasable, they
> 	can and will make changes so that an operational network
> 	exists.
>   
no demonstration has been made that what IETF provided is "not
operationally feasible".  also, I suggest that the RIRs are only
considering operations from a narrow point-of-view.
> 	now the IETF is a membership organization as well, so
> 	individuals can participate in both communities..  if
> 	you feel that an RIR policy is wrong, then the correct
> 	place to "fix" it is within the RIR community. 
perhaps, but if IETF has the problem that it's not willing to assert its
ownership over its own protocols, that problem is better addressed in
IETF than in ARIN.

Keith

---

From: Bill Manning <[email-masked]>
Date: Wed, 29 Aug 2007 13:21:01 -0700

now the IETF is a membership organization as well, so
	individuals can participate in both communities..  if
	you feel that an RIR policy is wrong, then the correct
	place to "fix" it is within the RIR community.  In ARIN's
	case, the public-policy mailing list is where you can post
	your concerns so that they will be heard by the operational
	community and you can persuade them that their operational
	practices are "second-guessing" IETF design decisions.

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Bill Manning <[email-masked]>
Date: Wed, 29 Aug 2007 14:33:38 -0700

> considering operations from a narrow point-of-view.

	hum... something got your dander up... that doesnt qualify
	as a demonstration?  and your suggestions (as Ray pointed
	out) are not reaching the RIR community by your posting here.

> ownership over its own protocols, that problem is better addressed in

	very true.  but throwing protocols "over the wall" and 
	ignoring operational input does tend to affect the credibility
	and/or the usefulness of said protocol. Or are you suggesting
	that the IETF designs protocols without regard to operational
	relevence?

-- 
--bill

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Aug 2007 17:36:06 -0400

>considering operations from a narrow point-of-view.

Besides the lack of widespread operational adoption, no, no one has 
proven it can't work.  If "it" was operationally feasible, would we 
be discussing this now?

The RIRs do not limit the discussion of operations experience to a 
narrow few sources, rather the the discussion is open to all and an 
array of perspectives are offered.  The RIRs do not per se discuss 
operations, the discussion is over policies that are reflective of 
real world operational experience.

>ownership over its own protocols, that problem is better addressed in

It's not a matter of ownership but whether the engineering solution 
is still germane to real world needs.

IPv6 (as I first understood it) did have a business model assumed - 
that one ISP would be all that an enterprise customer would need, 
hence "provider assigned" addressing would be the approach to 
providing more addresses, and via route aggregation, with out over 
taxing the routing system.  Traffic engineering, price competition, 
disaster recovery, etc., would all be something the ISP would do.

The trouble is that during the past decade a large set of customers 
are no longer willing to rely on a single ISP for their service for 
various reasons.  This is why the "provider independent" policies 
have been made in the RIRs - to remove the business model that was 
buried in the original IPv6 operations concept.

Okay, maybe I'm stretching the point here.  I am not sure why I am 
bothering to post.  I guess I've become disappointed in the amount of 
disrespect displayed in this thread.

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

Think glocally.  Act confused.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Aug 2007 23:37:30 +0200

> 	can and will make changes so that an operational network

In the IETF, you need rough consensus to make decisions. I'm not  
entirely sure how this works in all the RIRs, but I think at least  
for ARIN, there is some form of voting involved. There are five RIRs,  
but the decisions they make often have global impact, and once one  
RIR has taken a course of action, the others often feel the need to  
follow.

Case in point is provider independent address space for IPv6. For a  
decade, this wasn't possible because the IETF was first studying, and  
after a _lot_ of effort to get things rolling, working on, mechanisms  
to provide multihoming benefits without injecting a prefix into the  
global routing table for each multihomed site. Then, with something  
workable within reach but not quite finished, ARIN saw fit to allow  
PI for IPv6 anyway, with potentially very harmful long-term results.

The IETF leadership never saw fit to say something about this during  
the ARIN process, and the ARIN process mostly consisted of "I'm not  
worried about the future and I want my PI block". The RIR policy  
mechanisms are simply not capable of rejecting policy changes that  
benefit a subset of the community, especially any subset that is well- 
versed in RIR matters, if such a change is against the interest of  
the community at large. The IETF isn't immune to this, but does a lot  
better than the RIRs because it has a technically capable leadership  
rather than an administratively capable leadership. (Maybe that also  
explains the differences in the financial situation between the RIRs  
and the IETF...)

>         if

Good luck with that.

---

From: David Conrad <[email-masked]>
Date: Wed, 29 Aug 2007 14:56:29 -0700

Keith,

On Aug 29, 2007, at 1:36 PM, Keith Moore wrote:
> operationally feasible".

Given the stunningly successful deployment of IPv6 ten years after it  
has been standardized, I can see how you would say this.

IPv6 is fascinating in how it has inherited many of the problems of  
IPv4 but in a way that isn't backwards compatible with IPv4.  As  
such, it shouldn't be too surprising that the same operational  
considerations that apply to IPv4 also apply to IPv6.

> also, I suggest that the RIRs are only considering operations from  
> a narrow point-of-view.

The narrow point of view that says the network should actually work,  
yes.  The RIRs are comprised of folks who provide or use Internet  
services.  As such, they do sort of want the Internet to function,  
even if that functioning is aided by violations of IETF holy writs.

Regards,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Aug 2007 18:20:57 -0400

At 11:37 PM +0200 8/29/07, Iljitsch van Beijnum wrote:

>In the IETF, you need rough consensus to make decisions. I'm not entirely
>sure how this works in all the RIRs, but I think at least for ARIN, there
>is some form of voting involved.

Every point I was going to make in response to this has already been made here:

http://www1.ietf.org/mail-archive/web/ietf/current/msg41581.html
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Aug 2007 22:58:21 -0400

> 	that the IETF designs protocols without regard to operational
maybe I'm misled but I've never thought of the registries as bodies
whose purpose was to collect operational experience.

but yes, I'd very much like for IETF to have more input from those
involved in operation, as well as having more input from more
applications developers, as well as having more input from those who
understand architecture, as well as having more input from actual users
or user groups.  we need all of those kinds of input.

Keith

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 30 Aug 2007 12:03:24 +0900

i repeat: voice your opinions AFTER you start using IPv6 daily.
	i'm tired of this guessing games by people in ivory tower.

itojun

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Aug 2007 23:51:11 -0400

> has been standardized, I can see how you would say this.
and somehow the RIRs are going to fix this by changing the default
address allocation size?  as far as I knew this was the least of IPv6's
problems.
> IPv4 but in a way that isn't backwards compatible with IPv4.  As such,
> it shouldn't be too surprising that the same operational
it wouldn't be surprising if it were true.  but it's not true in general.
>> also, I suggest that the RIRs are only considering operations from a
>> narrow point-of-view.
perhaps, but they might have a different idea of "functionality" than
their customers.  if we're trying to balance the interests of ISPs
against those of users, somehow a body that consists of mostly ISPs
doesn't seem like the place to do it.

Keith

---

From: Bill Manning <[email-masked]>
Date: Wed, 29 Aug 2007 21:42:35 -0700

> or user groups.  we need all of those kinds of input.

	as an IETF member, i might suggest that those mountains will 
	not come to you on their own.  i will suggest you follow 
	the advice Ray (and others) have given - If you want to 
	understand them and get their input, you have to go to
	their fora.

--bill

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 30 Aug 2007 13:56:44 +0900 (JST)

> 	i'm tired of this guessing games by people in ivory tower.

	To: field was wrong.  "your" was general "you".

itojun

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Aug 2007 02:03:47 -0400

> 	understand them and get their input, you have to go to
I told Ray that I would write up something and send it to ARIN.  but I
don't see how that will solve the problem of getting more relevant input
to IETF.  allocation sizes still need to be decided in IETF, not by
RIRs.  if it's really necessary to give RIRs or ISPs more bits to play
with, then IMO there's a good chance that IETF needs to revisit some
other IPv6 design decisions.

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Aug 2007 02:13:19 -0400

> proven it can't work.  If "it" was operationally feasible, would we be
> discussing this now?
maybe.  just because the RIRs decided not to do as IETF recommended
doesn't mean it's not operationally feasible to follow the
recommendation.  at least, I think we need more detailed feedback than
that before being convinced.
> real world operational experience.
what I meant was that users' operations are arguably as important as
ISPs operations, and I presume that because of their membership the RIRs
are only considering the latter.
> It's not a matter of ownership but whether the engineering solution is
> still germane to real world needs.
they are separate problems.  if the recommendations we made are not
viable, then we need to know that so we can fix it.
> that one ISP would be all that an enterprise customer would need,
I don't know anybody who assumed that.  I think it was instead assumed
that multihomed sites could make do with multiple (prefixes,addresses)
per (net,host) and that applications could somehow tolerate having
multiple source and destination addresses, be able to pick a reasonable
pair from among those available, and fail over to another source or
destination address when one end or another renumbered or the connection
failed.  (All of which I find rather dubious, but it's not the same
thing as assuming that there would be one ISP for an enterprise.)

> disrespect displayed in this thread.
well, I'm disappointed in the amount of disrespect displayed by RIRs.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 30 Aug 2007 17:08:21 +0900

> 	i'm tired of this guessing games by people in ivory tower.

It's a perfect explanation of poor quality of IPv6 developed by
opinions voiced by those who never used IPv6.

E.g., stateless autoconfiguration is not even a well defined concept
and useless.

As a result, however, /64 is fine for subscribers to enjoy arbitrary
many subnets with DHCP-based autoconfiguration, which should be a
surprise for greedy ISPs foolish enough to believe quality of IETF
products high.

							Masataka Ohta

---

From: Bill Manning <[email-masked]>
Date: Thu, 30 Aug 2007 01:09:43 -0700

> other IPv6 design decisions.

	two step process:
		1) go to arin
		2) listen to their concerns

	i understand your desire to go to arin and tell them what
	to do, but listening and trying to understand WHY they are
	making the choices/options they are would go a long way -
	*IF* the IETF should reconsider what it has done.

	looking forward to your joining the PPML list and your participation
	there.

-- 
--bill

---

From: Thomas Narten <[email-masked]>
Date: Thu, 30 Aug 2007 09:11:15 -0400

> for ARIN, there is some form of voting involved.

ARIN also has a consensus call/declaration. Voting (at meetings) is
recorded for the record and for data. Mailing list input is also
considered as part of the weighing of community input. The ARIN
Advisory Committee (AC) makes the call as whether there is sufficient
support for a proposal to go forward. Details of the overall process
can be found at http://www.arin.net/policy/irpep.html

> There are five RIRs, but the decisions they make often have global
> impact, and once one RIR has taken a course of action, the others
> often feel the need to follow.

Correct.

> PI for IPv6 anyway, with potentially very harmful long-term results.

This is one view of what happened. My take is not so simplistic.

> the community at large.

This is FUD, pure and simple. There was overwhelming support for the
PI to end sites proposal. Anyone who was at the ARIN meeting would
have to take away two things: 1) some people were seriously worried
about the long-term impact the policy would have on routing table
size, and 2) there was still an overwhelming sense that PI for end
sites was needed anyway, to support the requirements of larger
enterprises. There were even some people who shared _both_ views.

> The IETF isn't immune to this, but does a lot better than the RIRs
> because it has a technically capable leadership rather than an
> administratively capable leadership. (Maybe that also explains the
> differences in the financial situation between the RIRs and the
> IETF...)

I find your characterization of the ARIN AC as only "adminstratively
capable" to be inaccurate and unhelpful.

Thomas

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Aug 2007 15:25:04 +0200

> This is one view of what happened. My take is not so simplistic.

Not sure how the above is simplistic, but please inform us about your  
take.

> There was overwhelming support for the
> PI to end sites proposal.

Right. Most of that was from people who benefit directly from that,  
and then a lot of others who I thought knew better jumped on the  
bandwagon, I believe thinking it would help IPv6 deployment. It  
didn't, of course. ARIN has given out 76 /48s that aren't "micro  
allocations" so I assume those are PI blocks. But:

+---------+----------+
| afrinic |       37 |
| apnic   |      503 |
| arin    |      429 |
| lacnic  |       83 |
| ripencc |      893 |
+---------+----------+

The fact that there was so much support for this shows that there was  
something broken in the decision making process somewhere.

> capable" to be inaccurate and unhelpful.

I would love to be helpful here but I haven't figured out how thusfar.

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Aug 2007 10:22:38 -0400

> 	*IF* the IETF should reconsider what it has done.
You are still missing the point.

1. This is NOT ARIN's decision to make, nor that of any of the other
RIRs, because the /48 decision is not independent of many other design
decisions in IPv6.
2. If ARIN or any of the other RIRs have concerns about an IETF design
decision, they need to express that to IETF and ask IETF to fix it.

The danger in my going to them personally is that it will weaken or
delay the communication that needs to occur.   By insisting that I do
this before either ARIN or IETF takes any action there is a far greater
chance that the problems in both ARIN and IETF will not get fixed.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 30 Aug 2007 15:32:43 +0100

Thomas Narten wrote:
> [..] There was overwhelming support for the PI to end sites proposal.
> Anyone who was at the ARIN meeting would have to take away two
> things: 1) some people were seriously worried about the long-term
> impact the policy would have on routing table size, and
> 2) there was still an overwhelming sense that PI for end

My view on this is that the RIRs have, partially, done the right thing.
A RIR is for allocating internet resources in their region, as such them
providing /48's and up to their members is the right thing to do. That
they have names like "PI" and "PA" for it is IMHO wrong though, they all
should have the same name "Allocation" and the only difference should be
the size that they are allocated in, which is based on the justification
provided by the request that gets sent to them. This would then allow
anybody who can justify the need for address space to get it.

A /48 per 'site' is good, especially in the case of businesses, for
home-usage though, most very likely a /56 will be more than enough. As
such IMHO having 2 sizes, one business, one homeuser, would not be a bad
compromise, otherwise the really large ISP's, eg the ones having
multiple million customers, would need multiple million /48's and then
the address space consumption suddenly really goes really fast. Having
/56's there would slow that down a little bit. A /56 is still 256 /64's,
and I have a hard time believing that most people even on lists such as
ARIN ppml or the various IETF ones will ever configure that many subnets
 at home.

But now something the RIRs should not be doing though is meddling in
what ends up in BGP. Fortunately mostly they do stay out of there, but
unfortunately the allocation policies are based on them. Routing
(currently done mostly using BGP) is something that the ISPs will figure
out. In IPv4 >/24 is filtered out, for IPv6 at the moment it is >/48.
ISPs are running the show there and they can do what they want, and as
long as their customers can reach the sites they need to they will.
They also make up the bulk of the RIR crowd and thus can also set up
most of the policies there, nice monopoly settings are very possible
that way. Fortunately policies are more or less relaxed and as long as
you can come up with some solid business arguments one can get address
space quite easily, still the take up on IPv6 is not very high yet.

The problem with this, at least assumed, is that a certain point the
IPv4 + IPv6 routing tables will 'explode' into millions of routes and
apparently people don't want to upgrade their routers to handle these
over the coming years, which is somewhat understandable. The big
question here is, how quickly will we reach that huge number, and also
which hardware will fall over first; or otherwise said: should we really
be so worried about this. Looking again at those IPv6 takeup numbers,
should we really be worried about routing table explosion in the next
couple of years? IMHO not really, most likely current equipment will be
able to be used for the next couple of years.

Looking at http://www.sixxs.net/tools/grh/growth/ we have surpassed last
years number of allocations and one can also clearly see that ARIN
(blue) took off quite a bit allocation wise, mostly because of their
"PI" /48s.

Still, the total number of prefixes that have been allocated is only
~1600*, thus if every one of them would be announced only 1600 of them
would exist in the BGP tables, (unless folks deaggregate) could be me
but that is far off from the 200k that we have in BGP, or the 300k that
some have internally. Of course internal BGP for IPv6 can become large,
but that is why one should use a /40 per PoP or similar constructs to
nicely aggregate things up.

In the mean time though, there is great working being done on the
Routing And Addressing Mailing List
(https://www1.ietf.org/mailman/listinfo/ram) and some great ideas have
already been shown there. One should also not forget HIP of course and a
variety of other problem statements and solutions.

Greets,
 Jeroen

* = http://www.sixxs.net/tools/grh/dfp/

---

From: <[email-masked]>
Date: Thu, 30 Aug 2007 15:52:59 +0100

> 1. This is NOT ARIN's decision to make, nor that of any of 
> the other RIRs, because the /48 decision is not independent 
> of many other design decisions in IPv6.

Show me the document where this is explained.

I'm not disagreeing with you, I am just saying "Show me the document"
because if you can't show it to me, then you are wrong. The IETF has not
made any design decision until it is in an RFC.

> 2. If ARIN or any of the other RIRs have concerns about an 
> IETF design decision, they need to express that to IETF and 
> ask IETF to fix it.

ARIN, like the IETF, is mainly a bunch of individuals. I, as an
individual with a history of involvement in ARIN (I was a founding
member of the ARIN Advisory Council), have already come to this mailing
list, which ostensibly is frequented by individuals who have a history
of involvement in the IETF. I have already asked the IETF to fix this.

Clearly you do not believe that a request from an individual is
sufficient. Since the IETF seems to be defined by its documents, I
wonder which RFC I can refer to in order to find out the correct formal
process for ARIN to follow in order to ask the IETF to fix the problem?

I will admit that I could attempt to fix this by writing an ID myself,
but since I was not involved in the IP-NG work in IETF, I really don't
know why the IPv6 architecture is what it is. And since I learned about
IPv6 mainly by reading RFCs, I worry that I may still have
misconceptions hanging around from before various things were
deprecated.

> this before either ARIN or IETF takes any action there is a 
> far greater chance that the problems in both ARIN and IETF 
> will not get fixed. 

The fact is that we need a document explaining the IPv6 architecture as
it stands today. A document that can guide the RIRs but also the many
IPv4 network designers who are being forced to architect or design their
first IPv6 network. A compact document that fairly states the IETF's
intent with regard to IPv6. But most importantly of all, this document
must answer objections and common misunderstanding. Failure to do this
last item, is failure to communicate, which will cause many people to
waste time and waste a lot of money. You can't answer objections and
correct misunderstandings unless you participate in forums *OUTSIDE* the
IETF where the objections and misunderstandings arise.

If this delays communications a bit, that is a good thing if it also
results in better quality of work.

--Michael Dillon

---

From: <[email-masked]>
Date: Thu, 30 Aug 2007 16:00:19 +0100

> A /48 per 'site' is good, especially in the case of 
> businesses, for home-usage though, most very likely a /56 
> will be more than enough. As such IMHO having 2 sizes, one 
> business, one homeuser, would not be a bad compromise, 
> otherwise the really large ISP's, eg the ones having multiple 
> million customers, would need multiple million /48's and then 
> the address space consumption suddenly really goes really 
> fast. Having /56's there would slow that down a little bit. A 
> /56 is still 256 /64's, and I have a hard time believing that 
> most people even on lists such as ARIN ppml or the various 
> IETF ones will ever configure that many subnets  at home.

I would still like to get to the bottom of this issue and understand
what things a /56 assignment size will break. I strongly suspect that
these things will not be of great importance to networks in the home,
but I would still like to know what they are and document the issues
clearly.

Also, I strongly suspect that the IETF did not consider the situation of
in-home networks in great detail when they reached the conclusion of /48
for all sites, because at that time, there were few, if any, companies
planning Internet deployments on the same scale as the phone system. I
suspect that we have grown things a bit faster than was expected.

--Michael Dillon

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Aug 2007 11:25:50 -0400

> Show me the document where this is explained.

for the most part, we don't document the rationale for our design
decisions, and we're even less likely to document the interdependencies
between our design decisions.  that doesn't mean that such
interdependencies don't exist.
> process for ARIN to follow in order to ask the IETF to fix the problem?
has ARIN, acting as an organization, attempted to communicate this to
IETF at all?

I don't know that there is a single correct way to do this, but sending
a note to IESG and/or IAB detailing the concerns and the reasons for
ARIN's current policy, and (if the material is long enough) writing an
internet-draft to support that note, both seem like useful and
appropriate ways of communicating concerns to IETF.
> waste time and waste a lot of money. 
The document sounds like a good idea.
> You can't answer objections and
well, mumble.  we can't be expected to participate in all of those
fora.  there are too many of them and just keeping up with IETF is
difficult enough.

maybe what we need is a better interface for "outsiders".  something
like an FAQ file and a way to submit new questions.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Aug 2007 11:45:03 -0400

> but I would still like to know what they are and document the issues
IMHO "home network connection" is a misnomer.  I'd call it "commodity
network connection".  The size of the network that is assigned to a home
ends up being the size of a network that you can get "off the shelf",
for a fixed price, with minimal support,  and using commodity
off-the-shelf mass-marketed equipment.  Such networks, and such
equipment, are used for a lot more than just residences.

Here's one scenario that concerns me.  Right now multiple layers of NAT
are not unusual.  The first NAT connects to the incoming network
connection, and additional layers of NAT are plugged into that one. 
Maybe they have a wireless base station that includes a NAT and they
plug that base station into their Ethernet router/NAT.   People do this
because it is convenient  to be able to connect a network at any point
to the existing network, and because using a NAT means that they don't
have to do anything special to make it work like configuring subnet
prefixes - the new "router" plugs in to the network and starts working.

In IPv6 we really want to make it possible to not use NAT.  So we need a
way for routers to allocate subnets automatically to routers within
their own networks.  If the initial router gets a /48 it can fairly
safely divide that up into (say) 16 /52s, or maybe 256 /56s, and give
one of those out to any router plugged into its network that asks for a
network.  Then if another router is plugged into to one of those
subnets,  it can give out /56s or /60s, and so on.  The scheme doesn't
support arbitrary levels of nesting, but 3 layers is probably "good
enough" in practice.

But if the initial assignment on a commodity network connection is /56,
that doesn't leave enough room for 3 layers and maybe not even 2 layers.

What I find ironic is that the encroachment on "user bits" seems to be
driven by a desire by ISPs to reserve enough bits for pre-allocation of
address blocks to routers that don't exist yet or don't have a customer
yet, and this impairs the ability of end-users to do the same thing. 
And I suggest that in both cases this is a really useful thing to do,
and what we need is to figure out a way to make it work well for both
ISPs and end users.
> suspect that we have grown things a bit faster than was expected.
Again, if IETF needs to reexamine the /48 or other design decisions, we
should do that. 

Keith

---

From: David Schutt <[email-masked]>
Date: Thu, 30 Aug 2007 14:40:32 -0500

Keith Moore wrote:

<snip>

> equipment, are used for a lot more than just residences.

<snip>

I just wanted to confirm that Keith has made an important point here. At 
least in our area, the local cable company is aggressively marketing 
their commodity connection to businesses. In fact, I was just cold 
called today, and offered the "$40/month business package". I tried to 
explain that there is no way in hades that I would trade our fractional 
T1 with a /25 for a cable connection and a commodity modem/router/nat.

We are a small business, though, and I suspect that many of our peers 
would not understand why I'd pass on a deal that would provide "Ten 
times the bandwidth for one tenth the money".

Homes, schools, businesses, local government, all commodity leaf 
connections.

Is it inevitable that all these entities end up with another round of, 
hmm, "short sighted specification" connections and have to live with 
them for another 10-20 years?

-- 
David Schutt

Speco, Inc		"When all you have is a screwdriver handle,
3946 Willow St		 everything looks like a nail"
Schiller Park, IL 60176
847.678.4240