Subject: Review of draft-narten-ipv6-3177bis-48boundary-05

From: Tony Li <[email-masked]>
Date: Fri, 20 Aug 2010 11:47:08 -0700

Hi all,

This is a solicited review of draft-narten-ipv6-3177bis-48boundary-05.

History: The IAB & IESG made some recommendations for v6 addressing in RFC 3177.  In particular, the recommended the assignment of /48 to a site.

This draft reconsiders that recommendation, and argues that more flexibility would be reasonable.

1) The draft retracts the recommendation that /128's can be allocated to sites.  The text here is clear about sites, but could possibly call out the distinction between a site and a host.  Clearly /128 allocations to a single host are a necessary alternative.  Consider the case of a hot spot service provider.  Allocating a /48 or even a /64 to each laptop in the coffee shop is not necessary or sane practice.

2) The draft calls out a specific motivation that sites should get enough address space so that they do not feel compelled to use NAT.  While this is fine in principle, the pragmatics here are hard to defend.  A site can easily make unjustified claims to arbitrary amounts of address space.  It is unreasonable to expect that every RIR and LIR is going to make detailed investigations for every single address space request, so there will be established policies for address space assignment, possibly with economic disincentives for over-allocation.  However, this will not prevent some end-sites wanting more, especially to avoid additional costs.  Thus, some sites will still feel compelled to use NAT.  We should avoid the hubris that we can dictate business practices.

3) The draft includes a discussion about the rationale of RFC 3177's argument in favor of /48 to simplify renumbering.  It is certainly true that renumbering from one prefix to another is greatly simplified if the prefixes are the same size.  The important point, missed in both 3177 and this draft, is that this only argues that any given site get the same sized prefix.  This does not imply that it needs to be a /48 for all sites.  Nor is there ANY benefit from that.  For example, if a site had a /57 (bad for other reasons), then having another /57 to renumber into satisfies this requirement.  /48 is not necessary, nor is any other fixed size.

4) The draft seems to shy away from making clear replacement recommendations.  While it recommends that policy take certain points into consideration, this seems like mere rhetoric and lacking in any substance.  I strongly recommend that the draft make real recommendations and very clearly call those out.  If nothing else, the draft needs to clearly and explicitly vacate the previous /48 recommendation.  This seems to be done in the Introduction, which seems somewhat odd.

5) The draft misses the opportunity to call for work in v6 renumbering.  The fact of the matter is that sooner or later, sites will need to renumber.  Even given adequate address space, there are other compelling events (e.g., corporate acquisitions) that drive renumbering.  There's much work to do here.  If we make the assumption that renumbering WILL be easy (and make it come to pass), then it's reasonable to argue that renumbering into a larger prefix is easy and thus we can be more conservative in initial site addressing.

Regards,
Tony Li, Ph.D.
Cisco Fellow
Cisco Systems, Inc.

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Aug 2010 13:16:05 -0700

Thanks, Tony.

Let me comment on one point in your review.

> 5) The draft misses the opportunity to call for work in v6 renumbering.  The fact of the matter is that sooner or later, sites will need to renumber.  Even given adequate address space, there are o…

When I sat down to write what is now RFC 4192, I was really scratching my head. Given that an IPv6 (or for that matter, an IPv4) interface can take two or more prefixes, it seemed to me that there was an obvious procedure for renumbering a network:

1) start with a working network that you don't like the address plan of
2) design a new address plan using a different set of numbers
3) configure the network equipment to use the new plan in addition to the old
4) test the new plan, fixing whatever needs to be fixed
---> you now have two working networks running on the same infrastructure <----
---> but you are only using one, the "old" one                            <----
5) tell the hosts and their applications to use the new address plan
6) verify that the hosts and applications in fact all work using the new plan
---> you now have two working networks running on the same infrastructure <----
---> and you are actively using both of them                              <----
7) stop advertising services using the old address plan
---> you now have two working networks running on the same infrastructure <----
---> but you are only using one, the "new" one                            <----
8) do what you like with the old plan

Several of those points obviously imply waiting periods - the fact that you removed a resource record in step 7 doesn't mean you're ready for step 8, for example. 

I then went to the operational community, inside and outside Cisco, and said "OK, I already know I'm insane. What I need to understand is WHY I'm insane."

I got an education, and much of what I learned wound up explicitly called out in the document. The thing that makes renumbering hard has nothing to do with the procedures for renumbering. It has to do with places where people type in numeric IP addresses, whether in router configurations like interface addresses and route maps or in applications that "Just Know" that the address of some system is 192.0.2.1 or 2001:db8::12. Web pages that refer to other servers by address instead of by name, SIP referrals, FTP (which tops it all by having a different passive mode command and behavior for IPv6 than it has for IPv4), and so on.

To be really honest, I have concluded that every time we further idiot-proof the world, the world makes better idiots.

I'm all for improving our ability to renumber, but I'm not sure that's something the IETF can solve technically. Vendors can help, by providing configuration options that associate names with numbers in one common location and then enables the administrator to use the names in configuration files. But even those have issues. Consider this one:

You have a router configured:

!
ipv6 unicast-routing
ipv6 general-prefix EXAMPLE 2001:0DB8:0:0::/48
!
interface foo 1
ipv6 address EXAMPLE 0:0:0:0::/64 eui-64
ipv6 enable
!
interface foo 2
ipv6 address EXAMPLE 0:0:0:1::/64 eui-64
ipv6 enable
!
interface foo 3
ipv6 address EXAMPLE 0:0:0:2::/64 eui-64
ipv6 enable
!

Now, someone decides to renumber the network, and replaces the general-prefix using

	ipv6 general-prefix EXAMPLE 2001:0DB8:1:0::/48

What happens? The network stops working for a period of time, at least through that router; depending on the placement of the router, the outage may prevent access to other routers that happen to be beyond it, and certainly disrupts the operations of hosts on the networks it is attached to. Why? Because the existing routing depended on the old prefix, and in replacing the configuration outright it disrupted the existing routing before the new prefix was stable in the network.

What should they have done?

They should have configured

!
ipv6 general-prefix EXAMPLE2 2001:0DB8:1:0::/48
!
interface foo 1
ipv6 address EXAMPLE2 0:0:0:0::/64 eui-64
!
interface foo 2
ipv6 address EXAMPLE2 0:0:0:1::/64 eui-64
!
interface foo 3
ipv6 address EXAMPLE2 0:0:0:2::/64 eui-64
!

waited and tested, and at some later time when the new prefix and old prefixes provably both worked for everyone concerned, applied

no ipv6 general-prefix EXAMPLE 2001:0DB8:0:0::/48
!
interface foo 1
no  ipv6 address EXAMPLE 0:0:0:0::/64 eui-64
!
interface foo 2
no  ipv6 address EXAMPLE 0:0:0:1::/64 eui-64
!
interface foo 3
no  ipv6 address EXAMPLE 0:0:0:2::/64 eui-64

In this case, the "better idiot" worked at a random router vendor of your and my acquaintance. Said person thought that by providing the general-prefix, s/he had made renumbering simple. No, s/he had at most added a level of indirection to the routing configuration.

s/he could be forgiven for the error, though; it is essentially the same as is recommended in RFC 2894, which has the network administrator distribute commands to, in its words

                       instruct the router to ... remove the prefix
which matched the Match-Prefix and replace it with the Use-Prefixes,
or replace all global-scope prefixes with the Use-Prefixes.

with the effect of disrupting the old prefix at a time that the new prefix is not yet fully deployed or distributed in routing, neighbor discovery, etc. Yes, it also has the option of adding a second prefix, which is what it should have done, but it doesn't have the option of removing a prefix. I guess you're supposed to add new prefixes, and then replace the old prefixes with the already-added new prefixes. Maybe.

Yes, we need work on renumbering. But I think it will require more than a simple technical solution.

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Aug 2010 13:23:32 -0700

On Aug 20, 2010, at 12:49 PM, Eric Gray wrote:

> 	Having multiple chunk sizes seems to me to be a recipe for in-
> efficient use of address space in general.  

speaking for myself, I think a one-size-fits-all model has the same effect. In my home, today, I have two LANs; I could easily imagine expanding that to half a dozen or even a dozen in various scenarios. Giving me a /48 is a waste of address space - it's at least 4096 times as much as I need, and would give my upstream the ability to address 4095 more homes like mine if they were to allocate /60's. To the extent that they are paying their RIR for address space, er, membership, it wastes their money and increases my monthly payment. 

I think there is a great reason to suggest that access and transit networks to offer their downstreams /48, /52, /56, and /60 options at various costs. It makes business sense for them, allows them to reasonably recover their costs without burdening the downstreams, allows for downstreams to number their networks in ways they like and reasonably move up to shorter prefixes when they need to, and (since I didn't mention /64) ensures that the smallest users - residential/SOHO - have options for routing within the home as appropriate.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Aug 2010 08:31:15 +1200

+1 to Fred's comments.

For more details, see RFC 5887.

Regards
   Brian Carpenter

On 2010-08-21 08:16, Fred Baker wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Aug 2010 08:35:31 +1200

> I think there is a great reason to suggest that access and transit networks to offer their downstreams /48, /52, /56, and /60 options at various costs. It makes business sense for them, allows them…

Another +1 to Fred. I was originally a strong advocate of Eric's view,
in fact I take credit/blame for a lot of RFC3177, but I believe that
experience, especially the remarkable success of CIDR in controlling
the growth of PA routes for IPv4, and the acquired wisdom of the RIRs
in administering CIDR, have shown that there is no efficiency benefit
in fixed chunks.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Aug 2010 08:57:20 +1200

On 2010-08-21 08:47, Joel M. Halpern wrote:
> There does seem to be one significant benefit for being able to get the
> same size block from different providers.
> If you have used one size, and change providers, if the prefix length
> gets longer, you have to rework your plan.  And if it gets shorter, but
> you don't rework your plan, you are wasting a LOT of space.

Yes. That's why there is a strong recommendation to people
developing site addressing plans to use only the longest
possible sub-prefix of their PA prefix, in case they later
change to another ISP who gives them less PA space.

> This does not mean that there should be one size for all cases.On the
> other hand, telling operators that they must offer four different sizes
> to all their customers (/48, /52, /56 and /60) makes the operator
> bookkeeping harder, at the very least.

There certainly should not be a MUST. In any case, the RIRs and ISPs would
ignore it. The /48 doctrine crashed and burned among the RIRs and ISPs
some years ago; 3177bis recognizes this reality.

    Brian

> Yours,
> Joel
> Brian E Carpenter wrote:
>>> speaking for myself, I think a one-size-fits-all model has the same
>>> effect. In my home, today, I have two LANs; I could easily imagine
>>> expanding that to half a dozen or even a dozen in various scenarios.
>>> Giving me a /48 is a waste of address space - it's at least 4096
>>> times as much as I need, and would give my upstream the ability to
>>> address 4095 more homes like mine if they were to allocate /60's. To
>>> the extent that they are paying their RIR for address space, er,
>>> membership, it wastes their money and increases my monthly payment.
>>> I think there is a great reason to suggest that access and transit
>>> networks to offer their downstreams /48, /52, /56, and /60 options at
>>> various costs. It makes business sense for them, allows them to
>>> reasonably recover their costs without burdening the downstreams,
>>> allows for downstreams to number their networks in ways they like and
>>> reasonably move up to shorter prefixes when they need to, and (since
>>> I didn't mention /64) ensures that the smallest users -
>>> residential/SOHO - have options for routing within the home as
>>> appropriate.
>>

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Aug 2010 14:43:36 -0700

Thomas et al:

Let me relay and comment on something Tony, Marla, and I discussed (Jason, I would mention you, but you and I didn't actually talk about this :-).

One of the important points of RFC 3177 is in the opening statements:

   The technical principles that apply to address allocation seek to
   balance healthy conservation practices and wisdom with a certain ease
   of access...

   The IETF makes no comment on business issues or relationships.
   However, in general, we observe that technical delegation policy can
   have strong business impacts.  A strong requirement of the address
   delegation plan is that it not be predicated on or unduly bias
   business relationships or models.

This mirrors comments made in CIDR documents and in the CIDR discussion to the effect that "gee, it would be Really Nice if we could aggregate announcements", and which came out in code words to the RIRs and ISPs saying "gee whiz, guys, would you consider being conservative in your allocations and your aggregation policy wink wink nudge nudge", recognizing their already-ongoing efforts in those directions and expressing approval of them.

These statements appear to be absent from draft-narten-ipv6-3177bis-48boundary.

Tony/Marla/Jason have a draft before the house, draft-azinger-cidrv6. It's fundamental point is "gee, it would be Really Nice if we could aggregate announcements", and suggests that provider-allocated address space is a good thing. It responds to RIR behaviors in allocation of PI address space, and asks that the RIRs tighten up the rules. Tony's observation is that the IETF has made no such statement to the RIRs regarding that, and such a statement might have value.

If we're going to replace a document entitled "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", it might be worthwhile actually updating the recommendations made on allocations to sites, and make a clear statement to the effect that "we make no pretense of telling RIRs or their members how to run their businesses, but we would humbly request that they consider the amount of money they spend on new routers and new memory every year, the amount of money spent on heat and heat dissipation, and seriously consider allocating address space in a way that promotes prefix aggregation in BGP routing." I could imagine, and would welcome, a response from the RIRs of the form "we would really appreciate consideration of an architecture that would address both ISP concerns about the size of the route table and edge network concerns about multihoming complexity and independence from their ISP".

Thought for the day...
Fred

---

From: Tony Li <[email-masked]>
Date: Fri, 20 Aug 2010 15:45:59 -0700

Hi Eric,

> 	The second is that they can differentiate themselves by offering
> address allocation sizes that do not align well with other providers, in
> an attempt to lock-in customers who will find that they can anticipate
> administrative head-aches and extra costs if they ever decide they want 
> to go with a different service provider.  This is probably a bad thing.

Alternate service providers can then respond by matching the odd address space allocation, or providing their next quantum up.  This hurts addressing efficiency slightly, but is unlikely to be a real deterrent.

Regards,
Tony

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Aug 2010 16:00:24 -0700

On Aug 20, 2010, at 2:55 PM, Eric Gray wrote:

> 	Following the CIDR model for IPv6 seems to allow for as
> many as (on the order of) 7-10 times as many possibly usable
> address allocation sizes.

Well, yes, saying that "you can pick any length you like" gives the address allocation authorities, at least in theory, 64 orders of magnitude.

There is a line of reasoning, which I subscribe to, that all of those options really aren't needed, and that there are human factors reasons to prefer prefix lengths on nibble (hex digit) boundaries. Not that allocations like 192.0.2.20/30 are impossible to grok - they're not - but if we have the opportunity to simplify things, why not?

One comment that comes to mind is a recent conversation with my son. He works for a company that makes radio-controlled model airplanes, the kind that have a 66 foot wingspan and shoot missiles. The planes are full of computers, and no they don't ask the DNS root to translate names. If you're in one of those computers and need to talk with another one, you need to know its IP address. So he is used to being in computer A and logging into computer B as 192.0.2.17 or whatever.

He and I spoke a few weeks about, and he asked "Dad, when you guys were designing IPv6, did you think at all about how LONG those addresses were?"

ta-dum!

Now ask yourself about being in my daughter's network (women enter her home as the girl-next-door and leave beautiful), telling her that she can use anything she likes in 2001:0db8:2775:1234/62, and having her notice that the address of something or another is 2001:0db8:2775:1235... In IPv4, I said "deal with it, you have to be somewhat technical". In IPv6, I would like to not have to go there. It's not her expertise, and she doesn't ask me to cut/color her hair either.

So, yes, I tend to think that the common rabble should deal with addresses that break on nibble boundaries.

That has nothing to do with RIRs or service providers, mind you; they are often "somewhat technical". Within their networks I expect them to do what makes sense to them, and I regard myself more as their student than their teacher...

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Aug 2010 11:15:54 +1200

+1

Why am I agreeing with Fred so much today?

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Aug 2010 11:17:29 +1200

> Alternate service providers can then respond by matching the odd address space allocation, or providing their next quantum up.  This hurts addressing efficiency slightly, but is unlikely to be a re…

Exactly. The market will provide. Of course, I agree with Fred that
we should stick to nibble boundaries.

     Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 21 Aug 2010 10:59:12 +0930

Hi Fred, Tony,

On Fri, 20 Aug 2010 13:16:05 -0700

> On Aug 20, 2010, at 11:47 AM, Tony Li wrote:
<snip>
> To be really honest, I have concluded that every time we further idiot-proof the world, the world makes better idiots.

(That made me laugh out loud when I first read it :-) )

That seems to me to be a good argument for less options and more
simplicity. The less knobs there are to tweak, the less chance of them
being tweaked incorrectly.

This topic has made me think a bit more about why I've liked e.g.
Novell's IPX, and why I think IPv6 should be at least as easy to use.

Protocols like IPX and Appletalk were easier to use because they were
designed to be user friendly - with the users of the protocols being
both the end users and the operators of the network (if the network
was large enough for them to exist). User friendliness is quite an
attractive feature of a protocol once you've experienced it.

I think the main reason I've liked the idea of everybody having a /48
as a minimum is that it creates more simplicity and therefore user (and
operator) friendliness. It's one less thing that varies, and therefore
one less thing that the better idiots are likely to get wrong. It also
makes my life easier as an operator because it's one less parameter to
track the value of when dealing with the majority of addressing tasks.

Having a "one size fits all" approach to addressing has worked
successfully with ethernet addressing and other layer 3 protocols, so I
think the principle is quite sound. The cost has been more
than functionally necessary addressing bits, however those bits are
generally pretty cheap and have provided a good simplicity and
convenience return.

So while I'm not strongly against the idea of having a small variety of
prefix lengths (which is a whole lot better than the 20+ in IPv4!), I
think it is worth trying to pursue operational simplicity and
convenience, as a priority, by fixing parameters that don't need to
vary. Hopefully that will continue to raise the threshold of the
quality of idiots, and the efforts they have to go to, to be successful
at breaking things :-) I think most low quality idiots won't bother when
things just work :-) 

I'd really like to see IPv6 being far more user friendly than IPv4 and
at least as user friendly as more modern protocols like IPX and
Appletalk. I think the original designs and parameters pursued that
goal, however as the protocol has been exposed to more and more
IPv4-only people, it seems to me that there is now a push to make it
more like IPv4 because those people are comfortable with IPv4 and
haven't experienced the user friendliness of anything else. I think this
is ultimately going to make IPv6 less user friendly than it was designed
to be and can be. That'd be a shame.

Regards,
Mark.

---

From: Randy Bush <[email-masked]>
Date: Sat, 21 Aug 2010 13:08:39 +0900

>    business relationships or models.

observing it is just fine.  mucking with it is something we got the
<bleep> out of the ietf and back into the hands of operators in a decade
ago.  we do not need to re-learn tose lessons.

the ietf has no actual brief for recommendating allocation sizes that
are not based on, likely ephemeral and often fallacious, beliefs about
isps' business practices, operational needs, this week's st00pid
hardwhere, and religios zealotry about freeing the consumer.

i strongly support the draft with the careful constraints it has.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Aug 2010 16:45:23 +1200

On 2010-08-21 13:29, Mark Smith wrote:
....
> was large enough for them to exist). 

Oh, archaeology is called for.

The direct inspiration for the /64 boundary in IPv6 was IPX (or,
to be historically correct, XNS). And a lot of the thinking behind
promoting /48 as the one-size-fits-all prefix length was also
based on IPX/XNS (and a little bit on DECnet).

IPX and Appletalk directly inspired the decision to have built-in
stateless autoconfiguration as part of IPv6; ND and RA were of course
invented anew, but the main goal was zero-conf ease of use.

At that time, IPv4 was a manual configuration nightmare, because
DHCP wasn't yet deployable.

But we have moved on since then, and I believe that 3177bis hits
the mark fairly accurately (given that we now have DHCPv6 where
needed).

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 21 Aug 2010 06:45:54 +0200 (CEST)

On Fri, 20 Aug 2010, Fred Baker wrote:

> various costs.

I can understand the /48 and /56 options (for corporate and residential 
respectively), but I don't really get the /52 and /60. What is the cost 
difference to the ISP that warrants a different end user price for these 
services, and isn't it just an extra cost to switch the user between these 
services (reprovisioning) when their needs change?

I believe in the "give 99% of the people what just works in the long run 
if it doesn't cost me extra" method, and I see it as sompler operationally 
to just offer /56 to residential users instead of /60 AND /56.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sat, 21 Aug 2010 14:01:42 +0900

> the mark fairly accurately (given that we now have DHCPv6 where

not exactly.  we have dhcp5.5, as we all know only too well.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 21 Aug 2010 14:02:43 +0900

> I can understand the /48 and /56 options (for corporate and
> residential respectively), but I don't really get the /52 and
> /60. What is the cost difference to the ISP that warrants a different
> end user price for these services, and isn't it just an extra cost to
> switch the user between these services (reprovisioning) when their
> needs change?

and why is the ietf discussing ephemeral operator pricing models?

randy

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Aug 2010 00:26:00 +0200

> In this case, the "better idiot" worked at a random router vendor of your and my acquaintance. Said person thought that by providing the general-prefix, s/he had made renumbering simple. No, s/he h…

as said person is one of my better acquaintances, I can with certainty say that said person thought no such thing.
the mechanism above handles indirection via a single "name" to multiple prefixes with differing lifetimes, but only with a dynamically acquired prefix, not with manual configuration. file a bug.

but that fact doesn't matter much, as the IETF hasn't figured out how a network with multiple prefixes should work. i.e multi-prefix multi-homing.

cheers,
Ole