Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
+1 Le 20 août 2010 à 22:35, Brian E Carpenter a écrit : On 2010-08-21 08:23, Fred Baker wrote: 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. 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
Thanks, Tony. Let me comment on one point in your review. On Aug 20, 2010, at 11:47 AM, Tony Li wrote: 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. 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
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
On Fri, Aug 20, 2010 at 11:47:08AM -0700, Tony Li wrote: 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. +1; Also, the draft isn't too clear about its target audience which could be either LIRs or the RIRs' respective communities/policy making bodies. That said, it isn't clear to me why the draft aims at BCP status. Also, it makes enough references to RFC 3177 to suggest that one has to read RFC3177 for the full experience. That again would elevate RFC3177 to a normative reference. Or in other words: the draft isn't a standalone replacement document but instead an addendum that revokes the recommendation of RFC3177 withaout a replacement (cf. quote above). Maybe RFC3177 should just be re-classified as Historic with this draft being the explanatory statement. -Peter ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
On Fri, 20 Aug 2010, Fred Baker wrote: 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. 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 Abrahamssonemail: swm...@swm.pp.se ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
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). not exactly. we have dhcp5.5, as we all know only too well. randy ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
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. 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
Tony, I believe you are correct in asserting that we cannot prevent NAT and/or renumbering, but I have some doubts about your assertion that there is no advantage to allocating address space in uniformly sized chunks. Having multiple chunk sizes seems to me to be a recipe for in- efficient use of address space in general. Either the address spaces would be allocated in some analog of the class-full IPv4 model, leading to the inefficiencies (and other problems) we've encountered before, or would be allocated on a first available conformant sized chunk basis - thus most likely fragmenting the available address allocation space over time. These seem to me to be disadvantages associated with not having a common allocation size - implying an advantage to having a common allocation size. Am I missing something here? Or are you arguing that it should be some common size - just not /48? -- Eric -Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Tony Li Sent: Friday, August 20, 2010 2:47 PM To: IPv6 Operations Cc: int-area@ietf.org Subject: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05 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. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
Thanks, Tony. Let me comment on one point in your review. On Aug 20, 2010, at 11:47 AM, Tony Li wrote: 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. 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
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
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. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
+1 to Fred's comments. For more details, see RFC 5887. Regards Brian Carpenter On 2010-08-21 08:16, Fred Baker wrote: Thanks, Tony. Let me comment on one point in your review. On Aug 20, 2010, at 11:47 AM, Tony Li wrote: 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. 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
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
On 2010-08-21 08:23, Fred Baker wrote: 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. 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
Fred, I see what you mean, but I had the impression that I would not (as a home-owner, at least) be getting my allocation from a top level address space. But I think I see the point of your argument now. Thanks for the clarification. -- Eric -Original Message- From: Fred Baker [mailto:f...@cisco.com] Sent: Friday, August 20, 2010 4:24 PM To: Eric Gray Cc: Tony Li; IPv6 Operations; int-area@ietf.org Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05 Importance: High 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. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
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. 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. Yours, Joel Brian E Carpenter wrote: On 2010-08-21 08:23, Fred Baker wrote: 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. 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
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: On 2010-08-21 08:23, Fred Baker wrote: 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. 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
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 On Aug 20, 2010, at 11:47 AM, Tony Li wrote: 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
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
Brian, This puts us on the horns of an interesting dilemma. Service providers can (and probably will) allocate different sized address spaces. There are two differentiation points (at least) that may be associated with this - one mostly good and one mostly bad. The first is that the efficiency with which a service provider uses the address space they are allocated, combined with the way that they do this, can reduce their operating costs, while allowing them to attract more (and different) customers. This is probably a good thing. 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. Over the long run, the good, bad and just plain ugly will be sorted out - but it might be a good idea to consider starting with at least some recommendations... -- Eric -Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, August 20, 2010 4:57 PM To: Joel M. Halpern Cc: IPv6 Operations; int-area@ietf.org Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05 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: On 2010-08-21 08:23, Fred Baker wrote: 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. 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
On 8/20/10 4:00 PM, Fred Baker wrote: 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. As I observed not so long ago at a v6ops wg meeting. having your your foo object (in the case described a point to point link) aligned on octet or nibble boundaries makes them way easier to read. have a few thousands 126 or 127 prefixes in a row and it kind of looks like fruit salad. Just because the robots don't have trouble with it doesn't mean the humans shouldn't be accommodated. 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... ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
