Subject: 3177-bis

From: "Tony Hain" <[email-masked]>
Date: Fri, 14 Mar 2008 17:37:49 -0700

The fundamental goal of this draft is just misguided. It is essentially
trying to get the IETF to revisit history & restate the IAB's
recommendation, in order to align it with the persistently short-sighted
policies of the RIR's. Due to their core objectives, the RIR's are incapable
of supporting innovation and looking to the future because they are focused
on the past, as their measures of 'fairness' are based on historical
measures of efficient deployment of technologies and networking models from
the last century. The call for 'reasonable' is a prime example of how
quickly this will fail, because perceptions of 'reason' that are based on
the past will never accommodate future innovation.

There is no math justifying the assertion that a /56 actually solves the
collective set of goals. In particular, the scare tactic reference
[ROUTE-SCALING] has no substantiating documentation, and even cursory
thought about the problem would expose the point that moving bits from local
to global routing will only make any scaling concerns worse. The arguments
at the mic today about fragmentation due to having to get additional space
are an artifact of RIR policy, and no matter what size the IAB/IETF
recommends, the RIR policies will insist on small periodic blocks for
'efficiency' (read that as power to say no), which will result in
fragmentation over time. The other argument at the mic today about needing
something longer than a /48 to avoid RIR policy to register assignments in
whois, completely misses the point that it is the RIR policy that has
failed, not the recommended size. For example, a policy that said 'any
deaggregate which results in an explicit DFZ table entry is required to have
a whois registration', would make much more sense than one that assumes all
units of the same size have the same policy. There is no reason that end
site assignments that are aggregated into the DFZ would need their own whois
entry, but rather than fixing RIR policy, there is an expectation that the
IETF/IAB should change to accommodate their unwillingness to act.

The half-hearted discussion about bridging possibly not being desired,
completely glosses over the point that time after time it has been shown
that bridging between media types is prone to failure, and that there will
be new media types that emerge during the lifetime of IPv6. Given the uproar
over a past technology that only allowed a single cell to consume 10
microseconds of link time, and that for the 100Gbps link Comcast used this
week a full-sized Ethernet frame only consumes 120 nanoseconds of link time,
we are already past due for a new framing technology. Whatever it is, there
will be routed rather than bridged interconnection of those. (never mind
that the IETF is supposed to be focused on L3 approaches, not promoting
bridging of a 30 year old L2 one)

The discussion about paying fees to get additional space is probably
inappropriate, because it presumes that the IETF knows this is a bad
business practice. The real goal here is to note that justifications on the
past are irrelevant and can't be assessed appropriately when talking about
future deployment needs. There are 281,474,976,710,656 /48's (minus special
use prefixes), so claims that we will run out are absurd. The fact that the
RIRs started out applying a host measure to what is a subnet assignment
reality does not mean that the IAB was wrong. What it means is that people
need to use real math justifications to back up their claims, not just vague
notions of a problem that will never exist. 

Tony

---

From: Brian Dickson <[email-masked]>
Date: Sat, 15 Mar 2008 02:44:02 -0400

Tony Hain wrote:
> The fundamental goal of this draft is just misguided.
>   

I read the goal (fundamental or otherwise) of the draft is to relax the 
requirement on end-site assignment size,
from fixed /48 to "whatever works best for meeting customer needs, 
within whatever existing policy framework is used."

If  this is not how you read the fundamental goal, then please, "send text".
What do you believe the fundamental goal of the draft is?

> to global routing will only make any scaling concerns worse.

I'm not sure I understand what you mean by, "moving bits from local to 
global".
Do you mean from inside end-site space, to inside PA aggregated space?
The latter is not global. Only the PA instances are presumed global.
(It's kind of the definition of PA, as such.)

> The arguments
> fragmentation over time.

The RIR implementations of current policy, reserve substantial blocks 
for each PA assignment,
specifically so subsequent assignments can be aggregated together.

I don't see how that can be characterized as fragmentation.

LIRs deaggregating things that *can* be aggregated is not the same as 
fragmentation.
Fragmentation is assigning things that are not adjacent, and for which 
aggregation is not
ever possible.

>
> There are 281,474,976,710,656 /48's (minus special
> use prefixes), so claims that we will run out are absurd. 

I don't think anyone has ever claimed we'll run out of /48's.

I believe the real concern is the percentages of PA blocks that will be 
exhausted and require new PA allocations,
when /48's and only /48's are assigned - as compared to mixes of /48's 
and other lengths including /56's.

By my math, where Unicast space is 2000::/3, /48's within a /3 number at 
2^45, or 35,184,372,088,832.
If the PA blocks are /32's, that means 2^29 /32's, or 536,870,912.

The real concern is how many PA blocks are in the DFZ, on any given 
year. If we presume each new generation
supports a substantial increase in TCAM capacity, say 2^3 increase, and 
a generation is 3-5 years, then we can
break down the upper limit on prefixes (i.e. PA blocks) by year, 
starting with present limits (ball-park).

So, roughly speaking, let's presume every 5 years, we can get a 10-fold 
increase in TCAM space.
And TCAM space today (give or take a factor of 2), is about 0.5M.
So, theoretically, FIBs could accommodate the full range of PA blocks in 
15 years or so. (Optimistic view).

At the low end, let's presume a 2-fold increase in TCAM every 3 years. 
That results in 30 years (pessimistic view).

Flip it around, and let's look at capacity in 10 years, when arguably 
most sites that have IPv4 will also have IPv6.
Optimistic view, 50M PA blocks, pessimistic view, 4M-5M PA blocks.
At /48 per site, that's about 3.2 x 10^12 sites optimistic, or 3.2 x 
10^11 sites pessimistic.
Half that to handle dual-homing, so pessimistic shows 160G sites, 
optimistic 1600G sites.

But, that is *only* if each PA block is 100% utilized. What does the HD 
ratio give for number of /48's per /32?
My calculations show it as being 2^(24*.86)/2^8, based on HD-56. This 
simplifies to 2^(12.64), or about 6400.
And *that* is about 10% of the previous values, i.e. pessimistic of 16G 
sites, optimistic of 160G sites.

The pessimistic view shows an estimated capacity of about 2 sites per 
person (based on roughly 8B people in 2018).
And this is within the "factor of 2" I initially said was a give or 
take. This is reason to want to reconsider the implications
of restricting the policy for end-sites to only /48.

The issue isn't waste. The issue is density. To scale adequately in the 
10-30 year time frame, we simply need to ensure
that the density of end-sites per PA is at least an order of magnitude 
larger. Having some, but not all, of the assignments
be something smaller, without insisting on either uniformly using a 
specific number, or choosing only one other size of
prefix for assignment, is sufficient to meet that need.

And *that* is exactly what 3177bis is proposing.

> What it means is that people
Can you be specific about what problem you think that won't exist?

I'm always happy to use real math, and in particular for comparing 
assumptions against conclusions.

I'm even happy to use real math to quantify problems, for purposes of 
refining problem statements,
or for determining scaling factors or choices of scale (linear, 
exponential, logarithmic, or other) when
comparing parameters of any problem space.

Brian Dickson

---

From: Thomas Narten <[email-masked]>
Date: Mon, 17 Mar 2008 17:00:03 -0400

Tony,

I'd really welcome your feedback on how to make the document
better. But to be blunt, I am having difficulty extracting the
substantive content to apply to the document.

> The fundamental goal of this draft is just misguided.

As Brian says, please be clear. The goal of this draft is to make
clear that /48 is not a technical/architecural requirement and that the
concerns/motivations that led to the original recommendation of /48
can be met with end site assignments other than "/48 for everyone". If
you disagree with this, please elaborate.

> It is essentially trying to get the IETF to revisit history &
> restate the IAB's recommendation, in order to align it with the
> persistently short-sighted policies of the RIR's.

Revisit history? Come on. By that logic, we can't revise any document
that has been made into an RFC, since that would revisit history.

3177 was written some 8 years ago. Some of what it says needs
updating. Also, the consensus for the 3177 recommendations was what I
would call "rough", even back then. Case in point, I supported it. But
I now view /48 for everyone to be unnecssary and inappropriate.

> Due to their core objectives, the RIR's are incapable of supporting
> innovation and looking to the future because they are focused on the
> past, as their measures of 'fairness' are based on historical
> measures of efficient deployment of technologies and networking
> models from the last century.  The call for 'reasonable' is a prime
> example of how quickly this will fail, because perceptions of
> 'reason' that are based on the past will never accommodate future
> innovation.

This seems like nonsense to me. To say that the RIR's idea of fairness
is based on "historical measures" seems to ignore the vastly different
RIR policies currently in place for IPv6 vs. IPv4. There is literally
no comparison between the two, in terms of how much address space one
gets under IPv6 per current RIR policies.

> to global routing will only make any scaling concerns worse.

The reference to [ROUTE-SCALING] is in the intro and is associated
with the sentence:

   There are a number of considerations that factor into address
   assignment policies. For example, to provide for the long-term health
   and scalability of the public routing infrastructure, it is important
   that addresses aggregate well [ROUTE-SCALING].

Are you saying that the sentence is false? Surely you are not going to
argue that aggregation isn't important. But more to the point, this
sentence is general background (and a true statement) and isn't
intended to (or actually used to) justify any other part of the
document. So I really don't get why you bring this up.

Also, moving bits from the left to the right does NOT automatically
make aggregation worse, as I indicated in another posting recently.
There are a number of other factors that come into play that are also
important. Aggregation is about the number of distinct prefixes that
the routing system must carry. The size of an individual prefix is
irrelevant. It's just the total number of prefixes that matter.
   
> The arguments at the mic today about fragmentation due to having to
> get additional space are an artifact of RIR policy, and no matter
> what size the IAB/IETF recommends, the RIR policies will insist on
> small periodic blocks for 'efficiency' (read that as power to say
> no), which will result in fragmentation over time.

I agree that RIR policy has a big impact on aggragation over time. But
that is not something this document can address, so I don't think this
has any impact on this document. (At least, not that I can tell.)

In any case, I'm optimistic that RIR policies can be made better to
address the aggregation problem, if that turns out to be a problem in
practice. 

> The other argument at the mic today about needing something longer
> than a /48 to avoid RIR policy to register assignments in whois,
> completely misses the point that it is the RIR policy that has
> failed, not the recommended size. For example, a policy that said
> 'any deaggregate which results in an explicit DFZ table entry is
> required to have a whois registration', would make much more sense
> than one that assumes all units of the same size have the same
> policy. There is no reason that end site assignments that are
> aggregated into the DFZ would need their own whois entry, but rather
> than fixing RIR policy, there is an expectation that the IETF/IAB
> should change to accommodate their unwillingness to act.

I agree that this argument is orthogonal to the end site assignment
size and out of scope for this document.

> bridging of a 30 year old L2 one)

The key point for this document is that we shouldn't force bridging on
anyone. The document says that. I.e., it says:

     Although a /64 can (in theory) address an almost unlimited number
        of devices, sites should be given sufficient address space to be
        able to lay out subnets as appropriate, and not be forced to use
        address conservation techniques such as using bridging. Whether
        or not bridging is an appropriate choice is an end site
        matter.
	
I don't think we need to spend a lot of time arguing about what will
or will not happen with frame formats over the next ten years.

The current text was based on a list suggestion. I am willing to make
it stronger. Going back to
http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00357.html, I'm
willing to add something like:

    In some cases, bridging is not an available alternative to routing
    or subnetting, as it requires a significant level of compatibility
    between the link layer technologies being bridged. For example, it
    is not possible to bridge between Ethernet and Bluetooth.)
	
(And FWIW, I think we are going to be stuck with Ethernet frame format
essentially forever, because the incremental improvement of other
formats simply aren't enough to get past the ease of interoperating
with a very well-established frame format.)

> business practice.

I am willing to take this out, but only reluctantly. I put it in to
counter the myth that ISPs charge for extra addresses because they
have to (i.e, because they are just passing along the cost of getting
addresses from RIRs.)  It is a myth that is widely
repeated. Unfortunately, the argument comes up when people voice
opposition to changing the end site assignment. Hence, I think it is
important to include it.

> The real goal here is to note that justifications on the past are
> irrelevant and can't be assessed appropriately when talking about
> future deployment needs. There are 281,474,976,710,656 /48's (minus
> special use prefixes), so claims that we will run out are
> absurd. The fact that the RIRs started out applying a host measure
> to what is a subnet assignment reality does not mean that the IAB
> was wrong. What it means is that people need to use real math
> justifications to back up their claims, not just vague notions of a
> problem that will never exist.

The RIRs are well past measuring "host utilization" for IPv6, and have
been for 6+ years. So I don't get why you bring this up.

Thomas

---

From: Shane Kerr <[email-masked]>
Date: Tue, 18 Mar 2008 13:20:45 +0100

Thomas,

> you disagree with this, please elaborate.

Thanks for writing this.

Tony's e-mail made me uncomfortable, but I wasn't really sure what to
make of it. Now I understand - his arguments may or may not make
sense, but the IETF is not the appropriate forum for policy
discussions. If Tony's arguments are compelling, then they should be
compelling to the RIR communities as well.

As a side note, making any blanket statements about what the RIRs want
makes as much sense as blanket statements about what the IETF wants,
and for the same reasons.

--
Shane

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 18 Mar 2008 07:41:31 -0700

> I now view /48 for everyone to be unnecssary and inappropriate.

As I recall your primary issue back then was renumbering, and that has not
gotten any easier. Despite chatter about not making people take a longer
prefix than one they already have, there is no policy anywhere that
explicitly enforces that. Primarily that is because the RIRs don't enforce
ISP business practice, they only withhold resources if their perception of
'reasonableness' is not met.

It appears you missed the point, I was not arguing that we can't revise
documents, I was pointing out that we are being asked to revise a document
because the RIRs are not willing to do what they need to. 3177 was never a
mandate, as it has 'Recommendation' in the title, and 'should' for the
expected action. Most of the clarification aspect of this document is fine,
but there is no need to explicitly say /56, and if it is going to be there
some math justifying the new value needs to go along with it. 

> gets under IPv6 per current RIR policies.

That paragraph is an indication of how easy the trap is to fall into. Number
of addresses is not the issue, it is the measure of 'reasonable' and how
much effort is required to justify more. Group-think is incapable of
imagination, so there is no way to ever move beyond past practice.

> irrelevant. It's just the total number of prefixes that matter.

I agree it is the total number of prefixes that matter, and moving the bits
from the site to the DFZ side of the default allocation unit will amplify
the number of possible prefixes that the global routing system has to carry.
Since we know the RIR policy will continue to be as stingy as possible,
there will be fragmentation over time, so more bits just means a bigger
scaling problem. 

> address the aggregation problem, if that turns out to be a problem in

Their actions show otherwise, and they lose the power to say no if their
customer base never has to come back and beg for more. 

> with a very well-established frame format.)

That text is better at making the point. While I agree that Ethernet will be
around for awhile, it is not the last framing technology, and eventually
something will come along when the pain of tiny 1500B frames exceeds the
cost of switching. 

> opposition to changing the end site assignment. Hence, I think it is

I will try to send you some text, but I need to get on the road right now.

> been for 6+ years. So I don't get why you bring this up.

HD and practice came up at the mic. If this document intends to state a
value other than /48, it needs to offer a mathematical basis for the change.
That basis also needs to indicate the impact on the DFZ of adding 256x the
number of prefixes.

Tony

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Mar 2008 09:29:39 -0700

</chair>

On Mar 18, 2008, at 7:41 AM, Tony Hain wrote:

> because the RIRs are not willing to do what they need to.

personally, I don't think that's the case. You saw my earlier message  
in another thread that said I thought that there were business cases  
for the use of /64, /60, /56, /48, and /44. I don't see a strong  
argument that one size in fact fits all, or that there should be.

The matter of reducing ones prefix length is, imho, either a red  
herring or poor statement of a normal silver one. If I used to have  
a /13 and deployed two subnets, and now am renumbered to a /63, what  
in terms of my present requirements have I lost? I needed two  
subnets, I used two subnets, and I have two subnets. I do believe  
that we always want to leave room for growth (hence I would argue for  
a /60 in the case, breaking allocation boundaries on nibble  
boundaries for readability). But changing for a /13 to a /60 will not  
have hurt me, nor will it have crimped my style. I would argue that  
the issue is that a customer should be able to get an allocation that  
gives them enough subnets for their purpose.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Mar 2008 08:40:18 +1100

> there will be fragmentation over time, so more bits just means a bigger

The number of possible prefixes that the global routing system has to carry could perhaps be more appropriately be phrased as 2 **32, as this discussion is about end site prefix sizes, not the size of minimum allocations to providers.

Address allocation policies in the RIRs have attempted to ensure maximal aggregation capability by setting the minimum provider allocation size as a /32. Using an HD ratio of 0.94 and a /56 end site size that comes to 6,183,533 end site allocations from a /32, or much the same as a /9 allocation in IPv4 terms.

I'm not exactly sure how such an approach is "stingy", nor can I understand how such an approach of making minimum allocations span such networks appears to intrinsically exacerbate routing fragmentation

AS an aside, if the issue that matters is the potential impact on the routing system, then the experience to date is that the size of the routing system is related to the number of entities who express distinct routing policies and the density of interconnection between these entities. 

Geoff

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Mar 2008 21:17:06 +1030

Hi Fred,

On Tue, 18 Mar 2008 09:29:39 -0700

> argument that one size in fact fits all, or that there should be.

As an operator, as somebody who'll be making recommendations and
probably decisions about what size prefixes my employer gives to our
primarily residential customers plus some SOHO customers, and as
somebody who's been "spoilt" by IPX in the past, I *really* like the
simplicity of a single, common prefix length for nearly all customer
end-sites.

An example of why "much" bigger than necessary can be useful is the
roads we drive on (courtesy of Linus Torvalds, when describing why
64 bits on a PC are better than 32 even though most people don't need
4GB+ of RAM). We build roads (and the lights and bridges over them)
that aren't actually sized for the common case of cars. We size them
for the occasional, yet common enough but much larger vehicle i.e.
trucks / semi-trailers etc. As an example, if you think about
the amount of extra steel that is and has been used to make lights over
the roads higher to suit this occasional rather than regular traffic,
that's a very large additional expense that is mostly distributed
across all road users, even though most of these road users won't ever
directly benefit, because they'll never own or even drive one of these
large trucks. 

While I don't own a large truck, and can question why I'm paying for
these additional overheads without direct benefits, every now and then
I need to move house, buy groceries or buy furniture. That's where I
do indirectly benefit from wearing this expense, because all of these
goods are transported in these large trucks. In the case of groceries,
I indirectly benefit every week. The indirect and hidden benefits when
I'm not using the roads are of far more value to me than the direct
ones when I myself use the road.

I see the single /48 allocation size in that light. Yes, too big for
most people, most of the time. However, /48 for nearly every end-site
might be providing more indirect benefits to all end-users/end-sites as
a whole rather than direct benefits to the individual. I know that
managing two end-site prefix lengths /48s and /56s will probably double
my employer's end-site addressing management costs. Two end-site prefix
lengths also creates twice as many opportunities for mistakes as a
single prefix length. A single prefix length means reduced end-site
addressing costs, which will likely be a fairly significant indirect
benefit that can (or may, depending on the business people :-) ) be passed
on to all end-sites.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2008 11:35:35 +1300

On 2008-03-18 10:00, Thomas Narten wrote:
...
> you disagree with this, please elaborate.

Another Brian chimes in:

I think that when we wrote 3177, we had a substantial hope that the
number of bits available for location in an IPv6 address, i.e. 64,
was enough that we could revert in some sense to classful addressing
(i.e., everybody gets a stretch Class A, in effect). There were
undoubtedly some convenient technical implications of this, which
were listed in 3177. Since then, I think the RIRs have come up
with ample technical and armchair-economics arguments why this
unreasonably constrains allocation policy (and hence aggregation
models and ultimately BGP table size).

It's a bit of a surprise that the arguments that destroyed classful
IPv4 addressing still apply in a /64 space, but since that seems to
be the case, I support the draft.

    Brian C

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Mar 2008 13:52:34 +0100

1. The idea is that ISPs MAY deploy prefixes that exceed /48; NOT that 
they MUST do it (your employer will remain free to avoid doing it).

For this, the advice of IAB/IESG to RIRs expressed in RFC 3177 MUST be
updated in some way. (revised, modified, deprecated... whatever.)

2. There was, back in 2001, what has been felt as a majority of reasons
for the "one size fits all" recommendation.
But, now in 2008, none of these reasons has become decisive, and reasons
to recommend "flexible prefix lengths" have become more numerous and
more decisive.

One of the new reasons is that deployment of longer than /48  prefixes
has actually taken place, indeed pleasing both customers and their ISP.

A /48 is, that is a fact, better for a customer site than longer a 
prefix, but having IPv6, be it with a longer prefix, is much better than 
having no IPv6.

3. Personnaly, I now use IPv6 on a regular basis, in particular to reach
Google and the IETF site, which I use frequently. Thanks for this to the 
open attitude of my ISP on prefix lengths (and to the user friendly dual 
stack of Apple in Mac OS X).

Regards.

Rémi

>  I *really* like the

> I see the single /48 allocation size in that light. 

> my employer's end-site addressing management costs.

---

From: Leo Vegoda <[email-masked]>
Date: Thu, 20 Mar 2008 12:20:22 -0700

On 18/03/2008 15:41, "Tony Hain" <[email-masked]> wrote:

[...]

> imagination, so there is no way to ever move beyond past practice.

This sounds like an argument for Plato's philosopher kings rather than the
sort of decision making process the IETF and RIRs use.

[...]

> there will be fragmentation over time, so more bits just means a bigger

I have seen a number of RIRs make very large allocations. I am not aware of
anyone complaining that their request for a big chunk of IPv6 has been
denied by a stingy RIR. If you are aware of a problem with the RIRs' current
IPv6 policies then you should draft a policy proposal for a different
policy.

I've seen them liberalise their policies. You just need a convincing
argument.

Leo

---

From: Thomas Narten <[email-masked]>
Date: Mon, 24 Mar 2008 08:36:51 -0400

Fred Baker <[email-masked]> writes:

> subnets, I used two subnets, and I have two subnets.

I agree. There are two parts of renumbering that are
painful. Renumbering at all is painful, meaning that there is pain if
*any* of the bits have to change. But that is a cost that is paid no
matter how many or how few bits actually change.

A second order pain is if you have to decrease the number of available
subnet bits when renumbering. If you previously had 5 bits of subnet
space, and have to compress that to (say) 3 or 4, there could be
additional pain if you have to change your subnet numbering plan. This
may still be relatively painless. For example, if you actually only
have 2 subnets and you are renumbering from a /48 to a /60, that might
be a slightly painful, but not terribly difficult either. On the other
hand, renumbering from a /48 to a /56 when you have 200 (or 300!)
subnets would be a very different story.

That is  why the document says:

     - assigning a longer prefix to an end site, compared with the
        existing prefixes the end site already has assigned to it, is
        likely to increase operational costs and complexity for the end
        site, with insufficient benefit to anyone.

But now that I have written the above, it seems to me that I could add
a bit more text to give some examples where renumbering to a smaller
subnet size really isn't a big deal vs. where it is.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Mon, 24 Mar 2008 08:38:06 -0400

> benefit that can (or may, depending on the business people :-) ) be passed

I think having 2 different end site prefix lengths (for a given end
site) is (generally) needlessly complicated and should be
discouraged. That is why the bar for getting more address space needs
to be reasonably low. Indeed, 3177bis does say:

   Looking back at some of the original motivations behind the /48
   recommendation [RFC3177], there were three main concerns. The first
   motivation was to ensure that end sites could easily obtain
   sufficient address space without having to "jump through hoops" to do
   so. For example, if someone felt they needed more space, just the act
   of asking would at some level be sufficient justification.

And:

But, that needs to be balanced against someone asking for a /48 when
they clearly only have a handful of subnets today (if even more than
one) and there is no credible scenario for them needing even a hundred
for the next ten years.

The other part that needs to be remembered is that getting an end site
assignment today does NOT lock one into that size forever. RIR
policies need to be (and currently are) flexible enough that if one
really can justify a need for more space, additional space can easily
be obtained.

We should not be looking at the end site assignment that one gets
today as what an end site will be stuck with forever.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2008 09:01:58 +1300

Hi Thomas,

On 2008-03-25 01:36, Thomas Narten wrote:
...
> subnets would be a very different story.

Indeed, and I wouldn't call it "second order" pain. A large site's
internal subnet numbering plan has enormous inertia - it's built
into config files, documentation, and brains. I think any large site
would exhibit enormous resistance to having to compress its address
space rather than simply change the prefix bits.

> subnet size really isn't a big deal vs. where it is.

Well, you can look at it the other way - possible advice to any site
designing a subnet numbering plan is to avoid very sparse numbering,
and seek a reasonably compact numbering plan, such that only the low
order bits of the subnet number vary. That would ease the pain of
a hypothetical increase in prefix length. But on the other hand,
this shouldn't become an artificial constraint on the subnet plan
either. For example I don't see why a large site with hundreds of
subnets would even bother considering a hypothetical future with
less space than a /48. This is after all an engineering tradeoff.

On 2008-03-25 01:38, Thomas Narten wrote:
...
> discouraged. 

I would use stronger language. It would be horrible, if the longer
prefix forced the site to have two different subnet numbering plans
for the two prefixes. That would be an operational and admin
nightmare.

> That is why the bar for getting more address space needs
> to be reasonably low.

And why there should be a preference for all prefixes
of a multihomed site being the same length.

    Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 25 Mar 2008 17:43:52 -0500

Thus spake "Leo Vegoda" <[email-masked]>
>> Since we know the RIR policy will continue to be as stingy as
>> possible, there will be fragmentation over time, so more bits just
>> means a bigger scaling problem.
>
> I have seen a number of RIRs make very large allocations.

Cases in point:

inet6num:        2003::/19
netname:         DE-TELEKOM-20050113
descr:           Deutsche Telekom AG

inet6num:        2a01:c000::/19
netname:         FR-TELECOM-20051230
descr:           France Telecom

I don't get the claims that RIRs will be "as stingy as possible", given 
they're already handing out IPv6 /19s to LIRs that can show a need.  That's 
536,870,912 customers without having to resort to per-site assignments 
longer than /48; given those two ISPs have a maximum of 82M and 64M 
customers, respectively, how are RIRs being "stingy"?

All this whining about needing longer prefixes for customer assignments just 
means the LIR isn't asking for a big enough allocation in the first place. 
There is plenty of space to go around on the left side, and all evidence to 
date is the RIRs will give it out if they're asked for it; we don't need to 
steal bits from customers on the right side.

(For instance, one cable operator in the US is said to need ~16M 
assignments, one for each home they pass, and that means they'll need to use 
/56s to fit into their /32.  However, they could just as easily get a /24 
and hand out /48s to each customer...)

> I am not aware of anyone complaining that their request for a big chunk
> of IPv6 has been denied by a stingy RIR. If you are aware of a problem
> with the RIRs' current IPv6 policies then you should draft a policy
> proposal for a different policy.

If someone brings me an example of a reasonable request for v6 space being 
denied in the ARIN region, I'll be first in line to draft a proposal to fix 
the problem; I'm sure other folks will step up in the others.  Frankly, 
though, the bar is already set so low that it requires little more than a 
pulse to get a v6 allocation (or assignment, in regions with PI) today...

> I've seen them liberalise their policies. You just need a convincing

Indeed.  While I've only watched ARIN's policy process, the trend has been 
for gradually more liberal policies over time -- even for IPv4 in the face 
of imminent exhaustion, when all logic tells us we should be making them 
stricter.  The IPv6 policies have been liberalised significantly, and not 
just in the adoption of PI assignments (which was certainly the most 
controversial).

All of that said, though, I fail to see the need for the IETF to revise RFC 
3177.  The RIRs started there and diverged, just like they started with RFC 
2050 and diverged.  This is nothing new; the RIRs view the IETF's input as 
advisory only, and have for a long time.  The reality is that the IETF has 
no enforcement power over the RIRs once the address space has been 
delegated, and if one wants to change how the RIRs operate, one should show 
up at their meetings or on their mailing lists and use _their_ processes, 
not spend years publishing another RFC that will eventually be ignored just 
like 3177 and 2050 are now.  Unless there's an overriding technical reason 
that /48s are too short -- and none has been identified so far, only the 
contrary -- this is a purely _policy_ matter, which is the RIRs' domain, not 
a _technical_ matter, which is the IETF's domain.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking