Re: Revising Centrally Assigned ULA draft
[cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...] JORDI PALET MARTINEZ wrote:
Operators have said that they will not be able to use ULA, but they could use ULA-C, for example for thinks like microallocations for internal infrastructure's.
I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way. Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA block. Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here.
I think the policy proposal that I sent to several regions includes text and links to other documents that can clarify this perspective.
For example in RIPE NCC: http://www.ripe.net/ripe/policies/proposals/2007-05.html
That is your proposal indeed. No "Operator" has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked out. Anybody needing a "globally unique" block can get either PA or PI space. ULA-C as such is useless. Greets, Jeroen
On Thu, 14 Jun 2007, Jeroen Massar wrote: <snip>
JORDI PALET MARTINEZ wrote:
Operators have said that they will not be able to use ULA, but they could use ULA-C, for example for thinks like microallocations for internal infrastructure's.
what operators? I cant remember to have seen one operator supporting that point of view. My point of view from a LIR/network point of view etc was that ULA-C could be usefull but without reverse DNS it is useless. Maybe even with reverse DNS we want todo it the correct way by using our netblock we got from RIPE. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
Jeroen Massar <jeroen@unfix.org> writes:
JORDI PALET MARTINEZ wrote:
Operators have said that they will not be able to use ULA, but they cou= ld use ULA-C, for example for thinks like microallocations for internal infrastructure's.
I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way.
Maybe the assertion came from those who supported ARIN Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure (http://www.arin.net/policy/proposals/2006_2.html), where using a /48 out of their aggregate did not solve the technical problem at hand. At that time, the question was raised whether ULA-P solved the problem adequately. The answer I heard was a very clear "no". And ULA-C (if had existed then) would have. Thomas
If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting. It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste. It seems to me irresponsible and unbalanced to do or try things like changing the HD-ratio or the default assignment size to end-sites because it is a waste, and then oppose to those that want to have ULA-C, not impacting in others and avoiding one further small saving in global unicast space. I'm not trying to convince anyone about supporting ULA-C, because it seems an impossible mission at least for a few, but at least, don't object to it if having it doesn't force you in any further implications, which is the case. Regards, Jordi
De: Jeroen Massar <jeroen@unfix.org> Organización: Unfix Responder a: <ipv6-bounces@ietf.org> Fecha: Thu, 14 Jun 2007 11:00:11 +0100 Para: <jordi.palet@consulintel.es> CC: ARIN People Posting Mailing List <ppml@arin.net>, <ipv6@ietf.org>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: Revising Centrally Assigned ULA draft
[cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...]
JORDI PALET MARTINEZ wrote:
Operators have said that they will not be able to use ULA, but they could use ULA-C, for example for thinks like microallocations for internal infrastructure's.
I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way.
Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA block.
Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here.
I think the policy proposal that I sent to several regions includes text and links to other documents that can clarify this perspective.
For example in RIPE NCC: http://www.ripe.net/ripe/policies/proposals/2007-05.html
That is your proposal indeed. No "Operator" has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked out.
Anybody needing a "globally unique" block can get either PA or PI space. ULA-C as such is useless.
Greets, Jeroen
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote:
If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting.
It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste.
Jordi, You have this backwards. Using PI for the purposes of ULA-C is no waste at all. Sectioning off a huge chunk of address space for ULA-C is the waste. If it's all PI, then, it can seamlessly move between being unrouted or routed as the address-holder sees fit and as needs change. If it is set aside as ULA, then, the address space is forever wasted and cannot (theoretically) be used as routable space, no matter how little of it is needed for ULA-C. Those of us who oppose ULA-C have what we believe to be an objective position that it provides no additional benefit over PI space while simultaneously creating some unnecessary classification of addresses that makes their status in the routing table ill-defined at best. In our opinion, this carries the potential for significant consequences globally. Just because we do not agree with you does not mean that our concerns are not legitimate. Do I think UUNET and others should be able to get secondary microallocations to solve the problem they presented? Absolutely. Do I think that we need to set aside a /8, /12, /16, or whatever separate from the rest of PI space to do it? No. We should just issue them a /48 or whatever it is they need from the general pool of available PI space and be done with it. No waste at all. No negative consequences to anyone. No ambiguous status as to where you can or can't route the addresses, etc. Owen
I agree wholeheartedly. There is nothing you can do with ULA-C that you can't do with PI and a minor firewall rule or two. Leaving the space as PI gives it either-or capability, putting it as ULA reduces PI. (And don't talk about 'more PI than we could ever use'.. remember when Mr. Gates told us you would never need more than 640K of RAM?)(of course he denies it now..)
-----Original Message----- From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of Owen DeLong Sent: Friday, June 15, 2007 2:41 PM To: jordi.palet@consulintel.es Cc: ARIN People Posting Mailing List; ipv6@ietf.org; address-policy-wg@ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft
On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote:
If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting.
It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste.
Jordi, You have this backwards. Using PI for the purposes of ULA-C is no waste at all. Sectioning off a huge chunk of address space for ULA-C is the waste. If it's all PI, then, it can seamlessly move between being unrouted or routed as the address-holder sees fit and as needs change. If it is set aside as ULA, then, the address space is forever wasted and cannot (theoretically) be used as routable space, no matter how little of it is needed for ULA-C.
Those of us who oppose ULA-C have what we believe to be an objective position that it provides no additional benefit over PI space while simultaneously creating some unnecessary classification of addresses that makes their status in the routing table ill-defined at best. In our opinion, this carries the potential for significant consequences globally.
Just because we do not agree with you does not mean that our concerns are not legitimate.
Do I think UUNET and others should be able to get secondary microallocations to solve the problem they presented? Absolutely. Do I think that we need to set aside a /8, /12, /16, or whatever separate from the rest of PI space to do it? No. We should just issue them a /48 or whatever it is they need from the general pool of available PI space and be done with it. No waste at all. No negative consequences to anyone. No ambiguous status as to where you can or can't route the addresses, etc.
Owen
_______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
On Fri, 15 Jun 2007 15:13:40 -0500 "Kevin Kargel" <kkargel@polartel.com> wrote:
I agree wholeheartedly. There is nothing you can do with ULA-C that you can't do with PI and a minor firewall rule or two. Leaving the space as PI gives it either-or capability, putting it as ULA reduces PI. (And don't talk about 'more PI than we could ever use'.. remember when Mr. Gates told us you would never need more than 640K of RAM?)(of course he denies it now..)
I understand that that was an IBM design decision - they chose to allow 384KB out of the 1MB of address space of the 8086/8088 for option ROMs for add-in cards. That decision was made during the design of the original IBM PC (i.e. the one before the XT), which originally came with 16KB of RAM (and a audio cassette interface for storage, no serial ports or printer ports, and a monochrome 4KB text adaptor). Allowing 384KB for option ROMs allowed for plenty of IO card expansion, because the platform was initially very barebones, and 640KB was extremely large amount of RAM at the time. The OS at the time didn't provide device drivers, unlike today's OSes - the option ROMs was were that functionality resided. When you look at that problem, at the time it was addressed, the 640KB/384KB boundary seems, at least to me, to be quite reasonable. The IBM PC architecture was never expected to (a) set an industry standard and (b) ever last as long as it has. Gates was unlikely to have ever been consulted on it, or conversely, was only ever agreeing with a decision that had already been made. Don't use this (mis)quote as a lack of design foresight, use it as an example of wildly unexpected success. IPv6 doesn't have the addressing quantity constraints that IPv4 has, so allow for wildly different and expanded uses of it and it's large address space. As a general example of how IPv6's "large" addressing could be used, look at Ethernet. Nobody needs 2^47 unicast addresses on a LAN segment. We "waste" millions of addresses everytime we enable a new LAN segment. The Ethernet address space we "waste" when a point to point ethernet link is brought up is the most "obscene" amount of address space "waste" I've ever seen in my life - because a point-to-point link doesn't even need addressing - the frame is either for this end or the other end. So what has all that "wasted" Ethernet address space got us ? _Convenience_ It is convenient that we can plug an Ethernet card in and not have to worry about configuring addresses or addressing collisions. Non-technical people can buy a network card at the local electrical store, plug it into their computer, and the ethernet functionality work (installing device drivers is obviously not a problem that ethernet attemps to solve). It's the original "plug-and-play". With Ethernet, we get a lot of convenience at the cheap price of 32 or so bits of "wasted" address space (on the rough assumption that nobody would ever build an ethernet segment with more than 65K nodes), or 64 bits in each packet. Here's what the people who chose 48 bit addressing for Ethernet said about the decision : "48-bit host numbers lead to large Ethernet and internet packets. We believe that this will not pose a problem as both local and public data networks continue to offer higher bandwidths at reasonable costs, and the memory and logic costs associated with storing and processing these numbers continue to become lower with the advances in LSI technology." ("48-bit Absolute Internet and Ethernet Host Numbers", Yogan K. Dalal and Robert S. Printis - definately worth a read) When did they say it ? 1981! 26 years ago! The problem with applying an IPv4 mentality to an IPv6 addressing problem is that IPv4 hasn't been an abundant resource for 15 or so years. We've had to give up operational convenience with it because we needed to ensure functionality as the Internet grew. When it came to the crunch, convenience had to be sacrificed. IPv6 address space is abundant, so we can now go back to placing value on operational convenience. All we need to do is ensure there isn't any reckless use of IPv6's address space. So, getting back to the ULA topic : If (non-globally routed) PI is the answer to the ULA-C question, is there going to be enough (non-globally routed) PI so that I can get a (non-globally routed) PI allocation for my home, at a small charge for the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal Area Network that interconnects my mobile phone, portable music player and pedometer in my shoes. Will there be enough (non-globally routed) PI that everybody on the planet who might end up having that sort of PAN can get a (non-globally routed) PI address allocation, should they want one ? How about if they want separate allocations for both their PAN and their home network. If the answer is no, then (non-globally routed) PI it isn't solving the ULA/ULA-C problem.
-----Original Message----- From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of Owen DeLong Sent: Friday, June 15, 2007 2:41 PM To: jordi.palet@consulintel.es Cc: ARIN People Posting Mailing List; ipv6@ietf.org; address-policy-wg@ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft
On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote:
If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting.
It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste.
Jordi, You have this backwards. Using PI for the purposes of ULA-C is no waste at all. Sectioning off a huge chunk of address space for ULA-C is the waste. If it's all PI, then, it can seamlessly move between being unrouted or routed as the address-holder sees fit and as needs change. If it is set aside as ULA, then, the address space is forever wasted and cannot (theoretically) be used as routable space, no matter how little of it is needed for ULA-C.
Those of us who oppose ULA-C have what we believe to be an objective position that it provides no additional benefit over PI space while simultaneously creating some unnecessary classification of addresses that makes their status in the routing table ill-defined at best. In our opinion, this carries the potential for significant consequences globally.
Just because we do not agree with you does not mean that our concerns are not legitimate.
Do I think UUNET and others should be able to get secondary microallocations to solve the problem they presented? Absolutely. Do I think that we need to set aside a /8, /12, /16, or whatever separate from the rest of PI space to do it? No. We should just issue them a /48 or whatever it is they need from the general pool of available PI space and be done with it. No waste at all. No negative consequences to anyone. No ambiguous status as to where you can or can't route the addresses, etc.
Owen
_______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
If (non-globally routed) PI is the answer to the ULA-C question, is there going to be enough (non-globally routed) PI so that I can get a (non-globally routed) PI allocation for my home, at a small charge for the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal Area Network that interconnects my mobile phone, portable music player and pedometer in my shoes. Will there be enough (non-globally routed) PI that everybody on the planet who might end up having that sort of PAN can get a (non-globally routed) PI address allocation, should they want one ? How about if they want separate allocations for both their PAN and their home network.
these are rir policy and price issues. they are not technical issues. except for routability, which, as smb says, don't think you ain't gonna want to connect it some day; you will. randy
Hi, On Sat, Jun 16, 2007 at 08:19:11AM +0930, Mark Smith wrote:
If (non-globally routed) PI is the answer to the ULA-C question, is there going to be enough (non-globally routed) PI so that I can get a (non-globally routed) PI allocation for my home, at a small charge for the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal Area Network that interconnects my mobile phone, portable music player and pedometer in my shoes. Will there be enough (non-globally routed) PI that everybody on the planet who might end up having that sort of PAN can get a (non-globally routed) PI address allocation, should they want one ? How about if they want separate allocations for both their PAN and their home network.
If the answer is no, then (non-globally routed) PI it isn't solving the ULA/ULA-C problem.
Something to consider for the folks that reject ULA-C because "PI would do the job". There is quite a number of people out there that are quite sceptic about PI space - and really do not want to make access to PI space easy and convenient. Consider me one of those - globally routed PI space puts burden on everybody else, so this should be well-considered, and putting some hurdles in people's way might make them reconsider whether they really want PI or not. The "non-routed globally unique address thing", however it is called, should be *very very very* easy to get - I would prefer to see a one-up fee here, but if there is registry service tacked to it, I could live with a small(!) yearly fee. This is where I see the benefit of ULA-C - address space that is unique, and doesn't need artificial obstacles to keep the number of occurances in the routing system low. (Of course this whole debate would immediately stop if the *routing crowd* would stop to offload their problems to address policy. From a pure address policy point of view, I could care less if folks get "a /48" from PA, PI, or ULA space - it's address consumption, and the type of address doesn't matter anything. Routing is hurt, but I see no resonable way (today) to put a global tax on each advertised prefix - which would achieve the "convenience" <-> "global cost" balancing...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 18 Jun 2007, at 17:09, Gert Doering wrote:
There is quite a number of people out there that are quite sceptic about PI space - and really do not want to make access to PI space easy and convenient. Consider me one of those - globally routed PI space puts burden on everybody else, so this should be well- considered, and putting some hurdles in people's way might make them reconsider whether they really want PI or not.
What, you'd rather people deagg their PA in order to let their customers multi-home ?
Total number of prefixes smaller than registry allocations: 113403
... because it doesn't look like you prefer that at all ....
Hi, On Mon, Jun 18, 2007 at 05:13:39PM +0100, Andy Davidson wrote:
On 18 Jun 2007, at 17:09, Gert Doering wrote:
There is quite a number of people out there that are quite sceptic about PI space - and really do not want to make access to PI space easy and convenient. Consider me one of those - globally routed PI space puts burden on everybody else, so this should be well- considered, and putting some hurdles in people's way might make them reconsider whether they really want PI or not.
What, you'd rather people deagg their PA in order to let their customers multi-home ?
Of course not. But multi-homing customers are only one facet of the picture - the other side is customers that just find it inconvenient to renumber when changing providers, so they go for PI, if that is more convenient (and we see this already happening in IPv4 in Europe - PI assignment rates have been going way up in recent years). Given current multi-homing technology (BGP), the number of participants doing BGP-style multi-homing is "somewhat limited" (because not everybody can run a BGP router yet, and ISPs do not usually offer BGP on DSL- or cable-style products yet) - while the number of end-users that would prefer to have a sticky IPv6 address and never having to renumber is virtually unlimited. And I direly want *those* to use PA space - and see that aggregated. For the multihomers, it's very hard to make generic statements, as the differences among these networks are huge. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
participants (10)
-
Andy Davidson
-
Gert Doering
-
Jeroen Massar
-
JORDI PALET MARTINEZ
-
Kevin Kargel
-
Mark Smith
-
Owen DeLong
-
Randy Bush
-
Roger Jorgensen
-
Thomas Narten