2008-01 Moved to Review Phase (Assigning IPv6 PI to Every Inetnum Holder)
PDP Number: 2008-01 Assigning IPv6 PI to Every Inetnum Holder Dear Colleagues, The impact analysis for the proposal described in 2008-01 has been published and the proposal is moved to the Review Phase. If this proposal reaches consensus, the RIPE NCC will conduct a one-time operation to assign a /56 IPv6 PI prefix to all End Users with an IPv4 assignment registered in the RIPE Database. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-01.html We encourage you to send your comments to address-policy-wg@ripe.net before 16 April 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
If this proposal reaches consensus, the RIPE NCC will conduct a one-time operation to assign a /56 IPv6 PI prefix to all End Users with an IPv4 assignment registered in the RIPE Database.
We encourage you to send your comments to address-policy-wg@ripe.net before 16 April 2008.
I strongly oppose on a number of counts: Not every inetnum holder in the RIPE database justifies a PI IPv4 assignment, why on earth should they receive a PI IPv6 assignment? Many entities will have no use for the /56 you're planning on giving them. Many entities will have no way of announcing the /56 you're planning on giving them even if they had a use for it. Theres lots of entities with multiple inetnum objects, that don't use a single person/role object. You'll end up assigning multiple /56s to entities when they have no need for them. The routing tables can't support another 2.25 million prefixes. Now, I would suggest dishing out /48 PI IPv6 space to entities who request them, and have genuine plans to announce them (making a one off and a yearly charge for this would be nice, for the sake of conserving routing table size rather than conserving available address space at this stage). This shouldn't cause the same amount of growth in the routing tables that dishing out /24s of v4 PI space has done since /48 is enough subnets to last (hopefully forever), thus a single entity announcing PI from a single location should only ever need a /48 (whereas a /56 might be pushing it). I'd also suggest marking a block of v6 space as never to be allocated for the purposes of global routability, but for the sake of internal networking for the sake of global uniqness. Theres little point in making this a /48 rather than a /56 since aggregation isn't an issue if they're not going to be globally routable anyway. Regards James
On Wed, 19 Mar 2008, James A. T. Rice wrote:
If this proposal reaches consensus, the RIPE NCC will conduct a one-time operation to assign a /56 IPv6 PI prefix to all End Users with an IPv4 assignment registered in the RIPE Database.
We encourage you to send your comments to address-policy-wg@ripe.net before 16 April 2008.
...
Many entities will have no way of announcing the /56 you're planning on giving them even if they had a use for it.
Well, this would build up pressure to get it announced and accepted, at least in some parts of the network. IMHO the very minimum required is assigning all of these from a single aggregated block where everything is assigned has the same prefixlength in order to ease ISPs' filtering decisions.
Theres lots of entities with multiple inetnum objects, that don't use a single person/role object. You'll end up assigning multiple /56s to entities when they have no need for them.
The routing tables can't support another 2.25 million prefixes. ... Now, I would suggest dishing out /48 PI IPv6 space to entities who request them, and have genuine plans to announce them (making a one off and a yearly charge for this would be nice, for the sake of conserving routing table size rather than conserving available address space at this stage).
I pretty much agree with James here, on all counts. If some version of this proposal were to go forward, I'd suggest /48's. And I would explicitly want the policy to specify that these /48's will be assigned from a single superblock where no other (other prefixlength) assignments or allocations are made. That way the ISPs have easier time to build their filters to either accept these as /48's, /56's or whatever (and no more specifics) or reject them completely. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
I oppose this proposal (can not tell more, than James has told ). Best regards, Dmitry V. Menzulskiy (DM3740-RIPE) address-policy-wg-admin@ripe.net написано 19.03.2008 18:09:33:
If this proposal reaches consensus, the RIPE NCC will conduct a one-time operation to assign a /56 IPv6 PI prefix to all End Users with an IPv4
assignment registered in the RIPE Database.
We encourage you to send your comments to address-policy-wg@ripe.net before 16 April 2008.
I strongly oppose on a number of counts:
Not every inetnum holder in the RIPE database justifies a PI IPv4 assignment, why on earth should they receive a PI IPv6 assignment?
Many entities will have no use for the /56 you're planning on giving them.
Many entities will have no way of announcing the /56 you're planning on giving them even if they had a use for it.
Theres lots of entities with multiple inetnum objects, that don't use a single person/role object. You'll end up assigning multiple /56s to entities when they have no need for them.
The routing tables can't support another 2.25 million prefixes.
Now, I would suggest dishing out /48 PI IPv6 space to entities who request them, and have genuine plans to announce them (making a one off and a yearly charge for this would be nice, for the sake of conserving routing
table size rather than conserving available address space at this stage).
This shouldn't cause the same amount of growth in the routing tables that dishing out /24s of v4 PI space has done since /48 is enough subnets to last (hopefully forever), thus a single entity announcing PI from a single location should only ever need a /48 (whereas a /56 might be pushing it).
I'd also suggest marking a block of v6 space as never to be allocated for the purposes of global routability, but for the sake of internal networking for the sake of global uniqness. Theres little point in making this a /48 rather than a /56 since aggregation isn't an issue if they're
not going to be globally routable anyway.
Regards James
James A. T. Rice wrote:
I strongly oppose on a number of counts:
Not every inetnum holder in the RIPE database justifies a PI IPv4 assignment, why on earth should they receive a PI IPv6 assignment?
Many entities will have no use for the /56 you're planning on giving them.
Many entities will have no way of announcing the /56 you're planning on giving them even if they had a use for it.
Theres lots of entities with multiple inetnum objects, that don't use a single person/role object. You'll end up assigning multiple /56s to entities when they have no need for them.
The routing tables can't support another 2.25 million prefixes.
Agreed on all counts - I strongly disagree with this proposal. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
Many entities will have no use for the /56 you're planning on giving them.
In general, I agree with those who oppose this proposal. But another problem with the proposal is that it will lead many organizations to design their IPv6 network based on a /56 rather than a /48 which is more normal. Organizations really should think about how they structure their IPv6 network and only squeeze it into a /56 if they need to. --Michael Dillon
On Thu, Mar 20, 2008 at 12:18:52PM -0000, michael.dillon@bt.com wrote:
Many entities will have no use for the /56 you're planning on giving them.
In general, I agree with those who oppose this proposal. But another problem with the proposal is that it will lead many organizations to design their IPv6 network based on a /56 rather than a /48 which is more normal. Organizations really should think about how they structure their IPv6 network and only squeeze it into a /56 if they need to.
--Michael Dillon
"normal" is a very odd way to couch this argument. why not /35 & /32, or the /56 & /64... pragmatically, a network operator would be working in the /88 to /110 space. the massive waste in delegated and unused/unusable space is almost entirely the result of protocol designers who had little or no network operational experience. IPv6 - 96 more bits, No Magic. --bill
Bill, [ Apologies for the following rant... ] On Thu, Mar 20, 2008 at 12:38:50PM +0000, bmanning@vacation.karoshi.com wrote:
On Thu, Mar 20, 2008 at 12:18:52PM -0000, michael.dillon@bt.com wrote:
Many entities will have no use for the /56 you're planning on giving them.
In general, I agree with those who oppose this proposal. But another problem with the proposal is that it will lead many organizations to design their IPv6 network based on a /56 rather than a /48 which is more normal. Organizations really should think about how they structure their IPv6 network and only squeeze it into a /56 if they need to.
"normal" is a very odd way to couch this argument. why not /35 & /32, or the /56 & /64...
pragmatically, a network operator would be working in the /88 to /110 space. the massive waste in delegated and unused/unusable space is almost entirely the result of protocol designers who had little or no network operational experience.
IPv6 - 96 more bits, No Magic.
I was a fly on the wall in one of the early discussions where /48 was presented as a recommendation (just when I was starting with this Internet stuff, done in a small circle of interested folks). One assertion was that "allocations must be on byte boundaries" - the reason given was hardware optimization. I didn't believe it then, and I don't believe it now. But the overriding idea was that it *must* be the same size for everyone, otherwise someone might charge more for a larger block, or simply not offer the same size. So people might end up either with a smaller block than they need, or migrate from a larger to a smaller network and not want to renumber. Which means they might use NAT. So, as far as I can tell, the "one size fits all" idea is an attempt to further the IETF anti-NAT jihad, and has nothing to do with anyone's operational needs. :-( -- Shane
On Thu, Mar 20, 2008 at 05:18:15PM +0100, Shane Kerr wrote:
Bill,
[ Apologies for the following rant... ]
So, as far as I can tell, the "one size fits all" idea is an attempt to further the IETF anti-NAT jihad, and has nothing to do with anyone's operational needs. :-(
snicker... :) a /56 is a tad over 1000 networks, each the size of the entire IPv4 space. Michaels claim that its going to be a tough "squeeze" to shoehorn an operational network into that small number of bits is enough to make me snort the diet coke out my nose in the morning. Humourous and a bit painful at the same time. --bill
-- Shane
a /56 is a tad over 1000 networks, each the size of the entire IPv4 space.
this is a little fallacy we keep playing on ourselves. it is only usefully true if you think you will be deploying absolutely jigongous layer two flat networks of O(2^64) size. and we all know that's not possible. or are you suggesting that we all throw the /64 magic lan boundary back in the ietf's face at this late date? while this would not break my little black heart, i don't think it's very likely to succeed. randy
On Tue, Mar 25, 2008 at 06:10:39PM +0900, Randy Bush wrote:
a /56 is a tad over 1000 networks, each the size of the entire IPv4 space.
this is a little fallacy we keep playing on ourselves. it is only usefully true if you think you will be deploying absolutely jigongous layer two flat networks of O(2^64) size. and we all know that's not possible.
or are you suggesting that we all throw the /64 magic lan boundary back in the ietf's face at this late date? while this would not break my little black heart, i don't think it's very likely to succeed.
randy
"we" in this case is me and the mouse in my pocket. and yes, this is tossing the /64 stricture. the house network is nicely tucked into a /112 - although we advertize a /48 covering prefix so it will get transit. --bill
On Tue, Mar 25, 2008 at 09:39:51AM +0000, bmanning@vacation.karoshi.com wrote: | "we" in this case is me and the mouse in my pocket. | and yes, this is tossing the /64 stricture. the house | network is nicely tucked into a /112 - although we advertize | a /48 covering prefix so it will get transit. good for you, bill. you get to do things different just because you can AND the world gets to see you adhere to what we collectively regard as good practice. I don't think I have your /48 in my routing tables. Sorry it didn't work out. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------
On Wed, Mar 26, 2008 at 09:27:41AM +0100, Pim van Pelt wrote:
On Tue, Mar 25, 2008 at 09:39:51AM +0000, bmanning@vacation.karoshi.com wrote: | "we" in this case is me and the mouse in my pocket. | and yes, this is tossing the /64 stricture. the house | network is nicely tucked into a /112 - although we advertize | a /48 covering prefix so it will get transit. good for you, bill. you get to do things different just because you can AND the world gets to see you adhere to what we collectively regard as good practice.
I don't think I have your /48 in my routing tables. Sorry it didn't work out.
got a target v6 address for me to reach? --bill
| "we" in this case is me and the mouse in my pocket. | and yes, this is tossing the /64 stricture. the house | network is nicely tucked into a /112 - although we advertize | a /48 covering prefix so it will get transit. good for you, bill. you get to do things different just because you can AND the world gets to see you adhere to what we collectively regard as good practice.
I don't think I have your /48 in my routing tables. Sorry it didn't work out. ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl
and good for you. although I expect your use of the term "we", might be different than my own. the picture you paint, bill v. the world - is only slightly off kilter. sorry that you chose to filter, but that is every ISP's perogative ... or more strongly, every ISP has an obligation to establish which prefixes they will and will not accept. leaning on a third party (IETF, RIR) to set those policies for you might be an abbrogation of responsibility. --bill
a /56 is a tad over 1000 networks, each the size of the entire IPv4 space.
this is a little fallacy we keep playing on ourselves. it is only usefully true if you think you will be deploying absolutely jigongous layer two flat networks of O(2^64) size. and we all know that's not possible.
or are you suggesting that we all throw the /64 magic lan boundary back in the ietf's face at this late date? while this would not break my little black heart, i don't think it's very likely to succeed.
If we accept that an IPv6 subnet prefix can be no longer than /64 then there are 8 bits between /56 and /64, that can be used to design a subnetting hierarchy. This is HALF the number of bits that is available with a standard site allocation of /48. Since these prefix sizes (/48 and /64) were agreed on in order to give subnets more bits than they could possibly need, and sites more bits than they could possibly need, I think it is reasonable to question a plan which gives organizations, possibly with multiple sites, only a single /56. This goes against the fundamental architecture of IPv6 which tries to give every network (ISP, site, subnet) enough bits to allow them to expand within their assigned prefix without needing to rearchitect whole sections of their network. Of course, there is a much better argument against this proposed allocation and that is that it is pointless to give stuff to organizations who have no need of it, when it is simple and cheap for them to get the same stuff (or better) when they do have the need. But I still think that it needs to be pointed out that the standard prefix lengths of /64 for a subnet, /48 for a site, and /32 for an ISP, provide real benefits in network architecture and design. We should never make changes to this architecture without considerable thought and understanding of the reasons why these prefix lengths were chosen. IPv6 is not the same as IPv4. --Michael Dillon
But I still think that it needs to be pointed out that the standard prefix lengths of /64 for a subnet, /48 for a site, and /32 for an ISP, provide real benefits in network architecture and design.
The /64 for subnet I can understand, as automatic address assignment relies on it. However, I think I personally would be more cautious in using such big words about the /48 and /32 limits. Sure, they're fine round binary numbers, but are they *really* anything more than that? Maybe it's time to play the "site" card? (Or hasn't that been played many times already?) Do you put a lower bound on what you call a "site"? Is a home network connected via DSL a "site"? What about a small business (sub-10 employees, say) which also uses DSL a "site" worthy of assignment of an entire /48? I can easily imagine ISPs having more then 64K (for the americans who might have a problem with math, that's 2^(48-32) :-) DSL users, and with the "one size fits all" address assignment policy outlined above, the ISP would blow through it's entire /32 by handing out IPv6 addresses to 65536 customers.
We should never make changes to this architecture without considerable thought and understanding of the reasons why these prefix lengths were chosen.
Which, briefly summarized, were...?
IPv6 is not the same as IPv4.
So I continue to see people say, but I've yet to see a justification for such broad sweeping statements which I can agree with justifies the statement. From my perspective it's *really* the same protocol done a second time with more bits, and the number of bits is *not* infinite. Regards, - Håvard
Havard, On Mar 25, 2008, at 11:50 AM, Havard Eidnes wrote:
The /64 for subnet I can understand, as automatic address assignment relies on it. However, I think I personally would be more cautious in using such big words about the /48 and /32 limits. Sure, they're fine round binary numbers, but are they *really* anything more than that?
They are conventions that some folks thought would help 'site' renumbering and aggregatability.
Maybe it's time to play the "site" card?
No. It's an icky card.
I can easily imagine ISPs having more then 64K (for the americans who might have a problem with math, that's 2^(48-32) :-) DSL users, and with the "one size fits all" address assignment policy outlined above, the ISP would blow through it's entire /32 by handing out IPv6 addresses to 65536 customers.
Yes. Leaving 35,184,372,023,296 (2^45 - 2^16) /48s left in the format prefix assigned to global unicast.
We should never make changes to this architecture without considerable thought and understanding of the reasons why these prefix lengths were chosen.
Which, briefly summarized, were...?
"We got bits. Lots o' bits."? I don't know the rationale myself, but I note that class Bs were once very popular... :-)
IPv6 is not the same as IPv4.
So I continue to see people say, but I've yet to see a justification for such broad sweeping statements which I can agree with justifies the statement. From my perspective it's *really* the same protocol done a second time with more bits,
I suspect it depends on where you look. From a network operations POV, most folks I think would agree that IPv6 is a backwards incompatibly tweaked IPv4 with more bits (giving you most if not all of the problems of IPv4 with little benefit of a new protocol to justify the cost of deployment). From an enterprise POV, you've got addresses coming out of every bodily orifice which is quantitatively different, albeit qualitatively since you're saddled with the same routing crap you have with IPv4, the difference isn't so useful. From an application programmer's POV, you get to touch every piece of network aware code (relinking at a minimum). The VAST TRACTS of address space _may_ provide for new network application architectures and communication techniques, although I'm not holding my breath.
and the number of bits is *not* infinite.
True. There are the same number of /19s, /20s, etc. in IPv6 as there are in IPv4... (I find it odd that some people don't seem to get this). Regards, -drc
True. There are the same number of /19s, /20s, etc. in IPv6 as there are in IPv4... (I find it odd that some people don't seem to get this).
Maybe a better way to explain it is that there are the same number of /32s in IPv6 as IPv4. But instead of assigning a /32 to a single device, in IPv6 we allocate it to a single ISP who can then make /48 allocations to 64k customer sites which can then address everything in that site including the light switches. As you can see, IPv6 makes much better use of a /32 than IPv4 does. --Michael Dillon
Maybe it's time to play the "site" card? (Or hasn't that been played many times already?) Do you put a lower bound on what you call a "site"? Is a home network connected via DSL a "site"?
Yes.
What about a small business (sub-10 employees, say) which also uses DSL a "site" worthy of assignment of an entire /48?
Yes.
I can easily imagine ISPs having more then 64K (for the americans who might have a problem with math, that's 2^(48-32) :-) DSL users, and with the "one size fits all" address assignment policy outlined above, the ISP would blow through it's entire /32 by handing out IPv6 addresses to 65536 customers.
Big ISPs already ask for and receive IPv6 allocations much bigger than a /32.
We should never make changes to this architecture without considerable thought and understanding of the reasons why these prefix lengths were chosen.
Which, briefly summarized, were...?
If only the IETF would produce a document that covers the whole story... My understanding is that a big part of the architecture was to allow networks to grow, at any level in the addressing hierarchy without requiring any changes to the hierarchy itself. That's why a site gets more addresses than they need and why many ISPs also get more addresses than they need. Of course, in the Americas, they have tempered this by dividing sites into homes and others. An ISP can assign /56s to home sites rather than /48, if they want to. Of course this complicates management systems and planning, so ARIN made this optional. If a site really is a home, then /56 still meets the goal of giving more subnetting ability than they could possibly need.
IPv6 is not the same as IPv4.
So I continue to see people say, but I've yet to see a justification for such broad sweeping statements which I can agree with justifies the statement. From my perspective it's *really* the same protocol done a second time with more bits, and the number of bits is *not* infinite.
There are many ways in which IPv6 differs from IPv4, not just the addressing hierarchy. And even though the number of bits is not infinite, it is really, really big. Almost unimaginably big. We can afford to waste IPv6 addresses because even if we do run out some day, our great-grandchildren will have enough generations of network operational experience to design a proper Internet Protocol. --Michael Dillon
Hi, On Thu, Mar 20, 2008 at 04:24:28PM +0000, bmanning@vacation.karoshi.com wrote:
a /56 is a tad over 1000 networks, each the size of the entire IPv4 space.
American math is funny. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 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 Mar 25, 2008, at 2:34 AM, Gert Doering wrote:
On Thu, Mar 20, 2008 at 04:24:28PM +0000, bmanning@vacation.karoshi.com wrote:
a /56 is a tad over 1000 networks, each the size of the entire IPv4 space. American math is funny.
Networks as WMD? Regards, -drc
Hi, On Thu, Mar 20, 2008 at 05:18:15PM +0100, Shane Kerr wrote:
So, as far as I can tell, the "one size fits all" idea is an attempt to further the IETF anti-NAT jihad, and has nothing to do with anyone's operational needs. :-(
Actually, it *does* make an operator's life easier. Just a single button "give this customer space", without long planning on the specific size that this specific end customer might need, in 3 years time. Regarding the actual size of the block, I don't really care - there are enough bits available. What good are 128 bits if we don't use them? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 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
Filiz Yilmaz wrote:
We encourage you to send your comments to address-policy-wg@ripe.net before 16 April 2008.
I strongly oppose this (2008-01) proposal for the reasons James A. T. Rice has given. Why would we want to forward all the messy swamp space issues we have in IPv4 to IPv6? I abstain from voting on 2008-02, I don't think it is necessary to push address space to people who don't use it. No size fits everyone, getting PAv6 is easy enough (especially since 2006-02) and allocations serve as good indicator for the growth of IPv6. Also I suspect this will create issues with the scoring system for people who suddenly have to pay for address space they didn't even want. But if the community thinks that this is a good move then go ahead. Regards, Bernhard
On 19 mrt 2008, at 16:40, Bernhard Schmidt wrote:
Filiz Yilmaz wrote:
We encourage you to send your comments to address-policy- wg@ripe.net before 16 April 2008.
I strongly oppose this (2008-01) proposal for the reasons James A. T. Rice has given. Why would we want to forward all the messy swamp space issues we have in IPv4 to IPv6?
I abstain from voting on 2008-02, I don't think it is necessary to push address space to people who don't use it. No size fits everyone, getting PAv6 is easy enough (especially since 2006-02) and allocations serve as good indicator for the growth of IPv6. Also I suspect this will create issues with the scoring system for people who suddenly have to pay for address space they didn't even want. But if the community thinks that this is a good move then go ahead.
Can't add much more as 'I fully agree', it seems as bad as the goold old classfull days and /8's. Groet, MarcoH
As others have pointed out, it makes little sense to give IPv6 address ranges to those who do not request or need them. I would support a proposal that would allow RIPE to give out IPv6 PI space to those Inetnum holders who specifically request it, no questions asked. I do not buy the argument that it should be rejected because this would fill up the routing tables. If the Cogent/Telia ongoing dispute is any indication, even the SOHO's will soon need to multihome if they want global connectivity. So, unless we want to repeat the NAT scenario we currently have in homes and small offices, PI space seems necessary and will develop further.The router industry will need to come up with faster hardware. Patrick Vande Walle
Patrick, On Mar 20, 2008, at 10:30 AM, Patrick Vande Walle wrote:
I would support a proposal that would allow RIPE to give out IPv6 PI space to those Inetnum holders who specifically request it, no questions asked.
A simple web form that allocates /48s on demand has been suggested several times in the past.
I do not buy the argument that it should be rejected because this would fill up the routing tables. If the Cogent/Telia ongoing dispute is any indication, even the SOHO's will soon need to multihome if they want global connectivity.
Indeed. I personally figure as people become more and more dependent on Internet connectivity (e.g., not just for communication/ entertainment, but for system monitoring and control), multi-homing will become the norm rather than the exception.
So, unless we want to repeat the NAT scenario we currently have in homes and small offices, PI space seems necessary and will develop further.The router industry will need to come up with faster hardware.
Be careful what you wish for. The router industry would undoubtedly be happy to sell you hardware as fast as the law of physics allow. Of course, building it will be mindbogglingly expensive (particularly given the market for the high end gear is so tiny), so you'll pay a premium. Or rather, the very large ISPs (who are the only ones who'll be able to afford it) will pay a premium and pass the cost down to you, the consumer. Oh, and it'll take a bit of time (designing and spinning ASICs doesn't happen overnight), so in the meantime, some ISPs will probably need to filter out stuff to keep their routers from falling over. Since nobody is really using IPv6 right now, I suspect it'll be the first to go. Oh, and most of those small multi-homed sites most likely aren't all that interesting to the very large ISPs, so they'll probably be targeted for filtering as well. As a small multi-homed site, you'll undoubtedly have the option of finding all those ISPs that are filtering you and paying them to not filter you, but that'll be pretty annoying. So it goes. TANSTAAFL. Regards, -drc
I do not buy the argument that it should be rejected because this would fill up the routing tables. If the Cogent/Telia ongoing dispute is any indication, even the SOHO's will soon need to multihome if they want global connectivity.
Indeed. I personally figure as people become more and more dependent on Internet connectivity (e.g., not just for communication/ entertainment, but for system monitoring and control), multi-homing will become the norm rather than the exception.
Let's suppose I'm SOHO user. Also let's suppose I have IPv6 only in form of /48 from one of tunnel brokers(native IPv6 is not available to me). And I want to multihome via IPv6(and think I have need for it). I think this would be rather common situation in near future. How I could do it now? - Where I can get PI space? And how much it will cost? - How I could get BGP sessions established with several ISPs?Is it possible at all now?(for small SOHO user) - What I could use as router(s)?Linux machine with Quagga(I'm SOHO user after all so no specialized Cisco gear)? How I can do it in 1-2 years from now? Or I better forget this idea and just get several /48s from different sources and let machines under my control to get several addresses and hope that in case one of connections will be broken, application-level mechanisms will retry and establish connection using different addresses?(in this case, i think this will be blatant waste of /48s _and_ decreased reliability for SOHO user) -- -- Best Regards, Dmitriy Kazimirov, C++ Developer of ISS Art, Ltd., Omsk, Russia Web: http://www.issart.com E-mail: dkazimirov@issart.com Personal e-mail:dkazimirow@gmail.com
Patrick, I think you bring up a very important issue. On 20/03/2008 18:30, "Patrick Vande Walle" <patrick@vande-walle.eu> wrote: [...]
I would support a proposal that would allow RIPE to give out IPv6 PI space to those Inetnum holders who specifically request it, no questions asked.
Right now, the policy for receiving an IPv4 PI assignment is that you get as many addresses as you can show that you need. So if you needed 25 addresses you'd get a /27 as that's the closest prefix length to your need. That's unlikely to get routed very far, though. The likely affect of this policy is some (but not much) pushback on people requesting PI space. They might accept a PA assignment from their ISP, saving everyone else from carrying an extra route. Alternatively, they might just lie. But the "one size fits all" approach of IPv6 doesn't provide any pushback. It is possible the demand for PI space would be very much higher if there were no difference between the size of networks assigned from the ISP's aggregate and the RIR. And then you write:
I do not buy the argument that it should be rejected because this would fill up the routing tables. If the Cogent/Telia ongoing dispute is any indication, even the SOHO's will soon need to multihome if they want global connectivity. So, unless we want to repeat the NAT scenario we currently have in homes and small offices, PI space seems necessary and will develop further.The router industry will need to come up with faster hardware.
Adding to what David says, additional routes and the extra cost they add could raise the barrier to entry for ISPs and encourage consolidation in the marketplace. That might result in reduced consumer choice. Not fun. Leo
On 19 Mar 2008, at 14:51, Filiz Yilmaz wrote:
PDP Number: 2008-01 Assigning IPv6 PI to Every Inetnum Holder
Forgive me if I have missed consensus (or perhaps an epiphany), but doesn't this suggestion rely on the arguments from PDP number 2006-01 being solved ? I oppose the proposal as it stands, but I support any efforts to encourage v6 adoption, and also recognise that this means fair and available v6 PI policy must be adopted. I would prefer to see global consensus that any organisation with a requirement for address resources can request, and have ONE block of PI. My rationale is that it should be extremely clear that originating one prefix at the end-site edge is both intended, and desirable. The RIRs should have permission to sanction additional blocks where seen as operationally imperative. Organisations should also have to justify a technical requirement for PI rather than PA, and additionally, should interface with the RIPE NCC via an LIR. This does not stop organisations registering additional, 'shill' organisations for the purposes of requesting more PI, but if someone is that desperate to design flaws into their network, there is little that can be described in a policy development environment that will help them. Best wishes Andy Davidson
participants (19)
-
Andy Davidson -
Bernhard Schmidt -
bmanning＠vacation.karoshi.com -
David Conrad -
Dmitriy Kazimirov -
Dmitriy V Menzulskiy -
Filiz Yilmaz -
Gert Doering -
Havard Eidnes -
James A. T. Rice -
Leo Vegoda -
Marco Hogewoning -
michael.dillon＠bt.com -
Nick Hilliard -
Patrick Vande Walle -
Pekka Savola -
Pim van Pelt -
Randy Bush -
Shane Kerr