From ncc at ripe.net Mon Apr 3 11:00:37 2006 From: ncc at ripe.net (Paul Rendek) Date: Mon, 03 Apr 2006 11:00:37 +0200 Subject: [address-policy-wg] ASO/ICANN Board Nominations Close Soon Message-ID: <5.2.1.1.2.20060403105615.01dd49c0@mailhost.ripe.net> [Sent on behalf of the Address Supporting Organization (ASO) - Apologies for Duplicates] Dear Colleagues In line with the ASO MoU and ICANN bylaws, the Address Council calls for nominations to the ICANN Board to fill the ASO seat. Mouhamet Diop currently holds this seat. His term ends in June 2006. You can send your nominations until 4 April 2006 to . Your e-mail should include the following information: - Full name of person that you want to nominate - A contact e-mail address for the person that you nominate - If available, a contact telephone number for your nominee - Your full name - Your contact e-mail address - Your contact telephone number Nominations will be reviewed in accordance with the ASO Board of Directors selection procedures. You can find these on the ASO website. Regards Paul Rendek RIPE NCC From leo at ripe.net Fri Apr 7 13:30:37 2006 From: leo at ripe.net (leo vegoda) Date: Fri, 07 Apr 2006 07:30:37 -0400 Subject: [address-policy-wg] RIR Comparative Policy Overview Update Message-ID: <44364D5D.5020407@ripe.net> [Apologies for duplicate e-mails] Dear Colleague, The Regional Internet Registry (RIR) Comparative Policy Overview has been updated and is available on the Number Resource Organization (NRO) website at: http://www.nro.net/policy/index.html This document enables the community to review the policies in the global RIR system. To view specific policy statements from individual RIRs, please visit each RIR's policy pages: - AfriNIC http://www.afrinic.net/policy.htm - APNIC http://www.apnic.net/docs/policy/dev/index.html - ARIN http://www.arin.net/policy/index.html - LACNIC http://lacnic.net/en/politicas/index.html - RIPE NCC http://www.ripe.net/ripe/policies/ Regards, -- leo vegoda Registration Services Manager RIPE NCC From alh-ietf at tndh.net Sat Apr 8 01:57:21 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 7 Apr 2006 16:57:21 -0700 Subject: [address-policy-wg] RE: Question In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BE85@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <156901c65a9f$02dc74e0$de79df0a@tndh.net> A public answer to a private question as I have been sitting on a beach for awhile without the laptop and missed some related conversations ... :) > Is the outcome really open for discussion on the PI issue? It doesn't > sound like it is. In the minds of some the route scaling issue outweighs any argument for PI. When taken to its extreme, there is a valid point that a broken routing system serves no one. At the same time the dogmatic stance by the ISPs enforcing lock-in is just as broken both for large organizations with financial or legal requirements for operational stability, and the individual consumer/small business with limited budgets looking for true competition. The hard part is finding the middle ground in a way that limits the exposure to a potential routing collapse. I personally refuse to declare some needs legitimate and others not, as the only point of such differentiation is to establish a power broker. When all uses are legitimate, the problem boils down to the technical approach that can be scaled as necessary to contain growth in the routing system. This is the logic that leads me to the bit-interleaved geo that can be aggregated in varying size pockets as necessary using existing BGP deployments. We can start flat and implement aggregation over time when a region becomes too large to handle. One nice side effect of this geo approach is that it mitigates the continuing political demands for sovereign rights to IPv6 space. Any aggregation approach will force the business models to change from current practice. That is not as bad a thing as the alarmists will make it out to be, because their accountants are claiming the current model is a broken money looser as it is (which if so means they will eventually change anyway). The primary difference is that there will need to be aggregation intermediaries between the last-mile and transit providers. The current model eliminates these middle-men by trading off their routing mitigation service against a larger routing table (actually they already exist in the right places but are currently limited to layer2 media aggregators). The anti-PI bunch is trying to use social engineering to directly counter the bottom line business reality that the customer will always win in the end. Rather than accept this situation and constructively work on the necessary business model and technology developments, they effectively stall progress by staunchly claiming there is no acceptable technical approach that works within the current business structure. Making the RIRs be the police deciding who qualifies for PI and who does not just adds to their workload and raises costs. The beneficiaries of this gatekeeper approach are the ISPs that claim they need full routing knowledge everywhere, while the cost burden for supporting the waste-of-time qualification/evaluation work is borne by the applicant. Given that the most vocal and organized membership in the RIR community are the ISPs it is easy to understand why it would seem like the PI issue is already decided as closed. I tend to believe it will just drag out until enough of the corporate world becomes aware of the IPv4 exhaustion in light of their growth needs that they collectively appear at their RIR and demand an immediate solution. Unfortunately this 'wait till the last minute' tactic will likely result in a reactionary quickie with its own set of long term side effects. A while back I tried to hold a BOF on geo PI in the IETF, but was told that shim6 was the anointed solution. Now that at least nanog has told the IAB where to put shim6 it might be possible to get the current IESG to reconsider. In any case the result would be a technical approach that would still require RIRs to establish policies around. As long as they are dominated by the ISPs it will be difficult to get real PI. Tony From Jim.Bound at hp.com Sat Apr 8 14:52:19 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Sat, 8 Apr 2006 08:52:19 -0400 Subject: [address-policy-wg] RE: Question Message-ID: <936A4045C332714F975800409DE09240021C8CB7@tayexc14.americas.cpqcorp.net> Tony, Excellent response and educational for sure. It is my belief that the corporate business model today for operating networks may be broken and I think you supported that below? If not my apologies for bad parsing? Their models were fine for an IPv4 world where NAT was required and some even confuse NAT with securing ones network (and some programs in the U.S. Government) and that is simply bad policy and view. In the interim can this be resolved by RIRs creating some kind of additional wording that address reclaim will be done in manner that is negotiable, and do no harm to corporate or government business operations? This would buy us time to work on the issue and stop the FUD around this topic? Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and addressing you can lead as ajunct to one of our regular meetings you can lead for an entire day and we get the right players in the room. So think about that as another option too. But do enjoy the beach this thread does not have to be resolved this week :--) Really want to hear from all of you and discussion Terry D., Latif, Yanick, Dave G. Mike B. etc. Thanks /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf at tndh.net] > Sent: Friday, April 07, 2006 7:57 PM > To: 'PPML'; address-policy-wg at ripe.net > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New > Internet based on IPv6")'; 'Davis, Terry L'; > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > Michael P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > RDECOM CERDEC STCD SRI' > Subject: RE: Question > > A public answer to a private question as I have been sitting > on a beach for awhile without the laptop and missed some > related conversations ... :) > > > Is the outcome really open for discussion on the PI issue? > It doesn't > > sound like it is. > > In the minds of some the route scaling issue outweighs any > argument for PI. > When taken to its extreme, there is a valid point that a > broken routing system serves no one. At the same time the > dogmatic stance by the ISPs enforcing lock-in is just as > broken both for large organizations with financial or legal > requirements for operational stability, and the individual > consumer/small business with limited budgets looking for true > competition. The hard part is finding the middle ground in a > way that limits the exposure to a potential routing collapse. > > I personally refuse to declare some needs legitimate and > others not, as the only point of such differentiation is to > establish a power broker. When all uses are legitimate, the > problem boils down to the technical approach that can be > scaled as necessary to contain growth in the routing system. > This is the logic that leads me to the bit-interleaved geo > that can be aggregated in varying size pockets as necessary > using existing BGP deployments. We can start flat and > implement aggregation over time when a region becomes too > large to handle. One nice side effect of this geo approach is > that it mitigates the continuing political demands for > sovereign rights to IPv6 space. > > Any aggregation approach will force the business models to > change from current practice. That is not as bad a thing as > the alarmists will make it out to be, because their > accountants are claiming the current model is a broken money > looser as it is (which if so means they will eventually > change anyway). The primary difference is that there will > need to be aggregation intermediaries between the last-mile > and transit providers. The current model eliminates these > middle-men by trading off their routing mitigation service > against a larger routing table (actually they already exist > in the right places but are currently limited to layer2 media > aggregators). The anti-PI bunch is trying to use social > engineering to directly counter the bottom line business > reality that the customer will always win in the end. > Rather than accept this situation and constructively work on > the necessary business model and technology developments, > they effectively stall progress by staunchly claiming there > is no acceptable technical approach that works within the > current business structure. > > Making the RIRs be the police deciding who qualifies for PI > and who does not just adds to their workload and raises > costs. The beneficiaries of this gatekeeper approach are the > ISPs that claim they need full routing knowledge everywhere, > while the cost burden for supporting the waste-of-time > qualification/evaluation work is borne by the applicant. > Given that the most vocal and organized membership in the RIR > community are the ISPs it is easy to understand why it would > seem like the PI issue is already decided as closed. I tend > to believe it will just drag out until enough of the > corporate world becomes aware of the IPv4 exhaustion in light > of their growth needs that they collectively appear at their > RIR and demand an immediate solution. Unfortunately this > 'wait till the last minute' tactic will likely result in a > reactionary quickie with its own set of long term side effects. > > A while back I tried to hold a BOF on geo PI in the IETF, but > was told that > shim6 was the anointed solution. Now that at least nanog has > told the IAB where to put shim6 it might be possible to get > the current IESG to reconsider. In any case the result would > be a technical approach that would still require RIRs to > establish policies around. As long as they are dominated by > the ISPs it will be difficult to get real PI. > > Tony > > From latif.ladid at village.uunet.lu Sat Apr 8 15:52:56 2006 From: latif.ladid at village.uunet.lu (Latif Ladid ("The New Internet based on IPv6")) Date: Sat, 8 Apr 2006 15:52:56 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <936A4045C332714F975800409DE09240021C8CB7@tayexc14.americas.cpqcorp.net> Message-ID: <001e01c65b13$c472c540$8482fea9@ipv6forum> The technical community should fix this one before the ITU sees this as another chance to have a political say on the IPv6 addressing. These things leak fast. My advice is that ARIN should seriously own this issue before the ITU turns it to a sovereignty issue, which they could for sure win this time. I know one of their noodles is sizzling at it. Cheers Latif -----Original Message----- From: Bound, Jim [mailto:Jim.Bound at hp.com] Sent: 08 April 2006 14:52 To: Tony Hain; PPML; address-policy-wg at ripe.net Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI; Bound, Jim Subject: RE: Question Tony, Excellent response and educational for sure. It is my belief that the corporate business model today for operating networks may be broken and I think you supported that below? If not my apologies for bad parsing? Their models were fine for an IPv4 world where NAT was required and some even confuse NAT with securing ones network (and some programs in the U.S. Government) and that is simply bad policy and view. In the interim can this be resolved by RIRs creating some kind of additional wording that address reclaim will be done in manner that is negotiable, and do no harm to corporate or government business operations? This would buy us time to work on the issue and stop the FUD around this topic? Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and addressing you can lead as ajunct to one of our regular meetings you can lead for an entire day and we get the right players in the room. So think about that as another option too. But do enjoy the beach this thread does not have to be resolved this week :--) Really want to hear from all of you and discussion Terry D., Latif, Yanick, Dave G. Mike B. etc. Thanks /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf at tndh.net] > Sent: Friday, April 07, 2006 7:57 PM > To: 'PPML'; address-policy-wg at ripe.net > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New Internet > based on IPv6")'; 'Davis, Terry L'; ollivier.robert at eurocontrol.fr; > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, Yanick; > 'Green, David B RDECOM CERDEC STCD SRI' > Subject: RE: Question > > A public answer to a private question as I have been sitting on a > beach for awhile without the laptop and missed some related > conversations ... :) > > > Is the outcome really open for discussion on the PI issue? > It doesn't > > sound like it is. > > In the minds of some the route scaling issue outweighs any argument > for PI. > When taken to its extreme, there is a valid point that a broken > routing system serves no one. At the same time the dogmatic stance by > the ISPs enforcing lock-in is just as broken both for large > organizations with financial or legal requirements for operational > stability, and the individual consumer/small business with limited > budgets looking for true competition. The hard part is finding the > middle ground in a way that limits the exposure to a potential routing > collapse. > > I personally refuse to declare some needs legitimate and others not, > as the only point of such differentiation is to establish a power > broker. When all uses are legitimate, the problem boils down to the > technical approach that can be scaled as necessary to contain growth > in the routing system. > This is the logic that leads me to the bit-interleaved geo that can be > aggregated in varying size pockets as necessary using existing BGP > deployments. We can start flat and implement aggregation over time > when a region becomes too large to handle. One nice side effect of > this geo approach is that it mitigates the continuing political > demands for sovereign rights to IPv6 space. > > Any aggregation approach will force the business models to change from > current practice. That is not as bad a thing as the alarmists will > make it out to be, because their accountants are claiming the current > model is a broken money looser as it is (which if so means they will > eventually change anyway). The primary difference is that there will > need to be aggregation intermediaries between the last-mile and > transit providers. The current model eliminates these middle-men by > trading off their routing mitigation service against a larger routing > table (actually they already exist in the right places but are > currently limited to layer2 media aggregators). The anti-PI bunch is > trying to use social engineering to directly counter the bottom line > business reality that the customer will always win in the end. > Rather than accept this situation and constructively work on the > necessary business model and technology developments, they effectively > stall progress by staunchly claiming there is no acceptable technical > approach that works within the current business structure. > > Making the RIRs be the police deciding who qualifies for PI and who > does not just adds to their workload and raises costs. The > beneficiaries of this gatekeeper approach are the ISPs that claim they > need full routing knowledge everywhere, while the cost burden for > supporting the waste-of-time qualification/evaluation work is borne by > the applicant. > Given that the most vocal and organized membership in the RIR > community are the ISPs it is easy to understand why it would seem like > the PI issue is already decided as closed. I tend to believe it will > just drag out until enough of the corporate world becomes aware of the > IPv4 exhaustion in light of their growth needs that they collectively > appear at their RIR and demand an immediate solution. Unfortunately > this 'wait till the last minute' tactic will likely result in a > reactionary quickie with its own set of long term side effects. > > A while back I tried to hold a BOF on geo PI in the IETF, but was told > that > shim6 was the anointed solution. Now that at least nanog has told the > IAB where to put shim6 it might be possible to get the current IESG to > reconsider. In any case the result would be a technical approach that > would still require RIRs to establish policies around. As long as they > are dominated by the ISPs it will be difficult to get real PI. > > Tony > > From terry.l.davis at boeing.com Mon Apr 10 02:40:01 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Sun, 9 Apr 2006 17:40:01 -0700 Subject: [address-policy-wg] RE: Question In-Reply-To: <001e01c65b13$c472c540$8482fea9@ipv6forum> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BE91@XCH-NW-8V1.nw.nos.boeing.com> Latif The ITU is one of my top concerns also. I am hearing the same tune it sounds like you are; they are chomping at the bit to get a chance to step in and "save the Internet". I'll respond with some longer thoughts tomorrow. Between Tony's and Jim's last response, I have some thinking to do to see how it might be made to work technically and politically with some of the caveats they mention. One of my open thoughts, is if I have PA space, can I get somehow get routing service (multi-homing) from more than the single ISP that provided the addressing? Take care Terry > -----Original Message----- > From: Latif Ladid ("The New Internet based on IPv6") > [mailto:latif.ladid at village.uunet.lu] > Sent: Saturday, April 08, 2006 6:53 AM > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > Cc: 'Richard Jimmerson'; Davis, Terry L; ollivier.robert at eurocontrol.fr; > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; 'Pouffary, Yanick'; > 'Green, David B RDECOM CERDEC STCD SRI' > Subject: RE: Question > > > > The technical community should fix this one before the ITU sees this as > another chance to have a political say on the IPv6 addressing. These > things > leak fast. My advice is that ARIN should seriously own this issue before > the > ITU turns it to a sovereignty issue, which they could for sure win this > time. I know one of their noodles is sizzling at it. > > Cheers > Latif > > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound at hp.com] > Sent: 08 April 2006 14:52 > To: Tony Hain; PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; Brig, > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC > STCD SRI; Bound, Jim > Subject: RE: Question > > Tony, > > Excellent response and educational for sure. It is my belief that the > corporate business model today for operating networks may be broken and I > think you supported that below? If not my apologies for bad parsing? > > > Their models were fine for an IPv4 world where NAT was required and some > even confuse NAT with securing ones network (and some programs in the U.S. > Government) and that is simply bad policy and view. > > In the interim can this be resolved by RIRs creating some kind of > additional > wording that address reclaim will be done in manner that is negotiable, > and > do no harm to corporate or government business operations? This would buy > us time to work on the issue and stop the FUD around this topic? > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > addressing you can lead as ajunct to one of our regular meetings you can > lead for an entire day and we get the right players in the room. So think > about that as another option too. > > But do enjoy the beach this thread does not have to be resolved this week > :--) > > Really want to hear from all of you and discussion Terry D., Latif, Yanick, > Dave G. Mike B. etc. > > Thanks > /jim > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > Sent: Friday, April 07, 2006 7:57 PM > > To: 'PPML'; address-policy-wg at ripe.net > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New Internet > > based on IPv6")'; 'Davis, Terry L'; ollivier.robert at eurocontrol.fr; > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, Yanick; > > 'Green, David B RDECOM CERDEC STCD SRI' > > Subject: RE: Question > > > > A public answer to a private question as I have been sitting on a > > beach for awhile without the laptop and missed some related > > conversations ... :) > > > > > Is the outcome really open for discussion on the PI issue? > > It doesn't > > > sound like it is. > > > > In the minds of some the route scaling issue outweighs any argument > > for PI. > > When taken to its extreme, there is a valid point that a broken > > routing system serves no one. At the same time the dogmatic stance by > > the ISPs enforcing lock-in is just as broken both for large > > organizations with financial or legal requirements for operational > > stability, and the individual consumer/small business with limited > > budgets looking for true competition. The hard part is finding the > > middle ground in a way that limits the exposure to a potential routing > > collapse. > > > > I personally refuse to declare some needs legitimate and others not, > > as the only point of such differentiation is to establish a power > > broker. When all uses are legitimate, the problem boils down to the > > technical approach that can be scaled as necessary to contain growth > > in the routing system. > > This is the logic that leads me to the bit-interleaved geo that can be > > aggregated in varying size pockets as necessary using existing BGP > > deployments. We can start flat and implement aggregation over time > > when a region becomes too large to handle. One nice side effect of > > this geo approach is that it mitigates the continuing political > > demands for sovereign rights to IPv6 space. > > > > Any aggregation approach will force the business models to change from > > current practice. That is not as bad a thing as the alarmists will > > make it out to be, because their accountants are claiming the current > > model is a broken money looser as it is (which if so means they will > > eventually change anyway). The primary difference is that there will > > need to be aggregation intermediaries between the last-mile and > > transit providers. The current model eliminates these middle-men by > > trading off their routing mitigation service against a larger routing > > table (actually they already exist in the right places but are > > currently limited to layer2 media aggregators). The anti-PI bunch is > > trying to use social engineering to directly counter the bottom line > > business reality that the customer will always win in the end. > > Rather than accept this situation and constructively work on the > > necessary business model and technology developments, they effectively > > stall progress by staunchly claiming there is no acceptable technical > > approach that works within the current business structure. > > > > Making the RIRs be the police deciding who qualifies for PI and who > > does not just adds to their workload and raises costs. The > > beneficiaries of this gatekeeper approach are the ISPs that claim they > > need full routing knowledge everywhere, while the cost burden for > > supporting the waste-of-time qualification/evaluation work is borne by > > the applicant. > > Given that the most vocal and organized membership in the RIR > > community are the ISPs it is easy to understand why it would seem like > > the PI issue is already decided as closed. I tend to believe it will > > just drag out until enough of the corporate world becomes aware of the > > IPv4 exhaustion in light of their growth needs that they collectively > > appear at their RIR and demand an immediate solution. Unfortunately > > this 'wait till the last minute' tactic will likely result in a > > reactionary quickie with its own set of long term side effects. > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was told > > that > > shim6 was the anointed solution. Now that at least nanog has told the > > IAB where to put shim6 it might be possible to get the current IESG to > > reconsider. In any case the result would be a technical approach that > > would still require RIRs to establish policies around. As long as they > > are dominated by the ISPs it will be difficult to get real PI. > > > > Tony > > > > From Jim.Bound at hp.com Mon Apr 10 04:11:42 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Sun, 9 Apr 2006 22:11:42 -0400 Subject: [address-policy-wg] RE: Question Message-ID: <936A4045C332714F975800409DE09240021C8DC5@tayexc14.americas.cpqcorp.net> Terry, SLAs can be set up to route multihoming and should work for high-order prefixes. See below URL RFC 3178. ftp://ftp.rfc-editor.org/in-notes/rfc3178.txt Also all see attached allocations data from Mike Brig long time IPv6 Forum and NAv6TF SME, actually working with ARIN now on address space for his day job. Mike this is very good. /jim > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > Sent: Sunday, April 09, 2006 8:40 PM > To: Latif Ladid ("The New Internet based on IPv6"); Bound, > Jim; Tony Hain; PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; ollivier.robert at eurocontrol.fr; > narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; Pouffary, > Yanick; Green, David B RDECOM CERDEC STCD SRI > Subject: RE: Question > > Latif > > The ITU is one of my top concerns also. I am hearing the > same tune it sounds like you are; they are chomping at the > bit to get a chance to step in and "save the Internet". > > I'll respond with some longer thoughts tomorrow. Between > Tony's and Jim's last response, I have some thinking to do to > see how it might be made to work technically and politically > with some of the caveats they mention. > > One of my open thoughts, is if I have PA space, can I get > somehow get routing service (multi-homing) from more than the > single ISP that provided the addressing? > > Take care > Terry > > > -----Original Message----- > > From: Latif Ladid ("The New Internet based on IPv6") > > [mailto:latif.ladid at village.uunet.lu] > > Sent: Saturday, April 08, 2006 6:53 AM > > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > Cc: 'Richard Jimmerson'; Davis, Terry L; > ollivier.robert at eurocontrol.fr; > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; 'Pouffary, > Yanick'; > > 'Green, David B RDECOM CERDEC STCD SRI' > > Subject: RE: Question > > > > > > > > The technical community should fix this one before the ITU sees this > as > > another chance to have a political say on the IPv6 > addressing. These > > things leak fast. My advice is that ARIN should seriously own this > > issue > before > > the > > ITU turns it to a sovereignty issue, which they could for sure win > this > > time. I know one of their noodles is sizzling at it. > > > > Cheers > > Latif > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > Sent: 08 April 2006 14:52 > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); > > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > Brig, > > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > CERDEC > > STCD SRI; Bound, Jim > > Subject: RE: Question > > > > Tony, > > > > Excellent response and educational for sure. It is my > belief that the > > corporate business model today for operating networks may be broken > and I > > think you supported that below? If not my apologies for > bad parsing? > > > > > > Their models were fine for an IPv4 world where NAT was required and > some > > even confuse NAT with securing ones network (and some > programs in the > U.S. > > Government) and that is simply bad policy and view. > > > > In the interim can this be resolved by RIRs creating some kind of > > additional wording that address reclaim will be done in > manner that is > negotiable, > > and > > do no harm to corporate or government business operations? > This would > buy > > us time to work on the issue and stop the FUD around this topic? > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > addressing you can lead as ajunct to one of our regular meetings you > can > > lead for an entire day and we get the right players in the room. So > think > > about that as another option too. > > > > But do enjoy the beach this thread does not have to be resolved this > week > > :--) > > > > Really want to hear from all of you and discussion Terry D., Latif, > Yanick, > > Dave G. Mike B. etc. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > Sent: Friday, April 07, 2006 7:57 PM > > > To: 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > New Internet > > > based on IPv6")'; 'Davis, Terry L'; > ollivier.robert at eurocontrol.fr; > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > Yanick; > > > 'Green, David B RDECOM CERDEC STCD SRI' > > > Subject: RE: Question > > > > > > A public answer to a private question as I have been sitting on a > > > beach for awhile without the laptop and missed some related > > > conversations ... :) > > > > > > > Is the outcome really open for discussion on the PI issue? > > > It doesn't > > > > sound like it is. > > > > > > In the minds of some the route scaling issue outweighs > any argument > > > for PI. > > > When taken to its extreme, there is a valid point that a broken > > > routing system serves no one. At the same time the dogmatic stance > by > > > the ISPs enforcing lock-in is just as broken both for large > > > organizations with financial or legal requirements for > operational > > > stability, and the individual consumer/small business > with limited > > > budgets looking for true competition. The hard part is > finding the > > > middle ground in a way that limits the exposure to a potential > routing > > > collapse. > > > > > > I personally refuse to declare some needs legitimate and > others not, > > > as the only point of such differentiation is to establish a power > > > broker. When all uses are legitimate, the problem boils > down to the > > > technical approach that can be scaled as necessary to > contain growth > > > in the routing system. > > > This is the logic that leads me to the bit-interleaved > geo that can > be > > > aggregated in varying size pockets as necessary using > existing BGP > > > deployments. We can start flat and implement aggregation > over time > > > when a region becomes too large to handle. One nice side > effect of > > > this geo approach is that it mitigates the continuing political > > > demands for sovereign rights to IPv6 space. > > > > > > Any aggregation approach will force the business models to change > from > > > current practice. That is not as bad a thing as the > alarmists will > > > make it out to be, because their accountants are claiming the > current > > > model is a broken money looser as it is (which if so > means they will > > > eventually change anyway). The primary difference is that > there will > > > need to be aggregation intermediaries between the last-mile and > > > transit providers. The current model eliminates these > middle-men by > > > trading off their routing mitigation service against a larger > routing > > > table (actually they already exist in the right places but are > > > currently limited to layer2 media aggregators). The > anti-PI bunch is > > > trying to use social engineering to directly counter the > bottom line > > > business reality that the customer will always win in the end. > > > Rather than accept this situation and constructively work on the > > > necessary business model and technology developments, they > effectively > > > stall progress by staunchly claiming there is no acceptable > technical > > > approach that works within the current business structure. > > > > > > Making the RIRs be the police deciding who qualifies for > PI and who > > > does not just adds to their workload and raises costs. The > > > beneficiaries of this gatekeeper approach are the ISPs that claim > they > > > need full routing knowledge everywhere, while the cost burden for > > > supporting the waste-of-time qualification/evaluation > work is borne > by > > > the applicant. > > > Given that the most vocal and organized membership in the RIR > > > community are the ISPs it is easy to understand why it would seem > like > > > the PI issue is already decided as closed. I tend to > believe it will > > > just drag out until enough of the corporate world becomes aware of > the > > > IPv4 exhaustion in light of their growth needs that they > collectively > > > appear at their RIR and demand an immediate solution. > Unfortunately > > > this 'wait till the last minute' tactic will likely result in a > > > reactionary quickie with its own set of long term side effects. > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > told > > > that > > > shim6 was the anointed solution. Now that at least nanog has told > the > > > IAB where to put shim6 it might be possible to get the > current IESG > to > > > reconsider. In any case the result would be a technical approach > that > > > would still require RIRs to establish policies around. As long as > they > > > are dominated by the ISPs it will be difficult to get real PI. > > > > > > Tony > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: RIR IPv6 Allocations to March 31 2006.xls Type: application/vnd.ms-excel Size: 2187776 bytes Desc: RIR IPv6 Allocations to March 31 2006.xls URL: From ncc at ripe.net Mon Apr 10 11:07:44 2006 From: ncc at ripe.net (Paul Rendek) Date: Mon, 10 Apr 2006 11:07:44 +0200 Subject: [address-policy-wg] ASO Candidates for ICANN Board Announced: Open Call for Statements of Support Message-ID: <5.2.1.1.2.20060410110545.01df8398@mailhost.ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The Address Supporting Organization (ASO) Address Council has announced details of the candidates to fill its seat on the ICANN Board of Directors. You can find the announcement, the list of candidates, and details on how to submit statements of support at: http://aso.icann.org/ Regards, Paul Rendek Head of Member Services and Communications RIPE NCC From plzak at arin.net Mon Apr 10 12:55:56 2006 From: plzak at arin.net (Ray Plzak) Date: Mon, 10 Apr 2006 06:55:56 -0400 Subject: [address-policy-wg] RE: Question In-Reply-To: <001e01c65b13$c472c540$8482fea9@ipv6forum> Message-ID: <20060410105557.ECE551FFAC@mercury.arin.net> The NAv6TF is in the ARIN region. If individuals associated with it think that ARIN should adopt a policy or change an existing policy they should not only say so they should propose such a policy. Remember policies in the ARIN region, like in all of the RIRs is made not by the RIR organization staff and board but by the community in the region. ARIN staff will be more than happy to help anyone through the process, which by the way, while an orderly and formal process is not onerous, but one designed to provide for an open and honest discussion of any policy proposal before it is adopted. If you are interested in pursuing this, please contact me and I will get a staff member to assist you. Ray > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Latif Ladid ("The New Internet based on > IPv6") > Sent: Saturday, April 08, 2006 9:53 AM > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; ollivier.robert at eurocontrol.fr; > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; 'Pouffary, Yanick'; > 'Green, David B RDECOM CERDEC STCD SRI' > Subject: [address-policy-wg] RE: Question > > > > The technical community should fix this one before the ITU sees this as > another chance to have a political say on the IPv6 addressing. These > things > leak fast. My advice is that ARIN should seriously own this issue before > the > ITU turns it to a sovereignty issue, which they could for sure win this > time. I know one of their noodles is sizzling at it. > > Cheers > Latif > > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound at hp.com] > Sent: 08 April 2006 14:52 > To: Tony Hain; PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; Brig, > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC > STCD SRI; Bound, Jim > Subject: RE: Question > > Tony, > > Excellent response and educational for sure. It is my belief that the > corporate business model today for operating networks may be broken and I > think you supported that below? If not my apologies for bad parsing? > > > Their models were fine for an IPv4 world where NAT was required and some > even confuse NAT with securing ones network (and some programs in the U.S. > Government) and that is simply bad policy and view. > > In the interim can this be resolved by RIRs creating some kind of > additional > wording that address reclaim will be done in manner that is negotiable, > and > do no harm to corporate or government business operations? This would buy > us time to work on the issue and stop the FUD around this topic? > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > addressing you can lead as ajunct to one of our regular meetings you can > lead for an entire day and we get the right players in the room. So think > about that as another option too. > > But do enjoy the beach this thread does not have to be resolved this week > :--) > > Really want to hear from all of you and discussion Terry D., Latif, > Yanick, > Dave G. Mike B. etc. > > Thanks > /jim > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > Sent: Friday, April 07, 2006 7:57 PM > > To: 'PPML'; address-policy-wg at ripe.net > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New Internet > > based on IPv6")'; 'Davis, Terry L'; ollivier.robert at eurocontrol.fr; > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, Yanick; > > 'Green, David B RDECOM CERDEC STCD SRI' > > Subject: RE: Question > > > > A public answer to a private question as I have been sitting on a > > beach for awhile without the laptop and missed some related > > conversations ... :) > > > > > Is the outcome really open for discussion on the PI issue? > > It doesn't > > > sound like it is. > > > > In the minds of some the route scaling issue outweighs any argument > > for PI. > > When taken to its extreme, there is a valid point that a broken > > routing system serves no one. At the same time the dogmatic stance by > > the ISPs enforcing lock-in is just as broken both for large > > organizations with financial or legal requirements for operational > > stability, and the individual consumer/small business with limited > > budgets looking for true competition. The hard part is finding the > > middle ground in a way that limits the exposure to a potential routing > > collapse. > > > > I personally refuse to declare some needs legitimate and others not, > > as the only point of such differentiation is to establish a power > > broker. When all uses are legitimate, the problem boils down to the > > technical approach that can be scaled as necessary to contain growth > > in the routing system. > > This is the logic that leads me to the bit-interleaved geo that can be > > aggregated in varying size pockets as necessary using existing BGP > > deployments. We can start flat and implement aggregation over time > > when a region becomes too large to handle. One nice side effect of > > this geo approach is that it mitigates the continuing political > > demands for sovereign rights to IPv6 space. > > > > Any aggregation approach will force the business models to change from > > current practice. That is not as bad a thing as the alarmists will > > make it out to be, because their accountants are claiming the current > > model is a broken money looser as it is (which if so means they will > > eventually change anyway). The primary difference is that there will > > need to be aggregation intermediaries between the last-mile and > > transit providers. The current model eliminates these middle-men by > > trading off their routing mitigation service against a larger routing > > table (actually they already exist in the right places but are > > currently limited to layer2 media aggregators). The anti-PI bunch is > > trying to use social engineering to directly counter the bottom line > > business reality that the customer will always win in the end. > > Rather than accept this situation and constructively work on the > > necessary business model and technology developments, they effectively > > stall progress by staunchly claiming there is no acceptable technical > > approach that works within the current business structure. > > > > Making the RIRs be the police deciding who qualifies for PI and who > > does not just adds to their workload and raises costs. The > > beneficiaries of this gatekeeper approach are the ISPs that claim they > > need full routing knowledge everywhere, while the cost burden for > > supporting the waste-of-time qualification/evaluation work is borne by > > the applicant. > > Given that the most vocal and organized membership in the RIR > > community are the ISPs it is easy to understand why it would seem like > > the PI issue is already decided as closed. I tend to believe it will > > just drag out until enough of the corporate world becomes aware of the > > IPv4 exhaustion in light of their growth needs that they collectively > > appear at their RIR and demand an immediate solution. Unfortunately > > this 'wait till the last minute' tactic will likely result in a > > reactionary quickie with its own set of long term side effects. > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was told > > that > > shim6 was the anointed solution. Now that at least nanog has told the > > IAB where to put shim6 it might be possible to get the current IESG to > > reconsider. In any case the result would be a technical approach that > > would still require RIRs to establish policies around. As long as they > > are dominated by the ISPs it will be difficult to get real PI. > > > > Tony > > > > From heldal at eml.cc Mon Apr 10 13:52:52 2006 From: heldal at eml.cc (Per Heldal) Date: Mon, 10 Apr 2006 13:52:52 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <001e01c65b13$c472c540$8482fea9@ipv6forum> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> Message-ID: <1144669972.7517.258725818@webmail.messagingengine.com> On Sat, 8 Apr 2006 15:52:56 +0200, "Latif Ladid (The New Internet based on IPv6)" said: > The technical community should fix this one before the ITU sees this as > another chance to have a political say on the IPv6 addressing. These > things > leak fast. My advice is that ARIN should seriously own this issue before > the > ITU turns it to a sovereignty issue, which they could for sure win this > time. I know one of their noodles is sizzling at it. ARIN, and all the other RIRs, represent the interests of people in their region. Anybody who is interested, yourself included, is welcome to suggest changes to current policies. I'm sure RIR-staff are happy to guide you through the process. However, to succeed you need to convince the RIR community that there is a need for a change. It's interesting to see how people are worried about ITU involvement. I share some concerns, but remember; the ITU and their OSI protocols were once at the core of everything in large-scale networking. Those were left behind because they were not flexible enough to keep up with the pace of internet growth in the '90s. ITU as an organization is just as inflexible today as they were 10 or 15 years ago, maybe even worse. To consider ITU a threat to the internet community speaks heaps about how the community has deteriorated over the last decade. Parts of the community are already mirroring ITU behaviour, with or without ITU-involvement. //per -- Per Heldal http://heldal.eml.cc/ From terry.l.davis at boeing.com Mon Apr 10 22:12:38 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 10 Apr 2006 13:12:38 -0700 Subject: [address-policy-wg] RE: Question - Aviation In-Reply-To: <936A4045C332714F975800409DE09240021C8CB7@tayexc14.americas.cpqcorp.net> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BEA5@XCH-NW-8V1.nw.nos.boeing.com> Jim/All I am going to respond in two parts here on PI issues; one in terms of aviation and one in terms of corporate. This one is on aviation. The next two paragraphs are from an original response to Thomas Narten, that I didn't see make the list. ---- I view systems that run "critical infrastructure" entirely different from those used to run anything else; especially systems that can directly impact the safety of the people using or relying on them. Safety engineering is just like security engineering; both depend on our ability to build in layers of defense and reliability trying to never rely entirely on a single system. By forcing an industry like aviation to accept the potential of address changing in a global fleet, an element of extreme risk is added as the system's overall reliability is decreased. ---- We know that in the next decade that there will be development initiated for a new air traffic control system. It will likely be built upon IP and if so, likely IP-v6. And ICAO currently has a working group studying this and the committee is leaning towards IP-v6 although there is a strong component that is pushing for IP-v4 and a continuation the NAT type usage currently required in the aviation industry by Arinc 664. And I do definitely agree with Jim here, the use IP-v4 and NAT would create huge risks; if in nothing else, the potential for mis-addressing through one of the hundreds of NAT gateways that would be required. I'll respectfully disagree with Jim in that I believe address change in a complex global system like air traffic control can create a hazard. Keep in mind, that the air traffic control system spans virtually every nation on globe and most everything manmade that flies. Likewise the technical and operational capabilities vary from extraordinary to very minimal; like the 30 or so aviation operators that the EU just banned from flying into EU countries because of their poor safety and maintenance performance record. Coordinating an address change across this type of infrastructure with aircraft and ground infrastructure in almost every nation on the globe, is simply beyond my ability comprehend. Assuming the technology would work flawlessly (discussed below), the politics of when and how to implement the change would likely end up on the floor of the UN for debate. Likewise, if a decision was made to implement a change, we would be dealing with such different levels of expertise around the world that no amount of pre-planning could ensure that implementation failures would not occur. Now just a bit about where ATC systems are likely going and why their criticality will likely grow over the next couple decades. Unless we suddenly develop anti-gravity capabilities to allow slow vertical takeoffs, we are stuck with the airports we have and only minimal abilities to expand them (cost, environmental, noise, etc). The only real way we can expand their capacity is with bigger airplanes and more flights. The "more flights" part is where this gets complicated and critical. To handle more flights, we have to decrease landing and takeoff separations and speed up aircraft ground movements so an airport can handle more aircraft per hour. We are about to human capacity with the current systems which means that these improvements will need to move more and more to relying on precise control systems; a minutes interruption here will be a really big deal. Also we as an industry are just beginning to migrate from bus data communications on the aircraft to networks. The commercial aircraft flying today are already largely computer controlled and as I mentioned above we try very hard not design the aircraft to be critically reliant on any one system. In almost all cases, it requires a cascading series of failures to present an aircraft with a catastrophic hazard. Now as I said, we are starting to put networks on the aircraft and as Arinc 664 shows; we are not the world's greatest network engineers (at least not yet..). In a decade or so, we will have hundreds of networked systems on an aircraft. I think the risk here in re-addressing is clear; how well will they all react. And yes we can probably take most of the risk down in certification testing but keep in mind variation in technical competence of the operators around the world and that we are continually accepting upgraded systems from our vendors as replacement parts and this could also inject potential failures in re-addressing. If we were to use 3178 without a single global address space, I still don't think this would scale as we then would be using probably in the neighborhood of 50 or more ISP's (you don't always get to pick your ISP's and while a country might accept addressing from an industry block, they'd probably insist on using theirs otherwise) around the world for the service. And the way I read it, I would still have lots of unnecessary backhauling to the other side of the planet and some very complicated policy routing to set up. Besides and then with mix of address spaces, I would probably be perpetually leaking with the global Internet in what should be a closed network. Finally at the moment with our existing certification processes, I'm not sure that we would even be permitted to change the aircraft addresses without re-issuing all the affected software with new part numbers. (I'll bet you assumed we used DHCP to address the current aircraft; nope we hard code address everything, remember "bus engineering" 101 ;-) With today's current rules, we haven't put any "critical systems" on anything but a closed onboard network. We are just discussing the ability upload new IP_tables/firewall-rules and authentication certs/passwords to the non-critical networks and I believe that this will be solved in the next couple years. And now also keep in mind that every aviation rule-making body around the world would also have to approve of the address change for an ATC network and define how they were going to certify the change. ====================================================================== Finally now having said all this Jim, I think it is possible for aviation to remain conforming. We have probably only two primary needs for stable IP addressed networks; one for Air Traffic Control and one for Airline Operations. These are industry traffic type designations that have safety related functions that are carried out over them. As we have discussed before, I expect both of them to be run as "closed networks" and should never (IMHO) be seen in the global routing tables; a closed network will provide them with a layer of security, better routing performance, the multi-homing that an aircraft needs, and more options for mobility solutions. Further, two organizations already exist that could legitimately hold the addresses; ICAO for the ATC network as they already govern it and the AEEC for "airline operations" whose members already essentially own "Arinc" which is an ISP already. If it were possible to convince these orgs, to apply for space and the registries to grant them, that would seem to be a solution. Take care Terry PS: Apologies for the length.. PSS: Back to "critical infrastructure" networks a moment, I'd say that any network that wanted to declare itself "critical infrastructure" could obtain PI space, BUT to me this type of network should always be run as a "closed network" with exchanges to the Internet only through "mediation gateways" operating at the application level, not at the routing level. Just food for thought but perhaps there is a class of IP-v6 networks for "critical infrastructure" that have their own PI space, but are prohibited from the participating in "Internet routing". Such a concept might solve lots of problems. > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound at hp.com] > Sent: Saturday, April 08, 2006 5:52 AM > To: Tony Hain; PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; Brig, > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC > STCD SRI; Bound, Jim > Subject: RE: Question > > Tony, > > Excellent response and educational for sure. It is my belief that the > corporate business model today for operating networks may be broken and > I think you supported that below? If not my apologies for bad parsing? > > > Their models were fine for an IPv4 world where NAT was required and some > even confuse NAT with securing ones network (and some programs in the > U.S. Government) and that is simply bad policy and view. > > In the interim can this be resolved by RIRs creating some kind of > additional wording that address reclaim will be done in manner that is > negotiable, and do no harm to corporate or government business > operations? This would buy us time to work on the issue and stop the > FUD around this topic? > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > addressing you can lead as ajunct to one of our regular meetings you can > lead for an entire day and we get the right players in the room. So > think about that as another option too. > > But do enjoy the beach this thread does not have to be resolved this > week :--) > > Really want to hear from all of you and discussion Terry D., Latif, > Yanick, Dave G. Mike B. etc. > > Thanks > /jim > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > Sent: Friday, April 07, 2006 7:57 PM > > To: 'PPML'; address-policy-wg at ripe.net > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New > > Internet based on IPv6")'; 'Davis, Terry L'; > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > > Michael P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > > RDECOM CERDEC STCD SRI' > > Subject: RE: Question > > > > A public answer to a private question as I have been sitting > > on a beach for awhile without the laptop and missed some > > related conversations ... :) > > > > > Is the outcome really open for discussion on the PI issue? > > It doesn't > > > sound like it is. > > > > In the minds of some the route scaling issue outweighs any > > argument for PI. > > When taken to its extreme, there is a valid point that a > > broken routing system serves no one. At the same time the > > dogmatic stance by the ISPs enforcing lock-in is just as > > broken both for large organizations with financial or legal > > requirements for operational stability, and the individual > > consumer/small business with limited budgets looking for true > > competition. The hard part is finding the middle ground in a > > way that limits the exposure to a potential routing collapse. > > > > I personally refuse to declare some needs legitimate and > > others not, as the only point of such differentiation is to > > establish a power broker. When all uses are legitimate, the > > problem boils down to the technical approach that can be > > scaled as necessary to contain growth in the routing system. > > This is the logic that leads me to the bit-interleaved geo > > that can be aggregated in varying size pockets as necessary > > using existing BGP deployments. We can start flat and > > implement aggregation over time when a region becomes too > > large to handle. One nice side effect of this geo approach is > > that it mitigates the continuing political demands for > > sovereign rights to IPv6 space. > > > > Any aggregation approach will force the business models to > > change from current practice. That is not as bad a thing as > > the alarmists will make it out to be, because their > > accountants are claiming the current model is a broken money > > looser as it is (which if so means they will eventually > > change anyway). The primary difference is that there will > > need to be aggregation intermediaries between the last-mile > > and transit providers. The current model eliminates these > > middle-men by trading off their routing mitigation service > > against a larger routing table (actually they already exist > > in the right places but are currently limited to layer2 media > > aggregators). The anti-PI bunch is trying to use social > > engineering to directly counter the bottom line business > > reality that the customer will always win in the end. > > Rather than accept this situation and constructively work on > > the necessary business model and technology developments, > > they effectively stall progress by staunchly claiming there > > is no acceptable technical approach that works within the > > current business structure. > > > > Making the RIRs be the police deciding who qualifies for PI > > and who does not just adds to their workload and raises > > costs. The beneficiaries of this gatekeeper approach are the > > ISPs that claim they need full routing knowledge everywhere, > > while the cost burden for supporting the waste-of-time > > qualification/evaluation work is borne by the applicant. > > Given that the most vocal and organized membership in the RIR > > community are the ISPs it is easy to understand why it would > > seem like the PI issue is already decided as closed. I tend > > to believe it will just drag out until enough of the > > corporate world becomes aware of the IPv4 exhaustion in light > > of their growth needs that they collectively appear at their > > RIR and demand an immediate solution. Unfortunately this > > 'wait till the last minute' tactic will likely result in a > > reactionary quickie with its own set of long term side effects. > > > > A while back I tried to hold a BOF on geo PI in the IETF, but > > was told that > > shim6 was the anointed solution. Now that at least nanog has > > told the IAB where to put shim6 it might be possible to get > > the current IESG to reconsider. In any case the result would > > be a technical approach that would still require RIRs to > > establish policies around. As long as they are dominated by > > the ISPs it will be difficult to get real PI. > > > > Tony > > > > From eivan.cerasi at eurocontrol.int Tue Apr 11 14:33:47 2006 From: eivan.cerasi at eurocontrol.int (CERASI Eivan) Date: Tue, 11 Apr 2006 14:33:47 +0200 Subject: [address-policy-wg] RE: Question - Aviation Message-ID: <65758C24A8772B49B2DE38D6F8B3D792A2BA09@HHBRUE004.hq.corp.eurocontrol.int> Hello just to give you some status/complement on what we are doing in Europe for air traffic management. EUROCONTROL (a European organization dealing with the safety of air navigation) has become LIR to obtain a /32. We have started using this address space for ground air traffic control unicast applications but take-up is slow due to the nature of our environment. With regard to air-ground applications, we have launched studies for a more global approach vis-?-vis air/ground applications and this is being performed in collaboration with ICAO working groups. Of course our primary goal is to enable an IP service for air traffic control communications, not passenger nor airline communications. As our environment is highly conservative, technology changes are very slow especially if they have to be global. Our European strategy is that IPv6 is our final target for all communications but our X.25 will still be around for another few years and our IPv4 for even more. It is correct to state that our safety critical applications operate in a closed environment as opposed to the use of classical internet services. However we do have exchanges with internet customers (airlines) via dedicated means. Clearly, both IP routing environments are isolated from each other. To come back on one of the points that was raised below, I do not see the benefit of creating a dedicated address space for such type of applications (just as RFC1918 provides private address space for IPv4). For me, it would just increase the end-user perceived complexity of IPv6. In doing so, you would already cause us a problem of having to change something we have already put into operations ! Best regards Eivan Cerasi -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Davis, Terry L Sent: Monday 10 April 2006 22:13 To: Bound, Jim; Tony Hain; PPML; address-policy-wg at ripe.net Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI Subject: [address-policy-wg] RE: Question - Aviation Jim/All I am going to respond in two parts here on PI issues; one in terms of aviation and one in terms of corporate. This one is on aviation. The next two paragraphs are from an original response to Thomas Narten, that I didn't see make the list. ---- I view systems that run "critical infrastructure" entirely different from those used to run anything else; especially systems that can directly impact the safety of the people using or relying on them. Safety engineering is just like security engineering; both depend on our ability to build in layers of defense and reliability trying to never rely entirely on a single system. By forcing an industry like aviation to accept the potential of address changing in a global fleet, an element of extreme risk is added as the system's overall reliability is decreased. ---- We know that in the next decade that there will be development initiated for a new air traffic control system. It will likely be built upon IP and if so, likely IP-v6. And ICAO currently has a working group studying this and the committee is leaning towards IP-v6 although there is a strong component that is pushing for IP-v4 and a continuation the NAT type usage currently required in the aviation industry by Arinc 664. And I do definitely agree with Jim here, the use IP-v4 and NAT would create huge risks; if in nothing else, the potential for mis-addressing through one of the hundreds of NAT gateways that would be required. I'll respectfully disagree with Jim in that I believe address change in a complex global system like air traffic control can create a hazard. Keep in mind, that the air traffic control system spans virtually every nation on globe and most everything manmade that flies. Likewise the technical and operational capabilities vary from extraordinary to very minimal; like the 30 or so aviation operators that the EU just banned from flying into EU countries because of their poor safety and maintenance performance record. Coordinating an address change across this type of infrastructure with aircraft and ground infrastructure in almost every nation on the globe, is simply beyond my ability comprehend. Assuming the technology would work flawlessly (discussed below), the politics of when and how to implement the change would likely end up on the floor of the UN for debate. Likewise, if a decision was made to implement a change, we would be dealing with such different levels of expertise around the world that no amount of pre-planning could ensure that implementation failures would not occur. Now just a bit about where ATC systems are likely going and why their criticality will likely grow over the next couple decades. Unless we suddenly develop anti-gravity capabilities to allow slow vertical takeoffs, we are stuck with the airports we have and only minimal abilities to expand them (cost, environmental, noise, etc). The only real way we can expand their capacity is with bigger airplanes and more flights. The "more flights" part is where this gets complicated and critical. To handle more flights, we have to decrease landing and takeoff separations and speed up aircraft ground movements so an airport can handle more aircraft per hour. We are about to human capacity with the current systems which means that these improvements will need to move more and more to relying on precise control systems; a minutes interruption here will be a really big deal. Also we as an industry are just beginning to migrate from bus data communications on the aircraft to networks. The commercial aircraft flying today are already largely computer controlled and as I mentioned above we try very hard not design the aircraft to be critically reliant on any one system. In almost all cases, it requires a cascading series of failures to present an aircraft with a catastrophic hazard. Now as I said, we are starting to put networks on the aircraft and as Arinc 664 shows; we are not the world's greatest network engineers (at least not yet..). In a decade or so, we will have hundreds of networked systems on an aircraft. I think the risk here in re-addressing is clear; how well will they all react. And yes we can probably take most of the risk down in certification testing but keep in mind variation in technical competence of the operators around the world and that we are continually accepting upgraded systems from our vendors as replacement parts and this could also inject potential failures in re-addressing. If we were to use 3178 without a single global address space, I still don't think this would scale as we then would be using probably in the neighborhood of 50 or more ISP's (you don't always get to pick your ISP's and while a country might accept addressing from an industry block, they'd probably insist on using theirs otherwise) around the world for the service. And the way I read it, I would still have lots of unnecessary backhauling to the other side of the planet and some very complicated policy routing to set up. Besides and then with mix of address spaces, I would probably be perpetually leaking with the global Internet in what should be a closed network. Finally at the moment with our existing certification processes, I'm not sure that we would even be permitted to change the aircraft addresses without re-issuing all the affected software with new part numbers. (I'll bet you assumed we used DHCP to address the current aircraft; nope we hard code address everything, remember "bus engineering" 101 ;-) With today's current rules, we haven't put any "critical systems" on anything but a closed onboard network. We are just discussing the ability upload new IP_tables/firewall-rules and authentication certs/passwords to the non-critical networks and I believe that this will be solved in the next couple years. And now also keep in mind that every aviation rule-making body around the world would also have to approve of the address change for an ATC network and define how they were going to certify the change. ====================================================================== Finally now having said all this Jim, I think it is possible for aviation to remain conforming. We have probably only two primary needs for stable IP addressed networks; one for Air Traffic Control and one for Airline Operations. These are industry traffic type designations that have safety related functions that are carried out over them. As we have discussed before, I expect both of them to be run as "closed networks" and should never (IMHO) be seen in the global routing tables; a closed network will provide them with a layer of security, better routing performance, the multi-homing that an aircraft needs, and more options for mobility solutions. Further, two organizations already exist that could legitimately hold the addresses; ICAO for the ATC network as they already govern it and the AEEC for "airline operations" whose members already essentially own "Arinc" which is an ISP already. If it were possible to convince these orgs, to apply for space and the registries to grant them, that would seem to be a solution. Take care Terry PS: Apologies for the length.. PSS: Back to "critical infrastructure" networks a moment, I'd say that any network that wanted to declare itself "critical infrastructure" could obtain PI space, BUT to me this type of network should always be run as a "closed network" with exchanges to the Internet only through "mediation gateways" operating at the application level, not at the routing level. Just food for thought but perhaps there is a class of IP-v6 networks for "critical infrastructure" that have their own PI space, but are prohibited from the participating in "Internet routing". Such a concept might solve lots of problems. > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound at hp.com] > Sent: Saturday, April 08, 2006 5:52 AM > To: Tony Hain; PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; Brig, > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC > STCD SRI; Bound, Jim > Subject: RE: Question > > Tony, > > Excellent response and educational for sure. It is my belief that the > corporate business model today for operating networks may be broken and > I think you supported that below? If not my apologies for bad parsing? > > > Their models were fine for an IPv4 world where NAT was required and some > even confuse NAT with securing ones network (and some programs in the > U.S. Government) and that is simply bad policy and view. > > In the interim can this be resolved by RIRs creating some kind of > additional wording that address reclaim will be done in manner that is > negotiable, and do no harm to corporate or government business > operations? This would buy us time to work on the issue and stop the > FUD around this topic? > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > addressing you can lead as ajunct to one of our regular meetings you can > lead for an entire day and we get the right players in the room. So > think about that as another option too. > > But do enjoy the beach this thread does not have to be resolved this > week :--) > > Really want to hear from all of you and discussion Terry D., Latif, > Yanick, Dave G. Mike B. etc. > > Thanks > /jim > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > Sent: Friday, April 07, 2006 7:57 PM > > To: 'PPML'; address-policy-wg at ripe.net > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New Internet > > based on IPv6")'; 'Davis, Terry L'; ollivier.robert at eurocontrol.fr; > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > Subject: RE: Question > > > > A public answer to a private question as I have been sitting on a > > beach for awhile without the laptop and missed some related > > conversations ... :) > > > > > Is the outcome really open for discussion on the PI issue? > > It doesn't > > > sound like it is. > > > > In the minds of some the route scaling issue outweighs any argument > > for PI. When taken to its extreme, there is a valid point that a > > broken routing system serves no one. At the same time the > > dogmatic stance by the ISPs enforcing lock-in is just as > > broken both for large organizations with financial or legal > > requirements for operational stability, and the individual > > consumer/small business with limited budgets looking for true > > competition. The hard part is finding the middle ground in a > > way that limits the exposure to a potential routing collapse. > > > > I personally refuse to declare some needs legitimate and others not, > > as the only point of such differentiation is to establish a power > > broker. When all uses are legitimate, the problem boils down to the > > technical approach that can be scaled as necessary to contain growth > > in the routing system. This is the logic that leads me to the > > bit-interleaved geo that can be aggregated in varying size pockets > > as necessary using existing BGP deployments. We can start flat and > > implement aggregation over time when a region becomes too > > large to handle. One nice side effect of this geo approach is > > that it mitigates the continuing political demands for > > sovereign rights to IPv6 space. > > > > Any aggregation approach will force the business models to change > > from current practice. That is not as bad a thing as the alarmists > > will make it out to be, because their accountants are claiming the > > current model is a broken money looser as it is (which if so means > > they will eventually change anyway). The primary difference is that > > there will need to be aggregation intermediaries between the > > last-mile and transit providers. The current model eliminates these > > middle-men by trading off their routing mitigation service > > against a larger routing table (actually they already exist > > in the right places but are currently limited to layer2 media > > aggregators). The anti-PI bunch is trying to use social > > engineering to directly counter the bottom line business > > reality that the customer will always win in the end. > > Rather than accept this situation and constructively work on > > the necessary business model and technology developments, > > they effectively stall progress by staunchly claiming there > > is no acceptable technical approach that works within the > > current business structure. > > > > Making the RIRs be the police deciding who qualifies for PI and who > > does not just adds to their workload and raises costs. The > > beneficiaries of this gatekeeper approach are the ISPs that claim > > they need full routing knowledge everywhere, while the cost burden > > for supporting the waste-of-time qualification/evaluation work is > > borne by the applicant. Given that the most vocal and organized > > membership in the RIR community are the ISPs it is easy to > > understand why it would seem like the PI issue is already decided as > > closed. I tend to believe it will just drag out until enough of the > > corporate world becomes aware of the IPv4 exhaustion in light > > of their growth needs that they collectively appear at their > > RIR and demand an immediate solution. Unfortunately this > > 'wait till the last minute' tactic will likely result in a > > reactionary quickie with its own set of long term side effects. > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > told that shim6 was the anointed solution. Now that at least nanog > > has told the IAB where to put shim6 it might be possible to get > > the current IESG to reconsider. In any case the result would > > be a technical approach that would still require RIRs to > > establish policies around. As long as they are dominated by > > the ISPs it will be difficult to get real PI. > > > > Tony > > > > ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. From alh-ietf at tndh.net Tue Apr 11 16:17:20 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 11 Apr 2006 07:17:20 -0700 Subject: [address-policy-wg] RE: Question In-Reply-To: <936A4045C332714F975800409DE09240021C9580@tayexc14.americas.cpqcorp.net> Message-ID: <193301c65d72$a53a3cb0$de79df0a@tndh.net> Jim, I will let Ray answer the question about individuals, but for the purposes of this discussion I am willing to do the leg work for any policy proposal that the task force thinks would be helpful. As of yesterday's vote it is clear that the ARIN AC will be working on the finishing touches for a basic PI policy, and I am already working with Scott Leibrand and a few others on a companion policy about how to manage the designated PI block to minimize long term routing impact. Tony > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound at hp.com] > Sent: Tuesday, April 11, 2006 6:30 AM > To: Ray Plzak; Latif Ladid ("The New Internet based on IPv6"); Tony Hain; > PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Davis, Terry L; ollivier.robert at eurocontrol.fr; > narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; > Green, David B RDECOM CERDEC STCD SRI; Bound, Jim > Subject: RE: [address-policy-wg] RE: Question > > Ray, So you don't take IETF direction but only from individuals in the > IETF? Just want this to be clarified very clearly. This also does not > preclude the IPv6 Forum stating a public position on the issue whether > RIRs react to it or not. Not that will happen but it could if the pain > is strong enough to prohibit IPv6 deployment. > > Thanks > /jim > > > -----Original Message----- > > From: Ray Plzak [mailto:plzak at arin.net] > > Sent: Monday, April 10, 2006 6:56 AM > > To: 'Latif Ladid ("The New Internet based on IPv6")'; Bound, > > Jim; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > > Michael P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > > RDECOM CERDEC STCD SRI' > > Subject: RE: [address-policy-wg] RE: Question > > > > The NAv6TF is in the ARIN region. If individuals associated > > with it think that ARIN should adopt a policy or change an > > existing policy they should not only say so they should > > propose such a policy. Remember policies in the ARIN region, > > like in all of the RIRs is made not by the RIR organization > > staff and board but by the community in the region. ARIN > > staff will be more than happy to help anyone through the > > process, which by the way, while an orderly and formal > > process is not onerous, but one designed to provide for an > > open and honest discussion of any policy proposal before it > > is adopted. If you are interested in pursuing this, please > > contact me and I will get a staff member to assist you. > > > > Ray > > > > > -----Original Message----- > > > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > > > admin at ripe.net] On Behalf Of Latif Ladid ("The New Internet based on > > > IPv6") > > > Sent: Saturday, April 08, 2006 9:53 AM > > > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, Michael P > > > CIV DISA GES-E'; 'Pouffary, Yanick'; 'Green, David B RDECOM > > CERDEC STCD SRI' > > > Subject: [address-policy-wg] RE: Question > > > > > > > > > > > > The technical community should fix this one before the ITU > > sees this > > > as another chance to have a political say on the IPv6 addressing. > > > These things leak fast. My advice is that ARIN should seriously own > > > this issue before the ITU turns it to a sovereignty issue, > > which they > > > could for sure win this time. I know one of their noodles > > is sizzling > > > at it. > > > > > > Cheers > > > Latif > > > > > > -----Original Message----- > > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > > Sent: 08 April 2006 14:52 > > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > on IPv6"); > > > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > > > Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B > > > RDECOM CERDEC STCD SRI; Bound, Jim > > > Subject: RE: Question > > > > > > Tony, > > > > > > Excellent response and educational for sure. It is my > > belief that the > > > corporate business model today for operating networks may be broken > > > and I think you supported that below? If not my apologies > > for bad parsing? > > > > > > > > > Their models were fine for an IPv4 world where NAT was required and > > > some even confuse NAT with securing ones network (and some > > programs in the U.S. > > > Government) and that is simply bad policy and view. > > > > > > In the interim can this be resolved by RIRs creating some kind of > > > additional wording that address reclaim will be done in > > manner that is > > > negotiable, and do no harm to corporate or government business > > > operations? This would buy us time to work on the issue > > and stop the > > > FUD around this topic? > > > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > > addressing you can lead as ajunct to one of our regular > > meetings you > > > can lead for an entire day and we get the right players in > > the room. > > > So think about that as another option too. > > > > > > But do enjoy the beach this thread does not have to be > > resolved this > > > week > > > :--) > > > > > > Really want to hear from all of you and discussion Terry D., Latif, > > > Yanick, Dave G. Mike B. etc. > > > > > > Thanks > > > /jim > > > > > > > -----Original Message----- > > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > > Sent: Friday, April 07, 2006 7:57 PM > > > > To: 'PPML'; address-policy-wg at ripe.net > > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > > New Internet > > > > based on IPv6")'; 'Davis, Terry L'; > > ollivier.robert at eurocontrol.fr; > > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > > Subject: RE: Question > > > > > > > > A public answer to a private question as I have been sitting on a > > > > beach for awhile without the laptop and missed some related > > > > conversations ... :) > > > > > > > > > Is the outcome really open for discussion on the PI issue? > > > > It doesn't > > > > > sound like it is. > > > > > > > > In the minds of some the route scaling issue outweighs > > any argument > > > > for PI. > > > > When taken to its extreme, there is a valid point that a broken > > > > routing system serves no one. At the same time the > > dogmatic stance > > > > by the ISPs enforcing lock-in is just as broken both for large > > > > organizations with financial or legal requirements for > > operational > > > > stability, and the individual consumer/small business > > with limited > > > > budgets looking for true competition. The hard part is > > finding the > > > > middle ground in a way that limits the exposure to a potential > > > > routing collapse. > > > > > > > > I personally refuse to declare some needs legitimate and > > others not, > > > > as the only point of such differentiation is to establish a power > > > > broker. When all uses are legitimate, the problem boils > > down to the > > > > technical approach that can be scaled as necessary to > > contain growth > > > > in the routing system. > > > > This is the logic that leads me to the bit-interleaved > > geo that can > > > > be aggregated in varying size pockets as necessary using existing > > > > BGP deployments. We can start flat and implement aggregation over > > > > time when a region becomes too large to handle. One nice > > side effect > > > > of this geo approach is that it mitigates the continuing > > political > > > > demands for sovereign rights to IPv6 space. > > > > > > > > Any aggregation approach will force the business models to change > > > > from current practice. That is not as bad a thing as the > > alarmists > > > > will make it out to be, because their accountants are > > claiming the > > > > current model is a broken money looser as it is (which if > > so means > > > > they will eventually change anyway). The primary > > difference is that > > > > there will need to be aggregation intermediaries between the > > > > last-mile and transit providers. The current model > > eliminates these > > > > middle-men by trading off their routing mitigation > > service against a > > > > larger routing table (actually they already exist in the right > > > > places but are currently limited to layer2 media > > aggregators). The > > > > anti-PI bunch is trying to use social engineering to directly > > > > counter the bottom line business reality that the > > customer will always win in the end. > > > > Rather than accept this situation and constructively work on the > > > > necessary business model and technology developments, they > > > > effectively stall progress by staunchly claiming there is no > > > > acceptable technical approach that works within the > > current business structure. > > > > > > > > Making the RIRs be the police deciding who qualifies for > > PI and who > > > > does not just adds to their workload and raises costs. The > > > > beneficiaries of this gatekeeper approach are the ISPs that claim > > > > they need full routing knowledge everywhere, while the > > cost burden > > > > for supporting the waste-of-time qualification/evaluation work is > > > > borne by the applicant. > > > > Given that the most vocal and organized membership in the RIR > > > > community are the ISPs it is easy to understand why it would seem > > > > like the PI issue is already decided as closed. I tend to > > believe it > > > > will just drag out until enough of the corporate world > > becomes aware > > > > of the > > > > IPv4 exhaustion in light of their growth needs that they > > > > collectively appear at their RIR and demand an immediate > > solution. > > > > Unfortunately this 'wait till the last minute' tactic will likely > > > > result in a reactionary quickie with its own set of long > > term side effects. > > > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > > > told that > > > > shim6 was the anointed solution. Now that at least nanog has told > > > > the IAB where to put shim6 it might be possible to get > > the current > > > > IESG to reconsider. In any case the result would be a technical > > > > approach that would still require RIRs to establish > > policies around. > > > > As long as they are dominated by the ISPs it will be > > difficult to get real PI. > > > > > > > > Tony > > > > > > > > > > > > From Jim.Bound at hp.com Tue Apr 11 15:30:18 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Tue, 11 Apr 2006 09:30:18 -0400 Subject: [address-policy-wg] RE: Question Message-ID: <936A4045C332714F975800409DE09240021C9580@tayexc14.americas.cpqcorp.net> Ray, So you don't take IETF direction but only from individuals in the IETF? Just want this to be clarified very clearly. This also does not preclude the IPv6 Forum stating a public position on the issue whether RIRs react to it or not. Not that will happen but it could if the pain is strong enough to prohibit IPv6 deployment. Thanks /jim > -----Original Message----- > From: Ray Plzak [mailto:plzak at arin.net] > Sent: Monday, April 10, 2006 6:56 AM > To: 'Latif Ladid ("The New Internet based on IPv6")'; Bound, > Jim; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > Michael P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > RDECOM CERDEC STCD SRI' > Subject: RE: [address-policy-wg] RE: Question > > The NAv6TF is in the ARIN region. If individuals associated > with it think that ARIN should adopt a policy or change an > existing policy they should not only say so they should > propose such a policy. Remember policies in the ARIN region, > like in all of the RIRs is made not by the RIR organization > staff and board but by the community in the region. ARIN > staff will be more than happy to help anyone through the > process, which by the way, while an orderly and formal > process is not onerous, but one designed to provide for an > open and honest discussion of any policy proposal before it > is adopted. If you are interested in pursuing this, please > contact me and I will get a staff member to assist you. > > Ray > > > -----Original Message----- > > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > > admin at ripe.net] On Behalf Of Latif Ladid ("The New Internet based on > > IPv6") > > Sent: Saturday, April 08, 2006 9:53 AM > > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, Michael P > > CIV DISA GES-E'; 'Pouffary, Yanick'; 'Green, David B RDECOM > CERDEC STCD SRI' > > Subject: [address-policy-wg] RE: Question > > > > > > > > The technical community should fix this one before the ITU > sees this > > as another chance to have a political say on the IPv6 addressing. > > These things leak fast. My advice is that ARIN should seriously own > > this issue before the ITU turns it to a sovereignty issue, > which they > > could for sure win this time. I know one of their noodles > is sizzling > > at it. > > > > Cheers > > Latif > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > Sent: 08 April 2006 14:52 > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); > > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > > Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B > > RDECOM CERDEC STCD SRI; Bound, Jim > > Subject: RE: Question > > > > Tony, > > > > Excellent response and educational for sure. It is my > belief that the > > corporate business model today for operating networks may be broken > > and I think you supported that below? If not my apologies > for bad parsing? > > > > > > Their models were fine for an IPv4 world where NAT was required and > > some even confuse NAT with securing ones network (and some > programs in the U.S. > > Government) and that is simply bad policy and view. > > > > In the interim can this be resolved by RIRs creating some kind of > > additional wording that address reclaim will be done in > manner that is > > negotiable, and do no harm to corporate or government business > > operations? This would buy us time to work on the issue > and stop the > > FUD around this topic? > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > addressing you can lead as ajunct to one of our regular > meetings you > > can lead for an entire day and we get the right players in > the room. > > So think about that as another option too. > > > > But do enjoy the beach this thread does not have to be > resolved this > > week > > :--) > > > > Really want to hear from all of you and discussion Terry D., Latif, > > Yanick, Dave G. Mike B. etc. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > Sent: Friday, April 07, 2006 7:57 PM > > > To: 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > New Internet > > > based on IPv6")'; 'Davis, Terry L'; > ollivier.robert at eurocontrol.fr; > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > Subject: RE: Question > > > > > > A public answer to a private question as I have been sitting on a > > > beach for awhile without the laptop and missed some related > > > conversations ... :) > > > > > > > Is the outcome really open for discussion on the PI issue? > > > It doesn't > > > > sound like it is. > > > > > > In the minds of some the route scaling issue outweighs > any argument > > > for PI. > > > When taken to its extreme, there is a valid point that a broken > > > routing system serves no one. At the same time the > dogmatic stance > > > by the ISPs enforcing lock-in is just as broken both for large > > > organizations with financial or legal requirements for > operational > > > stability, and the individual consumer/small business > with limited > > > budgets looking for true competition. The hard part is > finding the > > > middle ground in a way that limits the exposure to a potential > > > routing collapse. > > > > > > I personally refuse to declare some needs legitimate and > others not, > > > as the only point of such differentiation is to establish a power > > > broker. When all uses are legitimate, the problem boils > down to the > > > technical approach that can be scaled as necessary to > contain growth > > > in the routing system. > > > This is the logic that leads me to the bit-interleaved > geo that can > > > be aggregated in varying size pockets as necessary using existing > > > BGP deployments. We can start flat and implement aggregation over > > > time when a region becomes too large to handle. One nice > side effect > > > of this geo approach is that it mitigates the continuing > political > > > demands for sovereign rights to IPv6 space. > > > > > > Any aggregation approach will force the business models to change > > > from current practice. That is not as bad a thing as the > alarmists > > > will make it out to be, because their accountants are > claiming the > > > current model is a broken money looser as it is (which if > so means > > > they will eventually change anyway). The primary > difference is that > > > there will need to be aggregation intermediaries between the > > > last-mile and transit providers. The current model > eliminates these > > > middle-men by trading off their routing mitigation > service against a > > > larger routing table (actually they already exist in the right > > > places but are currently limited to layer2 media > aggregators). The > > > anti-PI bunch is trying to use social engineering to directly > > > counter the bottom line business reality that the > customer will always win in the end. > > > Rather than accept this situation and constructively work on the > > > necessary business model and technology developments, they > > > effectively stall progress by staunchly claiming there is no > > > acceptable technical approach that works within the > current business structure. > > > > > > Making the RIRs be the police deciding who qualifies for > PI and who > > > does not just adds to their workload and raises costs. The > > > beneficiaries of this gatekeeper approach are the ISPs that claim > > > they need full routing knowledge everywhere, while the > cost burden > > > for supporting the waste-of-time qualification/evaluation work is > > > borne by the applicant. > > > Given that the most vocal and organized membership in the RIR > > > community are the ISPs it is easy to understand why it would seem > > > like the PI issue is already decided as closed. I tend to > believe it > > > will just drag out until enough of the corporate world > becomes aware > > > of the > > > IPv4 exhaustion in light of their growth needs that they > > > collectively appear at their RIR and demand an immediate > solution. > > > Unfortunately this 'wait till the last minute' tactic will likely > > > result in a reactionary quickie with its own set of long > term side effects. > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > > told that > > > shim6 was the anointed solution. Now that at least nanog has told > > > the IAB where to put shim6 it might be possible to get > the current > > > IESG to reconsider. In any case the result would be a technical > > > approach that would still require RIRs to establish > policies around. > > > As long as they are dominated by the ISPs it will be > difficult to get real PI. > > > > > > Tony > > > > > > > > From Jim.Bound at hp.com Tue Apr 11 15:54:19 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Tue, 11 Apr 2006 09:54:19 -0400 Subject: [address-policy-wg] RE: Question - Aviation Message-ID: <936A4045C332714F975800409DE09240021C95C6@tayexc14.americas.cpqcorp.net> Thanks Terry. Good disagreement but I stand solid on my view. Note I did not say an address change would be transparent what I said is there should be legal binding methods that do not permit any RIR to disrupt any business. Meaning there would be no change that would affect production systems unless planned, that would prevent saftey issues. Regarding RIRs providing PI space I am soft against not hard liner. I do not want to see private addresses ever again on the Internet anywhere it prevents true end-to-end. I think we need to coordinate a time and place to have this debate and resulting effort discussed with all defending their views in person. Problem is we are all tapped with Travel now. Best, /jim > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > Sent: Monday, April 10, 2006 4:13 PM > To: Bound, Jim; Tony Hain; PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; Green, > David B RDECOM CERDEC STCD SRI > Subject: RE: Question - Aviation > > Jim/All > > I am going to respond in two parts here on PI issues; one in > terms of aviation and one in terms of corporate. This one is > on aviation. > > The next two paragraphs are from an original response to > Thomas Narten, that I didn't see make the list. > > ---- > I view systems that run "critical infrastructure" entirely > different from those used to run anything else; especially > systems that can directly impact the safety of the people > using or relying on them. > > Safety engineering is just like security engineering; both > depend on our ability to build in layers of defense and > reliability trying to never rely entirely on a single system. > By forcing an industry like aviation to accept the potential > of address changing in a global fleet, an element of extreme > risk is added as the system's overall reliability is decreased. > ---- > > We know that in the next decade that there will be > development initiated for a new air traffic control system. > It will likely be built upon IP and if so, likely IP-v6. And > ICAO currently has a working group studying this and the > committee is leaning towards IP-v6 although there is a strong > component that is pushing for IP-v4 and a continuation the > NAT type usage currently required in the aviation industry by > Arinc 664. > And I do definitely agree with Jim here, the use IP-v4 and > NAT would create huge risks; if in nothing else, the > potential for mis-addressing through one of the hundreds of > NAT gateways that would be required. > > I'll respectfully disagree with Jim in that I believe address > change in a complex global system like air traffic control > can create a hazard. > Keep in mind, that the air traffic control system spans > virtually every nation on globe and most everything manmade > that flies. Likewise the technical and operational > capabilities vary from extraordinary to very minimal; like > the 30 or so aviation operators that the EU just banned from > flying into EU countries because of their poor safety and > maintenance performance record. > > Coordinating an address change across this type of > infrastructure with aircraft and ground infrastructure in > almost every nation on the globe, is simply beyond my ability > comprehend. Assuming the technology would work flawlessly > (discussed below), the politics of when and how to implement > the change would likely end up on the floor of the UN for > debate. Likewise, if a decision was made to implement a > change, we would be dealing with such different levels of > expertise around the world that no amount of pre-planning > could ensure that implementation failures would not occur. > > Now just a bit about where ATC systems are likely going and > why their criticality will likely grow over the next couple > decades. Unless we suddenly develop anti-gravity > capabilities to allow slow vertical takeoffs, we are stuck > with the airports we have and only minimal abilities to > expand them (cost, environmental, noise, etc). The only real > way we can expand their capacity is with bigger airplanes and > more flights. The "more flights" part is where this gets > complicated and critical. To handle more flights, we have to > decrease landing and takeoff separations and speed up > aircraft ground movements so an airport can handle more > aircraft per hour. We are about to human capacity with the > current systems which means that these improvements will need > to move more and more to relying on precise control systems; > a minutes interruption here will be a really big deal. > > Also we as an industry are just beginning to migrate from bus > data communications on the aircraft to networks. The > commercial aircraft flying today are already largely computer > controlled and as I mentioned above we try very hard not > design the aircraft to be critically reliant on any one > system. In almost all cases, it requires a cascading series > of failures to present an aircraft with a catastrophic > hazard. Now as I said, we are starting to put networks on > the aircraft and as Arinc 664 shows; we are not the world's > greatest network engineers (at least not yet..). In a decade > or so, we will have hundreds of networked systems on an > aircraft. I think the risk here in re-addressing is clear; > how well will they all react. And yes we can probably take > most of the risk down in certification testing but keep in > mind variation in technical competence of the operators > around the world and that we are continually accepting > upgraded systems from our vendors as replacement parts and > this could also inject potential failures in re-addressing. > > If we were to use 3178 without a single global address space, > I still don't think this would scale as we then would be > using probably in the neighborhood of 50 or more ISP's (you > don't always get to pick your ISP's and while a country might > accept addressing from an industry block, they'd probably > insist on using theirs otherwise) around the world for the > service. And the way I read it, I would still have lots of > unnecessary backhauling to the other side of the planet and > some very complicated policy routing to set up. Besides and > then with mix of address spaces, I would probably be > perpetually leaking with the global Internet in what should > be a closed network. > > Finally at the moment with our existing certification > processes, I'm not sure that we would even be permitted to > change the aircraft addresses without re-issuing all the > affected software with new part numbers. > (I'll bet you assumed we used DHCP to address the current > aircraft; nope we hard code address everything, remember "bus > engineering" 101 ;-) With today's current rules, we haven't > put any "critical systems" on anything but a closed onboard > network. We are just discussing the ability upload new > IP_tables/firewall-rules and authentication certs/passwords > to the non-critical networks and I believe that this will be > solved in the next couple years. And now also keep in mind > that every aviation rule-making body around the world would > also have to approve of the address change for an ATC network > and define how they were going to certify the change. > > ====================================================================== > Finally now having said all this Jim, I think it is possible > for aviation to remain conforming. > > We have probably only two primary needs for stable IP > addressed networks; one for Air Traffic Control and one for > Airline Operations. > These are industry traffic type designations that have safety > related functions that are carried out over them. As we have > discussed before, I expect both of them to be run as "closed > networks" and should never > (IMHO) be seen in the global routing tables; a closed network > will provide them with a layer of security, better routing > performance, the multi-homing that an aircraft needs, and > more options for mobility solutions. > > Further, two organizations already exist that could > legitimately hold the addresses; ICAO for the ATC network as > they already govern it and the AEEC for "airline operations" > whose members already essentially own "Arinc" which is an ISP > already. If it were possible to convince these orgs, to > apply for space and the registries to grant them, that would > seem to be a solution. > > Take care > Terry > > PS: Apologies for the length.. > > PSS: Back to "critical infrastructure" networks a moment, I'd > say that any network that wanted to declare itself "critical > infrastructure" > could obtain PI space, BUT to me this type of network should > always be run as a "closed network" with exchanges to the > Internet only through "mediation gateways" operating at the > application level, not at the routing level. Just food for > thought but perhaps there is a class of > IP-v6 networks for "critical infrastructure" that have their > own PI space, but are prohibited from the participating in > "Internet routing". > Such a concept might solve lots of problems. > > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > Sent: Saturday, April 08, 2006 5:52 AM > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); > > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > Brig, > > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > CERDEC > > STCD SRI; Bound, Jim > > Subject: RE: Question > > > > Tony, > > > > Excellent response and educational for sure. It is my > belief that the > > corporate business model today for operating networks may be broken > and > > I think you supported that below? If not my apologies for bad > parsing? > > > > > > Their models were fine for an IPv4 world where NAT was required and > some > > even confuse NAT with securing ones network (and some > programs in the > > U.S. Government) and that is simply bad policy and view. > > > > In the interim can this be resolved by RIRs creating some kind of > > additional wording that address reclaim will be done in > manner that is > > negotiable, and do no harm to corporate or government business > > operations? This would buy us time to work on the issue > and stop the > > FUD around this topic? > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > addressing you can lead as ajunct to one of our regular meetings you > can > > lead for an entire day and we get the right players in the > room. So > > think about that as another option too. > > > > But do enjoy the beach this thread does not have to be > resolved this > > week :--) > > > > Really want to hear from all of you and discussion Terry D., Latif, > > Yanick, Dave G. Mike B. etc. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > Sent: Friday, April 07, 2006 7:57 PM > > > To: 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > New Internet > > > based on IPv6")'; 'Davis, Terry L'; > ollivier.robert at eurocontrol.fr; > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > Subject: RE: Question > > > > > > A public answer to a private question as I have been sitting on a > > > beach for awhile without the laptop and missed some related > > > conversations ... :) > > > > > > > Is the outcome really open for discussion on the PI issue? > > > It doesn't > > > > sound like it is. > > > > > > In the minds of some the route scaling issue outweighs > any argument > > > for PI. > > > When taken to its extreme, there is a valid point that a broken > > > routing system serves no one. At the same time the > dogmatic stance > > > by the ISPs enforcing lock-in is just as broken both for large > > > organizations with financial or legal requirements for > operational > > > stability, and the individual consumer/small business > with limited > > > budgets looking for true competition. The hard part is > finding the > > > middle ground in a way that limits the exposure to a potential > > > routing collapse. > > > > > > I personally refuse to declare some needs legitimate and > others not, > > > as the only point of such differentiation is to establish a power > > > broker. When all uses are legitimate, the problem boils > down to the > > > technical approach that can be scaled as necessary to > contain growth > > > in the routing system. > > > This is the logic that leads me to the bit-interleaved > geo that can > > > be aggregated in varying size pockets as necessary using existing > > > BGP deployments. We can start flat and implement aggregation over > > > time when a region becomes too large to handle. One nice > side effect > > > of this geo approach is that it mitigates the continuing > political > > > demands for sovereign rights to IPv6 space. > > > > > > Any aggregation approach will force the business models to change > > > from current practice. That is not as bad a thing as the > alarmists > > > will make it out to be, because their accountants are > claiming the > > > current model is a broken money looser as it is (which if > so means > > > they will eventually change anyway). The primary > difference is that > > > there will need to be aggregation intermediaries between the > > > last-mile and transit providers. The current model > eliminates these > > > middle-men by trading off their routing mitigation > service against a > > > larger routing table (actually they already exist in the right > > > places but are currently limited to layer2 media > aggregators). The > > > anti-PI bunch is trying to use social engineering to directly > > > counter the bottom line business reality that the customer will > > > always win in the end. > > > Rather than accept this situation and constructively work on the > > > necessary business model and technology developments, they > > > effectively stall progress by staunchly claiming there is no > > > acceptable technical approach that works within the > current business > > > structure. > > > > > > Making the RIRs be the police deciding who qualifies for > PI and who > > > does not just adds to their workload and raises costs. The > > > beneficiaries of this gatekeeper approach are the ISPs that claim > > > they need full routing knowledge everywhere, while the > cost burden > > > for supporting the waste-of-time qualification/evaluation work is > > > borne by the applicant. > > > Given that the most vocal and organized membership in the RIR > > > community are the ISPs it is easy to understand why it would seem > > > like the PI issue is already decided as closed. I tend to > believe it > > > will just drag out until enough of the corporate world > becomes aware > > > of the IPv4 exhaustion in light of their growth needs that they > > > collectively appear at their RIR and demand an immediate > solution. > > > Unfortunately this 'wait till the last minute' tactic will likely > > > result in a reactionary quickie with its own set of long > term side > > > effects. > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > > told that > > > shim6 was the anointed solution. Now that at least nanog has told > > > the IAB where to put shim6 it might be possible to get > the current > > > IESG to reconsider. In any case the result would be a technical > > > approach that would still require RIRs to establish > policies around. > > > As long as they are dominated by the ISPs it will be difficult to > > > get real PI. > > > > > > Tony > > > > > > > From terry.l.davis at boeing.com Tue Apr 11 16:02:28 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 11 Apr 2006 07:02:28 -0700 Subject: [address-policy-wg] RE: Question - Aviation In-Reply-To: <65758C24A8772B49B2DE38D6F8B3D792A2BA09@HHBRUE004.hq.corp.eurocontrol.int> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BEB2@XCH-NW-8V1.nw.nos.boeing.com> Eivan I don't think that I suggested changing anything that would really impact you all. I just suggested the possibility of formalizing the use of "closed networks" in my closing, I would not expect it to impact you at all. Take care Terry > -----Original Message----- > From: CERASI Eivan [mailto:eivan.cerasi at eurocontrol.int] > Sent: Tuesday, April 11, 2006 5:34 AM > To: Davis, Terry L; Bound, Jim; Tony Hain; PPML; address-policy- > wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; > Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI > Subject: RE: [address-policy-wg] RE: Question - Aviation > > Hello just to give you some status/complement on what we are doing in > Europe for air traffic management. > > EUROCONTROL (a European organization dealing with the safety of air > navigation) has become LIR to obtain a /32. > > We have started using this address space for ground air traffic control > unicast applications but take-up is slow due to the nature of our > environment. > > With regard to air-ground applications, we have launched studies for a > more global approach vis-?-vis air/ground applications and this is being > performed in collaboration with ICAO working groups. > > Of course our primary goal is to enable an IP service for air traffic > control communications, not passenger nor airline communications. As our > environment is highly conservative, technology changes are very slow > especially if they have to be global. Our European strategy is that IPv6 > is our final target for all communications but our X.25 will still be > around for another few years and our IPv4 for even more. > > It is correct to state that our safety critical applications operate in a > closed environment as opposed to the use of classical internet services. > However we do have exchanges with internet customers (airlines) via > dedicated means. Clearly, both IP routing environments are isolated from > each other. > > To come back on one of the points that was raised below, I do not see the > benefit of creating a dedicated address space for such type of > applications (just as RFC1918 provides private address space for IPv4). > For me, it would just increase the end-user perceived complexity of IPv6. > In doing so, you would already cause us a problem of having to change > something we have already put into operations ! > > > Best regards > Eivan Cerasi > > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Davis, Terry L > Sent: Monday 10 April 2006 22:13 > To: Bound, Jim; Tony Hain; PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; > Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI > Subject: [address-policy-wg] RE: Question - Aviation > > > Jim/All > > I am going to respond in two parts here on PI issues; one in terms of > aviation and one in terms of corporate. This one is on aviation. > > The next two paragraphs are from an original response to Thomas Narten, > that I didn't see make the list. > > ---- > I view systems that run "critical infrastructure" entirely different from > those used to run anything else; especially systems that can directly > impact the safety of the people using or relying on them. > > Safety engineering is just like security engineering; both depend on our > ability to build in layers of defense and reliability trying to never rely > entirely on a single system. By forcing an industry like aviation to > accept the potential of address changing in a global fleet, an element of > extreme risk is added as the system's overall reliability is decreased. > ---- > > We know that in the next decade that there will be development initiated > for a new air traffic control system. It will likely be built upon IP and > if so, likely IP-v6. And ICAO currently has a working group studying this > and the committee is leaning towards IP-v6 although there is a strong > component that is pushing for IP-v4 and a continuation the NAT type usage > currently required in the aviation industry by Arinc 664. And I do > definitely agree with Jim here, the use IP-v4 and NAT would create huge > risks; if in nothing else, the potential for mis-addressing through one of > the hundreds of NAT gateways that would be required. > > I'll respectfully disagree with Jim in that I believe address change in a > complex global system like air traffic control can create a hazard. Keep > in mind, that the air traffic control system spans virtually every nation > on globe and most everything manmade that flies. Likewise the technical > and operational capabilities vary from extraordinary to very minimal; like > the 30 or so aviation operators that the EU just banned from flying into > EU countries because of their poor safety and maintenance performance > record. > > Coordinating an address change across this type of infrastructure with > aircraft and ground infrastructure in almost every nation on the globe, is > simply beyond my ability comprehend. Assuming the technology would work > flawlessly (discussed below), the politics of when and how to implement > the change would likely end up on the floor of the UN for debate. > Likewise, if a decision was made to implement a change, we would be > dealing with such different levels of expertise around the world that no > amount of pre-planning could ensure that implementation failures would not > occur. > > Now just a bit about where ATC systems are likely going and why their > criticality will likely grow over the next couple decades. Unless we > suddenly develop anti-gravity capabilities to allow slow vertical takeoffs, > we are stuck with the airports we have and only minimal abilities to > expand them (cost, environmental, noise, etc). The only real way we can > expand their capacity is with bigger airplanes and more flights. The > "more flights" part is where this gets complicated and critical. To > handle more flights, we have to decrease landing and takeoff separations > and speed up aircraft ground movements so an airport can handle more > aircraft per hour. We are about to human capacity with the current > systems which means that these improvements will need to move more and > more to relying on precise control systems; a minutes interruption here > will be a really big deal. > > Also we as an industry are just beginning to migrate from bus data > communications on the aircraft to networks. The commercial aircraft > flying today are already largely computer controlled and as I mentioned > above we try very hard not design the aircraft to be critically reliant on > any one system. In almost all cases, it requires a cascading series of > failures to present an aircraft with a catastrophic hazard. Now as I said, > we are starting to put networks on the aircraft and as Arinc 664 shows; we > are not the world's greatest network engineers (at least not yet..). In a > decade or so, we will have hundreds of networked systems on an aircraft. > I think the risk here in re-addressing is clear; how well will they all > react. And yes we can probably take most of the risk down in > certification testing but keep in mind variation in technical competence > of the operators around the world and that we are continually accepting > upgraded systems from our vendors as replacement parts and this could also > inject potential failures in re-addressing. > > If we were to use 3178 without a single global address space, I still > don't think this would scale as we then would be using probably in the > neighborhood of 50 or more ISP's (you don't always get to pick your ISP's > and while a country might accept addressing from an industry block, they'd > probably insist on using theirs otherwise) around the world for the > service. And the way I read it, I would still have lots of unnecessary > backhauling to the other side of the planet and some very complicated > policy routing to set up. Besides and then with mix of address spaces, I > would probably be perpetually leaking with the global Internet in what > should be a closed network. > > Finally at the moment with our existing certification processes, I'm not > sure that we would even be permitted to change the aircraft addresses > without re-issuing all the affected software with new part numbers. (I'll > bet you assumed we used DHCP to address the current aircraft; nope we hard > code address everything, remember "bus engineering" 101 ;-) With today's > current rules, we haven't put any "critical systems" on anything but a > closed onboard network. We are just discussing the ability upload new > IP_tables/firewall-rules and authentication certs/passwords to the non- > critical networks and I believe that this will be solved in the next > couple years. And now also keep in mind that every aviation rule-making > body around the world would also have to approve of the address change for > an ATC network and define how they were going to certify the change. > > ====================================================================== > Finally now having said all this Jim, I think it is possible for aviation > to remain conforming. > > We have probably only two primary needs for stable IP addressed networks; > one for Air Traffic Control and one for Airline Operations. These are > industry traffic type designations that have safety related functions that > are carried out over them. As we have discussed before, I expect both of > them to be run as "closed networks" and should never > (IMHO) be seen in the global routing tables; a closed network will provide > them with a layer of security, better routing performance, the multi- > homing that an aircraft needs, and more options for mobility solutions. > > Further, two organizations already exist that could legitimately hold the > addresses; ICAO for the ATC network as they already govern it and the AEEC > for "airline operations" whose members already essentially own "Arinc" > which is an ISP already. If it were possible to convince these orgs, to > apply for space and the registries to grant them, that would seem to be a > solution. > > Take care > Terry > > PS: Apologies for the length.. > > PSS: Back to "critical infrastructure" networks a moment, I'd say that any > network that wanted to declare itself "critical infrastructure" could > obtain PI space, BUT to me this type of network should always be run as a > "closed network" with exchanges to the Internet only through "mediation > gateways" operating at the application level, not at the routing level. > Just food for thought but perhaps there is a class of IP-v6 networks for > "critical infrastructure" that have their own PI space, but are prohibited > from the participating in "Internet routing". Such a concept might solve > lots of problems. > > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > Sent: Saturday, April 08, 2006 5:52 AM > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > Brig, > > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > CERDEC > > STCD SRI; Bound, Jim > > Subject: RE: Question > > > > Tony, > > > > Excellent response and educational for sure. It is my belief that the > > corporate business model today for operating networks may be broken > and > > I think you supported that below? If not my apologies for bad > parsing? > > > > > > Their models were fine for an IPv4 world where NAT was required and > some > > even confuse NAT with securing ones network (and some programs in the > > U.S. Government) and that is simply bad policy and view. > > > > In the interim can this be resolved by RIRs creating some kind of > > additional wording that address reclaim will be done in manner that is > > negotiable, and do no harm to corporate or government business > > operations? This would buy us time to work on the issue and stop the > > FUD around this topic? > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > addressing you can lead as ajunct to one of our regular meetings you > can > > lead for an entire day and we get the right players in the room. So > > think about that as another option too. > > > > But do enjoy the beach this thread does not have to be resolved this > > week :--) > > > > Really want to hear from all of you and discussion Terry D., Latif, > > Yanick, Dave G. Mike B. etc. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > Sent: Friday, April 07, 2006 7:57 PM > > > To: 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New Internet > > > based on IPv6")'; 'Davis, Terry L'; ollivier.robert at eurocontrol.fr; > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > Subject: RE: Question > > > > > > A public answer to a private question as I have been sitting on a > > > beach for awhile without the laptop and missed some related > > > conversations ... :) > > > > > > > Is the outcome really open for discussion on the PI issue? > > > It doesn't > > > > sound like it is. > > > > > > In the minds of some the route scaling issue outweighs any argument > > > for PI. When taken to its extreme, there is a valid point that a > > > broken routing system serves no one. At the same time the > > > dogmatic stance by the ISPs enforcing lock-in is just as > > > broken both for large organizations with financial or legal > > > requirements for operational stability, and the individual > > > consumer/small business with limited budgets looking for true > > > competition. The hard part is finding the middle ground in a > > > way that limits the exposure to a potential routing collapse. > > > > > > I personally refuse to declare some needs legitimate and others not, > > > as the only point of such differentiation is to establish a power > > > broker. When all uses are legitimate, the problem boils down to the > > > technical approach that can be scaled as necessary to contain growth > > > in the routing system. This is the logic that leads me to the > > > bit-interleaved geo that can be aggregated in varying size pockets > > > as necessary using existing BGP deployments. We can start flat and > > > implement aggregation over time when a region becomes too > > > large to handle. One nice side effect of this geo approach is > > > that it mitigates the continuing political demands for > > > sovereign rights to IPv6 space. > > > > > > Any aggregation approach will force the business models to change > > > from current practice. That is not as bad a thing as the alarmists > > > will make it out to be, because their accountants are claiming the > > > current model is a broken money looser as it is (which if so means > > > they will eventually change anyway). The primary difference is that > > > there will need to be aggregation intermediaries between the > > > last-mile and transit providers. The current model eliminates these > > > middle-men by trading off their routing mitigation service > > > against a larger routing table (actually they already exist > > > in the right places but are currently limited to layer2 media > > > aggregators). The anti-PI bunch is trying to use social > > > engineering to directly counter the bottom line business > > > reality that the customer will always win in the end. > > > Rather than accept this situation and constructively work on > > > the necessary business model and technology developments, > > > they effectively stall progress by staunchly claiming there > > > is no acceptable technical approach that works within the > > > current business structure. > > > > > > Making the RIRs be the police deciding who qualifies for PI and who > > > does not just adds to their workload and raises costs. The > > > beneficiaries of this gatekeeper approach are the ISPs that claim > > > they need full routing knowledge everywhere, while the cost burden > > > for supporting the waste-of-time qualification/evaluation work is > > > borne by the applicant. Given that the most vocal and organized > > > membership in the RIR community are the ISPs it is easy to > > > understand why it would seem like the PI issue is already decided as > > > closed. I tend to believe it will just drag out until enough of the > > > corporate world becomes aware of the IPv4 exhaustion in light > > > of their growth needs that they collectively appear at their > > > RIR and demand an immediate solution. Unfortunately this > > > 'wait till the last minute' tactic will likely result in a > > > reactionary quickie with its own set of long term side effects. > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > > told that shim6 was the anointed solution. Now that at least nanog > > > has told the IAB where to put shim6 it might be possible to get > > > the current IESG to reconsider. In any case the result would > > > be a technical approach that would still require RIRs to > > > establish policies around. As long as they are dominated by > > > the ISPs it will be difficult to get real PI. > > > > > > Tony > > > > > > > > ____ > > This message and any files transmitted with it are legally privileged and > intended for the sole use of the individual(s) or entity to whom they are > addressed. If you are not the intended recipient, please notify the sender > by reply and delete the message and any attachments from your system. Any > unauthorised use or disclosure of the content of this message is strictly > prohibited and may be unlawful. > > Nothing in this e-mail message amounts to a contractual or legal > commitment on the part of EUROCONTROL, unless it is confirmed by > appropriately signed hard copy. > > Any views expressed in this message are those of the sender. > From Jim.Bound at hp.com Tue Apr 11 16:04:48 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Tue, 11 Apr 2006 10:04:48 -0400 Subject: [address-policy-wg] RE: Question - Aviation Message-ID: <936A4045C332714F975800409DE09240021C95EB@tayexc14.americas.cpqcorp.net> I agree with Eivan bottom line too. At some point we need to bring in the actual U.S. FAA persons and I will go find out who that is that contribute directly from FAA. I have been working with FAA for 4 years and have participate in their Distinguished Lecture Series with U.S. DOD personnel, as CTO IPv6 Forum (not as HP), and have point of contact. FAA has also been reviewing IPv6 and it has been visible to the CIO manager levels and test beds were being created. Will get back to all. FAA will also be driven by the U.S. Whitehouse Enterprise Architecture requirements via OMB and IPv6 is one part of those mandates for Federal Agencies by 2008 at least for the network core of a federated agency network. Thanks /jim > -----Original Message----- > From: CERASI Eivan [mailto:eivan.cerasi at eurocontrol.int] > Sent: Tuesday, April 11, 2006 8:34 AM > To: Davis, Terry L; Bound, Jim; Tony Hain; PPML; > address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); ROBERT Ollivier; narten at us.ibm.com; Brig, Michael > P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > CERDEC STCD SRI > Subject: RE: [address-policy-wg] RE: Question - Aviation > > Hello just to give you some status/complement on what we are > doing in Europe for air traffic management. > > EUROCONTROL (a European organization dealing with the safety > of air navigation) has become LIR to obtain a /32. > > We have started using this address space for ground air > traffic control unicast applications but take-up is slow due > to the nature of our environment. > > With regard to air-ground applications, we have launched > studies for a more global approach vis-?-vis air/ground > applications and this is being performed in collaboration > with ICAO working groups. > > Of course our primary goal is to enable an IP service for air > traffic control communications, not passenger nor airline > communications. As our environment is highly conservative, > technology changes are very slow especially if they have to > be global. Our European strategy is that IPv6 is our final > target for all communications but our X.25 will still be > around for another few years and our IPv4 for even more. > > It is correct to state that our safety critical applications > operate in a closed environment as opposed to the use of > classical internet services. However we do have exchanges > with internet customers (airlines) via dedicated means. > Clearly, both IP routing environments are isolated from each other. > > To come back on one of the points that was raised below, I do > not see the benefit of creating a dedicated address space for > such type of applications (just as RFC1918 provides private > address space for IPv4). For me, it would just increase the > end-user perceived complexity of IPv6. In doing so, you would > already cause us a problem of having to change something we > have already put into operations ! > > > Best regards > Eivan Cerasi > > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Davis, Terry L > Sent: Monday 10 April 2006 22:13 > To: Bound, Jim; Tony Hain; PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); ROBERT Ollivier; narten at us.ibm.com; Brig, Michael > P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > CERDEC STCD SRI > Subject: [address-policy-wg] RE: Question - Aviation > > > Jim/All > > I am going to respond in two parts here on PI issues; one in > terms of aviation and one in terms of corporate. This one is > on aviation. > > The next two paragraphs are from an original response to > Thomas Narten, that I didn't see make the list. > > ---- > I view systems that run "critical infrastructure" entirely > different from those used to run anything else; especially > systems that can directly impact the safety of the people > using or relying on them. > > Safety engineering is just like security engineering; both > depend on our ability to build in layers of defense and > reliability trying to never rely entirely on a single system. > By forcing an industry like aviation to accept the potential > of address changing in a global fleet, an element of extreme > risk is added as the system's overall reliability is decreased. > ---- > > We know that in the next decade that there will be > development initiated for a new air traffic control system. > It will likely be built upon IP and if so, likely IP-v6. And > ICAO currently has a working group studying this and the > committee is leaning towards IP-v6 although there is a strong > component that is pushing for IP-v4 and a continuation the > NAT type usage currently required in the aviation industry by > Arinc 664. And I do definitely agree with Jim here, the use > IP-v4 and NAT would create huge risks; if in nothing else, > the potential for mis-addressing through one of the hundreds > of NAT gateways that would be required. > > I'll respectfully disagree with Jim in that I believe address > change in a complex global system like air traffic control > can create a hazard. Keep in mind, that the air traffic > control system spans virtually every nation on globe and most > everything manmade that flies. Likewise the technical and > operational capabilities vary from extraordinary to very > minimal; like the 30 or so aviation operators that the EU > just banned from flying into EU countries because of their > poor safety and maintenance performance record. > > Coordinating an address change across this type of > infrastructure with aircraft and ground infrastructure in > almost every nation on the globe, is simply beyond my ability > comprehend. Assuming the technology would work flawlessly > (discussed below), the politics of when and how to implement > the change would likely end up on the floor of the UN for > debate. Likewise, if a decision was made to implement a > change, we would be dealing with such different levels of > expertise around the world that no amount of pre-planning > could ensure that implementation failures would not occur. > > Now just a bit about where ATC systems are likely going and > why their criticality will likely grow over the next couple > decades. Unless we suddenly develop anti-gravity > capabilities to allow slow vertical takeoffs, we are stuck > with the airports we have and only minimal abilities to > expand them (cost, environmental, noise, etc). The only real > way we can expand their capacity is with bigger airplanes and > more flights. The "more flights" part is where this gets > complicated and critical. To handle more flights, we have to > decrease landing and takeoff separations and speed up > aircraft ground movements so an airport can handle more > aircraft per hour. We are about to human capacity with the > current systems which means that these improvements will need > to move more and more to relying on precise control systems; > a minutes interruption here will be a really big deal. > > Also we as an industry are just beginning to migrate from bus > data communications on the aircraft to networks. The > commercial aircraft flying today are already largely computer > controlled and as I mentioned above we try very hard not > design the aircraft to be critically reliant on any one > system. In almost all cases, it requires a cascading series > of failures to present an aircraft with a catastrophic > hazard. Now as I said, we are starting to put networks on > the aircraft and as Arinc 664 shows; we are not the world's > greatest network engineers (at least not yet..). In a decade > or so, we will have hundreds of networked systems on an > aircraft. I think the risk here in re-addressing is clear; > how well will they all react. And yes we can probably take > most of the risk down in certification testing but keep in > mind variation in technical competence of the operators > around the world and that we are continually accepting > upgraded systems from our vendors as replacement parts and > this could also inject potential failures in re-addressing. > > If we were to use 3178 without a single global address space, > I still don't think this would scale as we then would be > using probably in the neighborhood of 50 or more ISP's (you > don't always get to pick your ISP's and while a country might > accept addressing from an industry block, they'd probably > insist on using theirs otherwise) around the world for the > service. And the way I read it, I would still have lots of > unnecessary backhauling to the other side of the planet and > some very complicated policy routing to set up. Besides and > then with mix of address spaces, I would probably be > perpetually leaking with the global Internet in what should > be a closed network. > > Finally at the moment with our existing certification > processes, I'm not sure that we would even be permitted to > change the aircraft addresses without re-issuing all the > affected software with new part numbers. (I'll bet you > assumed we used DHCP to address the current aircraft; nope we > hard code address everything, remember "bus engineering" 101 > ;-) With today's current rules, we haven't put any "critical > systems" on anything but a closed onboard network. We are > just discussing the ability upload new > IP_tables/firewall-rules and authentication certs/passwords > to the non-critical networks and I believe that this will be > solved in the next couple years. And now also keep in mind > that every aviation rule-making body around the world would > also have to approve of the address change for an ATC network > and define how they were going to certify the change. > > ====================================================================== > Finally now having said all this Jim, I think it is possible > for aviation to remain conforming. > > We have probably only two primary needs for stable IP > addressed networks; one for Air Traffic Control and one for > Airline Operations. These are industry traffic type > designations that have safety related functions that are > carried out over them. As we have discussed before, I expect > both of them to be run as "closed networks" and should never > (IMHO) be seen in the global routing tables; a closed network > will provide them with a layer of security, better routing > performance, the multi-homing that an aircraft needs, and > more options for mobility solutions. > > Further, two organizations already exist that could > legitimately hold the addresses; ICAO for the ATC network as > they already govern it and the AEEC for "airline operations" > whose members already essentially own "Arinc" which is an ISP > already. If it were possible to convince these orgs, to > apply for space and the registries to grant them, that would > seem to be a solution. > > Take care > Terry > > PS: Apologies for the length.. > > PSS: Back to "critical infrastructure" networks a moment, I'd > say that any network that wanted to declare itself "critical > infrastructure" could obtain PI space, BUT to me this type of > network should always be run as a "closed network" with > exchanges to the Internet only through "mediation gateways" > operating at the application level, not at the routing level. > Just food for thought but perhaps there is a class of IP-v6 > networks for "critical infrastructure" that have their own PI > space, but are prohibited from the participating in "Internet > routing". Such a concept might solve lots of problems. > > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > Sent: Saturday, April 08, 2006 5:52 AM > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); > > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > Brig, > > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > CERDEC > > STCD SRI; Bound, Jim > > Subject: RE: Question > > > > Tony, > > > > Excellent response and educational for sure. It is my > belief that the > > corporate business model today for operating networks may be broken > and > > I think you supported that below? If not my apologies for bad > parsing? > > > > > > Their models were fine for an IPv4 world where NAT was required and > some > > even confuse NAT with securing ones network (and some > programs in the > > U.S. Government) and that is simply bad policy and view. > > > > In the interim can this be resolved by RIRs creating some kind of > > additional wording that address reclaim will be done in > manner that is > > negotiable, and do no harm to corporate or government business > > operations? This would buy us time to work on the issue > and stop the > > FUD around this topic? > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > addressing you can lead as ajunct to one of our regular meetings you > can > > lead for an entire day and we get the right players in the > room. So > > think about that as another option too. > > > > But do enjoy the beach this thread does not have to be > resolved this > > week :--) > > > > Really want to hear from all of you and discussion Terry D., Latif, > > Yanick, Dave G. Mike B. etc. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > Sent: Friday, April 07, 2006 7:57 PM > > > To: 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > New Internet > > > based on IPv6")'; 'Davis, Terry L'; > ollivier.robert at eurocontrol.fr; > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > Subject: RE: Question > > > > > > A public answer to a private question as I have been sitting on a > > > beach for awhile without the laptop and missed some related > > > conversations ... :) > > > > > > > Is the outcome really open for discussion on the PI issue? > > > It doesn't > > > > sound like it is. > > > > > > In the minds of some the route scaling issue outweighs > any argument > > > for PI. When taken to its extreme, there is a valid point that a > > > broken routing system serves no one. At the same time the > dogmatic > > > stance by the ISPs enforcing lock-in is just as broken both for > > > large organizations with financial or legal requirements for > > > operational stability, and the individual consumer/small business > > > with limited budgets looking for true competition. The > hard part is > > > finding the middle ground in a way that limits the exposure to a > > > potential routing collapse. > > > > > > I personally refuse to declare some needs legitimate and > others not, > > > as the only point of such differentiation is to establish a power > > > broker. When all uses are legitimate, the problem boils > down to the > > > technical approach that can be scaled as necessary to > contain growth > > > in the routing system. This is the logic that leads me to the > > > bit-interleaved geo that can be aggregated in varying > size pockets > > > as necessary using existing BGP deployments. We can start > flat and > > > implement aggregation over time when a region becomes too > large to > > > handle. One nice side effect of this geo approach is that it > > > mitigates the continuing political demands for sovereign > rights to > > > IPv6 space. > > > > > > Any aggregation approach will force the business models to change > > > from current practice. That is not as bad a thing as the > alarmists > > > will make it out to be, because their accountants are > claiming the > > > current model is a broken money looser as it is (which if > so means > > > they will eventually change anyway). The primary > difference is that > > > there will need to be aggregation intermediaries between the > > > last-mile and transit providers. The current model > eliminates these > > > middle-men by trading off their routing mitigation > service against a > > > larger routing table (actually they already exist in the right > > > places but are currently limited to layer2 media > aggregators). The > > > anti-PI bunch is trying to use social engineering to directly > > > counter the bottom line business reality that the customer will > > > always win in the end. > > > Rather than accept this situation and constructively work on the > > > necessary business model and technology developments, they > > > effectively stall progress by staunchly claiming there is no > > > acceptable technical approach that works within the > current business > > > structure. > > > > > > Making the RIRs be the police deciding who qualifies for > PI and who > > > does not just adds to their workload and raises costs. The > > > beneficiaries of this gatekeeper approach are the ISPs that claim > > > they need full routing knowledge everywhere, while the > cost burden > > > for supporting the waste-of-time qualification/evaluation work is > > > borne by the applicant. Given that the most vocal and organized > > > membership in the RIR community are the ISPs it is easy to > > > understand why it would seem like the PI issue is already > decided as > > > closed. I tend to believe it will just drag out until > enough of the > > > corporate world becomes aware of the IPv4 exhaustion in light of > > > their growth needs that they collectively appear at their RIR and > > > demand an immediate solution. Unfortunately this 'wait > till the last > > > minute' tactic will likely result in a reactionary > quickie with its > > > own set of long term side effects. > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > > told that shim6 was the anointed solution. Now that at > least nanog > > > has told the IAB where to put shim6 it might be possible > to get the > > > current IESG to reconsider. In any case the result would be a > > > technical approach that would still require RIRs to establish > > > policies around. As long as they are dominated by the > ISPs it will > > > be difficult to get real PI. > > > > > > Tony > > > > > > > > ____ > > This message and any files transmitted with it are legally > privileged and intended for the sole use of the individual(s) > or entity to whom they are addressed. If you are not the > intended recipient, please notify the sender by reply and > delete the message and any attachments from your system. Any > unauthorised use or disclosure of the content of this message > is strictly prohibited and may be unlawful. > > Nothing in this e-mail message amounts to a contractual or > legal commitment on the part of EUROCONTROL, unless it is > confirmed by appropriately signed hard copy. > > Any views expressed in this message are those of the sender. > > > From Jim.Bound at hp.com Tue Apr 11 16:18:47 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Tue, 11 Apr 2006 10:18:47 -0400 Subject: [address-policy-wg] RE: Question - Aviation Message-ID: <936A4045C332714F975800409DE09240021C9612@tayexc14.americas.cpqcorp.net> Terry, I respectfully disagree closed networks can interfere with true end-to-end and end-to-end security, if not done very carefully with IPv6. Back at Digital we ran with global addresses (ok we had a Class A net 16) and implemented secure VPNs before they were popular in the late 80's and a form of IPsec with encryption. We had all the benefits of Firewalls just no "ADDRESS TRANSLATION". Your view of closed networks is far more dangerous than "potential" renumbering. Any network with globally routable addresses can be firewalled and protected it is not rocket science. But at the same time permits the end-to-end secure IP layer 3 model via IPsec as an option, which is the strongest security model we know of today from any cryptographer and black ops security analysts I speak with and quite often. This is also my position as SME (not HP) to the DOD per those furturistic networks for the GIG as one point of input to them . The only way to have global end-to-end which all enties should want is to have a pool of globally routable addresses and never use NAT again on the planet. That being said my view of Tony's proposal for PI space will not cause NAT but I want to be sure it is NAT bullet proof. Next to over abusive egoes/selfishness, elistism, and liars I think NAT is another great evil on the planet earth :--) (thats a joke ok). /jim > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > Sent: Tuesday, April 11, 2006 10:02 AM > To: CERASI Eivan; Bound, Jim; Tony Hain; PPML; > address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); ROBERT Ollivier; narten at us.ibm.com; Brig, Michael > P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > CERDEC STCD SRI > Subject: RE: [address-policy-wg] RE: Question - Aviation > > Eivan > > I don't think that I suggested changing anything that would > really impact you all. I just suggested the possibility of > formalizing the use of "closed networks" in my closing, I > would not expect it to impact you at all. > > Take care > Terry > > > -----Original Message----- > > From: CERASI Eivan [mailto:eivan.cerasi at eurocontrol.int] > > Sent: Tuesday, April 11, 2006 5:34 AM > > To: Davis, Terry L; Bound, Jim; Tony Hain; PPML; address-policy- > > wg at ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); > > ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; > > Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI > > Subject: RE: [address-policy-wg] RE: Question - Aviation > > > > Hello just to give you some status/complement on what we > are doing in > > Europe for air traffic management. > > > > EUROCONTROL (a European organization dealing with the safety of air > > navigation) has become LIR to obtain a /32. > > > > We have started using this address space for ground air traffic > > control unicast applications but take-up is slow due to the > nature of > > our environment. > > > > With regard to air-ground applications, we have launched > studies for a > > more global approach vis-?-vis air/ground applications and this is > > being performed in collaboration with ICAO working groups. > > > > Of course our primary goal is to enable an IP service for > air traffic > > control communications, not passenger nor airline > communications. As > > our environment is highly conservative, technology changes are very > > slow especially if they have to be global. Our European strategy is > > that IPv6 is our final target for all communications but > our X.25 will > > still be around for another few years and our IPv4 for even more. > > > > It is correct to state that our safety critical > applications operate > > in a closed environment as opposed to the use of classical > internet services. > > However we do have exchanges with internet customers (airlines) via > > dedicated means. Clearly, both IP routing environments are isolated > > from each other. > > > > To come back on one of the points that was raised below, I > do not see > > the benefit of creating a dedicated address space for such type of > > applications (just as RFC1918 provides private address > space for IPv4). > > For me, it would just increase the end-user perceived > complexity of IPv6. > > In doing so, you would already cause us a problem of having > to change > > something we have already put into operations ! > > > > > > Best regards > > Eivan Cerasi > > > > -----Original Message----- > > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > > admin at ripe.net] On Behalf Of Davis, Terry L > > Sent: Monday 10 April 2006 22:13 > > To: Bound, Jim; Tony Hain; PPML; address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); > > ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; > > Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI > > Subject: [address-policy-wg] RE: Question - Aviation > > > > > > Jim/All > > > > I am going to respond in two parts here on PI issues; one > in terms of > > aviation and one in terms of corporate. This one is on aviation. > > > > The next two paragraphs are from an original response to Thomas > > Narten, that I didn't see make the list. > > > > ---- > > I view systems that run "critical infrastructure" entirely > different > > from those used to run anything else; especially systems that can > > directly impact the safety of the people using or relying on them. > > > > Safety engineering is just like security engineering; both > depend on > > our ability to build in layers of defense and reliability trying to > > never rely entirely on a single system. By forcing an > industry like > > aviation to accept the potential of address changing in a global > > fleet, an element of extreme risk is added as the system's > overall reliability is decreased. > > ---- > > > > We know that in the next decade that there will be development > > initiated for a new air traffic control system. It will likely be > > built upon IP and if so, likely IP-v6. And ICAO currently has a > > working group studying this and the committee is leaning > towards IP-v6 > > although there is a strong component that is pushing for > IP-v4 and a > > continuation the NAT type usage currently required in the aviation > > industry by Arinc 664. And I do definitely agree with Jim here, the > > use IP-v4 and NAT would create huge risks; if in nothing else, the > > potential for mis-addressing through one of the hundreds of > NAT gateways that would be required. > > > > I'll respectfully disagree with Jim in that I believe > address change > > in a complex global system like air traffic control can create a > > hazard. Keep in mind, that the air traffic control system spans > > virtually every nation on globe and most everything manmade that > > flies. Likewise the technical and operational capabilities > vary from > > extraordinary to very minimal; like the 30 or so aviation operators > > that the EU just banned from flying into EU countries > because of their > > poor safety and maintenance performance record. > > > > Coordinating an address change across this type of > infrastructure with > > aircraft and ground infrastructure in almost every nation on the > > globe, is simply beyond my ability comprehend. Assuming the > > technology would work flawlessly (discussed below), the politics of > > when and how to implement the change would likely end up on > the floor of the UN for debate. > > Likewise, if a decision was made to implement a change, we would be > > dealing with such different levels of expertise around the > world that > > no amount of pre-planning could ensure that implementation failures > > would not occur. > > > > Now just a bit about where ATC systems are likely going and > why their > > criticality will likely grow over the next couple decades. > Unless we > > suddenly develop anti-gravity capabilities to allow slow vertical > > takeoffs, we are stuck with the airports we have and only minimal > > abilities to expand them (cost, environmental, noise, etc). > The only > > real way we can expand their capacity is with bigger airplanes and > > more flights. The "more flights" part is where this gets > complicated > > and critical. To handle more flights, we have to decrease > landing and > > takeoff separations and speed up aircraft ground movements so an > > airport can handle more aircraft per hour. We are about to human > > capacity with the current systems which means that these > improvements > > will need to move more and more to relying on precise > control systems; > > a minutes interruption here will be a really big deal. > > > > Also we as an industry are just beginning to migrate from bus data > > communications on the aircraft to networks. The commercial > aircraft > > flying today are already largely computer controlled and as I > > mentioned above we try very hard not design the aircraft to be > > critically reliant on any one system. In almost all cases, it > > requires a cascading series of failures to present an > aircraft with a > > catastrophic hazard. Now as I said, we are starting to put > networks > > on the aircraft and as Arinc 664 shows; we are not the world's > > greatest network engineers (at least not yet..). In a > decade or so, we will have hundreds of networked systems on > an aircraft. > > I think the risk here in re-addressing is clear; how well will they > > all react. And yes we can probably take most of the risk down in > > certification testing but keep in mind variation in technical > > competence of the operators around the world and that we are > > continually accepting upgraded systems from our vendors as > replacement > > parts and this could also inject potential failures in > re-addressing. > > > > If we were to use 3178 without a single global address > space, I still > > don't think this would scale as we then would be using > probably in the > > neighborhood of 50 or more ISP's (you don't always get to pick your > > ISP's and while a country might accept addressing from an industry > > block, they'd probably insist on using theirs otherwise) around the > > world for the service. And the way I read it, I would > still have lots > > of unnecessary backhauling to the other side of the planet and some > > very complicated policy routing to set up. Besides and > then with mix > > of address spaces, I would probably be perpetually leaking with the > > global Internet in what should be a closed network. > > > > Finally at the moment with our existing certification > processes, I'm > > not sure that we would even be permitted to change the aircraft > > addresses without re-issuing all the affected software with > new part > > numbers. (I'll bet you assumed we used DHCP to address the current > > aircraft; nope we hard code address everything, remember "bus > > engineering" 101 ;-) With today's current rules, we haven't put any > > "critical systems" on anything but a closed onboard > network. We are > > just discussing the ability upload new IP_tables/firewall-rules and > > authentication certs/passwords to the non- critical networks and I > > believe that this will be solved in the next couple years. And now > > also keep in mind that every aviation rule-making body around the > > world would also have to approve of the address change for > an ATC network and define how they were going to certify the change. > > > > > ====================================================================== > > Finally now having said all this Jim, I think it is possible for > > aviation to remain conforming. > > > > We have probably only two primary needs for stable IP addressed > > networks; one for Air Traffic Control and one for Airline > Operations. > > These are industry traffic type designations that have > safety related > > functions that are carried out over them. As we have discussed > > before, I expect both of them to be run as "closed networks" and > > should never > > (IMHO) be seen in the global routing tables; a closed network will > > provide them with a layer of security, better routing > performance, the > > multi- homing that an aircraft needs, and more options for > mobility solutions. > > > > Further, two organizations already exist that could > legitimately hold > > the addresses; ICAO for the ATC network as they already > govern it and > > the AEEC for "airline operations" whose members already > essentially own "Arinc" > > which is an ISP already. If it were possible to convince > these orgs, > > to apply for space and the registries to grant them, that > would seem > > to be a solution. > > > > Take care > > Terry > > > > PS: Apologies for the length.. > > > > PSS: Back to "critical infrastructure" networks a moment, > I'd say that > > any network that wanted to declare itself "critical infrastructure" > > could obtain PI space, BUT to me this type of network > should always be > > run as a "closed network" with exchanges to the Internet > only through > > "mediation gateways" operating at the application level, > not at the routing level. > > Just food for thought but perhaps there is a class of IP-v6 > networks > > for "critical infrastructure" that have their own PI space, but are > > prohibited from the participating in "Internet routing". Such a > > concept might solve lots of problems. > > > > > > > > > -----Original Message----- > > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > > Sent: Saturday, April 08, 2006 5:52 AM > > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on > > > IPv6"); Davis, Terry L; ollivier.robert at eurocontrol.fr; > > > narten at us.ibm.com; > > Brig, > > > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > > CERDEC > > > STCD SRI; Bound, Jim > > > Subject: RE: Question > > > > > > Tony, > > > > > > Excellent response and educational for sure. It is my > belief that > > > the corporate business model today for operating networks may be > > > broken > > and > > > I think you supported that below? If not my apologies for bad > > parsing? > > > > > > > > > Their models were fine for an IPv4 world where NAT was > required and > > some > > > even confuse NAT with securing ones network (and some programs in > > > the U.S. Government) and that is simply bad policy and view. > > > > > > In the interim can this be resolved by RIRs creating some kind of > > > additional wording that address reclaim will be done in > manner that > > > is negotiable, and do no harm to corporate or government business > > > operations? This would buy us time to work on the issue and stop > > > the FUD around this topic? > > > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF > on PI and > > > addressing you can lead as ajunct to one of our regular > meetings you > > can > > > lead for an entire day and we get the right players in > the room. So > > > think about that as another option too. > > > > > > But do enjoy the beach this thread does not have to be > resolved this > > > week :--) > > > > > > Really want to hear from all of you and discussion Terry > D., Latif, > > > Yanick, Dave G. Mike B. etc. > > > > > > Thanks > > > /jim > > > > > > > -----Original Message----- > > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > > Sent: Friday, April 07, 2006 7:57 PM > > > > To: 'PPML'; address-policy-wg at ripe.net > > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New > > > > Internet based on IPv6")'; 'Davis, Terry L'; > > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > 'Brig, Michael > > > > P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > RDECOM CERDEC STCD SRI' > > > > Subject: RE: Question > > > > > > > > A public answer to a private question as I have been > sitting on a > > > > beach for awhile without the laptop and missed some related > > > > conversations ... :) > > > > > > > > > Is the outcome really open for discussion on the PI issue? > > > > It doesn't > > > > > sound like it is. > > > > > > > > In the minds of some the route scaling issue outweighs any > > > > argument for PI. When taken to its extreme, there is a > valid point > > > > that a broken routing system serves no one. At the same > time the > > > > dogmatic stance by the ISPs enforcing lock-in is just as broken > > > > both for large organizations with financial or legal > requirements > > > > for operational stability, and the individual consumer/small > > > > business with limited budgets looking for true competition. The > > > > hard part is finding the middle ground in a way that limits the > > > > exposure to a potential routing collapse. > > > > > > > > I personally refuse to declare some needs legitimate and others > > > > not, as the only point of such differentiation is to > establish a > > > > power broker. When all uses are legitimate, the problem > boils down > > > > to the technical approach that can be scaled as necessary to > > > > contain growth in the routing system. This is the logic > that leads > > > > me to the bit-interleaved geo that can be aggregated in varying > > > > size pockets as necessary using existing BGP > deployments. We can > > > > start flat and implement aggregation over time when a region > > > > becomes too large to handle. One nice side effect of this geo > > > > approach is that it mitigates the continuing political > demands for > > > > sovereign rights to IPv6 space. > > > > > > > > Any aggregation approach will force the business models > to change > > > > from current practice. That is not as bad a thing as > the alarmists > > > > will make it out to be, because their accountants are > claiming the > > > > current model is a broken money looser as it is (which > if so means > > > > they will eventually change anyway). The primary difference is > > > > that there will need to be aggregation intermediaries > between the > > > > last-mile and transit providers. The current model eliminates > > > > these middle-men by trading off their routing > mitigation service > > > > against a larger routing table (actually they already > exist in the > > > > right places but are currently limited to layer2 media > > > > aggregators). The anti-PI bunch is trying to use social > > > > engineering to directly counter the bottom line > business reality > > > > that the customer will always win in the end. > > > > Rather than accept this situation and constructively > work on the > > > > necessary business model and technology developments, they > > > > effectively stall progress by staunchly claiming there is no > > > > acceptable technical approach that works within the current > > > > business structure. > > > > > > > > Making the RIRs be the police deciding who qualifies for PI and > > > > who does not just adds to their workload and raises costs. The > > > > beneficiaries of this gatekeeper approach are the ISPs > that claim > > > > they need full routing knowledge everywhere, while the > cost burden > > > > for supporting the waste-of-time > qualification/evaluation work is > > > > borne by the applicant. Given that the most vocal and organized > > > > membership in the RIR community are the ISPs it is easy to > > > > understand why it would seem like the PI issue is > already decided > > > > as closed. I tend to believe it will just drag out > until enough of > > > > the corporate world becomes aware of the IPv4 > exhaustion in light > > > > of their growth needs that they collectively appear at > their RIR > > > > and demand an immediate solution. Unfortunately this 'wait till > > > > the last minute' tactic will likely result in a reactionary > > > > quickie with its own set of long term side effects. > > > > > > > > A while back I tried to hold a BOF on geo PI in the > IETF, but was > > > > told that shim6 was the anointed solution. Now that at > least nanog > > > > has told the IAB where to put shim6 it might be possible to get > > > > the current IESG to reconsider. In any case the result > would be a > > > > technical approach that would still require RIRs to establish > > > > policies around. As long as they are dominated by the > ISPs it will > > > > be difficult to get real PI. > > > > > > > > Tony > > > > > > > > > > > > ____ > > > > This message and any files transmitted with it are legally > privileged > > and intended for the sole use of the individual(s) or > entity to whom > > they are addressed. If you are not the intended recipient, please > > notify the sender by reply and delete the message and any > attachments > > from your system. Any unauthorised use or disclosure of the > content of > > this message is strictly prohibited and may be unlawful. > > > > Nothing in this e-mail message amounts to a contractual or legal > > commitment on the part of EUROCONTROL, unless it is confirmed by > > appropriately signed hard copy. > > > > Any views expressed in this message are those of the sender. > > > > From Jim.Bound at hp.com Tue Apr 11 16:21:58 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Tue, 11 Apr 2006 10:21:58 -0400 Subject: [address-policy-wg] RE: Question Message-ID: <936A4045C332714F975800409DE09240021C961D@tayexc14.americas.cpqcorp.net> Tony, Thank you very much. I am in China now (I think you are too?) and after tonight I probably won't be capable of to much mail till I get back to the U.S. Saturday. If we do have to do this then great and appreciate it and we can work with Terry and the CTO-EXCOM too. Thanks Again, /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf at tndh.net] > Sent: Tuesday, April 11, 2006 10:17 AM > To: Bound, Jim; 'Ray Plzak'; 'Latif Ladid ("The New Internet > based on IPv6")'; 'PPML'; address-policy-wg at ripe.net > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > Michael P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > RDECOM CERDEC STCD SRI' > Subject: RE: [address-policy-wg] RE: Question > > Jim, > > I will let Ray answer the question about individuals, but for > the purposes of this discussion I am willing to do the leg > work for any policy proposal that the task force thinks would > be helpful. As of yesterday's vote it is clear that the ARIN > AC will be working on the finishing touches for a basic PI > policy, and I am already working with Scott Leibrand and a > few others on a companion policy about how to manage the > designated PI block to minimize long term routing impact. > > Tony > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > Sent: Tuesday, April 11, 2006 6:30 AM > > To: Ray Plzak; Latif Ladid ("The New Internet based on IPv6"); Tony > > Hain; PPML; address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Davis, Terry L; > ollivier.robert at eurocontrol.fr; > > narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; > Pouffary, Yanick; > > Green, David B RDECOM CERDEC STCD SRI; Bound, Jim > > Subject: RE: [address-policy-wg] RE: Question > > > > Ray, So you don't take IETF direction but only from > individuals in the > > IETF? Just want this to be clarified very clearly. This also does > > not preclude the IPv6 Forum stating a public position on the issue > > whether RIRs react to it or not. Not that will happen but > it could if > > the pain is strong enough to prohibit IPv6 deployment. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Ray Plzak [mailto:plzak at arin.net] > > > Sent: Monday, April 10, 2006 6:56 AM > > > To: 'Latif Ladid ("The New Internet based on IPv6")'; Bound, Jim; > > > 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > Michael P > > > CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B RDECOM CERDEC > > > STCD SRI' > > > Subject: RE: [address-policy-wg] RE: Question > > > > > > The NAv6TF is in the ARIN region. If individuals > associated with it > > > think that ARIN should adopt a policy or change an > existing policy > > > they should not only say so they should propose such a policy. > > > Remember policies in the ARIN region, like in all of the RIRs is > > > made not by the RIR organization staff and board but by the > > > community in the region. ARIN staff will be more than > happy to help > > > anyone through the process, which by the way, while an > orderly and > > > formal process is not onerous, but one designed to provide for an > > > open and honest discussion of any policy proposal before it is > > > adopted. If you are interested in pursuing this, please > contact me > > > and I will get a staff member to assist you. > > > > > > Ray > > > > > > > -----Original Message----- > > > > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg- > > > > admin at ripe.net] On Behalf Of Latif Ladid ("The New > Internet based > > > > on > > > > IPv6") > > > > Sent: Saturday, April 08, 2006 9:53 AM > > > > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; > address-policy-wg at ripe.net > > > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > 'Brig, Michael > > > > P CIV DISA GES-E'; 'Pouffary, Yanick'; 'Green, David B RDECOM > > > CERDEC STCD SRI' > > > > Subject: [address-policy-wg] RE: Question > > > > > > > > > > > > > > > > The technical community should fix this one before the ITU > > > sees this > > > > as another chance to have a political say on the IPv6 > addressing. > > > > These things leak fast. My advice is that ARIN should seriously > > > > own this issue before the ITU turns it to a sovereignty issue, > > > which they > > > > could for sure win this time. I know one of their noodles > > > is sizzling > > > > at it. > > > > > > > > Cheers > > > > Latif > > > > > > > > -----Original Message----- > > > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > > > Sent: 08 April 2006 14:52 > > > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > > on IPv6"); > > > > Davis, Terry L; ollivier.robert at eurocontrol.fr; > narten at us.ibm.com; > > > > Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; > Green, David B > > > > RDECOM CERDEC STCD SRI; Bound, Jim > > > > Subject: RE: Question > > > > > > > > Tony, > > > > > > > > Excellent response and educational for sure. It is my > > > belief that the > > > > corporate business model today for operating networks may be > > > > broken and I think you supported that below? If not my > apologies > > > for bad parsing? > > > > > > > > > > > > Their models were fine for an IPv4 world where NAT was required > > > > and some even confuse NAT with securing ones network (and some > > > programs in the U.S. > > > > Government) and that is simply bad policy and view. > > > > > > > > In the interim can this be resolved by RIRs creating > some kind of > > > > additional wording that address reclaim will be done in > > > manner that is > > > > negotiable, and do no harm to corporate or government business > > > > operations? This would buy us time to work on the issue > > > and stop the > > > > FUD around this topic? > > > > > > > > Also I am willing to sponsor a world wide IPv6 Forum > BOF on PI and > > > > addressing you can lead as ajunct to one of our regular > > > meetings you > > > > can lead for an entire day and we get the right players in > > > the room. > > > > So think about that as another option too. > > > > > > > > But do enjoy the beach this thread does not have to be > > > resolved this > > > > week > > > > :--) > > > > > > > > Really want to hear from all of you and discussion Terry D., > > > > Latif, Yanick, Dave G. Mike B. etc. > > > > > > > > Thanks > > > > /jim > > > > > > > > > -----Original Message----- > > > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > > > Sent: Friday, April 07, 2006 7:57 PM > > > > > To: 'PPML'; address-policy-wg at ripe.net > > > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > > > New Internet > > > > > based on IPv6")'; 'Davis, Terry L'; > > > ollivier.robert at eurocontrol.fr; > > > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; > Pouffary, > > > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > > > Subject: RE: Question > > > > > > > > > > A public answer to a private question as I have been > sitting on > > > > > a beach for awhile without the laptop and missed some related > > > > > conversations ... :) > > > > > > > > > > > Is the outcome really open for discussion on the PI issue? > > > > > It doesn't > > > > > > sound like it is. > > > > > > > > > > In the minds of some the route scaling issue outweighs > > > any argument > > > > > for PI. > > > > > When taken to its extreme, there is a valid point > that a broken > > > > > routing system serves no one. At the same time the > > > dogmatic stance > > > > > by the ISPs enforcing lock-in is just as broken both > for large > > > > > organizations with financial or legal requirements for > > > operational > > > > > stability, and the individual consumer/small business > > > with limited > > > > > budgets looking for true competition. The hard part is > > > finding the > > > > > middle ground in a way that limits the exposure to a > potential > > > > > routing collapse. > > > > > > > > > > I personally refuse to declare some needs legitimate and > > > others not, > > > > > as the only point of such differentiation is to establish a > > > > > power broker. When all uses are legitimate, the problem boils > > > down to the > > > > > technical approach that can be scaled as necessary to > > > contain growth > > > > > in the routing system. > > > > > This is the logic that leads me to the bit-interleaved > > > geo that can > > > > > be aggregated in varying size pockets as necessary using > > > > > existing BGP deployments. We can start flat and implement > > > > > aggregation over time when a region becomes too large > to handle. > > > > > One nice > > > side effect > > > > > of this geo approach is that it mitigates the continuing > > > political > > > > > demands for sovereign rights to IPv6 space. > > > > > > > > > > Any aggregation approach will force the business models to > > > > > change from current practice. That is not as bad a > thing as the > > > alarmists > > > > > will make it out to be, because their accountants are > > > claiming the > > > > > current model is a broken money looser as it is (which if > > > so means > > > > > they will eventually change anyway). The primary > > > difference is that > > > > > there will need to be aggregation intermediaries between the > > > > > last-mile and transit providers. The current model > > > eliminates these > > > > > middle-men by trading off their routing mitigation > > > service against a > > > > > larger routing table (actually they already exist in > the right > > > > > places but are currently limited to layer2 media > > > aggregators). The > > > > > anti-PI bunch is trying to use social engineering to directly > > > > > counter the bottom line business reality that the > > > customer will always win in the end. > > > > > Rather than accept this situation and constructively > work on the > > > > > necessary business model and technology developments, they > > > > > effectively stall progress by staunchly claiming there is no > > > > > acceptable technical approach that works within the > > > current business structure. > > > > > > > > > > Making the RIRs be the police deciding who qualifies for > > > PI and who > > > > > does not just adds to their workload and raises costs. The > > > > > beneficiaries of this gatekeeper approach are the ISPs that > > > > > claim they need full routing knowledge everywhere, while the > > > cost burden > > > > > for supporting the waste-of-time > qualification/evaluation work > > > > > is borne by the applicant. > > > > > Given that the most vocal and organized membership in the RIR > > > > > community are the ISPs it is easy to understand why it would > > > > > seem like the PI issue is already decided as closed. I tend to > > > believe it > > > > > will just drag out until enough of the corporate world > > > becomes aware > > > > > of the > > > > > IPv4 exhaustion in light of their growth needs that they > > > > > collectively appear at their RIR and demand an immediate > > > solution. > > > > > Unfortunately this 'wait till the last minute' tactic will > > > > > likely result in a reactionary quickie with its own > set of long > > > term side effects. > > > > > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but > > > > > was told that > > > > > shim6 was the anointed solution. Now that at least nanog has > > > > > told the IAB where to put shim6 it might be possible to get > > > the current > > > > > IESG to reconsider. In any case the result would be a > technical > > > > > approach that would still require RIRs to establish > > > policies around. > > > > > As long as they are dominated by the ISPs it will be > > > difficult to get real PI. > > > > > > > > > > Tony > > > > > > > > > > > > > > > > > > From terry.l.davis at boeing.com Tue Apr 11 18:08:35 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 11 Apr 2006 09:08:35 -0700 Subject: [address-policy-wg] RE: Question - Aviation In-Reply-To: <936A4045C332714F975800409DE09240021C95C6@tayexc14.americas.cpqcorp.net> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BEB4@XCH-NW-8V1.nw.nos.boeing.com> Jim On the private addressing, we are 100% in agreement. At least myself, I don't equate a "closed network" to anything resembling "private addressing". I like the idea of a face-to-face meeting hopefully with lots of white board space. Take care Terry > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound at hp.com] > Sent: Tuesday, April 11, 2006 6:54 AM > To: Davis, Terry L; Tony Hain; PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; Brig, Michael P CIV > DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI; Bound, > Jim > Subject: RE: Question - Aviation > > Thanks Terry. Good disagreement but I stand solid on my view. Note I > did not say an address change would be transparent what I said is there > should be legal binding methods that do not permit any RIR to disrupt > any business. Meaning there would be no change that would affect > production systems unless planned, that would prevent saftey issues. > > Regarding RIRs providing PI space I am soft against not hard liner. I > do not want to see private addresses ever again on the Internet anywhere > it prevents true end-to-end. > > I think we need to coordinate a time and place to have this debate and > resulting effort discussed with all defending their views in person. > Problem is we are all tapped with Travel now. > > Best, > /jim > > > -----Original Message----- > > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > > Sent: Monday, April 10, 2006 4:13 PM > > To: Bound, Jim; Tony Hain; PPML; address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > on IPv6"); ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > > Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; Green, > > David B RDECOM CERDEC STCD SRI > > Subject: RE: Question - Aviation > > > > Jim/All > > > > I am going to respond in two parts here on PI issues; one in > > terms of aviation and one in terms of corporate. This one is > > on aviation. > > > > The next two paragraphs are from an original response to > > Thomas Narten, that I didn't see make the list. > > > > ---- > > I view systems that run "critical infrastructure" entirely > > different from those used to run anything else; especially > > systems that can directly impact the safety of the people > > using or relying on them. > > > > Safety engineering is just like security engineering; both > > depend on our ability to build in layers of defense and > > reliability trying to never rely entirely on a single system. > > By forcing an industry like aviation to accept the potential > > of address changing in a global fleet, an element of extreme > > risk is added as the system's overall reliability is decreased. > > ---- > > > > We know that in the next decade that there will be > > development initiated for a new air traffic control system. > > It will likely be built upon IP and if so, likely IP-v6. And > > ICAO currently has a working group studying this and the > > committee is leaning towards IP-v6 although there is a strong > > component that is pushing for IP-v4 and a continuation the > > NAT type usage currently required in the aviation industry by > > Arinc 664. > > And I do definitely agree with Jim here, the use IP-v4 and > > NAT would create huge risks; if in nothing else, the > > potential for mis-addressing through one of the hundreds of > > NAT gateways that would be required. > > > > I'll respectfully disagree with Jim in that I believe address > > change in a complex global system like air traffic control > > can create a hazard. > > Keep in mind, that the air traffic control system spans > > virtually every nation on globe and most everything manmade > > that flies. Likewise the technical and operational > > capabilities vary from extraordinary to very minimal; like > > the 30 or so aviation operators that the EU just banned from > > flying into EU countries because of their poor safety and > > maintenance performance record. > > > > Coordinating an address change across this type of > > infrastructure with aircraft and ground infrastructure in > > almost every nation on the globe, is simply beyond my ability > > comprehend. Assuming the technology would work flawlessly > > (discussed below), the politics of when and how to implement > > the change would likely end up on the floor of the UN for > > debate. Likewise, if a decision was made to implement a > > change, we would be dealing with such different levels of > > expertise around the world that no amount of pre-planning > > could ensure that implementation failures would not occur. > > > > Now just a bit about where ATC systems are likely going and > > why their criticality will likely grow over the next couple > > decades. Unless we suddenly develop anti-gravity > > capabilities to allow slow vertical takeoffs, we are stuck > > with the airports we have and only minimal abilities to > > expand them (cost, environmental, noise, etc). The only real > > way we can expand their capacity is with bigger airplanes and > > more flights. The "more flights" part is where this gets > > complicated and critical. To handle more flights, we have to > > decrease landing and takeoff separations and speed up > > aircraft ground movements so an airport can handle more > > aircraft per hour. We are about to human capacity with the > > current systems which means that these improvements will need > > to move more and more to relying on precise control systems; > > a minutes interruption here will be a really big deal. > > > > Also we as an industry are just beginning to migrate from bus > > data communications on the aircraft to networks. The > > commercial aircraft flying today are already largely computer > > controlled and as I mentioned above we try very hard not > > design the aircraft to be critically reliant on any one > > system. In almost all cases, it requires a cascading series > > of failures to present an aircraft with a catastrophic > > hazard. Now as I said, we are starting to put networks on > > the aircraft and as Arinc 664 shows; we are not the world's > > greatest network engineers (at least not yet..). In a decade > > or so, we will have hundreds of networked systems on an > > aircraft. I think the risk here in re-addressing is clear; > > how well will they all react. And yes we can probably take > > most of the risk down in certification testing but keep in > > mind variation in technical competence of the operators > > around the world and that we are continually accepting > > upgraded systems from our vendors as replacement parts and > > this could also inject potential failures in re-addressing. > > > > If we were to use 3178 without a single global address space, > > I still don't think this would scale as we then would be > > using probably in the neighborhood of 50 or more ISP's (you > > don't always get to pick your ISP's and while a country might > > accept addressing from an industry block, they'd probably > > insist on using theirs otherwise) around the world for the > > service. And the way I read it, I would still have lots of > > unnecessary backhauling to the other side of the planet and > > some very complicated policy routing to set up. Besides and > > then with mix of address spaces, I would probably be > > perpetually leaking with the global Internet in what should > > be a closed network. > > > > Finally at the moment with our existing certification > > processes, I'm not sure that we would even be permitted to > > change the aircraft addresses without re-issuing all the > > affected software with new part numbers. > > (I'll bet you assumed we used DHCP to address the current > > aircraft; nope we hard code address everything, remember "bus > > engineering" 101 ;-) With today's current rules, we haven't > > put any "critical systems" on anything but a closed onboard > > network. We are just discussing the ability upload new > > IP_tables/firewall-rules and authentication certs/passwords > > to the non-critical networks and I believe that this will be > > solved in the next couple years. And now also keep in mind > > that every aviation rule-making body around the world would > > also have to approve of the address change for an ATC network > > and define how they were going to certify the change. > > > > ====================================================================== > > Finally now having said all this Jim, I think it is possible > > for aviation to remain conforming. > > > > We have probably only two primary needs for stable IP > > addressed networks; one for Air Traffic Control and one for > > Airline Operations. > > These are industry traffic type designations that have safety > > related functions that are carried out over them. As we have > > discussed before, I expect both of them to be run as "closed > > networks" and should never > > (IMHO) be seen in the global routing tables; a closed network > > will provide them with a layer of security, better routing > > performance, the multi-homing that an aircraft needs, and > > more options for mobility solutions. > > > > Further, two organizations already exist that could > > legitimately hold the addresses; ICAO for the ATC network as > > they already govern it and the AEEC for "airline operations" > > whose members already essentially own "Arinc" which is an ISP > > already. If it were possible to convince these orgs, to > > apply for space and the registries to grant them, that would > > seem to be a solution. > > > > Take care > > Terry > > > > PS: Apologies for the length.. > > > > PSS: Back to "critical infrastructure" networks a moment, I'd > > say that any network that wanted to declare itself "critical > > infrastructure" > > could obtain PI space, BUT to me this type of network should > > always be run as a "closed network" with exchanges to the > > Internet only through "mediation gateways" operating at the > > application level, not at the routing level. Just food for > > thought but perhaps there is a class of > > IP-v6 networks for "critical infrastructure" that have their > > own PI space, but are prohibited from the participating in > > "Internet routing". > > Such a concept might solve lots of problems. > > > > > > > > > -----Original Message----- > > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > > Sent: Saturday, April 08, 2006 5:52 AM > > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > on IPv6"); > > > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > > Brig, > > > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > > CERDEC > > > STCD SRI; Bound, Jim > > > Subject: RE: Question > > > > > > Tony, > > > > > > Excellent response and educational for sure. It is my > > belief that the > > > corporate business model today for operating networks may be broken > > and > > > I think you supported that below? If not my apologies for bad > > parsing? > > > > > > > > > Their models were fine for an IPv4 world where NAT was required and > > some > > > even confuse NAT with securing ones network (and some > > programs in the > > > U.S. Government) and that is simply bad policy and view. > > > > > > In the interim can this be resolved by RIRs creating some kind of > > > additional wording that address reclaim will be done in > > manner that is > > > negotiable, and do no harm to corporate or government business > > > operations? This would buy us time to work on the issue > > and stop the > > > FUD around this topic? > > > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > > addressing you can lead as ajunct to one of our regular meetings you > > can > > > lead for an entire day and we get the right players in the > > room. So > > > think about that as another option too. > > > > > > But do enjoy the beach this thread does not have to be > > resolved this > > > week :--) > > > > > > Really want to hear from all of you and discussion Terry D., Latif, > > > Yanick, Dave G. Mike B. etc. > > > > > > Thanks > > > /jim > > > > > > > -----Original Message----- > > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > > Sent: Friday, April 07, 2006 7:57 PM > > > > To: 'PPML'; address-policy-wg at ripe.net > > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > > New Internet > > > > based on IPv6")'; 'Davis, Terry L'; > > ollivier.robert at eurocontrol.fr; > > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > > Subject: RE: Question > > > > > > > > A public answer to a private question as I have been sitting on a > > > > beach for awhile without the laptop and missed some related > > > > conversations ... :) > > > > > > > > > Is the outcome really open for discussion on the PI issue? > > > > It doesn't > > > > > sound like it is. > > > > > > > > In the minds of some the route scaling issue outweighs > > any argument > > > > for PI. > > > > When taken to its extreme, there is a valid point that a broken > > > > routing system serves no one. At the same time the > > dogmatic stance > > > > by the ISPs enforcing lock-in is just as broken both for large > > > > organizations with financial or legal requirements for > > operational > > > > stability, and the individual consumer/small business > > with limited > > > > budgets looking for true competition. The hard part is > > finding the > > > > middle ground in a way that limits the exposure to a potential > > > > routing collapse. > > > > > > > > I personally refuse to declare some needs legitimate and > > others not, > > > > as the only point of such differentiation is to establish a power > > > > broker. When all uses are legitimate, the problem boils > > down to the > > > > technical approach that can be scaled as necessary to > > contain growth > > > > in the routing system. > > > > This is the logic that leads me to the bit-interleaved > > geo that can > > > > be aggregated in varying size pockets as necessary using existing > > > > BGP deployments. We can start flat and implement aggregation over > > > > time when a region becomes too large to handle. One nice > > side effect > > > > of this geo approach is that it mitigates the continuing > > political > > > > demands for sovereign rights to IPv6 space. > > > > > > > > Any aggregation approach will force the business models to change > > > > from current practice. That is not as bad a thing as the > > alarmists > > > > will make it out to be, because their accountants are > > claiming the > > > > current model is a broken money looser as it is (which if > > so means > > > > they will eventually change anyway). The primary > > difference is that > > > > there will need to be aggregation intermediaries between the > > > > last-mile and transit providers. The current model > > eliminates these > > > > middle-men by trading off their routing mitigation > > service against a > > > > larger routing table (actually they already exist in the right > > > > places but are currently limited to layer2 media > > aggregators). The > > > > anti-PI bunch is trying to use social engineering to directly > > > > counter the bottom line business reality that the customer will > > > > always win in the end. > > > > Rather than accept this situation and constructively work on the > > > > necessary business model and technology developments, they > > > > effectively stall progress by staunchly claiming there is no > > > > acceptable technical approach that works within the > > current business > > > > structure. > > > > > > > > Making the RIRs be the police deciding who qualifies for > > PI and who > > > > does not just adds to their workload and raises costs. The > > > > beneficiaries of this gatekeeper approach are the ISPs that claim > > > > they need full routing knowledge everywhere, while the > > cost burden > > > > for supporting the waste-of-time qualification/evaluation work is > > > > borne by the applicant. > > > > Given that the most vocal and organized membership in the RIR > > > > community are the ISPs it is easy to understand why it would seem > > > > like the PI issue is already decided as closed. I tend to > > believe it > > > > will just drag out until enough of the corporate world > > becomes aware > > > > of the IPv4 exhaustion in light of their growth needs that they > > > > collectively appear at their RIR and demand an immediate > > solution. > > > > Unfortunately this 'wait till the last minute' tactic will likely > > > > result in a reactionary quickie with its own set of long > > term side > > > > effects. > > > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > > > told that > > > > shim6 was the anointed solution. Now that at least nanog has told > > > > the IAB where to put shim6 it might be possible to get > > the current > > > > IESG to reconsider. In any case the result would be a technical > > > > approach that would still require RIRs to establish > > policies around. > > > > As long as they are dominated by the ISPs it will be difficult to > > > > get real PI. > > > > > > > > Tony > > > > > > > > > > From Dave.B.Green at us.army.mil Tue Apr 11 20:25:05 2006 From: Dave.B.Green at us.army.mil (Green, David B RDECOM CERDEC STCD SRI) Date: Tue, 11 Apr 2006 14:25:05 -0400 Subject: [address-policy-wg] RE: Question Message-ID: >From a technical standpoint, can't you multihome and use PA addresses for external comms and also create a numbering solution for provider independent internal numbering for critical systems by using RFC 4193 Unique Local IPv6 Unicast Addresses http://www.ietf.org/rfc/rfc4193.txt ? I thought this RFC was created to handle a provider independent internal numbering solution within a single routing domain (AKA North American Air Traffic Control) or other large critical operations enterprise. ~~~~~~~~~~~~~~~~~~~~ >From RFC 4193: Local IPv6 unicast addresses have the following characteristics: - Globally unique prefix (with high probability of uniqueness). - Well-known prefix to allow for easy filtering at site boundaries. - Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of interfaces that use these prefixes. - Internet Service Provider independent and can be used for communications inside of a site without having any permanent or intermittent Internet connectivity. - If accidentally leaked outside of a site via routing or DNS, there is no conflict with any other addresses. - In practice, applications may treat these addresses like global scoped addresses. 4.2. Renumbering and Site Merging The use of Local IPv6 addresses in a site results in making communication that uses these addresses independent of renumbering a site's provider-based global addresses. When merging multiple sites, the addresses created with these prefixes are unlikely to need to be renumbered because all of the addresses have a high probability of being unique. Routes for each specific prefix would have to be configured to allow routing to work correctly between the formerly separate sites.` ~~~~~~~~~~~~~~~~~~~~~~ Does anyone have a technical analysis of how to multihome with RFC 4193 addresses as a PI address space? Can we combine this with multihomed global addresses to avoid a NAT-like trap that hurts the E2E model? Perhaps we need a MOONv6 experiment designed to test this as a PI space option? David Green US Army CERDEC Site Manager SRI International Office: (732) 532-6715 Mobile: (732) 693-6500 From terry.l.davis at boeing.com Tue Apr 11 21:03:41 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 11 Apr 2006 12:03:41 -0700 Subject: [address-policy-wg] RE: Question - Aviation In-Reply-To: <936A4045C332714F975800409DE09240021C9612@tayexc14.americas.cpqcorp.net> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BEB5@XCH-NW-8V1.nw.nos.boeing.com> Jim As I said, I remain 100% opposed to NAT and certainly don't intend to implement it in any way or cause it to be furthered. A global "closed" network to me, means it requires both authentication to join and IPSec communication. To me, it is simply easier to build, secure, and route a "closed" network if it is all made from a single global allocation rather than built from a collage of individual networks. Take care Terry > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound at hp.com] > Sent: Tuesday, April 11, 2006 7:19 AM > To: Davis, Terry L; CERASI Eivan; Tony Hain; PPML; address-policy- > wg at ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; > Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI; Bound, Jim > Subject: RE: [address-policy-wg] RE: Question - Aviation > > Terry, > > I respectfully disagree closed networks can interfere with true end-to-end > and end-to-end security, if not done very carefully with IPv6. Back at > Digital we ran with global addresses (ok we had a Class A net 16) and > implemented secure VPNs before they were popular in the late 80's and a > form of IPsec with encryption. We had all the benefits of Firewalls just > no "ADDRESS TRANSLATION". Your view of closed networks is far more > dangerous than "potential" renumbering. Any network with globally > routable addresses can be firewalled and protected it is not rocket > science. But at the same time permits the end-to-end secure IP layer 3 > model via IPsec as an option, which is the strongest security model we > know of today from any cryptographer and black ops security analysts I > speak with and quite often. This is also my position as SME (not HP) to > the DOD per those furturistic networks for the GIG as one point of input > to them . The only way to have global end-to-end which all enties should > want is to have a pool of globally routable addresses and never use NAT > again on the planet. That being said my view of Tony's proposal for PI > space will not cause NAT but I want to be sure it is NAT bullet proof. > Next to over abusive egoes/selfishness, elistism, and liars I think NAT is > another great evil on the planet earth :--) (thats a joke ok). > > /jim > > > -----Original Message----- > > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > > Sent: Tuesday, April 11, 2006 10:02 AM > > To: CERASI Eivan; Bound, Jim; Tony Hain; PPML; > > address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > on IPv6"); ROBERT Ollivier; narten at us.ibm.com; Brig, Michael > > P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > > CERDEC STCD SRI > > Subject: RE: [address-policy-wg] RE: Question - Aviation > > > > Eivan > > > > I don't think that I suggested changing anything that would > > really impact you all. I just suggested the possibility of > > formalizing the use of "closed networks" in my closing, I > > would not expect it to impact you at all. > > > > Take care > > Terry > > > > > -----Original Message----- > > > From: CERASI Eivan [mailto:eivan.cerasi at eurocontrol.int] > > > Sent: Tuesday, April 11, 2006 5:34 AM > > > To: Davis, Terry L; Bound, Jim; Tony Hain; PPML; address-policy- > > > wg at ripe.net > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > on IPv6"); > > > ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; > > > Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI > > > Subject: RE: [address-policy-wg] RE: Question - Aviation > > > > > > Hello just to give you some status/complement on what we > > are doing in > > > Europe for air traffic management. > > > > > > EUROCONTROL (a European organization dealing with the safety of air > > > navigation) has become LIR to obtain a /32. > > > > > > We have started using this address space for ground air traffic > > > control unicast applications but take-up is slow due to the > > nature of > > > our environment. > > > > > > With regard to air-ground applications, we have launched > > studies for a > > > more global approach vis-?-vis air/ground applications and this is > > > being performed in collaboration with ICAO working groups. > > > > > > Of course our primary goal is to enable an IP service for > > air traffic > > > control communications, not passenger nor airline > > communications. As > > > our environment is highly conservative, technology changes are very > > > slow especially if they have to be global. Our European strategy is > > > that IPv6 is our final target for all communications but > > our X.25 will > > > still be around for another few years and our IPv4 for even more. > > > > > > It is correct to state that our safety critical > > applications operate > > > in a closed environment as opposed to the use of classical > > internet services. > > > However we do have exchanges with internet customers (airlines) via > > > dedicated means. Clearly, both IP routing environments are isolated > > > from each other. > > > > > > To come back on one of the points that was raised below, I > > do not see > > > the benefit of creating a dedicated address space for such type of > > > applications (just as RFC1918 provides private address > > space for IPv4). > > > For me, it would just increase the end-user perceived > > complexity of IPv6. > > > In doing so, you would already cause us a problem of having > > to change > > > something we have already put into operations ! > > > > > > > > > Best regards > > > Eivan Cerasi > > > > > > -----Original Message----- > > > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > > > admin at ripe.net] On Behalf Of Davis, Terry L > > > Sent: Monday 10 April 2006 22:13 > > > To: Bound, Jim; Tony Hain; PPML; address-policy-wg at ripe.net > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > on IPv6"); > > > ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; > > > Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI > > > Subject: [address-policy-wg] RE: Question - Aviation > > > > > > > > > Jim/All > > > > > > I am going to respond in two parts here on PI issues; one > > in terms of > > > aviation and one in terms of corporate. This one is on aviation. > > > > > > The next two paragraphs are from an original response to Thomas > > > Narten, that I didn't see make the list. > > > > > > ---- > > > I view systems that run "critical infrastructure" entirely > > different > > > from those used to run anything else; especially systems that can > > > directly impact the safety of the people using or relying on them. > > > > > > Safety engineering is just like security engineering; both > > depend on > > > our ability to build in layers of defense and reliability trying to > > > never rely entirely on a single system. By forcing an > > industry like > > > aviation to accept the potential of address changing in a global > > > fleet, an element of extreme risk is added as the system's > > overall reliability is decreased. > > > ---- > > > > > > We know that in the next decade that there will be development > > > initiated for a new air traffic control system. It will likely be > > > built upon IP and if so, likely IP-v6. And ICAO currently has a > > > working group studying this and the committee is leaning > > towards IP-v6 > > > although there is a strong component that is pushing for > > IP-v4 and a > > > continuation the NAT type usage currently required in the aviation > > > industry by Arinc 664. And I do definitely agree with Jim here, the > > > use IP-v4 and NAT would create huge risks; if in nothing else, the > > > potential for mis-addressing through one of the hundreds of > > NAT gateways that would be required. > > > > > > I'll respectfully disagree with Jim in that I believe > > address change > > > in a complex global system like air traffic control can create a > > > hazard. Keep in mind, that the air traffic control system spans > > > virtually every nation on globe and most everything manmade that > > > flies. Likewise the technical and operational capabilities > > vary from > > > extraordinary to very minimal; like the 30 or so aviation operators > > > that the EU just banned from flying into EU countries > > because of their > > > poor safety and maintenance performance record. > > > > > > Coordinating an address change across this type of > > infrastructure with > > > aircraft and ground infrastructure in almost every nation on the > > > globe, is simply beyond my ability comprehend. Assuming the > > > technology would work flawlessly (discussed below), the politics of > > > when and how to implement the change would likely end up on > > the floor of the UN for debate. > > > Likewise, if a decision was made to implement a change, we would be > > > dealing with such different levels of expertise around the > > world that > > > no amount of pre-planning could ensure that implementation failures > > > would not occur. > > > > > > Now just a bit about where ATC systems are likely going and > > why their > > > criticality will likely grow over the next couple decades. > > Unless we > > > suddenly develop anti-gravity capabilities to allow slow vertical > > > takeoffs, we are stuck with the airports we have and only minimal > > > abilities to expand them (cost, environmental, noise, etc). > > The only > > > real way we can expand their capacity is with bigger airplanes and > > > more flights. The "more flights" part is where this gets > > complicated > > > and critical. To handle more flights, we have to decrease > > landing and > > > takeoff separations and speed up aircraft ground movements so an > > > airport can handle more aircraft per hour. We are about to human > > > capacity with the current systems which means that these > > improvements > > > will need to move more and more to relying on precise > > control systems; > > > a minutes interruption here will be a really big deal. > > > > > > Also we as an industry are just beginning to migrate from bus data > > > communications on the aircraft to networks. The commercial > > aircraft > > > flying today are already largely computer controlled and as I > > > mentioned above we try very hard not design the aircraft to be > > > critically reliant on any one system. In almost all cases, it > > > requires a cascading series of failures to present an > > aircraft with a > > > catastrophic hazard. Now as I said, we are starting to put > > networks > > > on the aircraft and as Arinc 664 shows; we are not the world's > > > greatest network engineers (at least not yet..). In a > > decade or so, we will have hundreds of networked systems on > > an aircraft. > > > I think the risk here in re-addressing is clear; how well will they > > > all react. And yes we can probably take most of the risk down in > > > certification testing but keep in mind variation in technical > > > competence of the operators around the world and that we are > > > continually accepting upgraded systems from our vendors as > > replacement > > > parts and this could also inject potential failures in > > re-addressing. > > > > > > If we were to use 3178 without a single global address > > space, I still > > > don't think this would scale as we then would be using > > probably in the > > > neighborhood of 50 or more ISP's (you don't always get to pick your > > > ISP's and while a country might accept addressing from an industry > > > block, they'd probably insist on using theirs otherwise) around the > > > world for the service. And the way I read it, I would > > still have lots > > > of unnecessary backhauling to the other side of the planet and some > > > very complicated policy routing to set up. Besides and > > then with mix > > > of address spaces, I would probably be perpetually leaking with the > > > global Internet in what should be a closed network. > > > > > > Finally at the moment with our existing certification > > processes, I'm > > > not sure that we would even be permitted to change the aircraft > > > addresses without re-issuing all the affected software with > > new part > > > numbers. (I'll bet you assumed we used DHCP to address the current > > > aircraft; nope we hard code address everything, remember "bus > > > engineering" 101 ;-) With today's current rules, we haven't put any > > > "critical systems" on anything but a closed onboard > > network. We are > > > just discussing the ability upload new IP_tables/firewall-rules and > > > authentication certs/passwords to the non- critical networks and I > > > believe that this will be solved in the next couple years. And now > > > also keep in mind that every aviation rule-making body around the > > > world would also have to approve of the address change for > > an ATC network and define how they were going to certify the change. > > > > > > > > ====================================================================== > > > Finally now having said all this Jim, I think it is possible for > > > aviation to remain conforming. > > > > > > We have probably only two primary needs for stable IP addressed > > > networks; one for Air Traffic Control and one for Airline > > Operations. > > > These are industry traffic type designations that have > > safety related > > > functions that are carried out over them. As we have discussed > > > before, I expect both of them to be run as "closed networks" and > > > should never > > > (IMHO) be seen in the global routing tables; a closed network will > > > provide them with a layer of security, better routing > > performance, the > > > multi- homing that an aircraft needs, and more options for > > mobility solutions. > > > > > > Further, two organizations already exist that could > > legitimately hold > > > the addresses; ICAO for the ATC network as they already > > govern it and > > > the AEEC for "airline operations" whose members already > > essentially own "Arinc" > > > which is an ISP already. If it were possible to convince > > these orgs, > > > to apply for space and the registries to grant them, that > > would seem > > > to be a solution. > > > > > > Take care > > > Terry > > > > > > PS: Apologies for the length.. > > > > > > PSS: Back to "critical infrastructure" networks a moment, > > I'd say that > > > any network that wanted to declare itself "critical infrastructure" > > > could obtain PI space, BUT to me this type of network > > should always be > > > run as a "closed network" with exchanges to the Internet > > only through > > > "mediation gateways" operating at the application level, > > not at the routing level. > > > Just food for thought but perhaps there is a class of IP-v6 > > networks > > > for "critical infrastructure" that have their own PI space, but are > > > prohibited from the participating in "Internet routing". Such a > > > concept might solve lots of problems. > > > > > > > > > > > > > -----Original Message----- > > > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > > > Sent: Saturday, April 08, 2006 5:52 AM > > > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on > > > > IPv6"); Davis, Terry L; ollivier.robert at eurocontrol.fr; > > > > narten at us.ibm.com; > > > Brig, > > > > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > > > CERDEC > > > > STCD SRI; Bound, Jim > > > > Subject: RE: Question > > > > > > > > Tony, > > > > > > > > Excellent response and educational for sure. It is my > > belief that > > > > the corporate business model today for operating networks may be > > > > broken > > > and > > > > I think you supported that below? If not my apologies for bad > > > parsing? > > > > > > > > > > > > Their models were fine for an IPv4 world where NAT was > > required and > > > some > > > > even confuse NAT with securing ones network (and some programs in > > > > the U.S. Government) and that is simply bad policy and view. > > > > > > > > In the interim can this be resolved by RIRs creating some kind of > > > > additional wording that address reclaim will be done in > > manner that > > > > is negotiable, and do no harm to corporate or government business > > > > operations? This would buy us time to work on the issue and stop > > > > the FUD around this topic? > > > > > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF > > on PI and > > > > addressing you can lead as ajunct to one of our regular > > meetings you > > > can > > > > lead for an entire day and we get the right players in > > the room. So > > > > think about that as another option too. > > > > > > > > But do enjoy the beach this thread does not have to be > > resolved this > > > > week :--) > > > > > > > > Really want to hear from all of you and discussion Terry > > D., Latif, > > > > Yanick, Dave G. Mike B. etc. > > > > > > > > Thanks > > > > /jim > > > > > > > > > -----Original Message----- > > > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > > > Sent: Friday, April 07, 2006 7:57 PM > > > > > To: 'PPML'; address-policy-wg at ripe.net > > > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New > > > > > Internet based on IPv6")'; 'Davis, Terry L'; > > > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > > 'Brig, Michael > > > > > P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > > RDECOM CERDEC STCD SRI' > > > > > Subject: RE: Question > > > > > > > > > > A public answer to a private question as I have been > > sitting on a > > > > > beach for awhile without the laptop and missed some related > > > > > conversations ... :) > > > > > > > > > > > Is the outcome really open for discussion on the PI issue? > > > > > It doesn't > > > > > > sound like it is. > > > > > > > > > > In the minds of some the route scaling issue outweighs any > > > > > argument for PI. When taken to its extreme, there is a > > valid point > > > > > that a broken routing system serves no one. At the same > > time the > > > > > dogmatic stance by the ISPs enforcing lock-in is just as broken > > > > > both for large organizations with financial or legal > > requirements > > > > > for operational stability, and the individual consumer/small > > > > > business with limited budgets looking for true competition. The > > > > > hard part is finding the middle ground in a way that limits the > > > > > exposure to a potential routing collapse. > > > > > > > > > > I personally refuse to declare some needs legitimate and others > > > > > not, as the only point of such differentiation is to > > establish a > > > > > power broker. When all uses are legitimate, the problem > > boils down > > > > > to the technical approach that can be scaled as necessary to > > > > > contain growth in the routing system. This is the logic > > that leads > > > > > me to the bit-interleaved geo that can be aggregated in varying > > > > > size pockets as necessary using existing BGP > > deployments. We can > > > > > start flat and implement aggregation over time when a region > > > > > becomes too large to handle. One nice side effect of this geo > > > > > approach is that it mitigates the continuing political > > demands for > > > > > sovereign rights to IPv6 space. > > > > > > > > > > Any aggregation approach will force the business models > > to change > > > > > from current practice. That is not as bad a thing as > > the alarmists > > > > > will make it out to be, because their accountants are > > claiming the > > > > > current model is a broken money looser as it is (which > > if so means > > > > > they will eventually change anyway). The primary difference is > > > > > that there will need to be aggregation intermediaries > > between the > > > > > last-mile and transit providers. The current model eliminates > > > > > these middle-men by trading off their routing > > mitigation service > > > > > against a larger routing table (actually they already > > exist in the > > > > > right places but are currently limited to layer2 media > > > > > aggregators). The anti-PI bunch is trying to use social > > > > > engineering to directly counter the bottom line > > business reality > > > > > that the customer will always win in the end. > > > > > Rather than accept this situation and constructively > > work on the > > > > > necessary business model and technology developments, they > > > > > effectively stall progress by staunchly claiming there is no > > > > > acceptable technical approach that works within the current > > > > > business structure. > > > > > > > > > > Making the RIRs be the police deciding who qualifies for PI and > > > > > who does not just adds to their workload and raises costs. The > > > > > beneficiaries of this gatekeeper approach are the ISPs > > that claim > > > > > they need full routing knowledge everywhere, while the > > cost burden > > > > > for supporting the waste-of-time > > qualification/evaluation work is > > > > > borne by the applicant. Given that the most vocal and organized > > > > > membership in the RIR community are the ISPs it is easy to > > > > > understand why it would seem like the PI issue is > > already decided > > > > > as closed. I tend to believe it will just drag out > > until enough of > > > > > the corporate world becomes aware of the IPv4 > > exhaustion in light > > > > > of their growth needs that they collectively appear at > > their RIR > > > > > and demand an immediate solution. Unfortunately this 'wait till > > > > > the last minute' tactic will likely result in a reactionary > > > > > quickie with its own set of long term side effects. > > > > > > > > > > A while back I tried to hold a BOF on geo PI in the > > IETF, but was > > > > > told that shim6 was the anointed solution. Now that at > > least nanog > > > > > has told the IAB where to put shim6 it might be possible to get > > > > > the current IESG to reconsider. In any case the result > > would be a > > > > > technical approach that would still require RIRs to establish > > > > > policies around. As long as they are dominated by the > > ISPs it will > > > > > be difficult to get real PI. > > > > > > > > > > Tony > > > > > > > > > > > > > > > > ____ > > > > > > This message and any files transmitted with it are legally > > privileged > > > and intended for the sole use of the individual(s) or > > entity to whom > > > they are addressed. If you are not the intended recipient, please > > > notify the sender by reply and delete the message and any > > attachments > > > from your system. Any unauthorised use or disclosure of the > > content of > > > this message is strictly prohibited and may be unlawful. > > > > > > Nothing in this e-mail message amounts to a contractual or legal > > > commitment on the part of EUROCONTROL, unless it is confirmed by > > > appropriately signed hard copy. > > > > > > Any views expressed in this message are those of the sender. > > > > > > > From narten at us.ibm.com Wed Apr 12 14:20:29 2006 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 12 Apr 2006 08:20:29 -0400 Subject: [address-policy-wg] Re: Question - Aviation In-Reply-To: Message from "Davis, Terry L" of "Mon, 10 Apr 2006 13:12:38 PDT." <0D090F1E0F5536449C7E6527AFFA280A21BEA5@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <200604121220.k3CCKTvX006396@cichlid.raleigh.ibm.com> "Davis, Terry L" writes: > PSS: Back to "critical infrastructure" networks a moment, I'd say that > any network that wanted to declare itself "critical infrastructure" > could obtain PI space, Note: in my mind "PI" space is closely associated with the notion of "being routed within the DFZ of the public internet". > BUT to me this type of network should always be run as a "closed > network" with exchanges to the Internet only through "mediation > gateways" operating at the application level, not at the routing > level. So, this type of network isn't connected directly to the internet and is thus not really part of the public internet (which makes sense to me). Thus, it is unclear to me that PI space is really needed for this. Seems to me, that all you really need is globally unique, unrouted (on the public internet) space. Would RFC 4193 "unique local addresses" satisify the need? And if your answer is "they are not unique enough", would centrally assigned ones, ala (expired) draft-ietf-ipv6-ula-central-00.txt meet your needs? (It would be ironic if you answered yes, because the topic of resurrecting this document came up during the discussion of http://www.arin.net/policy/proposals/2006_2.html at Tuesday's ARIN meeting). Thomas From narten at us.ibm.com Wed Apr 12 14:22:38 2006 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 12 Apr 2006 08:22:38 -0400 Subject: [address-policy-wg] Re: Question In-Reply-To: Message from "Davis, Terry L" of "Sun, 09 Apr 2006 17:40:01 PDT." <0D090F1E0F5536449C7E6527AFFA280A21BE91@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <200604121222.k3CCMcGM006475@cichlid.raleigh.ibm.com> "Davis, Terry L" writes: > One of my open thoughts, is if I have PA space, can I get somehow get > routing service (multi-homing) from more than the single ISP that > provided the addressing? Yes. I spoke with one big ISP at the ARIN meeting that very clearly said "yes, people can and do multihome with PA space today". It turns out that not not everyone wants/needs PI space even though they multihome. Point is, there is spectrum of "requirements" out there. Multihoming does NOT immediately imply PI is a requirement. Thomas From heldal at eml.cc Wed Apr 12 14:50:54 2006 From: heldal at eml.cc (Per Heldal) Date: Wed, 12 Apr 2006 14:50:54 +0200 Subject: [address-policy-wg] Re: Question In-Reply-To: <200604121222.k3CCMcGM006475@cichlid.raleigh.ibm.com> References: <200604121222.k3CCMcGM006475@cichlid.raleigh.ibm.com> Message-ID: <1144846254.19836.258928236@webmail.messagingengine.com> [trimmed receipient-list] On Wed, 12 Apr 2006 08:22:38 -0400, "Thomas Narten" said: > "Davis, Terry L" writes: > > > One of my open thoughts, is if I have PA space, can I get somehow get > > routing service (multi-homing) from more than the single ISP that > > provided the addressing? > > Yes. I spoke with one big ISP at the ARIN meeting that very clearly > said "yes, people can and do multihome with PA space today". It turns > out that not not everyone wants/needs PI space even though they > multihome. That varies a lot. Are you sure all users of "PA-multihoming" really understand the consequences/limitations? In Europe most ISP's won't touch PA-space from other providers. In the US most will require some confirmation that they're allowed to originate the prefix, a confirmation it may take weeks or months to produce, blocking the quick changes one assume possible with PI-space. //per -- Per Heldal http://heldal.eml.cc/ From terry.l.davis at boeing.com Wed Apr 12 20:41:46 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Wed, 12 Apr 2006 11:41:46 -0700 Subject: [address-policy-wg] RE: Question - Aviation In-Reply-To: <200604121220.k3CCKTvX006396@cichlid.raleigh.ibm.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BED4@XCH-NW-8V1.nw.nos.boeing.com> Thomas It might; it does seem to meet requirements. We would need to spend some more time thinking about any potential impacts of address collision and how this would work DNS, gateway nodes, etc. Take care Terry > -----Original Message----- > From: Thomas Narten [mailto:narten at us.ibm.com] > Sent: Wednesday, April 12, 2006 5:20 AM > To: Davis, Terry L > Cc: Bound, Jim; Tony Hain; PPML; address-policy-wg at ripe.net; Richard > Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > ollivier.robert at eurocontrol.fr; Brig, Michael P CIV DISA GES-E; Pouffary, > Yanick; Green, David B RDECOM CERDEC STCD SRI > Subject: Re: Question - Aviation > > "Davis, Terry L" writes: > > > PSS: Back to "critical infrastructure" networks a moment, I'd say that > > any network that wanted to declare itself "critical infrastructure" > > could obtain PI space, > > Note: in my mind "PI" space is closely associated with the notion of > "being routed within the DFZ of the public internet". > > > BUT to me this type of network should always be run as a "closed > > network" with exchanges to the Internet only through "mediation > > gateways" operating at the application level, not at the routing > > level. > > So, this type of network isn't connected directly to the internet and > is thus not really part of the public internet (which makes sense to > me). Thus, it is unclear to me that PI space is really needed for > this. > > Seems to me, that all you really need is globally unique, unrouted (on > the public internet) space. > > Would RFC 4193 "unique local addresses" satisify the need? > > And if your answer is "they are not unique enough", would centrally > assigned ones, ala (expired) draft-ietf-ipv6-ula-central-00.txt meet > your needs? (It would be ironic if you answered yes, because the topic > of resurrecting this document came up during the discussion of > http://www.arin.net/policy/proposals/2006_2.html at Tuesday's ARIN > meeting). > > Thomas From plzak at arin.net Thu Apr 13 14:46:05 2006 From: plzak at arin.net (Ray Plzak) Date: Thu, 13 Apr 2006 08:46:05 -0400 Subject: [address-policy-wg] RE: Question In-Reply-To: <936A4045C332714F975800409DE09240021C9580@tayexc14.americas.cpqcorp.net> Message-ID: <20060413124609.3F2181FFAA@mercury.arin.net> Jim, Regarding direction, ARIN staff implements policies that have reached community consensus as determined by the ARIN Advisory Council and as ratified by the Board of Trustees. In one sense, ARIN works like the IETF in that it is individuals who contribute to the discussion. An organization is one voice and is not viewed as representative of its members from the standpoint of numbers. You are correct. This does not preclude someone representative of the IPv6 Forum from making a statement on either the ppml or at a meeting on behalf of the Forum. One last point, if the Forum feels that the community is developing policy that is harmful then the Forum should certainly make a statement, more importantly, its individual members should become active voices in the discussion. There are a lot of voices in the IPv6 discussions but the discussion could be much more robust if those of the Forum were included. Ray > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound at hp.com] > Sent: Tuesday, April 11, 2006 9:30 AM > To: Ray Plzak; Latif Ladid ("The New Internet based on IPv6"); Tony Hain; > PPML; address-policy-wg at ripe.net > Cc: Richard Jimmerson; Davis, Terry L; ollivier.robert at eurocontrol.fr; > narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; > Green, David B RDECOM CERDEC STCD SRI; Bound, Jim > Subject: RE: [address-policy-wg] RE: Question > > Ray, So you don't take IETF direction but only from individuals in the > IETF? Just want this to be clarified very clearly. This also does not > preclude the IPv6 Forum stating a public position on the issue whether > RIRs react to it or not. Not that will happen but it could if the pain > is strong enough to prohibit IPv6 deployment. > > Thanks > /jim > > > -----Original Message----- > > From: Ray Plzak [mailto:plzak at arin.net] > > Sent: Monday, April 10, 2006 6:56 AM > > To: 'Latif Ladid ("The New Internet based on IPv6")'; Bound, > > Jim; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > > Michael P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > > RDECOM CERDEC STCD SRI' > > Subject: RE: [address-policy-wg] RE: Question > > > > The NAv6TF is in the ARIN region. If individuals associated > > with it think that ARIN should adopt a policy or change an > > existing policy they should not only say so they should > > propose such a policy. Remember policies in the ARIN region, > > like in all of the RIRs is made not by the RIR organization > > staff and board but by the community in the region. ARIN > > staff will be more than happy to help anyone through the > > process, which by the way, while an orderly and formal > > process is not onerous, but one designed to provide for an > > open and honest discussion of any policy proposal before it > > is adopted. If you are interested in pursuing this, please > > contact me and I will get a staff member to assist you. > > > > Ray > > > > > -----Original Message----- > > > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > > > admin at ripe.net] On Behalf Of Latif Ladid ("The New Internet based on > > > IPv6") > > > Sent: Saturday, April 08, 2006 9:53 AM > > > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, Michael P > > > CIV DISA GES-E'; 'Pouffary, Yanick'; 'Green, David B RDECOM > > CERDEC STCD SRI' > > > Subject: [address-policy-wg] RE: Question > > > > > > > > > > > > The technical community should fix this one before the ITU > > sees this > > > as another chance to have a political say on the IPv6 addressing. > > > These things leak fast. My advice is that ARIN should seriously own > > > this issue before the ITU turns it to a sovereignty issue, > > which they > > > could for sure win this time. I know one of their noodles > > is sizzling > > > at it. > > > > > > Cheers > > > Latif > > > > > > -----Original Message----- > > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > > Sent: 08 April 2006 14:52 > > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > on IPv6"); > > > Davis, Terry L; ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > > > Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B > > > RDECOM CERDEC STCD SRI; Bound, Jim > > > Subject: RE: Question > > > > > > Tony, > > > > > > Excellent response and educational for sure. It is my > > belief that the > > > corporate business model today for operating networks may be broken > > > and I think you supported that below? If not my apologies > > for bad parsing? > > > > > > > > > Their models were fine for an IPv4 world where NAT was required and > > > some even confuse NAT with securing ones network (and some > > programs in the U.S. > > > Government) and that is simply bad policy and view. > > > > > > In the interim can this be resolved by RIRs creating some kind of > > > additional wording that address reclaim will be done in > > manner that is > > > negotiable, and do no harm to corporate or government business > > > operations? This would buy us time to work on the issue > > and stop the > > > FUD around this topic? > > > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > > addressing you can lead as ajunct to one of our regular > > meetings you > > > can lead for an entire day and we get the right players in > > the room. > > > So think about that as another option too. > > > > > > But do enjoy the beach this thread does not have to be > > resolved this > > > week > > > :--) > > > > > > Really want to hear from all of you and discussion Terry D., Latif, > > > Yanick, Dave G. Mike B. etc. > > > > > > Thanks > > > /jim > > > > > > > -----Original Message----- > > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > > Sent: Friday, April 07, 2006 7:57 PM > > > > To: 'PPML'; address-policy-wg at ripe.net > > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > > New Internet > > > > based on IPv6")'; 'Davis, Terry L'; > > ollivier.robert at eurocontrol.fr; > > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > > Subject: RE: Question > > > > > > > > A public answer to a private question as I have been sitting on a > > > > beach for awhile without the laptop and missed some related > > > > conversations ... :) > > > > > > > > > Is the outcome really open for discussion on the PI issue? > > > > It doesn't > > > > > sound like it is. > > > > > > > > In the minds of some the route scaling issue outweighs > > any argument > > > > for PI. > > > > When taken to its extreme, there is a valid point that a broken > > > > routing system serves no one. At the same time the > > dogmatic stance > > > > by the ISPs enforcing lock-in is just as broken both for large > > > > organizations with financial or legal requirements for > > operational > > > > stability, and the individual consumer/small business > > with limited > > > > budgets looking for true competition. The hard part is > > finding the > > > > middle ground in a way that limits the exposure to a potential > > > > routing collapse. > > > > > > > > I personally refuse to declare some needs legitimate and > > others not, > > > > as the only point of such differentiation is to establish a power > > > > broker. When all uses are legitimate, the problem boils > > down to the > > > > technical approach that can be scaled as necessary to > > contain growth > > > > in the routing system. > > > > This is the logic that leads me to the bit-interleaved > > geo that can > > > > be aggregated in varying size pockets as necessary using existing > > > > BGP deployments. We can start flat and implement aggregation over > > > > time when a region becomes too large to handle. One nice > > side effect > > > > of this geo approach is that it mitigates the continuing > > political > > > > demands for sovereign rights to IPv6 space. > > > > > > > > Any aggregation approach will force the business models to change > > > > from current practice. That is not as bad a thing as the > > alarmists > > > > will make it out to be, because their accountants are > > claiming the > > > > current model is a broken money looser as it is (which if > > so means > > > > they will eventually change anyway). The primary > > difference is that > > > > there will need to be aggregation intermediaries between the > > > > last-mile and transit providers. The current model > > eliminates these > > > > middle-men by trading off their routing mitigation > > service against a > > > > larger routing table (actually they already exist in the right > > > > places but are currently limited to layer2 media > > aggregators). The > > > > anti-PI bunch is trying to use social engineering to directly > > > > counter the bottom line business reality that the > > customer will always win in the end. > > > > Rather than accept this situation and constructively work on the > > > > necessary business model and technology developments, they > > > > effectively stall progress by staunchly claiming there is no > > > > acceptable technical approach that works within the > > current business structure. > > > > > > > > Making the RIRs be the police deciding who qualifies for > > PI and who > > > > does not just adds to their workload and raises costs. The > > > > beneficiaries of this gatekeeper approach are the ISPs that claim > > > > they need full routing knowledge everywhere, while the > > cost burden > > > > for supporting the waste-of-time qualification/evaluation work is > > > > borne by the applicant. > > > > Given that the most vocal and organized membership in the RIR > > > > community are the ISPs it is easy to understand why it would seem > > > > like the PI issue is already decided as closed. I tend to > > believe it > > > > will just drag out until enough of the corporate world > > becomes aware > > > > of the > > > > IPv4 exhaustion in light of their growth needs that they > > > > collectively appear at their RIR and demand an immediate > > solution. > > > > Unfortunately this 'wait till the last minute' tactic will likely > > > > result in a reactionary quickie with its own set of long > > term side effects. > > > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > > > told that > > > > shim6 was the anointed solution. Now that at least nanog has told > > > > the IAB where to put shim6 it might be possible to get > > the current > > > > IESG to reconsider. In any case the result would be a technical > > > > approach that would still require RIRs to establish > > policies around. > > > > As long as they are dominated by the ISPs it will be > > difficult to get real PI. > > > > > > > > Tony > > > > > > > > > > > > From jordi.palet at consulintel.es Fri Apr 14 14:08:05 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 14 Apr 2006 14:08:05 +0200 Subject: [address-policy-wg] Re: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: Message-ID: Hi all, My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE and the rest of the regions, trying to get a consensus for a "global" policy on this, but as this thread is being followed up in several mail exploders, to avoid a long cross-posting, I think it will be better to start some discussion already in a mailing list which is global, and actually I think we have the right one ... global-v6 at lists.apnic.net So, if you aren't subscribed in the global-v6 at lists.apnic.net, and you're interested in this thread, please subscribe at http://mailman.apnic.net/mailman/listinfo/global-v6 If you're late because the Eastern, the archives are also available at http://www.apnic.net/mailing-lists/global-v6/ Regards, Jordi > De: JORDI PALET MARTINEZ > Responder a: > Fecha: Fri, 14 Apr 2006 13:39:07 +0200 > Para: "v6ops at ops.ietf.org" , "ppml at arin.net" > , "shim6 at psg.com" > Conversaci?n: [ppml] PI addressing in IPv6 advances in ARIN > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN > > Hi Owen, > > You said it: If somebody find the good solution, it will be attractive to > the people to go for it. Otherwise, you always have the chance to become an > LIR. My proposal actually is already considering this point and a way to > avoid a need for renumbering if that happens. > > I just want to make sure that we have a way-out if it becomes necessary, but > avoid a showstopper now. I think is it possible. > > I don't have a technical solution yet (and agree with your views on this in > the email below in general), but I'm confident we will have. If it will take > 4 years from now, or just 2, who knows, so my proposal is ensuring that we > have those 4 years+3 for allowing the people either to return the block, or > become an LIR and avoid renumbering an any changes in their network. > > By the way, it may happen, and I'm hoping so, that the technical solution > don't make necessary to return the PI block anymore, and in that case, we > will be even able to remove at that time the "temporarily" point in the > policy (if it becomes accepted). > > Regards, > Jordi > > > > >> De: Owen DeLong >> Responder a: >> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >> Para: , "v6ops at ops.ietf.org" >> , >> "ppml at arin.net" , "shim6 at psg.com" >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >> >> >> >> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >> wrote: >> >> [snip] >>> However, I want to balance this with the medium-long term implications >>> created in the routing table and with the time needed to build and deploy >>> a better technical solution (or several) which is accepted by the >>> community. >>> >> I think we first need to define what we consider a solution... See below. >> >>> So my proposal basically is about having PI now everywhere (once ARIN >>> adopt it, is unfair not having it in other regions), but those PI >>> allocations for multihoming should be temporary and those address blocks >>> returned to the RIRs some time (lets say 3 years) after the new technical >>> solution is declared as a valid one. >>> >> I would not actually support this idea. The whole point of having PI >> space is to have the addresses for a long-term. Having a timeframe for >> return would simply restore the same barrier to entry that existed >> prior to passing the policy. >> >> Other RIRs are free to implement whatever v6 PI policy they feel is >> appropriate for their region. I would support a globally standardized >> v6 PI policy along the lines of ARIN 2005-1. >> >> However, I would like to argue that if the new technical solution will >> benefit from the return of this address space, it is most likely not >> truly a solution, but, instead, another clever hack piled on top of >> the existing set of hacks. >> >> I suppose if someone found the magic bullet to make geotopological >> addressing really work, that might qualify. However, I have very low >> expectations in that area. >> >> Absent that, any true solution will involve making the size of the routing >> table independent of the number of PI (or even PA) blocks issued by >> the RIRs or will make the size of the routing table practically >> irrelevant. >> >> I know this isn't the easy solution, but, we need to look long and >> hard at the way we do things. I think that solving these problems >> is going to require a significant paradigm shift. Assuming that we >> can use IP addresses for both end system identification and for >> routing topology indicators is how we created this problem. I don't >> see solving it without breaking that assumption, at least at the >> interdomain level. >> >> >>> At this way, on the long-run, we will not have routing table implications, >>> but we allow now the people that want to move ahead only if they have a >>> multihoming solution doing so. >>> >> If you think there is a possible solution (a real solution, not just >> a hack that postpones the inevitable at the expense of usability >> like CIDR did), then I'd like to hear what you are thinking. >> >>> This 3-years time for getting a multihoming network back to the new >>> technical solution (once adopted) is enough time, I think (it could be >>> changed to 5 years if needed, or whatever), so nobody today see the >>> temporarily of the proposal as a showstopper to go for it now. >>> >> I think you underestimate the momentum and requirements of the modern >> enterprise if you believe that to be true. Any capability available >> in v4 that is not available on at least equal or better terms in v6 >> is a deterrent to v6 deployment. >> >> The ability to get permanent addresses which do not have to be returned >> when you switch providers or renumbered on a schedule determined by >> some external organization is a major example of such a capability. >> >> Owen >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > 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. > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > 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. > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com 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. From iljitsch at muada.com Fri Apr 14 17:07:26 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 14 Apr 2006 17:07:26 +0200 Subject: [address-policy-wg] Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Message-ID: On 14-apr-2006, at 16:57, Scott Leibrand wrote: > 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. From iljitsch at muada.com Sun Apr 16 09:17:52 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 16 Apr 2006 09:17:52 +0200 Subject: [address-policy-wg] Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Message-ID: <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote: > Wow, Iljitsch, I have never lost so much respect so quickly for > someone who was not flaming a specific person or using profanity. > Congratulations. Well, that's too bad. But several years of trying to get a scalable multihoming off the ground (flying to different meetings on my own dime) where first my ideas about PI aggregation are rejected within the IETF mostly without due consideration because it involves the taboo word "geography" only to see the next best thing being rejected by people who, as far as I can tell, lack a view of the big picture, is enough to make me lose my cool. Just a little. > Back on topic, it is not just those 60 people - the "playground" > appears to overwhelmingly agree with their position. I know I do. Don't you think it's strange that the views within ARIN are so radically different than those within the IETF? Sure, inside the IETF there are also people who think PI in IPv6 won't be a problem, but it's not the majority (as far as I can tell) and certainly not anything close to 90%. Now the IETF process isn't perfect, as many things depend on whether people feel like actually doing something. But many of the best and the brightest in the IETF have been around for some time in multi6 and really looked at the problem. Many, if not most, of them concluded that we need something better than IPv4 practices to make IPv6 last as long as we need it to last. Do you think all of them were wrong? > I am sorry your technical arguments have not persuaded us in the > past. But I would urge you to stick to those, Stay tuned. From gert at space.net Sun Apr 16 18:04:12 2006 From: gert at space.net (Gert Doering) Date: Sun, 16 Apr 2006 18:04:12 +0200 Subject: [address-policy-wg] DRAFT agenda for RIPE 52 address policy WG meeting Message-ID: <20060416160412.GA66476@Space.Net> Hi APWG folks, here's a first draft of an agenda for the RIPE52 address policy meeting in Istanbul in two weeks. Please send me your comments pretty quickly, as we need to hand in the agenda for printing next Tuesday. Gert Doering -- NetMaster --------------------------- snip ------------------------- A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 51: http://www.ripe.net/ripe/wg/address-policy/r51-minutes.html B. Policy proposal overview (of address policy WG proposals) - Filiz Yilmaz - 2005-02 IP assignments for anycast DNS (OPEN) - 2005-03 IPv6 initial allocation criteria (Discussion) - 2005-08 Amend IPv6 assignment and utilization requirements (Open) - 2005-12 4-byte AS number policy (Open) - 2005-01 HD-Ratio proposal (concluding) - 2005-09 IPv6 IANA->RIR distribution policy (consensus) C. discussion on existing proposals that are not yet closed D. necessary steps to conclude 2005-09 E. ongoing policy work in other regions * presentation in the plenary * plus discussion time in the WG slot F. IPv6 PI policy - ongoing work in other regions * presentation about the ARIN IPv6 PI policy in the plenary (http://www.arin.net/policy/proposals/2005_1.html= * plus discussion time in the WG slot (Jordi Palet) Z. AOB -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jeroen at unfix.org Sun Apr 16 18:49:03 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 16 Apr 2006 18:49:03 +0200 Subject: [address-policy-wg] Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> Message-ID: <1145206143.23746.32.camel@firenze.zurich.ibm.com> [very nice cross posting going on here ;) ] On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote: [... large snip about trying to bash shim6 which is not finalized yet, thus how can you bash it ? Note: extra sarcasm included in this post. Eat the eggs with salt. ...] > Oh, and one thing I should have said last time: Technical arguments > are important, but they are only part of the decision process. In other words: "You are right with your arguments, but I just threw your args away as they are futile based on the comparison of money earned this way or the other."... > People (like me) have explained that the Internet is a business, and > in addition to being .. technically unsavory to many people, shim6 is > simply not viable in a business setting. And as you will only care for your business for the coming 10 or maybe 20 years you really can't care what happens to the internet afterward. The idea of IPv6 is (still not was) to have it around for quite some time longer than the lifespan of IPv4. Fortunately, the PI thing is far from the end of the world and will only help catch on, see below. Of course any vendor will love the idea of having to do another IP version of course, bring in the cash ;) > Neither backbone operators > (vendors) nor end users (customers) are warming to the idea. Just > the opposite. (At least in general, the one-in-a-million end user > with DSL and cable who likes the idea 'cause he can't figure out how > to spell "B-G-P" or doesn't want to pay for it is irrelevant.) Irrelevant for you as they don't give you money. Indeed, you only look at your own business interrest (and who can blame you for that ;) (Once though the internet was there for the masses and not only for the ones with cash) > So how do you get a technology widely accepted when the majority of > people involved do not think it is the best technical solution? When > the majority of vendors supposed to implement it will not do so for > technical -and- business reasons. There is for you indeed a business reason to not like it: the end-site won't have any reason to stick to the upstream. Which is indeed a bad business for many of the 'vendors' you mean. As Eliot Lear also said very clearly: Thanks for lining the vendors and all the stockholders pockets ;) That is in the long run, most likely in the coming 10-20 years the IPv6 routing tables will not have 'exploded' yet, but the folks selling equipment and having stocks of those venders after that most likely will have a nice retirement fund. Thanks to you! Nevertheless, the PI thing is really *not* a bad thing, as it can be used as an identifier for shim6, which is actually perfect. It just saves on having to do a complete policy process for getting address space for this type of usage. But thanks to this, this won't be needed and thus in the end anybody who can get PI can use a shim6-alike solution and won't have any problem with the upstream that actually wanted to lock them in by letting them pay loads for an entry in the BGP tables. Thus people voting for PI, thanks for helping shim6 or another solution in that space, progress a lot :) And finally on a much brighter note, especially for the shim6 folks: I know of quite a number of endsites that don't want to use BGP, the don't care about an entry in the routing tables, but do want to be multihomed in an easy way and also want to have 1 unique address space on their local network, but do want to use different upstreams. Shim6 will be perfect for this and thanks to the PI space their is the perfect identifier. Greets, Jeroen (being sarcastic, I guess the amounts of chocolate did it, but hey, I have a great excuse being only 7 mins away from the Lindt&Sprungli factory outlet, happy easter! ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From gert at space.net Mon Apr 17 19:44:44 2006 From: gert at space.net (Gert Doering) Date: Mon, 17 Apr 2006 19:44:44 +0200 Subject: [address-policy-wg] Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <936A4045C332714F975800409DE0924002250259@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924002250259@tayexc14.americas.cpqcorp.net> Message-ID: <20060417174444.GM60910@Space.Net> Hi, On Sun, Apr 16, 2006 at 06:03:22PM -0400, Bound, Jim wrote: > The IETF has NOTHING to say anymore than any other body about any RIR > policy. I want it to remain that way. IETF job is a standards body not > a deployment body. Things work a lot better if IETF and RIRs work hand-in-hand - that is, IETF makes standards that people can work with, and RIRs use allocation policies that somewhat reflect what the protocol designers had in mind. For IPv6, this isn't a huge success story yet... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From Jim.Bound at hp.com Fri Apr 14 08:14:36 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Fri, 14 Apr 2006 02:14:36 -0400 Subject: [address-policy-wg] RE: Question Message-ID: <936A4045C332714F975800409DE0924002217009@tayexc14.americas.cpqcorp.net> Ray, Thanks for the response. IPv6 Forum does not have an organizational opinion at this time, we have evolved to a technical in depth body and try to avoid such positions unless it interferes with IPv6 deployment. I will take your response as an indirect NO the IETF does not have input to RIRs as a body either. My assumption, which I did not state previously, that the IETF is given any special treatment regarding your policy, was an invalid assumption on my part. So thanks for clearing that up. We have taken this discussion offline to persons who want to continue the analysis discussion. Thank You, /jim > -----Original Message----- > From: Ray Plzak [mailto:plzak at arin.net] > Sent: Thursday, April 13, 2006 8:46 AM > To: Bound, Jim; 'Latif Ladid ("The New Internet based on > IPv6")'; 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > Michael P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > RDECOM CERDEC STCD SRI' > Subject: RE: [address-policy-wg] RE: Question > > Jim, > > Regarding direction, ARIN staff implements policies that have > reached community consensus as determined by the ARIN > Advisory Council and as ratified by the Board of Trustees. In > one sense, ARIN works like the IETF in that it is individuals > who contribute to the discussion. An organization is one > voice and is not viewed as representative of its members from > the standpoint of numbers. You are correct. This does not > preclude someone representative of the IPv6 Forum from making > a statement on either the ppml or at a meeting on behalf of > the Forum. One last point, if the Forum feels that the > community is developing policy that is harmful then the Forum > should certainly make a statement, more importantly, its > individual members should become active voices in the > discussion. There are a lot of voices in the IPv6 discussions > but the discussion could be much more robust if those of the > Forum were included. > > Ray > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > Sent: Tuesday, April 11, 2006 9:30 AM > > To: Ray Plzak; Latif Ladid ("The New Internet based on IPv6"); Tony > > Hain; PPML; address-policy-wg at ripe.net > > Cc: Richard Jimmerson; Davis, Terry L; > ollivier.robert at eurocontrol.fr; > > narten at us.ibm.com; Brig, Michael P CIV DISA GES-E; > Pouffary, Yanick; > > Green, David B RDECOM CERDEC STCD SRI; Bound, Jim > > Subject: RE: [address-policy-wg] RE: Question > > > > Ray, So you don't take IETF direction but only from > individuals in the > > IETF? Just want this to be clarified very clearly. This also does > > not preclude the IPv6 Forum stating a public position on the issue > > whether RIRs react to it or not. Not that will happen but > it could if > > the pain is strong enough to prohibit IPv6 deployment. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Ray Plzak [mailto:plzak at arin.net] > > > Sent: Monday, April 10, 2006 6:56 AM > > > To: 'Latif Ladid ("The New Internet based on IPv6")'; Bound, Jim; > > > 'Tony Hain'; 'PPML'; address-policy-wg at ripe.net > > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; 'Brig, > Michael P > > > CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B RDECOM CERDEC > > > STCD SRI' > > > Subject: RE: [address-policy-wg] RE: Question > > > > > > The NAv6TF is in the ARIN region. If individuals > associated with it > > > think that ARIN should adopt a policy or change an > existing policy > > > they should not only say so they should propose such a policy. > > > Remember policies in the ARIN region, like in all of the RIRs is > > > made not by the RIR organization staff and board but by the > > > community in the region. ARIN staff will be more than > happy to help > > > anyone through the process, which by the way, while an > orderly and > > > formal process is not onerous, but one designed to provide for an > > > open and honest discussion of any policy proposal before it is > > > adopted. If you are interested in pursuing this, please > contact me > > > and I will get a staff member to assist you. > > > > > > Ray > > > > > > > -----Original Message----- > > > > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg- > > > > admin at ripe.net] On Behalf Of Latif Ladid ("The New > Internet based > > > > on > > > > IPv6") > > > > Sent: Saturday, April 08, 2006 9:53 AM > > > > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; > address-policy-wg at ripe.net > > > > Cc: 'Richard Jimmerson'; 'Davis, Terry L'; > > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com; > 'Brig, Michael > > > > P CIV DISA GES-E'; 'Pouffary, Yanick'; 'Green, David B RDECOM > > > CERDEC STCD SRI' > > > > Subject: [address-policy-wg] RE: Question > > > > > > > > > > > > > > > > The technical community should fix this one before the ITU > > > sees this > > > > as another chance to have a political say on the IPv6 > addressing. > > > > These things leak fast. My advice is that ARIN should seriously > > > > own this issue before the ITU turns it to a sovereignty issue, > > > which they > > > > could for sure win this time. I know one of their noodles > > > is sizzling > > > > at it. > > > > > > > > Cheers > > > > Latif > > > > > > > > -----Original Message----- > > > > From: Bound, Jim [mailto:Jim.Bound at hp.com] > > > > Sent: 08 April 2006 14:52 > > > > To: Tony Hain; PPML; address-policy-wg at ripe.net > > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > > > on IPv6"); > > > > Davis, Terry L; ollivier.robert at eurocontrol.fr; > narten at us.ibm.com; > > > > Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; > Green, David B > > > > RDECOM CERDEC STCD SRI; Bound, Jim > > > > Subject: RE: Question > > > > > > > > Tony, > > > > > > > > Excellent response and educational for sure. It is my > > > belief that the > > > > corporate business model today for operating networks may be > > > > broken and I think you supported that below? If not my > apologies > > > for bad parsing? > > > > > > > > > > > > Their models were fine for an IPv4 world where NAT was required > > > > and some even confuse NAT with securing ones network (and some > > > programs in the U.S. > > > > Government) and that is simply bad policy and view. > > > > > > > > In the interim can this be resolved by RIRs creating > some kind of > > > > additional wording that address reclaim will be done in > > > manner that is > > > > negotiable, and do no harm to corporate or government business > > > > operations? This would buy us time to work on the issue > > > and stop the > > > > FUD around this topic? > > > > > > > > Also I am willing to sponsor a world wide IPv6 Forum > BOF on PI and > > > > addressing you can lead as ajunct to one of our regular > > > meetings you > > > > can lead for an entire day and we get the right players in > > > the room. > > > > So think about that as another option too. > > > > > > > > But do enjoy the beach this thread does not have to be > > > resolved this > > > > week > > > > :--) > > > > > > > > Really want to hear from all of you and discussion Terry D., > > > > Latif, Yanick, Dave G. Mike B. etc. > > > > > > > > Thanks > > > > /jim > > > > > > > > > -----Original Message----- > > > > > From: Tony Hain [mailto:alh-ietf at tndh.net] > > > > > Sent: Friday, April 07, 2006 7:57 PM > > > > > To: 'PPML'; address-policy-wg at ripe.net > > > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > > > New Internet > > > > > based on IPv6")'; 'Davis, Terry L'; > > > ollivier.robert at eurocontrol.fr; > > > > > narten at us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; > Pouffary, > > > > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > > > > Subject: RE: Question > > > > > > > > > > A public answer to a private question as I have been > sitting on > > > > > a beach for awhile without the laptop and missed some related > > > > > conversations ... :) > > > > > > > > > > > Is the outcome really open for discussion on the PI issue? > > > > > It doesn't > > > > > > sound like it is. > > > > > > > > > > In the minds of some the route scaling issue outweighs > > > any argument > > > > > for PI. > > > > > When taken to its extreme, there is a valid point > that a broken > > > > > routing system serves no one. At the same time the > > > dogmatic stance > > > > > by the ISPs enforcing lock-in is just as broken both > for large > > > > > organizations with financial or legal requirements for > > > operational > > > > > stability, and the individual consumer/small business > > > with limited > > > > > budgets looking for true competition. The hard part is > > > finding the > > > > > middle ground in a way that limits the exposure to a > potential > > > > > routing collapse. > > > > > > > > > > I personally refuse to declare some needs legitimate and > > > others not, > > > > > as the only point of such differentiation is to establish a > > > > > power broker. When all uses are legitimate, the problem boils > > > down to the > > > > > technical approach that can be scaled as necessary to > > > contain growth > > > > > in the routing system. > > > > > This is the logic that leads me to the bit-interleaved > > > geo that can > > > > > be aggregated in varying size pockets as necessary using > > > > > existing BGP deployments. We can start flat and implement > > > > > aggregation over time when a region becomes too large > to handle. > > > > > One nice > > > side effect > > > > > of this geo approach is that it mitigates the continuing > > > political > > > > > demands for sovereign rights to IPv6 space. > > > > > > > > > > Any aggregation approach will force the business models to > > > > > change from current practice. That is not as bad a > thing as the > > > alarmists > > > > > will make it out to be, because their accountants are > > > claiming the > > > > > current model is a broken money looser as it is (which if > > > so means > > > > > they will eventually change anyway). The primary > > > difference is that > > > > > there will need to be aggregation intermediaries between the > > > > > last-mile and transit providers. The current model > > > eliminates these > > > > > middle-men by trading off their routing mitigation > > > service against a > > > > > larger routing table (actually they already exist in > the right > > > > > places but are currently limited to layer2 media > > > aggregators). The > > > > > anti-PI bunch is trying to use social engineering to directly > > > > > counter the bottom line business reality that the > > > customer will always win in the end. > > > > > Rather than accept this situation and constructively > work on the > > > > > necessary business model and technology developments, they > > > > > effectively stall progress by staunchly claiming there is no > > > > > acceptable technical approach that works within the > > > current business structure. > > > > > > > > > > Making the RIRs be the police deciding who qualifies for > > > PI and who > > > > > does not just adds to their workload and raises costs. The > > > > > beneficiaries of this gatekeeper approach are the ISPs that > > > > > claim they need full routing knowledge everywhere, while the > > > cost burden > > > > > for supporting the waste-of-time > qualification/evaluation work > > > > > is borne by the applicant. > > > > > Given that the most vocal and organized membership in the RIR > > > > > community are the ISPs it is easy to understand why it would > > > > > seem like the PI issue is already decided as closed. I tend to > > > believe it > > > > > will just drag out until enough of the corporate world > > > becomes aware > > > > > of the > > > > > IPv4 exhaustion in light of their growth needs that they > > > > > collectively appear at their RIR and demand an immediate > > > solution. > > > > > Unfortunately this 'wait till the last minute' tactic will > > > > > likely result in a reactionary quickie with its own > set of long > > > term side effects. > > > > > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but > > > > > was told that > > > > > shim6 was the anointed solution. Now that at least nanog has > > > > > told the IAB where to put shim6 it might be possible to get > > > the current > > > > > IESG to reconsider. In any case the result would be a > technical > > > > > approach that would still require RIRs to establish > > > policies around. > > > > > As long as they are dominated by the ISPs it will be > > > difficult to get real PI. > > > > > > > > > > Tony > > > > > > > > > > > > > > > > > > From jordi.palet at consulintel.es Fri Apr 14 17:01:03 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 14 Apr 2006 17:01:03 +0200 Subject: [address-policy-wg] Global IPv6 PI policy proposal Message-ID: Please, use global-v6 at lists.apnic.net for inputs to this draft policy proposal, in order to avoid threads being split across multiple mail exploders in different regions. 1. Number: (The RIPE NCC will assign this) 2. Policy Proposal Name: Provider-Independent (PI) IPv6 Assignments for End-User-Organizations Note: We can use ?Portable IPv6 Assignments for End-User-Organizations? if that helps some folks to buy-in the proposal. 3. Author: a. name: Jordi Palet Martinez b. e-mail: jordi.palet at consulintel.es c. organisation: Consulintel 4. Proposal Version: 1.1 5. Submission Date: 17/4/2006 6. Suggested RIPE Working Group for discussion and publication: Address Policy 7. Proposal type: a. new, modify, or delete. NEW 8. Policy term: a. temporary, permanent, or renewable. TEMPORARY 9. Summary of proposal: This policy is intended to provide a solution for organizations that have a need for provider independent assignments in IPv6. Typically those organizations will require the provider independent assignment in order to be able to become multihomed in a similar fashion as today is done for IPv4, but other reasons are also foreseen. For example some organizations aren?t multihomed, but still require being globally routable with stable addressing (avoiding renumbering if they change the upstream provider) and in those cases (reasons behind may be administrative, policy, security, etc.) it seems that no other solution than provider independence is feasible, at least by now. Considering the foreseen consequences in the medium/long-term of this policy in the routing tables, this policy proposes an expiry date of 3 years once a technically correct alternative valid and deployable solution becomes accepted by the community. After that sunset period, the assignments done for multihoming purposes should be reclaimed and this policy should be modified to still allow assignments that could be required for purposes different than multhoming. At the sunset, the organizations that want to avoid renumbering and qualify to become an LIR, will be able to opt for that solution and they will get allocated the same prefix. 10. Policy text: a. Current (if modify): b. New: Provider-Independent IPv6 assignment to End-User-Organizations Qualification for an IPv6 Provider-Independent assignment: To qualify for a direct assignment, the organization must not be an IPv6 LIR and must qualify for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4 policy. This is valid regardless of actually having being assigned or allocated such an IPv4 block. Provider-Independent IPv6 assignment size to End-User-Organizations: The minimum size of the assignment is /32. However a larger assignment can be provided if duly documented and justified. Subsequent assignment size to End-User-Organizations: Whenever possible, further assignments will be made from adjacent address blocks, but only if duly documented and justified. Assignment super-block: Those assignments shall be allocated from a separate super-block to allow for LIRs to filter them if required. Expiry for those assignments: In the case of assignments done under this proposal in order to address the multihoming issue, they will need to return the block in a maximum period of 3 years after a technically correct alternative valid and deployable solution becomes accepted by the community. Alternatively, to avoid renumbering, some of the organizations affected by this, could become an LIR, if they qualify for it. 11. Rationale: a. Arguments supporting the proposal In IPv4 there are organizations that qualify for an allocation for being PI, or could opt to be an LIR, either because they need to be multihomed or have other administrative or technical reasons to require a portable addressing block. This is not the case today for IPv6 and it is perceived as a clear barrier for deployment of IPv6 in some organizations, and is being addressed by this proposal by means of providing a direct assignment from RIPE NCC. These organizations are not allowed to make further assignments to other external organizations, but instead only to assign subnets internally within their own facilities. Assigning /32 will make those blocks to behave as other regular LIR-allocated ones and follow the generally accepted routing filtering practices, but at the same time being identifiable belonging to a special super-block. Also, it allows becoming an LIR, if that?s the case, without requiring a renumbering. By setting up this policy, we avoid creating an unfairness situation among different regions and allow any organization that requires PI to access to it. All the organizations that opt for this PI, will be in the same fair situation once the technical solution is agreed and will have to either move to the new solution or become an LIR if they qualify. Newcomers will be in the same situation. Organizations that don?t opt to PI with this policy is because they don?t need it, so they aren?t put in an unfair situation. Those that don?t believe in possible alternative solutions and agree in going for a permanent PI policy instead, don?t have valid reasons to oppose to this proposal, as the sunset will only enter into effect once that solution is agreed, so this proposal is not against their view. Some organizations my qualify to become an LIR now and avoid using this temporary assignment, but if their only reason to become an LIR is to get the PI block, then it seems better, looking in the long-term routing table size conservation, to go for this choice, which is more fair for the overall community. The ?temporarily? of this assignment must be understood as a long-term one, as we may expect those alternative solutions to be available possible in 3-4 years, which means that with the ?transition? period of 3 years, asking for a change in 6-7 years must not be considered as a pain. b. Arguments opposing the proposal The possible effect of this proposal is the grow of the routing tables to figures which, together with the existing (and forecasted) IPv4 routing entries, could create an important trouble to operators before vendors provide products with implement technical solutions, or even if those technical solutions exists, have an important impact in the cost or/and depreciation period for the infrastructure investments. This is the reason why the proposal provides already a fix sunset, but relative to the date where an alternative and technically correct solution is available and accepted as deployable by the community. Regarding the size of the assignment (/32), being a temporal one, should not be considered as a space waste, and instead be seen as an advantage in the sense of not requiring new special filters. Acknowledgments: I will like to acknowledge the inputs received for the first version of this proposal from Marcelo Bagnulo and Lea Roberts. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com 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. From sleibrand at internap.com Fri Apr 14 17:14:51 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 14 Apr 2006 11:14:51 -0400 (EDT) Subject: [address-policy-wg] Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Message-ID: On 04/14/06 at 5:07pm +0200, Iljitsch van Beijnum wrote: > On 14-apr-2006, at 16:57, Scott Leibrand wrote: > > > 60 voted in favor of moving forward with PI. 6 voted against. > > Wow, 10 to 1. Amazing. > > Even more amazing: 60 people who represent nobody but their own > paycheck get to blow up the internet. Did you participate in the process? Even if you can't justify travel to Montreal, the PPML is wide open. ARIN doesn't go solely by the vote in the room; they also consider whether there was consensus on the PPML. > Where is ICANN when you need it? This little experiment in playground > democracy has to end before people get hurt. I think the ARIN process is closer to the IETF's "rough consensus" process than to "democracy". If you think the PI policy ARIN passed will "blow up the internet", I would encourage you to participate in drafting policy proposals to help limit the impact of PI on the routing table. Bear in mind that we didn't approve an "IPv6 PI for everyone" policy precisely to avoid "blowing up the Internet": instead we only extended existing IPv4 policy to IPv6. As I've written before, I'm attempting to draft an ARIN policy proposal to ensure PI addresses are assigned in a regular fashion instead of the random chronological fashion we do now with IPv4. As you seem to support that, I would encourage you to help draft such a policy proposal and help get people to support it. -Scott P.S. I don't think we need quite so much cross-posting as this... From hannigan at gmail.com Fri Apr 14 21:39:36 2006 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 14 Apr 2006 15:39:36 -0400 Subject: [address-policy-wg] Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Message-ID: <2d106eb50604141239i16e405eak5ac81051de0a2a7b@mail.gmail.com> On 4/14/06, Iljitsch van Beijnum wrote: > > On 14-apr-2006, at 16:57, Scott Leibrand wrote: > > > 60 voted in favor of moving forward with PI. 6 voted against. > > Wow, 10 to 1. Amazing. > > Even more amazing: 60 people who represent nobody but their own > paycheck get to blow up the internet. > > Where is ICANN when you need it? This little experiment in playground > democracy has to end before people get hurt. I am a member of the ICANN ASO AC and I was there, but I'm not sure you meant that, and, the ARIN forums are open to all. The vote was a display to our advisory council to what the constituents "want". The ARIN mailing lists get just as much consideration. Where are you? -M< _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Sat Apr 15 06:23:31 2006 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 15 Apr 2006 00:23:31 -0400 Subject: [address-policy-wg] Re: [ppml] [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Message-ID: <20060415042331.GA74377@ussenterprise.ufp.org> This message was cross posted to a large number of lists. I would like to make the root of the discussion clear, without taking an opinion. This link is the original message, best I can tell. Hopefully from there each individual on this message can tell how they came to receive it. http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00162.html Please go back to the header as well. Lists from several different organizations have been CC'ed, and each will have their own opinion. All are available on the web. A well informed reply is the best reply. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From patrick at ianai.net Sun Apr 16 06:09:43 2006 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 16 Apr 2006 00:09:43 -0400 Subject: [address-policy-wg] Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Message-ID: On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote: > On 14-apr-2006, at 16:57, Scott Leibrand wrote: > >> 60 voted in favor of moving forward with PI. 6 voted against. > > Wow, 10 to 1. Amazing. > > Even more amazing: 60 people who represent nobody but their own > paycheck get to blow up the internet. > > Where is ICANN when you need it? This little experiment in > playground democracy has to end before people get hurt. Wow, Iljitsch, I have never lost so much respect so quickly for someone who was not flaming a specific person or using profanity. Congratulations. Back on topic, it is not just those 60 people - the "playground" appears to overwhelmingly agree with their position. I know I do. I am sorry your technical arguments have not persuaded us in the past. But I would urge you to stick to those, or at least consider why we remain unconvinced, rather than devolve into .. whatever that post was supposed to be. -- TTFN, patrick From patrick at ianai.net Sun Apr 16 18:10:36 2006 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 16 Apr 2006 12:10:36 -0400 Subject: [address-policy-wg] Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> Message-ID: <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> On Apr 16, 2006, at 3:17 AM, Iljitsch van Beijnum wrote: > On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote: > >> Wow, Iljitsch, I have never lost so much respect so quickly for >> someone who was not flaming a specific person or using profanity. >> Congratulations. > > Well, that's too bad. But several years of trying to get a scalable > multihoming off the ground (flying to different meetings on my own > dime) where first my ideas about PI aggregation are rejected within > the IETF mostly without due consideration because it involves the > taboo word "geography" only to see the next best thing being > rejected by people who, as far as I can tell, lack a view of the > big picture, is enough to make me lose my cool. Just a little. Thank you for believing my opposition of your ideas is simply because I "lack a view of the big picture". Note that it is entirely possible I believe the reverse to be true. Or perhaps you see a big picture, and I just see a bigger one. However, I probably won't lose my cool since, as I stated before, the overwhelming majority of people who run the Internet seem to see my "bigger" picture. >> Back on topic, it is not just those 60 people - the "playground" >> appears to overwhelmingly agree with their position. I know I do. > > Don't you think it's strange that the views within ARIN are so > radically different than those within the IETF? Sure, inside the > IETF there are also people who think PI in IPv6 won't be a problem, > but it's not the majority (as far as I can tell) and certainly not > anything close to 90%. Now the IETF process isn't perfect, as many > things depend on whether people feel like actually doing something. > But many of the best and the brightest in the IETF have been around > for some time in multi6 and really looked at the problem. Many, if > not most, of them concluded that we need something better than IPv4 > practices to make IPv6 last as long as we need it to last. Do you > think all of them were wrong? Yes. And so does essentially everyone else who runs an Internet backbone. These are some of the "best and brightest" in the world, and most of them have been around for .. well, 'forever' in Internet terms. But decision such as these really shouldn't be decided simply because someone has been doing this longer. >> I am sorry your technical arguments have not persuaded us in the >> past. But I would urge you to stick to those, > > Stay tuned. I'll try. But honestly, reading the same arguments over and over gets tiresome, especially when so many well-qualified people have explained the opposing PoV so well. Oh, and one thing I should have said last time: Technical arguments are important, but they are only part of the decision process. People (like me) have explained that the Internet is a business, and in addition to being .. technically unsavory to many people, shim6 is simply not viable in a business setting. Neither backbone operators (vendors) nor end users (customers) are warming to the idea. Just the opposite. (At least in general, the one-in-a-million end user with DSL and cable who likes the idea 'cause he can't figure out how to spell "B-G-P" or doesn't want to pay for it is irrelevant.) So how do you get a technology widely accepted when the majority of people involved do not think it is the best technical solution? When the majority of vendors supposed to implement it will not do so for technical -and- business reasons. When the majority of end users who are supposed to buy the service will not? Okie, trick question. :) You don't. -- TTFN, patrick From Jim.Bound at hp.com Mon Apr 17 00:02:04 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Sun, 16 Apr 2006 18:02:04 -0400 Subject: [address-policy-wg] RE: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Message-ID: <936A4045C332714F975800409DE0924002250258@tayexc14.americas.cpqcorp.net> I agree. /jim > -----Original Message----- > From: owner-shim6 at psg.com [mailto:owner-shim6 at psg.com] On > Behalf Of Patrick W. Gilmore > Sent: Sunday, April 16, 2006 12:10 AM > To: Iljitsch van Beijnum > Cc: Patrick W. Gilmore; shim6-wg; ppml at arin.net; > global-v6 at lists.apnic.net; IETF Discussion; > address-policy-wg at ripe.net; v6ops at ops.ietf.org > Subject: Re: [narten at us.ibm.com: PI addressing in IPv6 > advances in ARIN] > > On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote: > > > On 14-apr-2006, at 16:57, Scott Leibrand wrote: > > > >> 60 voted in favor of moving forward with PI. 6 voted against. > > > > Wow, 10 to 1. Amazing. > > > > Even more amazing: 60 people who represent nobody but their own > > paycheck get to blow up the internet. > > > > Where is ICANN when you need it? This little experiment in > playground > > democracy has to end before people get hurt. > > Wow, Iljitsch, I have never lost so much respect so quickly for > someone who was not flaming a specific person or using profanity. > Congratulations. > > > Back on topic, it is not just those 60 people - the "playground" > appears to overwhelmingly agree with their position. I know I do. > > I am sorry your technical arguments have not persuaded us in > the past. But I would urge you to stick to those, or at > least consider why we remain unconvinced, rather than devolve > into .. whatever that post was supposed to be. > > -- > TTFN, > patrick > > From Jim.Bound at hp.com Mon Apr 17 00:03:22 2006 From: Jim.Bound at hp.com (Bound, Jim) Date: Sun, 16 Apr 2006 18:03:22 -0400 Subject: [address-policy-wg] RE: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Message-ID: <936A4045C332714F975800409DE0924002250259@tayexc14.americas.cpqcorp.net> The IETF has NOTHING to say anymore than any other body about any RIR policy. I want it to remain that way. IETF job is a standards body not a deployment body. /jim > -----Original Message----- > From: owner-shim6 at psg.com [mailto:owner-shim6 at psg.com] On > Behalf Of Iljitsch van Beijnum > Sent: Sunday, April 16, 2006 3:18 AM > To: Patrick W. Gilmore > Cc: shim6-wg; ppml at arin.net; global-v6 at lists.apnic.net; IETF > Discussion; address-policy-wg at ripe.net; v6ops at ops.ietf.org > Subject: Re: [narten at us.ibm.com: PI addressing in IPv6 > advances in ARIN] > > On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote: > > > Wow, Iljitsch, I have never lost so much respect so quickly for > > someone who was not flaming a specific person or using profanity. > > Congratulations. > > Well, that's too bad. But several years of trying to get a > scalable multihoming off the ground (flying to different > meetings on my own > dime) where first my ideas about PI aggregation are rejected > within the IETF mostly without due consideration because it > involves the taboo word "geography" only to see the next best > thing being rejected by people who, as far as I can tell, > lack a view of the big picture, is enough to make me lose my > cool. Just a little. > > > Back on topic, it is not just those 60 people - the "playground" > > appears to overwhelmingly agree with their position. I know I do. > > Don't you think it's strange that the views within ARIN are > so radically different than those within the IETF? Sure, > inside the IETF there are also people who think PI in IPv6 > won't be a problem, but it's not the majority (as far as I > can tell) and certainly not anything close to 90%. Now the > IETF process isn't perfect, as many things depend on whether > people feel like actually doing something. > But many of the best and the brightest in the IETF have been > around for some time in multi6 and really looked at the > problem. Many, if not most, of them concluded that we need > something better than IPv4 practices to make IPv6 last as > long as we need it to last. Do you think all of them were wrong? > > > I am sorry your technical arguments have not persuaded us > in the past. > > But I would urge you to stick to those, > > Stay tuned. > > From pesherb at yahoo.com Mon Apr 17 20:59:46 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Mon, 17 Apr 2006 11:59:46 -0700 (PDT) Subject: [address-policy-wg] Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <20060417174444.GM60910@Space.Net> Message-ID: <20060417185946.37582.qmail@web54712.mail.yahoo.com> Hi, > Things work a lot better if IETF and RIRs work hand-in-hand - that is, > IETF makes standards that people can work with, and RIRs use allocation > policies that somewhat reflect what the protocol designers had in mind. This is a proper model which should remain this way with a little fix. IETF engineering effort is funded (indirectly) by the employers of the engineers. RIRs administrative work is funded through membership and allocation fees, which essentially equals selling of IP addresses. Because the Internet is a shared resourse its enablers such as IP addresses are not for sale but rather for a free assignment to everyone. RIRs function should be funded through a politically / economically neutral body, e.g. UN. Technically the current way of RIR cost recovery hinders the network neutrality. Peter --- Gert Doering wrote: > Hi, > > On Sun, Apr 16, 2006 at 06:03:22PM -0400, Bound, Jim wrote: > > The IETF has NOTHING to say anymore than any other body about any RIR > > policy. I want it to remain that way. IETF job is a standards body not > > a deployment body. > > Things work a lot better if IETF and RIRs work hand-in-hand - that is, > IETF makes standards that people can work with, and RIRs use allocation > policies that somewhat reflect what the protocol designers had in mind. > > For IPv6, this isn't a huge success story yet... > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 88685 > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > D- 80807 Muenchen Fax : +49-89-32356-234 > > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jordi.palet at consulintel.es Tue Apr 18 10:46:22 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 18 Apr 2006 10:46:22 +0200 Subject: [address-policy-wg] IPv6 workshop in Istanbul Message-ID: Hi all, Sponsored by ISOC, there will be an IPv6 workshop next Friday 28th afternoon in Istanbul, right after the RIPE lunch. The workshop is intended for those that don't have IPv6 knowledge. More information and registration: http://www.ipv6tf.org/ipv6_istanbul_isoc.php Please, forward this to your colleagues and other people that may be interested in participating. Thanks ! Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com 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. From jordi.palet at consulintel.es Tue Apr 18 20:13:57 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 18 Apr 2006 20:13:57 +0200 Subject: [address-policy-wg] Global IPv6 PI policy proposal In-Reply-To: Message-ID: Hi Michael, I know is difficult to achieve, but I think is worth to try and at least try to make it as much close as possible if no way to make a single one. I'm in favor of the RIRs process but also in favor of trying to achieve global consensus, avoiding regional shopping, etc. In fact not trying to make it as much global and fair to all as possible, we could say otherwise that there is no reason to set policy by regions, but by country, or estate, etc., which I'm sure you don't agree. We need to understand the very high importance of the PI implications on a global level, which make a good candidate for a global policy, in my opinion. Regards, Jordi > De: > Responder a: > Fecha: Tue, 18 Apr 2006 13:09:26 +0100 > Para: > CC: "address-policy-wg-admin at ripe.net" , > "global-v6 at lists.apnic.net" > Asunto: Re: [address-policy-wg] Global IPv6 PI policy proposal > >> Please, use global-v6 at lists.apnic.net for inputs to this draft policy >> proposal, in order to avoid threads being split across multiple mail >> exploders in different regions. > > I strongly doubt that you will get anywhere with a global > policy proposal. There is a reason that RIRs set their > policies independently. The IPv6 policy was a special case > due to the need to create a new policy for a new type of > address. But from now on, the 5 RIRs are likely to continue > making local changes to policies and it is extremenly unlikely > for any global policy to survive the 5 RIRs intact. > > In fact, the concept of a global policy is in direct > contradiction with the bottom-up nature of the RIRs. > > --Michael Dillon > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com 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. From hph at oslo.net Tue Apr 18 23:39:19 2006 From: hph at oslo.net (Hans Petter Holen) Date: Tue, 18 Apr 2006 23:39:19 +0200 Subject: [address-policy-wg] Re: HD-ratio Proposal - Last Call has ended. Cosensus not reached. In-Reply-To: <20060323112339.71AB32F595@herring.ripe.net> References: <20060323112339.71AB32F595@herring.ripe.net> Message-ID: <44455C87.90608@oslo.net> RIPE NCC Policy Coordinator wrote: > PDP Number: 2005-01 > HD-ratio Proposal > > Dear Hans Petter > > This is to remind you that the "Last Call" period for the proposed > change to RIPE Document ripe-368 has ended. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2005-1.html > > Please reply to this e-mail to let me know how you would like to proceed. > > * Consensus has been reached. We should publish the policy. > > * Consensus has not been reached. You want to > > * withdraw the policy; > > * return to the review phase (please tell us what duration to set for > the review period); or > The chairs of the Address policy working group have consulted and are divided on the matter of this policy. The outcome of this discussion and consultation with wg-chairs and RIPE Chair in general is that we see a clear consensus in favor of the current proposal. We do see a growing opposition based on the perception of how this will influence future address allocations to emerging regions. I will therefor return the policy to the review phase, for further discussion on the mailing-list and on the upcoming RIPE meeting. As a side note the matter of how RIPE should relate to other organizations in our policy making process I would like to make the following remark; RIPE policy is made by individual contributions to mailing lists and at RIPE meetings. Not by meetings of other organizations. Our discussions should be based on technical arguments in the relevant RIPE fora. Best Regards, Hans Petter Holen Address Policy Chair From hph at oslo.net Tue Apr 18 23:42:40 2006 From: hph at oslo.net (Hans Petter Holen) Date: Tue, 18 Apr 2006 23:42:40 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] Re: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: References: Message-ID: <44455D50.5080703@oslo.net> JORDI PALET MARTINEZ wrote: > Hi all, > > My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE > and the rest of the regions, trying to get a consensus for a "global" policy > on this, As as slight formality: I would strongly advice against using the term Global Policy in any other meaning than the definition set forth in the ASO MoU: http://www.aso.icann.org/docs/aso-mou2004.html Global policies are defined within the scope of this agreement as Internet number resource policies that have the agreement of all RIRs according to their policy development processes and ICANN, and require specific actions or outcomes on the part of IANA or any other external ICANN-related body in order to be implemented. Global policies will be developed in the context of this agreement, according to the processes defined by attachment A to this MoU. Under this agreement the ICANN Board will ratify proposed global policies in accordance with the Global Policy Development Process, using review procedures as determined by ICANN. ICANN will publish these procedures no later than ninety (90) days from the date of the signature of this agreement by all parties. Hans Petter Holen Address Policy WG chair / ICANN Address Council Member. > but as this thread is being followed up in several mail exploders, > to avoid a long cross-posting, I think it will be better to start some > discussion already in a mailing list which is global, and actually I think > we have the right one ... global-v6 at lists.apnic.net > > So, if you aren't subscribed in the global-v6 at lists.apnic.net, and you're > interested in this thread, please subscribe at > http://mailman.apnic.net/mailman/listinfo/global-v6 > > If you're late because the Eastern, the archives are also available at > http://www.apnic.net/mailing-lists/global-v6/ > > Regards, > Jordi > > > > > >> De: JORDI PALET MARTINEZ >> Responder a: >> Fecha: Fri, 14 Apr 2006 13:39:07 +0200 >> Para: "v6ops at ops.ietf.org" , "ppml at arin.net" >> , "shim6 at psg.com" >> Conversaci?n: [ppml] PI addressing in IPv6 advances in ARIN >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >> >> Hi Owen, >> >> You said it: If somebody find the good solution, it will be attractive to >> the people to go for it. Otherwise, you always have the chance to become an >> LIR. My proposal actually is already considering this point and a way to >> avoid a need for renumbering if that happens. >> >> I just want to make sure that we have a way-out if it becomes necessary, but >> avoid a showstopper now. I think is it possible. >> >> I don't have a technical solution yet (and agree with your views on this in >> the email below in general), but I'm confident we will have. If it will take >> 4 years from now, or just 2, who knows, so my proposal is ensuring that we >> have those 4 years+3 for allowing the people either to return the block, or >> become an LIR and avoid renumbering an any changes in their network. >> >> By the way, it may happen, and I'm hoping so, that the technical solution >> don't make necessary to return the PI block anymore, and in that case, we >> will be even able to remove at that time the "temporarily" point in the >> policy (if it becomes accepted). >> >> Regards, >> Jordi >> >> >> >> >> >>> De: Owen DeLong >>> Responder a: >>> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >>> Para: , "v6ops at ops.ietf.org" >>> , >>> "ppml at arin.net" , "shim6 at psg.com" >>> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >>> >>> >>> >>> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >>> wrote: >>> >>> [snip] >>> >>>> However, I want to balance this with the medium-long term implications >>>> created in the routing table and with the time needed to build and deploy >>>> a better technical solution (or several) which is accepted by the >>>> community. >>>> >>>> >>> I think we first need to define what we consider a solution... See below. >>> >>> >>>> So my proposal basically is about having PI now everywhere (once ARIN >>>> adopt it, is unfair not having it in other regions), but those PI >>>> allocations for multihoming should be temporary and those address blocks >>>> returned to the RIRs some time (lets say 3 years) after the new technical >>>> solution is declared as a valid one. >>>> >>>> >>> I would not actually support this idea. The whole point of having PI >>> space is to have the addresses for a long-term. Having a timeframe for >>> return would simply restore the same barrier to entry that existed >>> prior to passing the policy. >>> >>> Other RIRs are free to implement whatever v6 PI policy they feel is >>> appropriate for their region. I would support a globally standardized >>> v6 PI policy along the lines of ARIN 2005-1. >>> >>> However, I would like to argue that if the new technical solution will >>> benefit from the return of this address space, it is most likely not >>> truly a solution, but, instead, another clever hack piled on top of >>> the existing set of hacks. >>> >>> I suppose if someone found the magic bullet to make geotopological >>> addressing really work, that might qualify. However, I have very low >>> expectations in that area. >>> >>> Absent that, any true solution will involve making the size of the routing >>> table independent of the number of PI (or even PA) blocks issued by >>> the RIRs or will make the size of the routing table practically >>> irrelevant. >>> >>> I know this isn't the easy solution, but, we need to look long and >>> hard at the way we do things. I think that solving these problems >>> is going to require a significant paradigm shift. Assuming that we >>> can use IP addresses for both end system identification and for >>> routing topology indicators is how we created this problem. I don't >>> see solving it without breaking that assumption, at least at the >>> interdomain level. >>> >>> >>> >>>> At this way, on the long-run, we will not have routing table implications, >>>> but we allow now the people that want to move ahead only if they have a >>>> multihoming solution doing so. >>>> >>>> >>> If you think there is a possible solution (a real solution, not just >>> a hack that postpones the inevitable at the expense of usability >>> like CIDR did), then I'd like to hear what you are thinking. >>> >>> >>>> This 3-years time for getting a multihoming network back to the new >>>> technical solution (once adopted) is enough time, I think (it could be >>>> changed to 5 years if needed, or whatever), so nobody today see the >>>> temporarily of the proposal as a showstopper to go for it now. >>>> >>>> >>> I think you underestimate the momentum and requirements of the modern >>> enterprise if you believe that to be true. Any capability available >>> in v4 that is not available on at least equal or better terms in v6 >>> is a deterrent to v6 deployment. >>> >>> The ability to get permanent addresses which do not have to be returned >>> when you switch providers or renumbered on a schedule determined by >>> some external organization is a major example of such a capability. >>> >>> Owen >>> >>> >>> -- >>> If it wasn't crypto-signed, it probably didn't come from me. >>> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >> >> 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. >> >> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >> >> 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. >> >> >> > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > 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. > > > > From adrian at ripe.net Wed Apr 19 09:32:35 2006 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Wed, 19 Apr 2006 09:32:35 +0200 Subject: [address-policy-wg] 2005-01 Review Period Extended Until 10 May 2006 (HD-ratio Proposal) Message-ID: <20060419073235.B74602F5B8@herring.ripe.net> PDP Number: 2005-01 HD-ratio Proposal Dear Colleagues The Review Period for the change to RIPE Document ripe-368 described in proposal 2005-01 has been extended until 10 May 2006 You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-1.html We encourage you to review this policy proposal and send your comments to . Regards Adrian Bedford RIPE NCC From adrian at ripe.net Wed Apr 19 09:53:30 2006 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Wed, 19 Apr 2006 09:53:30 +0200 Subject: [address-policy-wg] Proposal Accepted - IANA Policy for Allocation of IPv6 Blocks to RIRs Message-ID: <20060419075330.7F8302F5B8@herring.ripe.net> RIPE PDP Number: 2005-09 Internet Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Dear Colleagues Consensus has been reached, and the proposal described in 2005-09 has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-09.html Thank you for your input. Regards Adrian Bedford RIPE NCC From adrian at ripe.net Wed Apr 19 10:10:49 2006 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Wed, 19 Apr 2006 10:10:49 +0200 Subject: [address-policy-wg] HD-ratio Proposal - Review Period Date Correction Message-ID: <5.2.1.1.2.20060419100741.01e262b8@mailhost.ripe.net> PDP Number: 2005-01 HD-ratio Proposal Dear Colleagues The Review Period for RIPE policy proposal 2005-01 has been extended until 17 May 2006. Please ignore the previous mail that gave a date of 10 May 2006. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-1.html We encourage you to review this policy proposal and send your comments to . Regards Adrian Bedford RIPE NCC From gert at space.net Wed Apr 19 13:18:03 2006 From: gert at space.net (Gert Doering) Date: Wed, 19 Apr 2006 13:18:03 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BE91@XCH-NW-8V1.nw.nos.boeing.com> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <0D090F1E0F5536449C7E6527AFFA280A21BE91@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <20060419111803.GG60910@Space.Net> Hi, On Sun, Apr 09, 2006 at 05:40:01PM -0700, Davis, Terry L wrote: > One of my open thoughts, is if I have PA space, can I get somehow get > routing service (multi-homing) from more than the single ISP that > provided the addressing? You can, and it works. It has its own set of problems, though. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From Michael.Dillon at btradianz.com Wed Apr 19 16:50:14 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 19 Apr 2006 15:50:14 +0100 Subject: [address-policy-wg] Re: HD-ratio Proposal - Last Call has ended. Cosensus not reached. In-Reply-To: <44455C87.90608@oslo.net> Message-ID: > > http://www.ripe.net/ripe/policies/proposals/2005-1.html > I will therefor return the policy to the review phase, for further > discussion on the mailing-list and on the upcoming RIPE meeting. My company supports this proposal moving forward. On the one hand as a large network operator we have the need to deploy hierarchy in our IPv4 networks and thus the HD ratio is a fairer way of measuring addresses used, i.e. locked up by the network architecture. While it is possible to mitigate this by carrying lots of small prefixes internally, this creates unacceptable scaling issues of its own. The HD ratio policy, submitted by Alain Bidron, strikes a balance between these issues. Of course, some have noted that this will cause a small reduction in the overall lifetime of IPv4 addresses and feel that this will penalize emerging regions. We do not believe this is so, since there are still many years left for emerging regions to acquire IPv4 addresses and build infrastructure. At the same time, IPv6 has matured as a technology and presents the emerging regions with an opportunity to leapfrog over developed countries. By doing this they will have no dependency on IPv4 addresses nor will they need to deal with the complexities that have been grafted onto IPv4 over the years. I note that in Asia, the takeup of IPv6 has been quite a bit stronger than in most of the developed world. My company, and many of the companies supporting this proposal, operate IPv6 networks as well. > As a side note the matter of how RIPE should relate to other > organizations in our policy making process I would like to make the > following remark; > RIPE policy is made by individual contributions to mailing lists and > at RIPE meetings. Not by meetings of other organizations. Our > discussions should be based on technical arguments in the relevant RIPE fora. I agree and I strongly urge Alain to go back to the members of ETNO who drafted Expert Contribution 064 http://www.etno.be/Portals/34/ETNO%20Documents/Information%20Society%20i2010/EC064%20-%20NANI%20EC%20on%20IPv4%20AD%20ratio.pdf and get them to come to this mailing list and explain the reasons behind their support of this policy proposal. --Michael Dillon From maxtul at merezha.net Wed Apr 19 13:45:37 2006 From: maxtul at merezha.net (Maxim V. Tulyev) Date: Wed, 19 Apr 2006 15:45:37 +0400 Subject: [address-policy-wg] RE: Question In-Reply-To: <20060419111803.GG60910@Space.Net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <0D090F1E0F5536449C7E6527AFFA280A21BE91@XCH-NW-8V1.nw.nos.boeing.com> <20060419111803.GG60910@Space.Net> Message-ID: <200604191545.37240.maxtul@merezha.net> Hi! it does _NOT_ work for IPv6 in the wild, by the way. > Hi, > > On Sun, Apr 09, 2006 at 05:40:01PM -0700, Davis, Terry L wrote: > > One of my open thoughts, is if I have PA space, can I get somehow get > > routing service (multi-homing) from more than the single ISP that > > provided the addressing? > > You can, and it works. It has its own set of problems, though. > > Gert Doering > -- NetMaster -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From pekkas at netcore.fi Wed Apr 19 22:51:32 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 19 Apr 2006 23:51:32 +0300 (EEST) Subject: [address-policy-wg] RE: Question In-Reply-To: <200604191545.37240.maxtul@merezha.net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <0D090F1E0F5536449C7E6527AFFA280A21BE91@XCH-NW-8V1.nw.nos.boeing.com> <20060419111803.GG60910@Space.Net> <200604191545.37240.maxtul@merezha.net> Message-ID: On Wed, 19 Apr 2006, Maxim V. Tulyev wrote: > it does _NOT_ work for IPv6 in the wild, by the way. FWIW, many consider 'not working' a feature, not a bug :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From gert at space.net Wed Apr 19 23:23:07 2006 From: gert at space.net (Gert Doering) Date: Wed, 19 Apr 2006 23:23:07 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <200604191545.37240.maxtul@merezha.net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <0D090F1E0F5536449C7E6527AFFA280A21BE91@XCH-NW-8V1.nw.nos.boeing.com> <20060419111803.GG60910@Space.Net> <200604191545.37240.maxtul@merezha.net> Message-ID: <20060419212307.GU60910@Space.Net> Hi, (thanks for doing proper quoting - which is *below* *properly trimmed* original articles) > > On Sun, Apr 09, 2006 at 05:40:01PM -0700, Davis, Terry L wrote: > > > One of my open thoughts, is if I have PA space, can I get somehow get > > > routing service (multi-homing) from more than the single ISP that > > > provided the addressing? > > > > You can, and it works. It has its own set of problems, though. On Wed, Apr 19, 2006 at 03:45:37PM +0400, Maxim V. Tulyev wrote: > it does _NOT_ work for IPv6 in the wild, by the way. Well, YMMV, but my customers claim "it does work" - with IPv6, and in the wild. But as I said: it has its own set of problems - the biggest being "inconsistant filter policies in a remote AS, and thus bad routing for the more-specific network". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From adrian at ripe.net Thu Apr 20 10:42:13 2006 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Thu, 20 Apr 2006 10:42:13 +0200 Subject: [address-policy-wg] 2006-01 New Policy Proposal - PI IPv6 Assignments for End User Organisations Message-ID: <20060420084213.AF0D82F59E@herring.ripe.net> PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues A new RIPE Policy has been proposed and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html We encourage you to review this proposal and send your comments to before 18 May 2006. After this date, we will prepare a draft RIPE Document. We will let you know when this is available. Regards Adrian Bedford RIPE NCC From maxtul at merezha.net Thu Apr 20 11:08:20 2006 From: maxtul at merezha.net (Maxim V. Tulyev) Date: Thu, 20 Apr 2006 13:08:20 +0400 Subject: [address-policy-wg] RE: Question In-Reply-To: <20060419212307.GU60910@Space.Net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <200604191545.37240.maxtul@merezha.net> <20060419212307.GU60910@Space.Net> Message-ID: <200604201308.21095.maxtul@merezha.net> Hi, > (thanks for doing proper quoting - which is *below* *properly trimmed* > original articles) This sticks to me as the good FIDONet behaviour ;) > > it does _NOT_ work for IPv6 in the wild, by the way. > Well, YMMV, but my customers claim "it does work" - with IPv6, and in > the wild. I tried to announce network 2001:4058::/48, and in fact, I couldn't get working connectivity. Of course, if you have two channels, and one of them also announces entire /32, it will be "seems to work", because you will get incoming traffic from there. But if that channel fails, you will lose connectivity at all. So, why? Local peerings? Something else? That's NOT like PI or more specific IPv4 that can be announced and is working in the wild as an independent part of Internet. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From webmaster at ripe.net Thu Apr 20 13:40:54 2006 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Thu, 20 Apr 2006 13:40:54 +0200 Subject: [address-policy-wg] New Document available: RIPE-376 Message-ID: <20060420114054.710CB2F5BD@herring.ripe.net> <<< our apologies for duplicate e-mails >>> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-376 Title: Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Author: AfriNIC APNIC ARIN LACNIC RIPE NCC Date: 19 April 2006 Format: PDF=10551 TXT=4280 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements will be specified by appropriate agreements between ICANN and the NRO. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL: http://www.ripe.net/ripe/docs/ripe-376.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-376.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-376.txt plain text version Kind Regards, Jeroen Bet RIPE NCC Content Webmaster From gert at space.net Thu Apr 20 13:47:29 2006 From: gert at space.net (Gert Doering) Date: Thu, 20 Apr 2006 13:47:29 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <200604201308.21095.maxtul@merezha.net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <200604191545.37240.maxtul@merezha.net> <20060419212307.GU60910@Space.Net> <200604201308.21095.maxtul@merezha.net> Message-ID: <20060420114729.GK60910@Space.Net> Hi, On Thu, Apr 20, 2006 at 01:08:20PM +0400, Maxim V. Tulyev wrote: > > (thanks for doing proper quoting - which is *below* *properly trimmed* > > original articles) > This sticks to me as the good FIDONet behaviour ;) Thanks. > > > it does _NOT_ work for IPv6 in the wild, by the way. > > Well, YMMV, but my customers claim "it does work" - with IPv6, and in > > the wild. > > I tried to announce network 2001:4058::/48, and in fact, I couldn't get > working connectivity. > > Of course, if you have two channels, and one of them also announces > entire /32, it will be "seems to work", because you will get incoming traffic > from there. Yes, that's the underlying assumption when using "PA slice multihoming" - the aggregate is always visible in the global table. > But if that channel fails, you will lose connectivity at all. ... to destinations that filter the /48 and have no default route. Which is not so much different from "if one of your upstreams is messing up their routing completely, you'll have problems reaching parts of the internet". There is no way anyone can guarantee reachability to any place at all times. > So, why? Local peerings? Something else? > > That's NOT like PI or more specific IPv4 that can be announced and is working > in the wild as an independent part of Internet. As long as the aggregate is visible, reachability is as good as for IPv4 PI space, if not better. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From pekkas at netcore.fi Thu Apr 20 15:14:47 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 16:14:47 +0300 (EEST) Subject: [address-policy-wg] RE: Question In-Reply-To: <20060420114729.GK60910@Space.Net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <200604191545.37240.maxtul@merezha.net> <20060419212307.GU60910@Space.Net> <200604201308.21095.maxtul@merezha.net> <20060420114729.GK60910@Space.Net> Message-ID: On Thu, 20 Apr 2006, Gert Doering wrote: [v6 aggregate and a leaked more specific] > As long as the aggregate is visible, reachability is as good as for IPv4 PI > space, if not better. But note that if the most direct path filters out the /48, following /48 will result in going a "round-about" route, possibly through all kinds of 6bone-oriented experimental networks. I (and many others, no doubt) have seen packs crossing the Atlantic multiple times -- caused by some folks (e.g., longer path) allowing the /48 through, others (the shortest path) filtering it out. I wouldn't recommend advertising more specifics to anyone... and again, I consider that a feature :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From gert at space.net Thu Apr 20 15:18:49 2006 From: gert at space.net (Gert Doering) Date: Thu, 20 Apr 2006 15:18:49 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <200604191545.37240.maxtul@merezha.net> <20060419212307.GU60910@Space.Net> <200604201308.21095.maxtul@merezha.net> <20060420114729.GK60910@Space.Net> Message-ID: <20060420131849.GM60910@Space.Net> Hi, On Thu, Apr 20, 2006 at 04:14:47PM +0300, Pekka Savola wrote: > I wouldn't recommend advertising more specifics to anyone... and > again, I consider that a feature :-) Well, the combination of "no PI", "no working non-PI/BGP-multihoming solution" and "PA+BGP multihoming not working either" is certainly not something that makes currently-multihomed customers want to move to IPv6... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From slz at baycix.de Thu Apr 20 15:24:38 2006 From: slz at baycix.de (Sascha Lenz) Date: Thu, 20 Apr 2006 15:24:38 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <20060420131849.GM60910@Space.Net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <200604191545.37240.maxtul@merezha.net> <20060419212307.GU60910@Space.Net> <200604201308.21095.maxtul@merezha.net> <20060420114729.GK60910@Space.Net> <20060420131849.GM60910@Space.Net> Message-ID: <44478B96.6070307@baycix.de> Hi, Gert Doering schrieb: > Hi, > > On Thu, Apr 20, 2006 at 04:14:47PM +0300, Pekka Savola wrote: >> I wouldn't recommend advertising more specifics to anyone... and >> again, I consider that a feature :-) > > Well, the combination of "no PI", "no working non-PI/BGP-multihoming > solution" and "PA+BGP multihoming not working either" is certainly > not something that makes currently-multihomed customers want to move to > IPv6... so, let's switch to discussing http://www.ripe.net/ripe/policies/proposals/2006-01.html :-) P.S.: The question is, if any Prefix longer than /32 makes any sense at all after years of propagating "/32 and shorter only!!!" - you can't force anyone to undo his filter descisions, let alone fix orphaned IPv6 setups (similar to the good old IPv4-IANA-reserverd-space-filter problematic). -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From pekkas at netcore.fi Thu Apr 20 15:48:30 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 16:48:30 +0300 (EEST) Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive Message-ID: Hi, I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity. Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis. We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix... .... Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through. If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance): 1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something. 2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters. 3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas at netcore.fi Thu Apr 20 16:18:47 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 17:18:47 +0300 (EEST) Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On Thu, 20 Apr 2006, Scott Leibrand wrote: >> 1. Each assignment must be accompanied by a recurring fee (at least >> 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts >> (compared to other costs) to anyone who actually needs this >> multihoming solution. However, this ensures at least some minimum >> usage barrier ("those who don't really need this can use different >> multihoming solutions"), and recovery of the resources back to RIR >> after the company has gone bankrupt or no longer needs the addresses. >> If you don't know where to put the extra money, donate it to ISOC or >> something. > > As has been discussed at ARIN, this is a good way to get the government to > declare the RIR a monopoly engaging in anticompetitive behavior. I for > one don't want that. I don't think that follows, but unless ARIN legal counsel or someone who is a real lawyer has made a statement here, I'm not sure how seriously to take this. Pointer to such official legal counsel would be appreciated. That is, ARIN has every right to require, for example, that everyone getting a prefix is (for instance) a member of ARIN, and charging for the membership should be OK. RIRs run on non-profit principle, but nothing precludes them from increasing the expenses, e.g., for donations to make the internet a better place, setting a foundation for multihoming research to actually SOLVE this problem, etc.etc. >> 2. one-size-fits-all assignments, period. You get a /48 or /32 (I >> don't have much preference here), but you must not be able to justify >> for larger space. This is to avoid the organization from getting a >> larger block and chopping it into smaller pieces and polluting the >> global routing table with more specifics which would get past prefix >> length filters. > > With the current ARIN policy proposal, you'd get a /48, with a /44 > reserved for growth. Would you advocate giving everyone a /44 up front > instead? Or something else? I don't have too much preference here, FWIW. I wouldn't object to reserving a /44 just in case, but make no provisions (at this point) for applying more. If someone needs more than /48, it needs to justify another one, and get a separate /48 (with its own reserved /44). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dennis at gippnet.com Thu Apr 20 16:24:30 2006 From: dennis at gippnet.com (=?ISO-8859-1?Q?Dennis_Lundstr=F6m?=) Date: Thu, 20 Apr 2006 16:24:30 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <4447999E.10205@gippnet.com> Hi Pekka. Totally agree with you there. At the moment as we have PI with IPv4, and I'll guess there will be lot's of fuzz dropping It. On the other hand. If PI allocations were no more, then the same people you nag about here would try to become their own ASN:s. And the percentage of peers running on cheap 'o pc-boxes would quite possibly increase. Resulting in that the problem with flapping routes would probably remain, or even get worse. So the problem is really. How do we regulate PI to only be an accepted solution for extreme cases? And still have a fair policy to those who really needs this feature. Best regards. --Dennis Lundstr?m GippNET Pekka Savola wrote: > Hi, > > I don't support PI space to end-sites. We have to get rid of the > notion that a random end-site has any business whatsoever in mucking > with the global routing tables, either by making it much larger than > need be or by polluting it with needless dynamicity. > > Example of the latter: deploying inbound traffic engineering > adjustment solutions which result in thousands of daily flaps in the > advertisements, as shown by Huston's analysis. > > We have way too much trouble with clueless ISPs to also add (or > continue to add) end-sites to the mix... > > .... > > Now, from practical point of view, it seems there is strong "need" for > PI, and it might be a PI policy of some kind might actually get through. > > If so, the policy should be such that it minimizes the bad effects of > PI and encourages people to use other solutions if those are viable > for them (unfortunately, the only way to achieve that appears to be > $$$$), in particular (in the rough order of importance): > > 1. Each assignment must be accompanied by a recurring fee (at least > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > (compared to other costs) to anyone who actually needs this > multihoming solution. However, this ensures at least some minimum > usage barrier ("those who don't really need this can use different > multihoming solutions"), and recovery of the resources back to RIR > after the company has gone bankrupt or no longer needs the addresses. > If you don't know where to put the extra money, donate it to ISOC or > something. > > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > don't have much preference here), but you must not be able to justify > for larger space. This is to avoid the organization from getting a > larger block and chopping it into smaller pieces and polluting the > global routing table with more specifics which would get past prefix > length filters. > > 3. assignments from a separate address block, set aside for PI. To > ease strict "assignment-size only" filtering of these blocks. > From nils at druecke.strg-alt-entf.org Thu Apr 20 16:48:57 2006 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Thu, 20 Apr 2006 16:48:57 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <20060420144857.GA7339@h8000.serverkompetenz.net> On Thu, Apr 20, 2006 at 04:48:30PM +0300, Pekka Savola wrote: > I don't support PI space to end-sites. We have to get rid of the > notion that a random end-site has any business whatsoever in mucking > with the global routing tables, either by making it much larger than > need be or by polluting it with needless dynamicity. > Example of the latter: deploying inbound traffic engineering > adjustment solutions which result in thousands of daily flaps in the > advertisements, as shown by Huston's analysis. > We have way too much trouble with clueless ISPs to also add (or > continue to add) end-sites to the mix... So there shouldn't be PI for ISPs either, I guess. Only to Peering points (one per RIR). Would make the routing table so much cleaner. Completely impractical? Why is it possible for end sites then? > Now, from practical point of view, it seems there is strong "need" for > PI, and it might be a PI policy of some kind might actually get > through. I strongly hope so. > If so, the policy should be such that it minimizes the bad effects of > PI and encourages people to use other solutions if those are viable > for them (unfortunately, the only way to achieve that appears to be > $$$$), in particular (in the rough order of importance): > > 1. Each assignment must be accompanied by a recurring fee (at least > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > (compared to other costs) to anyone who actually needs this > multihoming solution. However, this ensures at least some minimum > usage barrier ("those who don't really need this can use different > multihoming solutions"), and recovery of the resources back to RIR > after the company has gone bankrupt or no longer needs the addresses. > If you don't know where to put the extra money, donate it to ISOC or > something. Where does this money go? Do you really want an Sub-PI-sales-market popping up? There will be startups buying a /32 and then selling /48s and /64s for a discount rate. There will be demand for anyone to route these nets. > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > don't have much preference here), but you must not be able to justify > for larger space. This is to avoid the organization from getting a > larger block and chopping it into smaller pieces and polluting the > global routing table with more specifics which would get past prefix > length filters. This will also happen with /48 and /32. I am convinced the only solution to avoid this is only handing out /128s. Everything else will be taken apart. > 3. assignments from a separate address block, set aside for PI. To > ease strict "assignment-size only" filtering of these blocks. Won't take long until the first ISPs fall. And then more and more will have to. There is no strong community, apart from those customers with lots-o-money. Nils -- Will trade links for food. [geklaut bei www.userfriendly.org] From Joao_Damas at isc.org Thu Apr 20 16:56:00 2006 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 20 Apr 2006 16:56:00 +0200 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On 20 Apr, 2006, at 16:18, Pekka Savola wrote: > On Thu, 20 Apr 2006, Scott Leibrand wrote: >>> 1. Each assignment must be accompanied by a recurring fee (at >>> least >>> 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts >>> (compared to other costs) to anyone who actually needs this >>> multihoming solution. However, this ensures at least some minimum >>> usage barrier ("those who don't really need this can use different >>> multihoming solutions"), and recovery of the resources back to RIR >>> after the company has gone bankrupt or no longer needs the >>> addresses. >>> If you don't know where to put the extra money, donate it to ISOC or >>> something. >> >> As has been discussed at ARIN, this is a good way to get the >> government to >> declare the RIR a monopoly engaging in anticompetitive behavior. >> I for >> one don't want that. > Pekka, this doesn't sound like the right way to do policy, and yes, things that smell like "big guys get it, small guys don't" will be looked at suspiciously and rightly so. Criteria ought to be of a technical nature. Don't want PI: propose a feasible alternative that provides the same functionality under the current routing system, while looking for a better system. > > > RIRs run on non-profit principle, but nothing precludes them from > increasing the expenses, e.g., for donations to make the internet a > better place, setting a foundation for multihoming research to > actually SOLVE this problem, etc.etc. Now, *this* I do like a lot. RIRs sponsoring some research into something that directly affects the business they are chartered to do sounds right. It is one step further than the reporting pointing at the problem that Geoff is already doing at APNIC. Joao Damas ISC From Michael.Dillon at btradianz.com Thu Apr 20 17:26:52 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 20 Apr 2006 16:26:52 +0100 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: Message-ID: > > As has been discussed at ARIN, this is a good way to get the government to > > declare the RIR a monopoly engaging in anticompetitive behavior. I for > > one don't want that. > > I don't think that follows, but unless ARIN legal counsel or someone > who is a real lawyer has made a statement here, I'm not sure how > seriously to take this. Pointer to such official legal counsel would > be appreciated. Those of us who have lived and worked in North America or the UK, have a general understanding of this because restraint of trade doctrine is a part of English common law which was then inherited by other countries such as Canada and the USA. However, European competition law is not based on the same principles and in the UK today, there are often conflicts between the doctrine of restraint of trade and European competition law. If you are interested in understanding this then start here http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx The important bit is the RULE OF REASON towards the bottom. If your English is advanced enough, then you could try reading legislation such as the Sherman Act, but you may find that lawyers like to use common words in uncommon ways. This illustrates the wisdom of the industry driven bottom-up policy development process that results in ARIN developing IP address policy in North America and RIPE doing the same job in Europe. There are different norms of society and of law in these different places. The people of North America would probably view your position as a SOCIALIST one and see that as a very negative thing. However, in Europe, people will tend to see your position as a SOCIALIST one and see that as a good thing. Because you are crossposting this thread to a global V6 list and to a RIPE mailing list, it seems to me that you feel there should be a single unitary global policy. However, that is contrary to the structure of the RIR system, contrary to NRO policy and contrary to the outcome of last autumns WSIS meetings. Policy proposal 2005-1 is an ARIN proposal that has worked its way through the ARIN policy process. We discussed it intensely at the recent ARIN meeting in Montreal and it was broadly accepted by the participants at that meeting. It is highly likely that it will become part of ARIN policy and ARIN *WILL* be issuing PI IPv6 blocks by the end of the year. You are welcome to register your disapproval, however so many people have worked to develop this reasonable compromise that I don't think you will be able to sway any of them. > RIRs run on non-profit principle, but nothing precludes them from > increasing the expenses, e.g., for donations to make the internet a > better place, setting a foundation for multihoming research to > actually SOLVE this problem, etc.etc. I'm not sure if research is within ARIN's scope, however even if it is, we cannot delay deployment of IPv6 merely because there is still a need for research. Throughout the deployment of IPv4 and the astronomical growth of the Internet, both research and commercial deployment happened simultaneously and the results brought major benefits to society, even if it did mean a lot of struggle with imperfections. > I wouldn't object to reserving a /44 just in case, but make no > provisions (at this point) for applying more. If someone needs more > than /48, it needs to justify another one, and get a separate /48 > (with its own reserved /44). I think you misunderstand ARIN's allocation algorithm here. The purpose of a reserved block is to allow an applicant to receive an increased allocation from the reserved block in order to be able to aggregate the new and old allocations. If the recipient of a /48 allocation applies for more and receieves the rest of their reserved /44 then they can announce a single /44 prefix instead of two /48 prefixes (or more). This minimizes the impact on the global routing table. The ARIN IPv4 allocation algorithm works the same way. --Michael Dillon From pekkas at netcore.fi Thu Apr 20 17:28:41 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 18:28:41 +0300 (EEST) Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On Thu, 20 Apr 2006, Joao Damas wrote: >>> As has been discussed at ARIN, this is a good way to get the government to >>> declare the RIR a monopoly engaging in anticompetitive behavior. I for >>> one don't want that. > > Pekka, this doesn't sound like the right way to do policy, and yes, > things that smell like "big guys get it, small guys don't" will be > looked at suspiciously and rightly so. Criteria ought to be of a > technical nature. I'm assuming this is already in reference to, "PI should cost money" instead of "PI shouldn't be available, period"... Larger end-sites already have 10-20k+ annual budget (most have much, much larger than that): caused by CAPEX by getting at least two routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and salaries of network engineering staff. AFAICS, whether or not a PI space would cost 0, 1000 or 5000 USD a year is NOT a barrier for entry. It's just *one* metric (you may be able to think of technical metrics that could imply the same, I can't) to say, "if you REALLY don't need this, it'd be nice if you seriously consider PA address space". > Don't want PI: propose a feasible alternative that provides the same > functionality under the current routing system, while looking for a better > system Use PA addresses and Unique Local Addresses if you really think you need them. Push for shim6. Put some work on solving the remaining problems if there really are any that aren't caused by the desire to graze the commons for free. Maybe I should have snipped this quote, as this seems like a rathole which isn't worth exploring (again) here... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas at netcore.fi Thu Apr 20 18:15:15 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 19:15:15 +0300 (EEST) Subject: [address-policy-wg] Re: [GLOBAL-V6] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On Thu, 20 Apr 2006, Michael.Dillon at btradianz.com wrote: >> I don't think that follows, but unless ARIN legal counsel or someone >> who is a real lawyer has made a statement here, I'm not sure how >> seriously to take this. Pointer to such official legal counsel would >> be appreciated. >... > If you are interested in understanding this then start here > http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx This includes important gold nuggets such as ".. whether the practice complained of _unreasonably_ restrains competition", "The true test of legality is whether the restraint imposed is such as _merely regulates_ and perhaps thereby promotes competition ..." .. which imply that reasonable restraints may be OK (and many could count e.g., continued well-being of the common Internet routing system a reasonable thing), or that such acts may not necessarily be restrictive, but rather leveling the competion. But all of this is irrelevant, as I'm not interested in your or my arm-chair lawyering. I'm interested in reference to what ARIN legal counsel has said on this. > Because you are crossposting this thread to a global V6 list > and to a RIPE mailing list, it seems to me that you feel there > should be a single unitary global policy. No, the discussion has been recently brought up at least on those lists, and it would seem unwise to repeat it on every list. Even if each region made its own policies, it might be much easier for everyone (IMHO) if the discussion was held on a common list, and then when the time comes, folks would each go to their own individual RIR to make their informed or uninformed decisions. >> I wouldn't object to reserving a /44 just in case, but make no >> provisions (at this point) for applying more. If someone needs more >> than /48, it needs to justify another one, and get a separate /48 >> (with its own reserved /44). > > I think you misunderstand ARIN's allocation algorithm here. The purpose > of a reserved block is to allow an applicant to receive an increased > allocation from the reserved block in order to be able to aggregate > the new and old allocations. If the recipient of a /48 allocation > applies for more and receieves the rest of their reserved /44 then > they can announce a single /44 prefix instead of two /48 prefixes (or > more). > This minimizes the impact on the global routing table. The ARIN IPv4 > allocation algorithm works the same way. I understand the policy very well. If the above only were the case. The possible outcomes are (in an example case of expansion to /47): - the site advertises a 2001:db8:0::/47 - the site advertises a 2001:db8:0::/48 and 2001:db8:1::/48 - the site advertises a 2001:db8:0::/47 and one of /48's - the site advertises a 2001:db8:0::/47 and both of /48's Based on observations in v4 land, there are sites that specifically want to do something other than the first option, and I specifically want to preclude them from doing so. For almost every site, a /48 is enough. For those for whom it's not enough, they already want separable advertisements for TE purposes (e.g., multiple data centers), so they need either multiple /48's or tricks like above in any case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From tjc at ecs.soton.ac.uk Thu Apr 20 18:28:43 2006 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 20 Apr 2006 17:28:43 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <20060420162842.GP13930@login.ecs.soton.ac.uk> On Thu, Apr 20, 2006 at 07:15:15PM +0300, Pekka Savola wrote: > > Based on observations in v4 land, there are sites that specifically > want to do something other than the first option, and I specifically > want to preclude them from doing so. > > For almost every site, a /48 is enough. For those for whom it's not > enough, they already want separable advertisements for TE purposes > (e.g., multiple data centers), so they need either multiple /48's or > tricks like above in any case. I think pekka already hinted at it, but people interested in this topic really should look at: http://www.iepg.org/march2006/BGP-2005.pdf for some analysis of a situation that could get worse. I think there's arguments both ways on this, but Geoff's talk was very interesting and enlightening. -- Tim/::1 From hph at oslo.net Thu Apr 20 18:57:49 2006 From: hph at oslo.net (Hans Petter Holen) Date: Thu, 20 Apr 2006 18:57:49 +0200 Subject: [address-policy-wg] Re: HD-ratio Proposal - Last Call has ended. Cosensus not reached. In-Reply-To: <44455C87.90608@oslo.net> References: <20060323112339.71AB32F595@herring.ripe.net> <44455C87.90608@oslo.net> Message-ID: <4447BD8D.1000407@oslo.net> Hans Petter Holen wrote: It was pointed out to me that there is a ambigous typo in this message > > > The chairs of the Address policy working group have consulted and are divided on the matter of this policy. The outcome of this discussion and consultation with wg-chairs and RIPE Chair in general is that we see a clear consensus in favor of the current proposal. > This should read: "that we do not see a clear consensus in favour of the current proposal. My apologies for From pekkas at netcore.fi Thu Apr 20 22:44:42 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Apr 2006 23:44:42 +0300 (EEST) Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <054601c66496$60f6b210$3712fea9@ssprunk> References: <054601c66496$60f6b210$3712fea9@ssprunk> Message-ID: On Thu, 20 Apr 2006, Stephen Sprunk wrote: > I think that the multihoming requirement will be enough to keep the > number of assignments reasonable; if you look at the actual number > of non-transit ASNs in the v4 table, it's not all that large. If we > assume one PIv6 prefix per non-transit ASN, which is the goal, we're > looking at under 10k routes from the ARIN region. (Actually, the number is somewhere between 15k and 20k but that's beside the point.) The upper limit is around the number of AS numbers, and if it's expanded to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure 64K folks playing around at DFZ isn't enough??? we want 4B instead...????" Remember, it's easy and cheap to have a multihoming setup with two DSL lines... >> That is, ARIN has every right to require, for example, that everyone >> getting a prefix is (for instance) a member of ARIN, and charging for >> the membership should be OK. > > I'd want a lawyer to sign off on it. You're talking about > deliberately charging an excessive fee to make it more difficult for > smaller companies to compete with larger ones. That has the > appearance of an industry cartel creating artificial barriers to > lock their smaller competitors out of the market, and the FTC > generally doesn't like that. Come on, arguing that 1K or even 5K is an "excessive fee" for PI prefixes in the context of reliable multihoming setup and services provided seems a bit absurd. I'd agree that if the charge was 100K per year, this could be considered locking out smaller competitors, but (say) 1K is nothing -- that's less than 100 bucks a month! You might even consider a payment like 1K or 2K fair: small ISPs which get exactly the same resources have to pay such in their membership fees. Obviously the end-sites should pay at least the same if they consume the same resources.. >> setting a foundation for multihoming research to actually SOLVE this >> problem, etc.etc. > > In theory, we already have a group tasked with that: the IETF. Are you > proposing that RIRs start developing protocols outside the IETF? Or funding > people to work full-time in the IETF on problems pertinent to RIRs? Again, > this is a slippery slope and distracts from the RIRs' purpose. I said 'research', not 'engineering'. The IETF isn't the right vessel for research, though IETF could maybe be consulted on it. >> I wouldn't object to reserving a /44 just in case, but make no >> provisions (at this point) for applying more. If someone needs more >> than /48, it needs to justify another one, and get a separate /48 >> (with its own reserved /44). > > So instead of giving an org a /47, which _could_ be advertised as a single > route, you'd prefer to give them two /48s, which _must_ be advertised as two > routes? That seems to increase routing table pollution, not reduce it. Not necessarily. Doing so would hopefully ensure that it'll be *more* difficult to justify for more than a /48 especially if you have to pay for the extra too (hence less pollution). I.e., we'd need to figure out we have sufficiently strict criteria. > Also, what's the point of reserving a /44, or worse multiple /44s, if we're > only going to let people use a /48? That seems to defeat the purpose of > having a reserved block. As I said, I wouldn't object to reserving a /44 under those conditions, but I wouldn't require reservation either. One reason for reserving is that we could have the option of changing the policy later if we become wiser (or dumber) and decide that maybe we'll want to be able to deal out aggregatable chunks after all, regardless of the more specific crap that's filling the routing tables right now. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jorgen at hovland.cx Thu Apr 20 23:31:37 2006 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Thu, 20 Apr 2006 23:31:37 +0200 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: Message-ID: <001601c664c1$ce2fc260$0200000a@j> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Pekka Savola Hello, A few words. > The upper limit is around the number of AS numbers, and if it's > expanded to 32 bits, at least I start to feel uncomforable... "Umm.. > are we sure 64K folks playing around at DFZ isn't enough??? we want 4B > instead...????" The upper limit is infinite. There is no requirement to first request an AS number to get a PI prefix (in this region) or to even use the AS. > Remember, it's easy and cheap to have a multihoming setup with two DSL > lines... It is cheaper to get redundancy than multihoming which is more or less the same thing. But they want multihoming, okay. > Come on, arguing that 1K or even 5K is an "excessive fee" for PI > prefixes in the context of reliable multihoming setup and services > provided seems a bit absurd. I'd agree that if the charge was 100K > per year, this could be considered locking out smaller competitors, > but (say) 1K is nothing -- that's less than 100 bucks a month! I think the fee should be the same as a normal LIR. I see no reason not to. Ah ok. Let's decrease it by ?25 due to database storage and processing applications when the AW is not large enough. > You might even consider a payment like 1K or 2K fair: small ISPs which > get exactly the same resources have to pay such in their membership > fees. Obviously the end-sites should pay at least the same if they > consume the same resources.. Agreed. And the size of the prefix shouldn't matter as long as it is higher than the recommended(?) /48 filter limit. Complicated policies are a pain and makes people ignore/forget/misunderstand them. Yes it will potentially create a trillion prefixes in the table, but you are free to ignore them should someone carve their /19 into /48s - just like you are with IPv4 today. j From dr at cluenet.de Fri Apr 21 05:23:49 2006 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 21 Apr 2006 05:23:49 +0200 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: <054601c66496$60f6b210$3712fea9@ssprunk> Message-ID: <20060421032349.GA20024@srv01.cluenet.de> On Thu, 20 Apr 2006 18:28:41 +0300, you wrote: > Larger end-sites already have 10-20k+ annual budget (most have much, > much larger than that): caused by CAPEX by getting at least two > routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and > salaries of network engineering staff. On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote: > Remember, it's easy and cheap to have a multihoming setup with two DSL > lines... Could you finally make up your mind? First, your argument was that multihoming is expensive anyway, so shelling out another couple thousand of EUR/USD/whatever doesn't make a difference - just to keep the clueless bottom-feeders out. Now you say it's totally cheap to multihome. You're contradicting yourself. If you want to contain /senseless/ DFZ pollution, start with the ISPs. Just take a look at CIDR report. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From pekkas at netcore.fi Fri Apr 21 11:01:51 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 21 Apr 2006 12:01:51 +0300 (EEST) Subject: [address-policy-wg] Re: [GLOBAL-V6] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <20060421032349.GA20024@srv01.cluenet.de> References: <054601c66496$60f6b210$3712fea9@ssprunk> <20060421032349.GA20024@srv01.cluenet.de> Message-ID: On Fri, 21 Apr 2006, Daniel Roesen wrote: > On Thu, 20 Apr 2006 18:28:41 +0300, you wrote: >> Larger end-sites already have 10-20k+ annual budget (most have much, >> much larger than that): caused by CAPEX by getting at least two >> routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and >> salaries of network engineering staff. > > On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote: >> Remember, it's easy and cheap to have a multihoming setup with two DSL >> lines... > > Could you finally make up your mind? First, your argument was that > multihoming is expensive anyway, so shelling out another couple thousand > of EUR/USD/whatever doesn't make a difference - just to keep the > clueless bottom-feeders out. Now you say it's totally cheap to multihome. > > You're contradicting yourself. You took the comments out of context. The former describes that _real_ multihoming is expensive, the latter describes that you could obtain "multihoming" very easily. The point is that we definitely shouldn't want to assign PI to the organizations in the latter category. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Michael.Dillon at btradianz.com Fri Apr 21 12:48:07 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 21 Apr 2006 11:48:07 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: Message-ID: > > If you are interested in understanding this then start here > > http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx > > This includes important gold nuggets such as ".. whether the practice > complained of _unreasonably_ restrains competition", "The true test > of legality is whether the restraint imposed is such as _merely > regulates_ and perhaps thereby promotes competition ..." Yes, of course. All laws are like that, especially in a country like the USA which relies heavily on common-law and case-law precedents. People who live and work in the ARIN region tend to develop a gut feel for what is legal and what is not based on their experience in business and exposure to local media. I don't think it is productive to try and second guess on this list, what an American judge might decide. > No, the discussion has been recently brought up at least on those > lists, and it would seem unwise to repeat it on every list. Even if > each region made its own policies, it might be much easier for > everyone (IMHO) if the discussion was held on a common list, and then > when the time comes, folks would each go to their own individual RIR > to make their informed or uninformed decisions. On that, I disagree with you. That kind of centralised system defeats the bottom up nature of the existing RIRs. > Based on observations in v4 land, there are sites that specifically > want to do something other than the first option, and I specifically > want to preclude them from doing so. It is probably not too late to suggest that the ARIN AC include the same "no deaggregation" language as was used for IPv6 LIRs. This was discussed tangentially at the meeting and I don't recall any of the speakers objecting to that. On the other hand, ARIN policy cannot restrict what two peers do between themselves. At this point in time, the global routing table is merely a convenient phrase used in routing discussions. There really is no such thing. Nobody manages the global routing table. There are no explicit agreements on what can or cannot be announced into the global routing table. And so on. If that were to change then your issues would be perfectly within scope. However, this would require the ARIN Board of Trustees to agree to undertake this activity. Interestingly enough, this does seem to be within ARIN's scope if you read items 2, 3, 4 and 6 of the purposes in the ARIN Articles of Incorporation. Assuming that there was to be an RIR function which produced guidelines for management of the global routing table, how would it operate and how would it ensure industry-wide consensus on those rules? --Michael Dillon From narten at us.ibm.com Fri Apr 21 14:56:03 2006 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 21 Apr 2006 08:56:03 -0400 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: Message from "Stephen Sprunk" of "Thu, 20 Apr 2006 21:39:44 CDT." <088201c664ec$d991ac60$3712fea9@ssprunk> Message-ID: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> "Stephen Sprunk" writes: > OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two > pipes or tunnels), and there's not all that many companies doing it. It's > not growing much either. The doors are already wide open for a land rush > and nobody is taking ARIN up on it. Why does everyone assume it'll happen > with v6 if it's not happening with v4, which _is_ useful today? Because today, people are a lot more network savvy, and they now understand the potential value of getting real PI space. Moreover, anyone who understands history, realizes that getting PI space may become harder in the future, rather than easier. Consequently, it would be a smart business move to get PI space ASAP, in case the rules change down the road. i.e, a rather prudent investment. Thomas From Michael.Dillon at btradianz.com Fri Apr 21 15:45:02 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 21 Apr 2006 14:45:02 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <20060420144857.GA7339@h8000.serverkompetenz.net> Message-ID: > So there shouldn't be PI for ISPs either, I guess. Only to Peering points > (one per RIR). Would make the routing table so much cleaner. Completely > impractical? Why is it possible for end sites then? Now that is a very interesting suggestion. If you assume that multiple peering points in a single city have rich and cheap interconnection, you could extend this idea to one prefix per city with a population greater than 100,000. There are about 5000 such cities in the world so we are talking about 5000 prefixes. Of course, each of these cities serves a larger surrounding area with various services and such services often reach across national borders. For instance, the inhabitants of Kehl and Offenburg in Germany are likely to use services in Strasbourg, France such as the Opera du Rhin, shopping, etc. If you consider these large cities as centres of gravity for the surrounding area, then these 5000 cities cover almost all of the populated surface of the Earth. What could we do with 5000 such routes in the global routing table? Well, for one thing, we could offer an almost unlimited number of PI IPv6 address blocks to ever business or organization that feels the need to multihome in order to secure the separacy plus resiliency that need in their network connections. All of those PI blocks would be invisible in 4999 of the world's cities because those cities will only see the single city prefix. We then have solved the routing table scaling problem by dividing and conquering. There still could be some localised issues in some cities, but it is much simpler for a group of local ISPs to sort out a local issue than it is for everybody in the world to agree on the one true routing solution. The best part of this solution is that it requires no protocol changes, no new code in routers, and works with all existing IPv6 technology. It can be implemented entirely by changing RIR allocation rules, and ISP business practices. This is not a "flag day" situation either. There is no need to stop issuing and using provider aggregatable addresses. These new geo-topo aggregatable addresses can coexist in the same network. Some ISPs will choose to only assign one kind of addresses, either classic PA or new geo-topo addresses. Others will use both and use the newer ones to provide new services. The only area where business practices needs to change is inside a single city aggregate where the ISPs inside that aggregate have to agree on how to exchange traffic and how to deal with the hot-potato nature of geo-topo routing. Each city is free to come up with its own variation on this as long as they do not deaggregate the city aggregate address block outside of bilateral peering agreements. In other words, ISPs in London will see only a single route to all of the geo-topo space in Paris unless they have specific bilateral agreements with Paris ISPs. Remember we have reserved 7/8ths of the IPv6 address space in order to be able to implement these types of new addressing schemes. The main problem to be solved in order to deploy this, other than general agreement on the scheme, is how to size each of the 5000 city aggregate blocks. Geographers and economists would likely find this easy work, but we have to make contact with them, explain the problem, and ask for their analyses. > Won't take long until the first ISPs fall. And then more and more will have > to. There is no strong community, apart from those customers with > lots-o-money. Most businesses only survive and thrive because they serve their customers well. Any ISP that expects to have a strong future must understand the needs of their customer base and then organize their company resources to serve those customers. This means that ISPs who see this as a battle of the PROVIDERS (with PA addresses) against the END USERS (with subnets assigned from PA blocks) are doomed. Providers have to look at this problem from the end user point of view and then find some solution that meets the end user needs while at the same time offering the ability for the provider to continue providing valuable services. In general, as you point out, these situations are like a steamroller and end user demand will win out in the end. However, we can avoid a period of chaos and instability if the providers take the lead and manage an orderly transition to the new network order. --Michael Dillon From Michael.Dillon at btradianz.com Fri Apr 21 15:55:39 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 21 Apr 2006 14:55:39 +0100 Subject: [address-policy-wg] Re: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <87hd4ndsjf.fsf@valhalla.seastrom.com> Message-ID: > Commodity Frame Relay or ATM with two DAFs entering the facility, but > an inspection of the DLRs for the PVCs shows that they both traverse > the same switch. > > Two SONET connections that are groomed onto the same OC48. We know that separacy of circuits is subject to change due to the widespread use of switches (DACS, ATM, Ethernet) and the widespread telecom practice of grooming customer circuits over time. It is hard work to ensure that true separacy exists when it is needed to meet customer contract conditions. Given this, I think it would be unwise to specify the degree of separacy in an ARIN policy. It would be almost impossible to enforce such a provision even if you restrict it to new applications. And even then, anyone can comply to get their ASN and PI block, then go back to the pair of IPv6 tunnels for the long haul. ARIN policy has always had to strike a balance. We are not lawmakers or law enforcers. --Michael Dillon From sleibrand at internap.com Thu Apr 20 16:10:22 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 20 Apr 2006 10:10:22 -0400 (EDT) Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On 04/20/06 at 4:48pm +0300, Pekka Savola wrote: > Now, from practical point of view, it seems there is strong "need" for > PI, and it might be a PI policy of some kind might actually get > through. Very true. I'd even s/might/will/. > If so, the policy should be such that it minimizes the bad effects of > PI and encourages people to use other solutions if those are viable > for them (unfortunately, the only way to achieve that appears to be > $$$$), in particular (in the rough order of importance): > > 1. Each assignment must be accompanied by a recurring fee (at least > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > (compared to other costs) to anyone who actually needs this > multihoming solution. However, this ensures at least some minimum > usage barrier ("those who don't really need this can use different > multihoming solutions"), and recovery of the resources back to RIR > after the company has gone bankrupt or no longer needs the addresses. > If you don't know where to put the extra money, donate it to ISOC or > something. As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that. Now if you think ISPs should start charging end sites for the privilege of running BGP, that might fly. ISPs in the DFZ are bearing the costs of maintaining the extra routes*, so they can justify a per-route charge, and they actually have contracts with their customers, so they can collect. (* Yes, other end sites in the DFZ also bear those costs, but since they contribute routes to the table as well, and can sometimes switch to default-only BGP, I'd argue that DFZ ISPs are the ones stuck "holding the bag" of routing table growth.) > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > don't have much preference here), but you must not be able to justify > for larger space. This is to avoid the organization from getting a > larger block and chopping it into smaller pieces and polluting the > global routing table with more specifics which would get past prefix > length filters. With the current ARIN policy proposal, you'd get a /48, with a /44 reserved for growth. Would you advocate giving everyone a /44 up front instead? Or something else? I don't have too much preference here, FWIW. > 3. assignments from a separate address block, set aside for PI. To > ease strict "assignment-size only" filtering of these blocks. This is already a part of 2005-1, and has been a part (expressed or implied) of every other PI proposal I've seen. -Scott From maxtul at merezha.net Thu Apr 20 16:29:22 2006 From: maxtul at merezha.net (Maxim V. Tulyev) Date: Thu, 20 Apr 2006 18:29:22 +0400 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <200604201829.22213.maxtul@merezha.net> Hi, I can understand well your wish to glue client to your company with many different things, such as IP addresses (like non-portable phone numbers). But be honest - routing table size is _NOT_ a technical problem. It is an puffed up management "problem" aimed to take out users' ability to choise connectivity provider(s). Now routing table for IPv4 is near 190000 prefixes. And so what? Where is the problem? > Hi, > > I don't support PI space to end-sites. We have to get rid of the > notion that a random end-site has any business whatsoever in mucking > with the global routing tables, either by making it much larger than > need be or by polluting it with needless dynamicity. > > Example of the latter: deploying inbound traffic engineering > adjustment solutions which result in thousands of daily flaps in the > advertisements, as shown by Huston's analysis. > > We have way too much trouble with clueless ISPs to also add (or > continue to add) end-sites to the mix... > > .... > > Now, from practical point of view, it seems there is strong "need" for > PI, and it might be a PI policy of some kind might actually get > through. > > If so, the policy should be such that it minimizes the bad effects of > PI and encourages people to use other solutions if those are viable > for them (unfortunately, the only way to achieve that appears to be > $$$$), in particular (in the rough order of importance): > > 1. Each assignment must be accompanied by a recurring fee (at least > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > (compared to other costs) to anyone who actually needs this > multihoming solution. However, this ensures at least some minimum > usage barrier ("those who don't really need this can use different > multihoming solutions"), and recovery of the resources back to RIR > after the company has gone bankrupt or no longer needs the addresses. > If you don't know where to put the extra money, donate it to ISOC or > something. > > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > don't have much preference here), but you must not be able to justify > for larger space. This is to avoid the organization from getting a > larger block and chopping it into smaller pieces and polluting the > global routing table with more specifics which would get past prefix > length filters. > > 3. assignments from a separate address block, set aside for PI. To > ease strict "assignment-size only" filtering of these blocks. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From maxtul at merezha.net Thu Apr 20 16:45:02 2006 From: maxtul at merezha.net (Max Tulyev) Date: Thu, 20 Apr 2006 18:45:02 +0400 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <4447999E.10205@gippnet.com> References: <4447999E.10205@gippnet.com> Message-ID: <200604201845.02764.maxtul@merezha.net> Hi! Please, somebody, explain me The Big Problem! How routing table size on borders really affects the Internet? But please tell me about REAL routers and REAL situation. I can't see the differense between 10 path static routing and 190000 full view BGP even on old-like-dinosaurus-bones Cisco 3660. What I am doing wrong? > Hi Pekka. Totally agree with you there. > At the moment as we have PI with IPv4, and I'll guess there will be > lot's of fuzz dropping It. > On the other hand. If PI allocations were no more, then the same people > you nag about here would try to become their own ASN:s. > And the percentage of peers running on cheap 'o pc-boxes would quite > possibly increase. > Resulting in that the problem with flapping routes would probably > remain, or even get worse. > > So the problem is really. How do we regulate PI to only be an accepted > solution for extreme cases? > And still have a fair policy to those who really needs this feature. > > > Best regards. > > --Dennis Lundstr?m > GippNET > > Pekka Savola wrote: > > Hi, > > > > I don't support PI space to end-sites. We have to get rid of the > > notion that a random end-site has any business whatsoever in mucking > > with the global routing tables, either by making it much larger than > > need be or by polluting it with needless dynamicity. > > > > Example of the latter: deploying inbound traffic engineering > > adjustment solutions which result in thousands of daily flaps in the > > advertisements, as shown by Huston's analysis. > > > > We have way too much trouble with clueless ISPs to also add (or > > continue to add) end-sites to the mix... > > > > .... > > > > Now, from practical point of view, it seems there is strong "need" for > > PI, and it might be a PI policy of some kind might actually get through. > > > > If so, the policy should be such that it minimizes the bad effects of > > PI and encourages people to use other solutions if those are viable > > for them (unfortunately, the only way to achieve that appears to be > > $$$$), in particular (in the rough order of importance): > > > > 1. Each assignment must be accompanied by a recurring fee (at least > > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > > (compared to other costs) to anyone who actually needs this > > multihoming solution. However, this ensures at least some minimum > > usage barrier ("those who don't really need this can use different > > multihoming solutions"), and recovery of the resources back to RIR > > after the company has gone bankrupt or no longer needs the addresses. > > If you don't know where to put the extra money, donate it to ISOC or > > something. > > > > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > > don't have much preference here), but you must not be able to justify > > for larger space. This is to avoid the organization from getting a > > larger block and chopping it into smaller pieces and polluting the > > global routing table with more specifics which would get past prefix > > length filters. > > > > 3. assignments from a separate address block, set aside for PI. To > > ease strict "assignment-size only" filtering of these blocks. From stephen at sprunk.org Thu Apr 20 18:19:07 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 20 Apr 2006 11:19:07 -0500 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive References: Message-ID: <054601c66496$60f6b210$3712fea9@ssprunk> Thus spake "Pekka Savola" > On Thu, 20 Apr 2006, Scott Leibrand wrote: >>> 1. Each assignment must be accompanied by a recurring fee (at least >>> 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts >>> (compared to other costs) to anyone who actually needs this >>> multihoming solution. However, this ensures at least some minimum >>> usage barrier ("those who don't really need this can use different >>> multihoming solutions"), and recovery of the resources back to RIR >>> after the company has gone bankrupt or no longer needs the addresses. >>> If you don't know where to put the extra money, donate it to ISOC or >>> something. I think that the multihoming requirement will be enough to keep the number of assignments reasonable; if you look at the actual number of non-transit ASNs in the v4 table, it's not all that large. If we assume one PIv6 prefix per non-transit ASN, which is the goal, we're looking at under 10k routes from the ARIN region. >> As has been discussed at ARIN, this is a good way to get the >> government to declare the RIR a monopoly engaging in anticompetitive >> behavior. I for one don't want that. > > I don't think that follows, but unless ARIN legal counsel or someone > who is a real lawyer has made a statement here, I'm not sure how > seriously to take this. Pointer to such official legal counsel would > be appreciated. > > That is, ARIN has every right to require, for example, that everyone > getting a prefix is (for instance) a member of ARIN, and charging for > the membership should be OK. I'd want a lawyer to sign off on it. You're talking about deliberately charging an excessive fee to make it more difficult for smaller companies to compete with larger ones. That has the appearance of an industry cartel creating artificial barriers to lock their smaller competitors out of the market, and the FTC generally doesn't like that. Then again, IANAL. > RIRs run on non-profit principle, but nothing precludes them from > increasing the expenses, e.g., for donations to make the internet a > better place, That's an interesting thought, but siphoning off fees for other purposes (no matter how noble or popular) is a slippery slope. Let's keep the RIRs focused on what they were created for and on a cost-recovery basis, and members who want to donate to ISOC or other groups can do so. > setting a foundation for multihoming research to actually SOLVE this > problem, etc.etc. In theory, we already have a group tasked with that: the IETF. Are you proposing that RIRs start developing protocols outside the IETF? Or funding people to work full-time in the IETF on problems pertinent to RIRs? Again, this is a slippery slope and distracts from the RIRs' purpose. I definitely encourage the folks that are against PIv6 to work on better solutions, but IMHO the RIRs are not the correct vehicle or forum for that. ARIN is already treading on thin ice by rejecting the IETF's addressing plan. >>> 2. one-size-fits-all assignments, period. You get a /48 or /32 (I >>> don't have much preference here), but you must not be able to justify >>> for larger space. This is to avoid the organization from getting a >>> larger block and chopping it into smaller pieces and polluting the >>> global routing table with more specifics which would get past prefix >>> length filters. >> >> With the current ARIN policy proposal, you'd get a /48, with a /44 >> reserved for growth. Would you advocate giving everyone a /44 up front >> instead? Or something else? I don't have too much preference here, >> FWIW. > > I wouldn't object to reserving a /44 just in case, but make no > provisions (at this point) for applying more. If someone needs more > than /48, it needs to justify another one, and get a separate /48 > (with its own reserved /44). So instead of giving an org a /47, which _could_ be advertised as a single route, you'd prefer to give them two /48s, which _must_ be advertised as two routes? That seems to increase routing table pollution, not reduce it. Also, what's the point of reserving a /44, or worse multiple /44s, if we're only going to let people use a /48? That seems to defeat the purpose of having a reserved block. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From tme at multicasttech.com Thu Apr 20 18:32:23 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 20 Apr 2006 12:32:23 -0400 Subject: [ppml] [address-policy-wg] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <5BD9BD06-D30E-4FDD-89A8-837ECBAF4566@multicasttech.com> Hello; On Apr 20, 2006, at 11:28 AM, Pekka Savola wrote: > On Thu, 20 Apr 2006, Joao Damas wrote: >>>> As has been discussed at ARIN, this is a good way to get the >>>> government to >>>> declare the RIR a monopoly engaging in anticompetitive >>>> behavior. I for >>>> one don't want that. >> >> Pekka, this doesn't sound like the right way to do policy, and yes, >> things that smell like "big guys get it, small guys don't" will be >> looked at suspiciously and rightly so. Criteria ought to be of a >> technical nature. > > I'm assuming this is already in reference to, "PI should cost money" > instead of "PI shouldn't be available, period"... > > Larger end-sites already have 10-20k+ annual budget (most have much, > much larger than that): caused by CAPEX by getting at least two > routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and > salaries of network engineering staff. > Yes, but I know many of people (including myself and basically all of my clients) who would regard a $ 5K tax as pretty onerous. You also run the risk of giving people the feeling that the system is weighted towards the large stakeholders. Now, I do not feel that way, but I hear from plenty of people who do, and it's hard to see how they wouldn't take it this way. Regards Marshall > AFAICS, whether or not a PI space would cost 0, 1000 or 5000 USD a > year is NOT a barrier for entry. It's just *one* metric (you may be > able to think of technical metrics that could imply the same, I can't) > to say, "if you REALLY don't need this, it'd be nice if you seriously > consider PA address space". > >> Don't want PI: propose a feasible alternative that provides the same >> functionality under the current routing system, while looking for >> a better >> system > > Use PA addresses and Unique Local Addresses if you really think you > need them. Push for shim6. Put some work on solving the remaining > problems if there really are any that aren't caused by the desire to > graze the commons for free. > > Maybe I should have snipped this quote, as this seems like a rathole > which isn't worth exploring (again) here... > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From maxtul at merezha.net Thu Apr 20 18:48:50 2006 From: maxtul at merezha.net (Maxim V. Tulyev) Date: Thu, 20 Apr 2006 20:48:50 +0400 Subject: [address-policy-wg] RE: Question In-Reply-To: <20060420114729.GK60910@Space.Net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <200604201308.21095.maxtul@merezha.net> <20060420114729.GK60910@Space.Net> Message-ID: <200604202048.50442.maxtul@merezha.net> Hi, > > But if that channel fails, you will lose connectivity at all. > ... to destinations that filter the /48 and have no default route. No. When I tried to announce /48 last time (near one year ago) - it was filtered out at third hop or so. Also it wasn't present at all looking glasses. Hm. Now it is interesting to try out it now. Just try tomorrow and say the result ;) > > That's NOT like PI or more specific IPv4 that can be announced and is > > working in the wild as an independent part of Internet. > > As long as the aggregate is visible, reachability is as good as for IPv4 PI > space, if not better. As long as the aggregate is visible, assuming I have connectivity from my primary uplink. And when it is not visible - I can't get connectivity at all :( -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From steven.feldman at cnet.com Thu Apr 20 19:27:39 2006 From: steven.feldman at cnet.com (Steve Feldman) Date: Thu, 20 Apr 2006 10:27:39 -0700 Subject: [ppml] [address-policy-wg] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <5BD9BD06-D30E-4FDD-89A8-837ECBAF4566@multicasttech.com> References: <5BD9BD06-D30E-4FDD-89A8-837ECBAF4566@multicasttech.com> Message-ID: >>> Pekka, this doesn't sound like the right way to do policy, and yes, >>> things that smell like "big guys get it, small guys don't" will be >>> looked at suspiciously and rightly so. Criteria ought to be of a >>> technical nature. >> >> I'm assuming this is already in reference to, "PI should cost money" >> instead of "PI shouldn't be available, period"... >> >> Larger end-sites already have 10-20k+ annual budget (most have much, >> much larger than that): caused by CAPEX by getting at least two >> routers, OPEX by paying to multiple ISPs for fibers, transit, etc. >> and >> salaries of network engineering staff. >> > > Yes, but I know many of people (including myself and basically all of > my clients) who > would regard a $ 5K tax as pretty onerous. > > You also run the risk of giving people the feeling that the system is > weighted towards > the large stakeholders. Now, I do not feel that way, but I hear from > plenty of people who do, > and it's hard to see how they wouldn't take it this way. It doesn't make much sense to me for an RIR to charge large fees for v6 PI assignments, doing so is essentially behavior modification through taxation. On the other hand, it make perfect sense for anyone who wants their PI space advertised to pay their upstreams for the privilege, since there is a real cost in doing so. Also, it's naive to think that we won't ever have to pay for another round of router upgrades across the Internet; the only question is how long it can be delayed. Perhaps this time, though, it can be funded by the providers' customers, not the stockholders and creditors. Steve From terry.l.davis at boeing.com Thu Apr 20 19:35:01 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Thu, 20 Apr 2006 10:35:01 -0700 Subject: [address-policy-wg] RE: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BF4F@XCH-NW-8V1.nw.nos.boeing.com> Scott Good points. I might also ask folks to think back to the mid-nineties when the v6 designs were initiated. In 95 few businesses considered their network links to be "business critical", we couldn't have known that the corporate world would expect network reliability of 5 9's as a baseline today. Nor could we have guessed even in 2000 that our network reliability and outage recovery plans would be part our Sarbanes-Oxley audits. What I can tell you now is that because of these fundamental changes in business globally, the deployment model we envisioned in the mid-nineties won't work for business today. -There is simply no way that large corporations would sign up with a "single provider" for their IP addresses. The network is now the life blood of business and I don't know of any business executive that would permit themselves to be tied to a single supplier for something so critical to their bottom line. -Likewise, multi-homing to business is now a de-facto network expectation of most large corporations. As I said, they expect to deploy regional/national/global networks that have seamless connectivity with their sites and 5 9's or better of reliability. -I'm not even sure if a single service provider for this level of business criticality would pass the Sarbanes-Oxley audits. Business, in the post Enron environment, has a level of responsibility to their shareholders that they never could have envisioned a decade ago. In the decade it has taken us to be ready to deploy IP-v6, the world we based many of the deployment concepts of IP-v6 on has changed radically. We need to find a way to accommodate these changes in the relationship of the network to business; PI space is the only concept that I have seen so far that will provide business with the service model they now need. I'm virtually certain that most large and/or international corporations won't deploy IP-v6 unless they can make the service model fit their business needs. Take care Terry > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Thursday, April 20, 2006 7:10 AM > To: Pekka Savola > Cc: ppml at arin.net; address-policy-wg at ripe.net; global-v6 at lists.apnic.net > Subject: Re: [ppml] Just say *NO* to PI space -- or how to make it > lessdestructive > > On 04/20/06 at 4:48pm +0300, Pekka Savola wrote: > > > Now, from practical point of view, it seems there is strong "need" for > > PI, and it might be a PI policy of some kind might actually get > > through. > > Very true. I'd even s/might/will/. > > > If so, the policy should be such that it minimizes the bad effects of > > PI and encourages people to use other solutions if those are viable > > for them (unfortunately, the only way to achieve that appears to be > > $$$$), in particular (in the rough order of importance): > > > > 1. Each assignment must be accompanied by a recurring fee (at least > > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > > (compared to other costs) to anyone who actually needs this > > multihoming solution. However, this ensures at least some minimum > > usage barrier ("those who don't really need this can use different > > multihoming solutions"), and recovery of the resources back to RIR > > after the company has gone bankrupt or no longer needs the addresses. > > If you don't know where to put the extra money, donate it to ISOC or > > something. > > As has been discussed at ARIN, this is a good way to get the government to > declare the RIR a monopoly engaging in anticompetitive behavior. I for > one don't want that. > > Now if you think ISPs should start charging end sites for the privilege > of running BGP, that might fly. ISPs in the DFZ are bearing the costs of > maintaining the extra routes*, so they can justify a per-route charge, and > they actually have contracts with their customers, so they can collect. > (* Yes, other end sites in the DFZ also bear those costs, but since they > contribute routes to the table as well, and can sometimes switch to > default-only BGP, I'd argue that DFZ ISPs are the ones stuck "holding the > bag" of routing table growth.) > > > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > > don't have much preference here), but you must not be able to justify > > for larger space. This is to avoid the organization from getting a > > larger block and chopping it into smaller pieces and polluting the > > global routing table with more specifics which would get past prefix > > length filters. > > With the current ARIN policy proposal, you'd get a /48, with a /44 > reserved for growth. Would you advocate giving everyone a /44 up front > instead? Or something else? I don't have too much preference here, FWIW. > > > 3. assignments from a separate address block, set aside for PI. To > > ease strict "assignment-size only" filtering of these blocks. > > This is already a part of 2005-1, and has been a part (expressed or > implied) of every other PI proposal I've seen. > > -Scott > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Fri Apr 21 04:39:44 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 20 Apr 2006 21:39:44 -0500 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive References: <054601c66496$60f6b210$3712fea9@ssprunk> Message-ID: <088201c664ec$d991ac60$3712fea9@ssprunk> Thus spake "Pekka Savola" > On Thu, 20 Apr 2006, Stephen Sprunk wrote: >> I think that the multihoming requirement will be enough to keep the >> number of assignments reasonable; if you look at the actual number of >> non-transit ASNs in the v4 table, it's not all that large. If we assume >> one PIv6 prefix per non-transit ASN, which is the goal, we're looking at >> under 10k routes from the ARIN region. > > (Actually, the number is somewhere between 15k and 20k but that's beside > the point.) ARIN Region origin ASes present in the Internet Routing Table: 10637 ... ARIN Region transit ASes present in the Internet Routing Table: 986 To me, that says we have 9651 non-transit ASes in ARIN-land today. Now, if every one of those ASes got an assignment under 2005-1, we'd kick up the size of the v6 routing table to 14 times its current size -- but it'd still be only 1/18th of the current v4 table. Where's the problem? > The upper limit is around the number of AS numbers, and if it's expanded > to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure > 64K folks playing around at DFZ isn't enough??? we want 4B instead...????" There's at least one router vendor that claims their box can do 1M routes today; Moore's Law says in 18 years they'll be able to do 4B ASes with one prefix each. I'm pretty confident we won't run into that particular limit before we run out of networks to multihome, at least not with the proposal on the table today. > Remember, it's easy and cheap to have a multihoming setup with two DSL > lines... That loophole in the definition of multihoming needs to be fixed. For that matter, ARIN told me offlist that two IP-in-IP tunnels over a single physical link counts as multihoming... Sheesh. OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two pipes or tunnels), and there's not all that many companies doing it. It's not growing much either. The doors are already wide open for a land rush and nobody is taking ARIN up on it. Why does everyone assume it'll happen with v6 if it's not happening with v4, which _is_ useful today? >>> setting a foundation for multihoming research to actually SOLVE this >>> problem, etc.etc. >> >> In theory, we already have a group tasked with that: the IETF. Are >> you proposing that RIRs start developing protocols outside the IETF? Or >> funding people to work full-time in the IETF on problems pertinent >> to RIRs? Again, this is a slippery slope and distracts from the RIRs' >> purpose. > > I said 'research', not 'engineering'. The IETF isn't the right vessel for > research, though IETF could maybe be consulted on it. s/IETF/IRTF/ then. The RRG is expecting to have results sometime between 2007 and 2011. That's probably sufficient, if they actually deliver something useful. Still, the RIRs' job is not research, it is stewardship of address space and serving its members. >>> I wouldn't object to reserving a /44 just in case, but make no >>> provisions (at this point) for applying more. If someone needs more >>> than /48, it needs to justify another one, and get a separate /48 >>> (with its own reserved /44). >> >> So instead of giving an org a /47, which _could_ be advertised as a >> single route, you'd prefer to give them two /48s, which _must_ be >> advertised as two routes? That seems to increase routing table >> pollution, not reduce it. > > Not necessarily. Doing so would hopefully ensure that it'll be *more* > difficult to justify for more than a /48 especially if you have to pay for > the extra too (hence less pollution). I.e., we'd need to figure out we > have sufficiently strict criteria. That just seems backwards to me. If a site _can_ justify more than a /48 under whatever the policy is, why would we want to assign two separate blocks that can't be aggregated into a single route? >> Also, what's the point of reserving a /44, or worse multiple /44s, if >> we're only going to let people use a /48? That seems to defeat the >> purpose of having a reserved block. > > As I said, I wouldn't object to reserving a /44 under those conditions, > but I wouldn't require reservation either. One reason for reserving is > that we could have the option of changing the policy later if we become > wiser (or dumber) and decide that maybe we'll want to be able to deal out > aggregatable chunks after all, regardless of the more specific crap that's > filling the routing tables right now. If we're going to reserve, we ought to assign supernets within that block as justified by the org. If they deaggregate, so be it, but at least there's the chance they won't. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From Marcus.Ruchti at colt.net Fri Apr 21 10:57:05 2006 From: Marcus.Ruchti at colt.net (Ruchti, Marcus) Date: Fri, 21 Apr 2006 09:57:05 +0100 Subject: AW: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive Message-ID: Hi Dennis, I don't think flapping routes will increase due to the assignments of PI space, as in the most cases ISP's are requesting those for customers and offers managed multihoming solutions. So announcing these routes into BGP is the responsibility of an ISP. Regards Marcus Ruchti COLT Telecom -----Urspr?ngliche Nachricht----- Von: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von Dennis Lundstr?m Gesendet: Donnerstag, 20. April 2006 16:25 An: Pekka Savola Cc: ppml at arin.net; address-policy-wg at ripe.net; global-v6 at lists.apnic.net Betreff: Re: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive Hi Pekka. Totally agree with you there. At the moment as we have PI with IPv4, and I'll guess there will be lot's of fuzz dropping It. On the other hand. If PI allocations were no more, then the same people you nag about here would try to become their own ASN:s. And the percentage of peers running on cheap 'o pc-boxes would quite possibly increase. Resulting in that the problem with flapping routes would probably remain, or even get worse. So the problem is really. How do we regulate PI to only be an accepted solution for extreme cases? And still have a fair policy to those who really needs this feature. Best regards. --Dennis Lundstr?m GippNET Pekka Savola wrote: > Hi, > > I don't support PI space to end-sites. We have to get rid of the > notion that a random end-site has any business whatsoever in mucking > with the global routing tables, either by making it much larger than > need be or by polluting it with needless dynamicity. > > Example of the latter: deploying inbound traffic engineering > adjustment solutions which result in thousands of daily flaps in the > advertisements, as shown by Huston's analysis. > > We have way too much trouble with clueless ISPs to also add (or > continue to add) end-sites to the mix... > > .... > > Now, from practical point of view, it seems there is strong "need" for > PI, and it might be a PI policy of some kind might actually get > through. > > If so, the policy should be such that it minimizes the bad effects of > PI and encourages people to use other solutions if those are viable > for them (unfortunately, the only way to achieve that appears to be > $$$$), in particular (in the rough order of importance): > > 1. Each assignment must be accompanied by a recurring fee (at least > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > (compared to other costs) to anyone who actually needs this > multihoming solution. However, this ensures at least some minimum > usage barrier ("those who don't really need this can use different > multihoming solutions"), and recovery of the resources back to RIR > after the company has gone bankrupt or no longer needs the addresses. > If you don't know where to put the extra money, donate it to ISOC or > something. > > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > don't have much preference here), but you must not be able to justify > for larger space. This is to avoid the organization from getting a > larger block and chopping it into smaller pieces and polluting the > global routing table with more specifics which would get past prefix > length filters. > > 3. assignments from a separate address block, set aside for PI. To > ease strict "assignment-size only" filtering of these blocks. > ************************************************************************************* The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way. The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security at colt.net and delete the message and any attachments without retaining any copies. Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses. No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party. Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900. From stephen at sprunk.org Fri Apr 21 12:19:31 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 21 Apr 2006 05:19:31 -0500 Subject: [address-policy-wg] Re: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive References: <054601c66496$60f6b210$3712fea9@ssprunk><20060421032349.GA20024@srv01.cluenet.de> Message-ID: <0b4301c6652d$15b1def0$3712fea9@ssprunk> Thus spake "Pekka Savola" > On Fri, 21 Apr 2006, Daniel Roesen wrote: >> On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote: >>> Remember, it's easy and cheap to have a multihoming setup with >>> two DSL lines... ARIN has replied to me privately that two IPv6 tunnels over the same physical link count as "multihoming"; another PPML poster has told me privately he's actually gotten an ASN that way. IMHO this needs to be corrected, but it doesn't appear to be abused except out of novelty, so it's not a dire emergency. >> Could you finally make up your mind? First, your argument was that >> multihoming is expensive anyway, so shelling out another couple >> thousand of EUR/USD/whatever doesn't make a difference - just to >> keep the clueless bottom-feeders out. Now you say it's totally >> cheap to multihome. >> >> You're contradicting yourself. > > You took the comments out of context. The former describes that > _real_ multihoming is expensive, the latter describes that you could > obtain "multihoming" very easily. The point is that we definitely > shouldn't want to assign PI to the organizations in the latter > category. My reading of the proposal is that it would allow anyone who is multihomed to get a PIv6 /48 if they can demonstrate the ability to utilize 256 addresses immediately and 512 addresses within one year, or 1024 and 2048 addresses, respectively, if not multihomed. The address counts appear to be reasonable at first blush. They're high enough to stop residential and SOHO users, but low enough for nearly any shop with BGP clue to get a block. Do remember that only a few hundred direct assignments have been made under the PIv4 policy, so apparently it's not _too_ low or we'd have seen a land rush already. As far as fees, if the org already has IPv4 space of some sort, the PIv6 assignment will presumably be free through 31 Dec 07 like PAv6 assignments and USD1250/yr after that. The idea of charging thousands of dollars more to discourage PIv6 applications is not in line with existing fee schedules and rather pointless since folks can apparently claim to be LIRs without much difficulty and pay USD2250/yr for a /32. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From ppml at rs.seastrom.com Fri Apr 21 14:25:40 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Fri, 21 Apr 2006 08:25:40 -0400 Subject: [address-policy-wg] Re: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <0b4301c6652d$15b1def0$3712fea9@ssprunk> (Stephen Sprunk's message of "Fri, 21 Apr 2006 05:19:31 -0500") References: <054601c66496$60f6b210$3712fea9@ssprunk> <20060421032349.GA20024@srv01.cluenet.de> <0b4301c6652d$15b1def0$3712fea9@ssprunk> Message-ID: <87hd4ndsjf.fsf@valhalla.seastrom.com> "Stephen Sprunk" writes: > ARIN has replied to me privately that two IPv6 tunnels over the same > physical link count as "multihoming"; another PPML poster has told me > privately he's actually gotten an ASN that way. > > IMHO this needs to be corrected, but it doesn't appear to be abused except > out of novelty, so it's not a dire emergency. Now, this is an interesting one. Where would you draw the line for diversity of connections being truly "multihomed"? Here are a few scenarios for your consideration: Commodity MPLS from a third party provider (yes, i know this doesn't exist yet) with one pipe going to two ISPs. Commodity Frame Relay or ATM with two DAFs entering the facility, but an inspection of the DLRs for the PVCs shows that they both traverse the same switch. Two SONET connections that are groomed onto the same OC48. Two SONET connections that are physically distinct but enter the customer facility via the same conduit. I'm not so sure that I agree with your implication that justifying an ASN on the basis of two tunnels is "abuse". It might be "poor engineering", "unwise", or "certainly something I would never do", but ARIN policy is intended to apply good stewardship principles, not coerce people's business or engineering plans. We agree that the current level of unconventional registration is likely low. I don't agree that there's anything to "fix" here. By the way, the other way you can justify an ASN is to have a "unique routing policy". What that constitutes is left as an exercise to the reader, but I'm sure that a session in the bar in St. Louis could come up with some really freaky scenarios. Current policy is OK by me. It will be even more OK after 32-bit ASNs are the norm. ---Rob From tme at multicasttech.com Fri Apr 21 15:55:47 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 21 Apr 2006 09:55:47 -0400 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> References: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> Message-ID: Hello; On Apr 21, 2006, at 8:56 AM, Thomas Narten wrote: > "Stephen Sprunk" writes: > >> OTOH, it's ridiculously easy to get PIv4 space today (512 hosts >> and two >> pipes or tunnels), and there's not all that many companies doing >> it. It's >> not growing much either. The doors are already wide open for a >> land rush >> and nobody is taking ARIN up on it. Why does everyone assume >> it'll happen >> with v6 if it's not happening with v4, which _is_ useful today? > > Because today, people are a lot more network savvy, and they now > understand the potential value of getting real PI space. Moreover, > anyone who understands history, realizes that getting PI space may > become harder in the future, rather than easier. Consequently, it > would be a smart business move to get PI space ASAP, in case the rules > change down the road. i.e, a rather prudent investment. > No doubt. That still doesn't explain why more people aren't taking advantage of 2002-3 in IPv4. I think that this is an indicator that - there are some small companies that need to multi-home - the numbers of these is fairly small - people are not (yet) viewing PI space as real property. (There are clearly a number of small companies that truly need to multi-home. Streaming and videoconferencing providers, for example, probably should multi-home regardless of their size.) Clearly, I think it would be to everyone's advantage if people (on a wide scale) _never_ start viewing PI space as real property. I think that the best way to ensure that this does not happen is to adopt 2005-1. If there is a near infinite supply of something, there is no need to hoard it. > Thomas > Regards Marshall > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From tme at multicasttech.com Fri Apr 21 16:00:11 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 21 Apr 2006 10:00:11 -0400 Subject: [address-policy-wg] Re: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: On Apr 21, 2006, at 9:55 AM, Michael.Dillon at btradianz.com wrote: >> Commodity Frame Relay or ATM with two DAFs entering the >> facility, but >> an inspection of the DLRs for the PVCs shows that they both >> traverse >> the same switch. >> >> Two SONET connections that are groomed onto the same OC48. > > We know that separacy of circuits is subject to change due to > the widespread use of switches (DACS, ATM, Ethernet) and the > widespread telecom practice of grooming customer circuits > over time. It is hard work to ensure that true separacy > exists when it is needed to meet customer contract conditions. Empirically, I would say that it is impossible to be sure. I have heard too many stories of a {fire, collision, back hoe, etc.} taking down two circuits that were supposed to be geographically separated, or circuits that weren't supposed to be going that way at all. If the people charged with doing this can't be sure, how can ARIN ? > Given this, I think it would be unwise to specify the degree > of separacy in an ARIN policy. It would be almost impossible to > enforce such a provision even if you restrict it to new > applications. And even then, anyone can comply to get their > ASN and PI block, then go back to the pair of IPv6 tunnels > for the long haul. > > ARIN policy has always had to strike a balance. We are not > lawmakers or law enforcers. I would agree. Regards Marshall > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Fri Apr 21 19:49:30 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Apr 2006 10:49:30 -0700 Subject: [address-policy-wg] Re: [ppml] [GLOBAL-V6] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <0b4301c6652d$15b1def0$3712fea9@ssprunk> References: <054601c66496$60f6b210$3712fea9@ssprunk> <20060421032349.GA20024@srv01.cluenet.de> <0b4301c6652d$15b1def0$3712fea9@ssprunk> Message-ID: <418ABC4E7F319E31AF9A7871@imac-en0.delong.sj.ca.us> > As far as fees, if the org already has IPv4 space of some sort, the PIv6 > assignment will presumably be free through 31 Dec 07 like PAv6 > assignments and USD1250/yr after that. The idea of charging thousands > of dollars more to discourage PIv6 applications is not in line with > existing fee schedules and rather pointless since folks can apparently > claim to be LIRs without much difficulty and pay USD2250/yr for a /32. > Only if the ORG is an ARIN member. If they are not a member, there is no waiver. Membership is $500/year if you are not an ISP subscriber member (which involves paying significantly more for your allocation/assignment unless you are a v6-only ISP). Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From nick at inex.ie Fri Apr 21 22:13:17 2006 From: nick at inex.ie (Nick Hilliard) Date: Fri, 21 Apr 2006 21:13:17 +0100 Subject: [ppml] [address-policy-wg] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: <5BD9BD06-D30E-4FDD-89A8-837ECBAF4566@multicasttech.com> Message-ID: <1145650397.78861.4.camel@crumpet.netability.ie> > On the other hand, it make perfect sense for anyone who wants their > PI space advertised to pay their upstreams for the privilege, since > there is a real cost in doing so. Mmmm, and how is this going to guarantee that the PI space is accepted by third party networks? I'm aware that the two things are separate, paying to have your prefixes accepted by an upstream, and expecting them to be globally routable. But how is the average Joe Schmoe customer going to feel if they pay a premium to have their PI prefixes "accepted" by their ISP's upstreams, when they're not accepted by anyone else? Not convinced, Nick From randy at psg.com Sat Apr 22 08:50:59 2006 From: randy at psg.com (Randy Bush) Date: Fri, 21 Apr 2006 20:50:59 -1000 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> References: <200604211256.k3LCu3V5011765@cichlid.raleigh.ibm.com> Message-ID: <4449D253.2030700@psg.com> > Because today, people are a lot more network savvy, and they now > understand the potential value of getting real PI space. Moreover, > anyone who understands history, realizes that getting PI space may > become harder in the future, rather than easier. Consequently, it > would be a smart business move to get PI space ASAP, in case the rules > change down the road. i.e, a rather prudent investment. aka 'land rush' pfui! randy From gert at space.net Sat Apr 22 10:20:29 2006 From: gert at space.net (Gert Doering) Date: Sat, 22 Apr 2006 10:20:29 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <200604202048.50442.maxtul@merezha.net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <200604201308.21095.maxtul@merezha.net> <20060420114729.GK60910@Space.Net> <200604202048.50442.maxtul@merezha.net> Message-ID: <20060422082029.GH60910@Space.Net> Hi, On Thu, Apr 20, 2006 at 08:48:50PM +0400, Maxim V. Tulyev wrote: > > > That's NOT like PI or more specific IPv4 that can be announced and is > > > working in the wild as an independent part of Internet. > > > > As long as the aggregate is visible, reachability is as good as for IPv4 PI > > space, if not better. > > As long as the aggregate is visible, assuming I have connectivity from my > primary uplink. If the primary and secondary uplink peer with each other, and the primary accepts the /48 from the secondary (which would be a good thing to do), you are always reachable as long as the aggregate is up - the aggregate will draw the traffic "near to" the primary uplink, and at some point, it will hit a router that will also know the /48, and send the packets to the secondary uplink. As I said: we do this with customers, and it works better than the currently available alternatives. (It's not perfect, no.) > And when it is not visible - I can't get connectivity at all :( Not to people that have no default and decide to filter your more-specific route, yes. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From rogerj at jorgensen.no Sat Apr 22 12:34:04 2006 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Sat, 22 Apr 2006 12:34:04 +0200 (CEST) Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: References: Message-ID: On Fri, 21 Apr 2006 Michael.Dillon at btradianz.com wrote: great idea, finaly others that also have thought baout it... however, yeah it's a great change of the way Internet are and exist, and work... but it's doable. Guess the ISP just hate the idea tho... > > Now that is a very interesting suggestion. If you assume > that multiple peering points in a single city have rich > and cheap interconnection, you could extend this idea > to one prefix per city with a population greater than > 100,000. There are about 5000 such cities in the world > so we are talking about 5000 prefixes. Of course, each > of these cities serves a larger surrounding area with > various services and such services often reach across > national borders. For instance, the inhabitants of Kehl > and Offenburg in Germany are likely to use services in > Strasbourg, France such as the Opera du Rhin, shopping, > etc. > > If you consider these large cities as centres of gravity > for the surrounding area, then these 5000 cities cover > almost all of the populated surface of the Earth. What > could we do with 5000 such routes in the global routing > table? > > Well, for one thing, we could offer an almost unlimited > number of PI IPv6 address blocks to ever business or > organization that feels the need to multihome in order > to secure the separacy plus resiliency that need in > their network connections. All of those PI blocks would > be invisible in 4999 of the world's cities because those > cities will only see the single city prefix. We then have > solved the routing table scaling problem by dividing > and conquering. There still could be some localised issues > in some cities, but it is much simpler for a group of > local ISPs to sort out a local issue than it is for everybody > in the world to agree on the one true routing solution. > > The best part of this solution is that it requires no > protocol changes, no new code in routers, and works with > all existing IPv6 technology. It can be implemented entirely > by changing RIR allocation rules, and ISP business practices. > This is not a "flag day" situation either. There is no need > to stop issuing and using provider aggregatable addresses. > These new geo-topo aggregatable addresses can coexist in the > same network. Some ISPs will choose to only assign one kind > of addresses, either classic PA or new geo-topo addresses. Others > will use both and use the newer ones to provide new services. > > The only area where business practices needs to change is > inside a single city aggregate where the ISPs inside that > aggregate have to agree on how to exchange traffic and how > to deal with the hot-potato nature of geo-topo routing. > Each city is free to come up with its own variation on this > as long as they do not deaggregate the city aggregate address > block outside of bilateral peering agreements. In other words, > ISPs in London will see only a single route to all of the geo-topo > space in Paris unless they have specific bilateral agreements > with Paris ISPs. > > Remember we have reserved 7/8ths of the IPv6 address space in > order to be able to implement these types of new addressing schemes. > The main problem to be solved in order to deploy this, other > than general agreement on the scheme, is how to size each of the > 5000 city aggregate blocks. Geographers and economists would likely > find this easy work, but we have to make contact with them, explain > the problem, and ask for their analyses. > > > Won't take long until the first ISPs fall. And then more and more will > have > > to. There is no strong community, apart from those customers with > > lots-o-money. > > Most businesses only survive and thrive because they serve their > customers well. Any ISP that expects to have a strong future must > understand the needs of their customer base and then organize their > company resources to serve those customers. This means that ISPs who > see this as a battle of the PROVIDERS (with PA addresses) against the > END USERS (with subnets assigned from PA blocks) are doomed. Providers > have to look at this problem from the end user point of view and then > find some solution that meets the end user needs while at the same > time offering the ability for the provider to continue providing > valuable services. > > In general, as you point out, these situations are like a steamroller > and end user demand will win out in the end. However, we can avoid a > period of chaos and instability if the providers take the lead and > manage an orderly transition to the new network order. > > --Michael Dillon > > -- ------------------------------ Roger Jorgensen | roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From jorgen at hovland.cx Sat Apr 22 15:21:56 2006 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Sat, 22 Apr 2006 15:21:56 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: Message-ID: <001a01c6660f$babd5270$0200000a@j> I think this idea is no better than standard redundancy (multiple lines to the same ISP). Actually, I think it is worse since it is required of you to either stay in the city or stretch a long fibre to it should you move all or some of your stuff to another. Companies will try to do the latter because they don't want to change their IP. There are three types of PI-holders today a.f.a.i.k.: * The ones that just don't want to change IP-address and never use more than 1 ISP anyway. They don't have an AS number. * Same as above, but they have multiple lines to the ISP (redundancy). * Enterprises with "real" need of multi-homing having multiple uplinks to multiple ISPs and their own AS number. Couldn't the companies that _need_ PI multi-homing for redundancy reasons, these enterprises, create an ISP and get their "multi-homing" there instead? Can't be too hard filling in a ltd. application. I wouldn't be surprised if several enterprises have done it that way already. Since the stocks are owned by the enterprise (and perhaps a few others), being afraid of so-called bankruptcy is void. At least it is easier than getting IPv6 PI today. I believe the issue with keeping your IP-address when changing ISP is another problem. First of all, it is bad network setup to have such a requirement but there is a long way to avoid this with some of todays technology. Secondly, everybody should be able to keep their IP-address if they want (DNS is obviously not good enough). Not just PI-holders. j -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Roger Jorgensen Sent: 22. april 2006 12:34 To: Michael.Dillon at btradianz.com Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive On Fri, 21 Apr 2006 Michael.Dillon at btradianz.com wrote: great idea, finaly others that also have thought baout it... however, yeah it's a great change of the way Internet are and exist, and work... but it's doable. Guess the ISP just hate the idea tho... > > Now that is a very interesting suggestion. If you assume > that multiple peering points in a single city have rich > and cheap interconnection, you could extend this idea > to one prefix per city with a population greater than > 100,000. There are about 5000 such cities in the world > so we are talking about 5000 prefixes. Of course, each > of these cities serves a larger surrounding area with > various services and such services often reach across > national borders. For instance, the inhabitants of Kehl > and Offenburg in Germany are likely to use services in > Strasbourg, France such as the Opera du Rhin, shopping, > etc. > > If you consider these large cities as centres of gravity > for the surrounding area, then these 5000 cities cover > almost all of the populated surface of the Earth. What > could we do with 5000 such routes in the global routing > table? > > Well, for one thing, we could offer an almost unlimited > number of PI IPv6 address blocks to ever business or > organization that feels the need to multihome in order > to secure the separacy plus resiliency that need in > their network connections. All of those PI blocks would > be invisible in 4999 of the world's cities because those > cities will only see the single city prefix. We then have > solved the routing table scaling problem by dividing > and conquering. There still could be some localised issues > in some cities, but it is much simpler for a group of > local ISPs to sort out a local issue than it is for everybody > in the world to agree on the one true routing solution. > > The best part of this solution is that it requires no > protocol changes, no new code in routers, and works with > all existing IPv6 technology. It can be implemented entirely > by changing RIR allocation rules, and ISP business practices. > This is not a "flag day" situation either. There is no need > to stop issuing and using provider aggregatable addresses. > These new geo-topo aggregatable addresses can coexist in the > same network. Some ISPs will choose to only assign one kind > of addresses, either classic PA or new geo-topo addresses. Others > will use both and use the newer ones to provide new services. > > The only area where business practices needs to change is > inside a single city aggregate where the ISPs inside that > aggregate have to agree on how to exchange traffic and how > to deal with the hot-potato nature of geo-topo routing. > Each city is free to come up with its own variation on this > as long as they do not deaggregate the city aggregate address > block outside of bilateral peering agreements. In other words, > ISPs in London will see only a single route to all of the geo-topo > space in Paris unless they have specific bilateral agreements > with Paris ISPs. > > Remember we have reserved 7/8ths of the IPv6 address space in > order to be able to implement these types of new addressing schemes. > The main problem to be solved in order to deploy this, other > than general agreement on the scheme, is how to size each of the > 5000 city aggregate blocks. Geographers and economists would likely > find this easy work, but we have to make contact with them, explain > the problem, and ask for their analyses. > > > Won't take long until the first ISPs fall. And then more and more will > have > > to. There is no strong community, apart from those customers with > > lots-o-money. > > Most businesses only survive and thrive because they serve their > customers well. Any ISP that expects to have a strong future must > understand the needs of their customer base and then organize their > company resources to serve those customers. This means that ISPs who > see this as a battle of the PROVIDERS (with PA addresses) against the > END USERS (with subnets assigned from PA blocks) are doomed. Providers > have to look at this problem from the end user point of view and then > find some solution that meets the end user needs while at the same > time offering the ability for the provider to continue providing > valuable services. > > In general, as you point out, these situations are like a steamroller > and end user demand will win out in the end. However, we can avoid a > period of chaos and instability if the providers take the lead and > manage an orderly transition to the new network order. > > --Michael Dillon > > -- ------------------------------ Roger Jorgensen | roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From gert at space.net Sat Apr 22 21:36:25 2006 From: gert at space.net (Gert Doering) Date: Sat, 22 Apr 2006 21:36:25 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <001a01c6660f$babd5270$0200000a@j> References: <001a01c6660f$babd5270$0200000a@j> Message-ID: <20060422193625.GI60910@Space.Net> Hi, On Sat, Apr 22, 2006 at 03:21:56PM +0200, J?rgen Hovland wrote: > technology. Secondly, everybody should be able to keep their IP-address if > they want (DNS is obviously not good enough). Not just PI-holders. That's the *definition* of "PI" - "take it with you when you change your ISP". The whole point of having PA and PI is to make sure that as much aggregation is done as possible - and for many (smaller) companies, changing their IP addresses is much less effort than getting a new leased line. The nice thing about Internet (as opposed to the telephone system) is the fact that we have DNS - and thus no need to take our "numbers" with us to be reachable. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From nick at inex.ie Mon Apr 24 10:39:30 2006 From: nick at inex.ie (Nick Hilliard) Date: Mon, 24 Apr 2006 09:39:30 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060422193625.GI60910@Space.Net> References: <001a01c6660f$babd5270$0200000a@j> <20060422193625.GI60910@Space.Net> Message-ID: <444C8EC2.1070703@inex.ie> Gert Doering wrote: > The nice thing about Internet (as opposed to the telephone system) is > the fact that we have DNS - and thus no need to take our "numbers" with > us to be reachable. This is certainly the theory. However, if you are a growing ISP, renumbering from PA space from another LIR to your own PI space or LIR/PA space can be - depending on how your customers are configured - pure pain. The portability associated with PI space is also important in one other view, in that it allows the holder to switch providers quickly and efficiently. There's no tie-in of any form, and this is something which is extremely important to business. Nick From rogerj at jorgensen.no Sun Apr 23 10:54:35 2006 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Sun, 23 Apr 2006 10:54:35 +0200 (CEST) Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <444C8EC2.1070703@inex.ie> References: <001a01c6660f$babd5270$0200000a@j> <20060422193625.GI60910@Space.Net> <444C8EC2.1070703@inex.ie> Message-ID: On Mon, 24 Apr 2006, Nick Hilliard wrote: > Gert Doering wrote: > > The nice thing about Internet (as opposed to the telephone system) is > > the fact that we have DNS - and thus no need to take our "numbers" with > > us to be reachable. > > This is certainly the theory. However, if you are a growing ISP, > renumbering from PA space from another LIR to your own PI space or > LIR/PA space can be - depending on how your customers are configured - > pure pain. > > The portability associated with PI space is also important in one other > view, in that it allows the holder to switch providers quickly and > efficiently. There's no tie-in of any form, and this is something which > is extremely important to business. So what you are saying are we need a better way to configure, reconfigure/change the connection to the end-users/customers? Thought IPv6 was suppose to solve that issue. -- ------------------------------ Roger Jorgensen | roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From gert at space.net Sun Apr 23 13:59:13 2006 From: gert at space.net (Gert Doering) Date: Sun, 23 Apr 2006 13:59:13 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <444C8EC2.1070703@inex.ie> References: <001a01c6660f$babd5270$0200000a@j> <20060422193625.GI60910@Space.Net> <444C8EC2.1070703@inex.ie> Message-ID: <20060423115913.GK60910@Space.Net> Hi, On Mon, Apr 24, 2006 at 09:39:30AM +0100, Nick Hilliard wrote: > Gert Doering wrote: > >The nice thing about Internet (as opposed to the telephone system) is > >the fact that we have DNS - and thus no need to take our "numbers" with > >us to be reachable. > > This is certainly the theory. However, if you are a growing ISP, > renumbering from PA space from another LIR to your own PI space or > LIR/PA space can be - depending on how your customers are configured - > pure pain. Yes. Been there, done that. Couple of times (renumbering an ISP's recursive name servers is *very much* pain). But that's local pain. PI is global pain to everybody else. > The portability associated with PI space is also important in one other > view, in that it allows the holder to switch providers quickly and > efficiently. There's no tie-in of any form, and this is something which > is extremely important to business. This is the standard argument, but only half-true. For serious internet connections, you usually need to move your leased-line connection, or move your servers to a new colocation - which is, assuming ``standard'' setups and some planning in advance, comparable if not more effort to changing the addresses. A poorly planned network, with everything hardcoded everywhere (up to applications that access IP addresses hard-coded in the source) is not a proper excuse to burden everbody else's routers. I accept that PI for BGP multihoming purposes is - today - one of the more reasonable ways to achieve the goal (ISP independence and resilience), but I still hope that we won't ever see the "let's get PI once, and never have to renumber again!" land rush. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From lea.roberts at stanford.edu Sun Apr 23 17:42:32 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sun, 23 Apr 2006 08:42:32 -0700 (PDT) Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: Message-ID: Roger - On Sun, 23 Apr 2006, Roger Jorgensen wrote: > On Mon, 24 Apr 2006, Nick Hilliard wrote: > > Gert Doering wrote: > > > The nice thing about Internet (as opposed to the telephone system) is > > > the fact that we have DNS - and thus no need to take our "numbers" with > > > us to be reachable. > > > > This is certainly the theory. However, if you are a growing ISP, > > renumbering from PA space from another LIR to your own PI space or > > LIR/PA space can be - depending on how your customers are configured - > > pure pain. > > > > The portability associated with PI space is also important in one other > > view, in that it allows the holder to switch providers quickly and > > efficiently. There's no tie-in of any form, and this is something which > > is extremely important to business. > > So what you are saying are we need a better way to configure, > reconfigure/change the connection to the end-users/customers? Thought > IPv6 was suppose to solve that issue. IPv6 has made it possible to renumber the network almost automatically. it seems possible to make that change without a "flag day" and an outage. however, the tools are mostly *NOT* there for similarly easy renumbering of router ACLs and firewall configs and DNS, so as the size of the network increases, large organizations are saying there is still a significant cost to renumbering (at this time...). one can only hope that appropriate tools will be developed to make full renumbering reasonably painless. or the appropriate protocol enhancements are made so that local numbers become much less relevant to global routing? /Lea From rogerj at jorgensen.no Sun Apr 23 18:54:58 2006 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Sun, 23 Apr 2006 18:54:58 +0200 (CEST) Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: References: Message-ID: On Sun, 23 Apr 2006, Lea Roberts wrote: > On Sun, 23 Apr 2006, Roger Jorgensen wrote: > > On Mon, 24 Apr 2006, Nick Hilliard wrote: > > > Gert Doering wrote: > > > > The nice thing about Internet (as opposed to the telephone system) is > > > > the fact that we have DNS - and thus no need to take our "numbers" with > > > > us to be reachable. > > > This is certainly the theory. However, if you are a growing ISP, > > > renumbering from PA space from another LIR to your own PI space or > > > LIR/PA space can be - depending on how your customers are configured - > > > pure pain. > > > > > > The portability associated with PI space is also important in one other > > > view, in that it allows the holder to switch providers quickly and > > > efficiently. There's no tie-in of any form, and this is something which > > > is extremely important to business. > > So what you are saying are we need a better way to configure, > > reconfigure/change the connection to the end-users/customers? Thought > > IPv6 was suppose to solve that issue. > IPv6 has made it possible to renumber the network almost automatically. > it seems possible to make that change without a "flag day" and an outage. > however, the tools are mostly *NOT* there for similarly easy renumbering > of router ACLs and firewall configs and DNS, so as the size of the network > increases, large organizations are saying there is still a significant > cost to renumbering (at this time...). one can only hope that appropriate > tools will be developed to make full renumbering reasonably painless. exactly! Let's use the time creatig the tools, create some standards and guidelines on HOWTO renumber instead of spending time reduing the same mistakes done in IPv4. We now have the change to save ourself from alot of trouble ~10-15years into the future... > or the appropriate protocol enhancements are made so that local numbers > become much less relevant to global routing? /Lea This would be an even better solution, but... it'll take time.... -- ------------------------------ Roger Jorgensen | roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From jeroen at unfix.org Sun Apr 23 19:07:45 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 23 Apr 2006 19:07:45 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: References: Message-ID: <1145812065.6942.6.camel@firenze.zurich.ibm.com> On Sun, 2006-04-23 at 18:54 +0200, Roger Jorgensen wrote: [mumbling about renumbering] > exactly! Let's use the time creatig the tools, create some standards and > guidelines on HOWTO renumber instead of spending time reduing the same > mistakes done in IPv4. We now have the change to save ourself from alot of > trouble ~10-15years into the future... Take a 200k+ node organisation, intra-dependencies with other companies and most of all external resources. Read: firewall rules at other parties, DNS servers hosted at other places and a lot lot more. There is no single tool which can cover that, that is a human issue as the other party will have to change things, if you can't reach them, you can't change. You don't want to wait for the other party to act. For many large organisations this will thus not work. Renumbering a large site is simply not easy. Indeed a small site (20 boxes max) with not too many external depencies can be done, but anything larger is a huge pain. > > or the appropriate protocol enhancements are made so that local numbers > > become much less relevant to global routing? /Lea > > This would be an even better solution, but... it'll take time.... This is why people are busy workin on SHIM6, HIP, SCTP and a number of other protocols. Still you will need a globally unique $something. IPv6 PI blocks can be used for this perfectly well. Just wait... before the routing tables explode (if they will) 16-bit ASN numbers run out any way and people will have to move to 32bit ASN's (funny isn't it that IPv4 is also 32bit, thus one will be addressing 32bits with 32bits...). The 32bit ASN's make sure that BGP won't go over the 2^32 routes, thus no problem there, as according to many the BGP tables can hold that (now lets see what convergence and flapping does ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From nils at druecke.strg-alt-entf.org Mon Apr 24 08:36:52 2006 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Mon, 24 Apr 2006 08:36:52 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: References: Message-ID: <20060424063652.GA31917@h8000.serverkompetenz.net> On Sun, Apr 23, 2006 at 06:54:58PM +0200, Roger Jorgensen wrote: > > IPv6 has made it possible to renumber the network almost automatically. > > it seems possible to make that change without a "flag day" and an outage. > > however, the tools are mostly *NOT* there for similarly easy renumbering > > of router ACLs and firewall configs and DNS, so as the size of the network > > increases, large organizations are saying there is still a significant > > cost to renumbering (at this time...). one can only hope that appropriate > > tools will be developed to make full renumbering reasonably painless. > exactly! Let's use the time creatig the tools, create some standards and > guidelines on HOWTO renumber instead of spending time reduing the same > mistakes done in IPv4. We now have the change to save ourself from alot of > trouble ~10-15years into the future... Your wording implies PI was a mistake in IPv4. I think it is one of the reasons for its success, not a mistake. Nils From marc.van.selm at nc3a.nato.int Mon Apr 24 09:10:26 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Mon, 24 Apr 2006 09:10:26 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <44478B96.6070307@baycix.de> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <20060420131849.GM60910@Space.Net> <44478B96.6070307@baycix.de> Message-ID: <200604240910.26454.marc.van.selm@nc3a.nato.int> On Thursday 20 April 2006 15:24, Sascha Lenz wrote: > Hi, > > Gert Doering schrieb: > > Hi, > > > > On Thu, Apr 20, 2006 at 04:14:47PM +0300, Pekka Savola wrote: > >> I wouldn't recommend advertising more specifics to anyone... and > >> again, I consider that a feature :-) > > > > Well, the combination of "no PI", "no working non-PI/BGP-multihoming > > solution" and "PA+BGP multihoming not working either" is certainly > > not something that makes currently-multihomed customers want to move to > > IPv6... > > so, let's switch to discussing > > http://www.ripe.net/ripe/policies/proposals/2006-01.html I would support this policy proposal. This would be a sound alternative to those that need to be a LIR today but do not really have to be a LIR but only require address-space that does not tie them with 1 or 2 providers "for life" and gives them the possibility to have global multi-homing (so for example, 2 access points to the Net: 1x US, 1x Europe and a private global corporate network to provide internal connectivity). Marc van Selm -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From marc.van.selm at nc3a.nato.int Mon Apr 24 09:19:18 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Mon, 24 Apr 2006 09:19:18 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <200604240919.19143.marc.van.selm@nc3a.nato.int> On Thursday 20 April 2006 15:48, Pekka Savola wrote: > Hi, > > I don't support PI space to end-sites. We have to get rid of the > notion that a random end-site has any business whatsoever in mucking > with the global routing tables, either by making it much larger than > need be or by polluting it with needless dynamicity. > > Example of the latter: deploying inbound traffic engineering > adjustment solutions which result in thousands of daily flaps in the > advertisements, as shown by Huston's analysis. > > We have way too much trouble with clueless ISPs to also add (or > continue to add) end-sites to the mix... Sorry I can't agree with you there. Organizations that really need this are generally very professional (ok not always but they they can hire a professional for them) and many times much larger than some ISPs. I think it is unfair to say that a non-ISP business is per definition not able to handle routing networks. I have just seen the 2nd fully uncordinated, but promissed to be smooth, transition of network connectivity by a large ISP in NL so I guess we all make mistakes. Could we leave emotions and kingdoms out of the discussion and focus on the real issue of a large network that happens not to be an ISP that needs solid connectivity to the net and has a large world-wide internal network managed by professionals.... Best regards, Marc -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From marc.van.selm at nc3a.nato.int Mon Apr 24 09:25:00 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Mon, 24 Apr 2006 09:25:00 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: References: Message-ID: <200604240925.01156.marc.van.selm@nc3a.nato.int> On Sunday 23 April 2006 17:42, Lea Roberts wrote: > Roger - > > On Sun, 23 Apr 2006, Roger Jorgensen wrote: > > On Mon, 24 Apr 2006, Nick Hilliard wrote: > > > Gert Doering wrote: > > > > The nice thing about Internet (as opposed to the telephone system) is > > > > the fact that we have DNS - and thus no need to take our "numbers" > > > > with us to be reachable. > > > > > > This is certainly the theory. However, if you are a growing ISP, > > > renumbering from PA space from another LIR to your own PI space or > > > LIR/PA space can be - depending on how your customers are configured - > > > pure pain. > > > > > > The portability associated with PI space is also important in one other > > > view, in that it allows the holder to switch providers quickly and > > > efficiently. There's no tie-in of any form, and this is something > > > which is extremely important to business. > > > > So what you are saying are we need a better way to configure, > > reconfigure/change the connection to the end-users/customers? Thought > > IPv6 was suppose to solve that issue. > > IPv6 has made it possible to renumber the network almost automatically. > it seems possible to make that change without a "flag day" and an outage. > however, the tools are mostly *NOT* there for similarly easy renumbering > of router ACLs and firewall configs and DNS, so as the size of the network > increases, large organizations are saying there is still a significant > cost to renumbering (at this time...). one can only hope that appropriate > tools will be developed to make full renumbering reasonably painless. Did anyone try that in a mission crytical 200+ site network? That is what I'm looking at. I'm not conviced yet that one would really like to do that. Is anyone brave enough to calculate the risks and costs for a network like that? (We solved it via the LIR route by the way.) Marc -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From gert at space.net Mon Apr 24 09:28:14 2006 From: gert at space.net (Gert Doering) Date: Mon, 24 Apr 2006 09:28:14 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <200604240919.19143.marc.van.selm@nc3a.nato.int> References: <200604240919.19143.marc.van.selm@nc3a.nato.int> Message-ID: <20060424072814.GP60910@Space.Net> Hi, On Mon, Apr 24, 2006 at 09:19:18AM +0200, Marc van Selm wrote: > Sorry I can't agree with you there. Organizations that really need this are > generally very professional (ok not always but they they can hire a > professional for them) and many times much larger than some ISPs. I think it > is unfair to say that a non-ISP business is per definition not able to handle > routing networks. I have just seen the 2nd fully uncordinated, but promissed > to be smooth, transition of network connectivity by a large ISP in NL so I > guess we all make mistakes. Could we leave emotions and kingdoms out of the > discussion and focus on the real issue of a large network that happens not to > be an ISP that needs solid connectivity to the net and has a large world-wide > internal network managed by professionals.... This is actually what I see as the major point in the "PI policy" - figure out who really "needs" it -- and I can agree that there are many networks that would qualify, "being large enough, competent enough, and important[1] enough". Speaking as a network operator (not as WG co-chair) I would be fairly unhappy with a PI policy that permits "about anyone" to get PI - because PI is very unbalanced regarding "who benefits, and who pays for it". [1] yes, "important enough" is very difficult to measure. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From marc.van.selm at nc3a.nato.int Mon Apr 24 09:40:35 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Mon, 24 Apr 2006 09:40:35 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <20060424072814.GP60910@Space.Net> References: <200604240919.19143.marc.van.selm@nc3a.nato.int> <20060424072814.GP60910@Space.Net> Message-ID: <200604240940.36060.marc.van.selm@nc3a.nato.int> On Monday 24 April 2006 09:28, Gert Doering wrote: > Hi, > > On Mon, Apr 24, 2006 at 09:19:18AM +0200, Marc van Selm wrote: > > Sorry I can't agree with you there. Organizations that really need this > > are generally very professional (ok not always but they they can hire a > > professional for them) and many times much larger than some ISPs. I think > > it is unfair to say that a non-ISP business is per definition not able to > > handle routing networks. I have just seen the 2nd fully uncordinated, but > > promissed to be smooth, transition of network connectivity by a large ISP > > in NL so I guess we all make mistakes. Could we leave emotions and > > kingdoms out of the discussion and focus on the real issue of a large > > network that happens not to be an ISP that needs solid connectivity to > > the net and has a large world-wide internal network managed by > > professionals.... > > This is actually what I see as the major point in the "PI policy" - figure > out who really "needs" it -- and I can agree that there are many networks > that would qualify, "being large enough, competent enough, and important[1] > enough". > > Speaking as a network operator (not as WG co-chair) I would be fairly > unhappy with a PI policy that permits "about anyone" to get PI - because > PI is very unbalanced regarding "who benefits, and who pays for it". True you have a good point here that is worth exploring. So how do we seperate then the "about anyone" from "those that need". I personally do not think the community should judge than one has a need and try to cast that in stone in some form of policy. But one could demand a sound justication in the request for PI that describes why PI is vital/important. This is to be judged by the RIR. Would adjusting the policy in that direction make sense? I know that this will take resourses of the RIR but I think it is fair that the requester should pay for that. Marc van Selm -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From gert at space.net Mon Apr 24 09:55:51 2006 From: gert at space.net (Gert Doering) Date: Mon, 24 Apr 2006 09:55:51 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <200604240940.36060.marc.van.selm@nc3a.nato.int> References: <200604240919.19143.marc.van.selm@nc3a.nato.int> <20060424072814.GP60910@Space.Net> <200604240940.36060.marc.van.selm@nc3a.nato.int> Message-ID: <20060424075551.GQ60910@Space.Net> Hi, On Mon, Apr 24, 2006 at 09:40:35AM +0200, Marc van Selm wrote: > > Speaking as a network operator (not as WG co-chair) I would be fairly > > unhappy with a PI policy that permits "about anyone" to get PI - because > > PI is very unbalanced regarding "who benefits, and who pays for it". > > True you have a good point here that is worth exploring. > > So how do we seperate then the "about anyone" from "those that need". Can't say. > I personally do not think the community should judge than one has a need and > try to cast that in stone in some form of policy. But one could demand a > sound justication in the request for PI that describes why PI is > vital/important. This is to be judged by the RIR. Would adjusting the policy > in that direction make sense? I know that this will take resourses of the RIR > but I think it is fair that the requester should pay for that. I understand what you're aiming for, but the problem is - the RIRs system doesn't work that way. The RIRs enforce the policy that the community (*we*) agree upon. Consider the RIRs "the executive arm of the community will" - so we need to provide clear guidance to the RIRs on "what's ok" and "what's not ok" - otherwise the hostmasters need to make up rules, and people will find themselves quite surprised at the outcome "now *that* is not what we imagined". Specifically in this case: the RIRs don't look at our routes, don't feel the pain of "too many routes", can't decide on "what will ISPs route?", and so on. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From oliver at bartels.de Mon Apr 24 10:52:43 2006 From: oliver at bartels.de (Oliver Bartels) Date: Mon, 24 Apr 2006 10:52:43 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <200604240910.26454.marc.van.selm@nc3a.nato.int> Message-ID: <200604240852.k3O8qMip015367@alpha.bartels.de> On Mon, 24 Apr 2006 09:10:26 +0200, Marc van Selm wrote: >> so, let's switch to discussing >> >> http://www.ripe.net/ripe/policies/proposals/2006-01.html > >I would support this policy proposal. > >This would be a sound alternative to those that need to be a LIR today but do >not really have to be a LIR but only require address-space that does not tie >them with 1 or 2 providers "for life" and gives them the possibility to have >global multi-homing (so for example, 2 access points to the Net: 1x US, 1x >Europe and a private global corporate network to provide internal >connectivity). This argument is absolutely correct, the impact on the BGP table will be negligible and can - as proven by IPv4 - be handled by modern routing hardware, thus: I support your argument and the proposal, too. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From president at ukraine.su Mon Apr 24 10:57:54 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 24 Apr 2006 12:57:54 +0400 Subject: [ppml] [address-policy-wg] Re: Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <1145650397.78861.4.camel@crumpet.netability.ie> References: <1145650397.78861.4.camel@crumpet.netability.ie> Message-ID: <200604241257.54499.president@ukraine.su> > > On the other hand, it make perfect sense for anyone who wants their > > PI space advertised to pay their upstreams for the privilege, since > > there is a real cost in doing so. > > Mmmm, and how is this going to guarantee that the PI space is accepted > by third party networks? As well as PA: nobody is guaranteeing nothing :) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From Michael.Dillon at btradianz.com Mon Apr 24 10:58:15 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 24 Apr 2006 09:58:15 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <001a01c6660f$babd5270$0200000a@j> Message-ID: > I think this idea is no better than standard redundancy (multiple lines to > the same ISP). Actually, I think it is worse since it is required of you to > either stay in the city or stretch a long fibre to it should you move all or > some of your stuff to another. Companies will try to do the latter because > they don't want to change their IP. Most companies do not move to another city. But if they do, then the cost of long distance backhaul will likely drive them to renumber their networks to the new city's aggregate. Every situation will have corner cases that don't appear to fit the mold. But, if we introduce geo-topo addressing as an ALTERNATIVE to classical provider addressing, then corner cases are less of a problem because there are two types of address. Sometimes classical PA will work better and sometimes GEO-TOPO will work better. > * Enterprises with "real" need of multi-homing having multiple uplinks to > multiple ISPs and their own AS number. Others have pointed out how this category is likely to grow a lot as Internet infrastructure becomes more and more important. > Couldn't the companies that _need_ PI multi-homing for redundancy reasons, > these enterprises, create an ISP and get their "multi-homing" there instead? Yes. But RIR policy should not force people to adopt this business model. Policy should give people the flexibility to adopt the business model that is right for them. --Michael Dillon From gert at space.net Mon Apr 24 10:59:47 2006 From: gert at space.net (Gert Doering) Date: Mon, 24 Apr 2006 10:59:47 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <200604240852.k3O8qMip015367@alpha.bartels.de> References: <200604240910.26454.marc.van.selm@nc3a.nato.int> <200604240852.k3O8qMip015367@alpha.bartels.de> Message-ID: <20060424085947.GR60910@Space.Net> Hi, On Mon, Apr 24, 2006 at 10:52:43AM +0200, Oliver Bartels wrote: > This argument is absolutely correct, the impact on the BGP table > will be negligible and can - as proven by IPv4 - be handled by modern > routing hardware, thus: Does someone have numbers on the amount of IPv6 prefixes that currently deployed Cisco and Juniper routers can handle? I know that the Cisco Sup720/3B can handle 256k routes for IPv4+IPv6 *together* (TCAM space), which limits the "unlimited growth of IPv6" a bit (but which can be fixed by upgrading to 3BXL). Please let's not discuss "how stupid router vendors are" now, just collect facts - there must be some upper limits in the hardware for GSR line cards and Juniper IPII-ASICs as well. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From Michael.Dillon at btradianz.com Mon Apr 24 11:07:58 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 24 Apr 2006 10:07:58 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060423115913.GK60910@Space.Net> Message-ID: > This is the standard argument, but only half-true. For serious internet > connections, you usually need to move your leased-line connection, This can be solved by having physical IXes. This is not the same as existing logical IXes because in a physical IX, businesses will connect their circuits to the IX and then cross-connect to an ISP. There is no peering here, just cross-connect cables. To provide separacy, you need two or more physical IXes in a city. Such things do not exist today because it is not common for businesses to have PI space. This means that currently they are not able to switch providers quickly so there is no demand for a physical IX. Once geo-topo addressing is implemented, I expect that the peering exchanges will expand their business into offering this type of physical exchange service. > A poorly planned network, with everything hardcoded everywhere (up to > applications that access IP addresses hard-coded in the source) is not > a proper excuse to burden everbody else's routers. Maybe that's why people who do hardcode addresses for security reasons, are building private internetworks. Of course, these people have the same right to PI addresses as everybody else. It doesn't matter whether you are on the public Internet or a private internet. > I accept that PI for BGP multihoming purposes is - today - one of the more > reasonable ways to achieve the goal (ISP independence and resilience), but > I still hope that we won't ever see the "let's get PI once, and never have > to renumber again!" land rush. You do realize that in IPv6 there is enough address space to supply such a "land rush" in an orderly manner so that everyone gets their unique PI block? --Michael Dillon From president at ukraine.su Mon Apr 24 11:16:30 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 24 Apr 2006 13:16:30 +0400 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060423115913.GK60910@Space.Net> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> Message-ID: <200604241316.30188.president@ukraine.su> Hi, > I accept that PI for BGP multihoming purposes is - today - one of the more > reasonable ways to achieve the goal (ISP independence and resilience), but > I still hope that we won't ever see the "let's get PI once, and never have > to renumber again!" land rush. Please, take a look at hosting providers. Changing thousands of domains and sites (probably not under his control) is a Really Big Problem. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From gert at space.net Mon Apr 24 12:36:23 2006 From: gert at space.net (Gert Doering) Date: Mon, 24 Apr 2006 12:36:23 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: References: <20060423115913.GK60910@Space.Net> Message-ID: <20060424103623.GS60910@Space.Net> Hi, On Mon, Apr 24, 2006 at 10:07:58AM +0100, Michael.Dillon at btradianz.com wrote: > > I accept that PI for BGP multihoming purposes is - today - one of the > more > > reasonable ways to achieve the goal (ISP independence and resilience), > but > > I still hope that we won't ever see the "let's get PI once, and never > have > > to renumber again!" land rush. > > You do realize that in IPv6 there is enough address space > to supply such a "land rush" in an orderly manner so that > everyone gets their unique PI block? The problem is not the amount of address space. The problem is the pressure on the AS numbers, and the amount of slots in the global routing table. Which, as a matter of fact, won't be able to handle "an unique PI block for everyone" (5 billion?) any time soon. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Mon Apr 24 12:38:55 2006 From: gert at space.net (Gert Doering) Date: Mon, 24 Apr 2006 12:38:55 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <200604241316.30188.president@ukraine.su> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> Message-ID: <20060424103855.GT60910@Space.Net> Hi, On Mon, Apr 24, 2006 at 01:16:30PM +0400, Max Tulyev wrote: > > I accept that PI for BGP multihoming purposes is - today - one of the more > > reasonable ways to achieve the goal (ISP independence and resilience), but > > I still hope that we won't ever see the "let's get PI once, and never have > > to renumber again!" land rush. > > Please, take a look at hosting providers. Changing thousands of domains and > sites (probably not under his control) is a Really Big Problem. Most (if not all) larger hosting providers I know are LIRs, so this question really doesn't apply. And for smaller hosting providers, this can be done - yes, it's painful, but the alternatives are also painful. When asking for "PI-for-everbody" keep in mind that everybody *else* has to pay the cost, and if the pain level gets too high, might just decide to drop "PI-for-everbody" routes.. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From president at ukraine.su Mon Apr 24 12:56:59 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 24 Apr 2006 14:56:59 +0400 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060424103855.GT60910@Space.Net> References: <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> Message-ID: <200604241457.00064.president@ukraine.su> Hi, > Most (if not all) larger hosting providers I know are LIRs, so this > question really doesn't apply. And for smaller hosting providers, this can > be done - yes, it's painful, but the alternatives are also painful. In fact, no (especially, in .RU/.UA). But! Some of hosting providers are LIRs to have own IPs and AS, but many of them need no more than /24 (ok, /23 at the most), because of HTTP/1.1 nowdays is an industry standard. I also know many cases people get LIRs (and /20) because of they aware of potential (I think mostly imagined) PI problems, when they really need /24. What about conserving of address space? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From gert at space.net Mon Apr 24 13:07:03 2006 From: gert at space.net (Gert Doering) Date: Mon, 24 Apr 2006 13:07:03 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <200604241457.00064.president@ukraine.su> References: <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <200604241457.00064.president@ukraine.su> Message-ID: <20060424110703.GU60910@Space.Net> Hi, On Mon, Apr 24, 2006 at 02:56:59PM +0400, Max Tulyev wrote: > What about conserving of address space? When talking about IPv6, and /32 or /48 allocations/assignments, routing table slots are more valuable than /48 blocks (because routers will explode long before the address space is done). IPv4 is legacy anyway, and the sooner it goes away, the better. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From Michael.Dillon at btradianz.com Mon Apr 24 13:24:32 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 24 Apr 2006 12:24:32 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060424103623.GS60910@Space.Net> Message-ID: > > You do realize that in IPv6 there is enough address space > > to supply such a "land rush" in an orderly manner so that > > everyone gets their unique PI block? > > The problem is not the amount of address space. The problem is the > pressure on the AS numbers, and the amount of slots in the global > routing table. Which, as a matter of fact, won't be able to handle > "an unique PI block for everyone" (5 billion?) any time soon. That is precisely why I am promoting the concept of geo-topo addressing. This solves global routing table problem by using roughly 5000 routes for city-based aggregates to serve millions of PI address blocks. And it can be done with no new protocols, no new technology and no changes to the existing PA address regime for ISPs which want to stick with pure classic PA addresses. Only ISPs which want to offer services to geo-topo address holders will need to make adjustments to their internal practices. --Michael Dillon From gert at space.net Mon Apr 24 13:26:23 2006 From: gert at space.net (Gert Doering) Date: Mon, 24 Apr 2006 13:26:23 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: References: <20060424103623.GS60910@Space.Net> Message-ID: <20060424112623.GX60910@Space.Net> Hi, On Mon, Apr 24, 2006 at 12:24:32PM +0100, Michael.Dillon at btradianz.com wrote: > > > You do realize that in IPv6 there is enough address space > > > to supply such a "land rush" in an orderly manner so that > > > everyone gets their unique PI block? [..] > That is precisely why I am promoting the concept of > geo-topo addressing. This solves global routing table > problem by using roughly 5000 routes for city-based > aggregates to serve millions of PI address blocks. > And it can be done with no new protocols, no new > technology and no changes to the existing PA address > regime for ISPs which want to stick with pure classic > PA addresses. Only ISPs which want to offer services to > geo-topo address holders will need to make adjustments > to their internal practices. Understood. I just wanted to comment on that specific comment, which wasn't made in the context of geo-topo addressing, but more "generally". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From mohta at necom830.hpcl.titech.ac.jp Mon Apr 24 14:16:23 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 24 Apr 2006 21:16:23 +0900 Subject: [address-policy-wg] Say *YES* to PI space to anyone, but *NO* to small entities In-Reply-To: <200604240919.19143.marc.van.selm@nc3a.nato.int> References: <200604240919.19143.marc.van.selm@nc3a.nato.int> Message-ID: <444CC197.7030107@necom830.hpcl.titech.ac.jp> Marc van Selm wrote: As a person who deeply interacted with IETF multihoming issues, I can understand you. > Sorry I can't agree with you there. Organizations that really need this are > generally very professional (ok not always but they they can hire a > professional for them) and many times much larger than some ISPs. I think it > is unfair to say that a non-ISP business is per definition not able to handle > routing networks. Exactly. To the Internet, yahoo and google, for example, are a lot more important and generate a lot more traffic than some tier 1 ISP. However, it is also true that PI space is evil to explode routing tables. So, the only fair solution is to allow anyone qualify as an ISP and make ISP addresses dependent to upper layer ISP addresses. And, let major ISPs chances to get PI space through auction or other fair methods. If PI space MUST be scares, let it be scares even for ISPs. It should be noted that even though I wrote an ID for multi6 WG that BGP-style policy control works even for ISPs with non-PI addresses, I was never given any chance of discussion by the WG chairs, Brian and Kurt, at that time. IMHO, at least 1000 ISPs should be allowed to have the top level PI addresses. If renumbering is so painful and fairness is still required, even top level ISPs with PI space should also be forced renumbering. Masataka Ohta From Woeber at CC.UniVie.ac.at Mon Apr 24 14:32:10 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 24 Apr 2006 12:32:10 +0000 Subject: [address-policy-wg] RE: Question In-Reply-To: <200604240852.k3O8qMip015367@alpha.bartels.de> References: <200604240852.k3O8qMip015367@alpha.bartels.de> Message-ID: <444CC54A.6060409@CC.UniVie.ac.at> Oliver Bartels wrote: > On Mon, 24 Apr 2006 09:10:26 +0200, Marc van Selm wrote: > >>>so, let's switch to discussing >>> >>> http://www.ripe.net/ripe/policies/proposals/2006-01.html [ ... ] > I support your argument and the proposal, too. I very strongly tend to support the proposal, with some questions and qualifications (peculiar to the NCC) attached: - As the proposal is worded now, it implicitely states that an applicant can "walk in from the street" and ask for an assignment. However, some time ago, we consciously supported the NCC to _exclusively_ do business with LIRs. Whenever an entity requests resources that are not "directly" tied in with an ISP, this entity has to find someone (an existing LIR) to act on their behalf. - Looking at the text further under the heading "Expiry for Assignments" there is the possibility to the holder of such an assignment to become an LIR Given that setup, and the fact that (from an RIR's point of view there is not too much difference in handling when cmparing PA and PI address space, I would propose to *require* the applicant to become an LIR in the 1st place. At that point in time when this LIR does no longer need the resources, and has returned them properly, it can cancel the contract (and stop paying the annual fee) I have the very strong opinion that any entity requesting "core resources" from or using services from an an RIR (big address blocks, AS numbers, rev. delegations,...) should also contribute to the operational cost *and* be alerted to the responsibilties of holding/using such resources. Which then goes hand in hand with the privilege of providing guidance to the RIR's operation by way of e.g. voting rights in the GM. Potentially inventing a separate fee structure or dedicated size category is a minor administrative exercise, I think. Please note that the "nice" thing about that approach is to vent a lot of steam regarding PA(good) and PI(bad). Very simplistically put - this proposal is a way around the (dreaded) 200 "customer" rule, isn't it ;-) Wilfried. From jordi.palet at consulintel.es Mon Apr 24 15:19:04 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 24 Apr 2006 16:19:04 +0300 Subject: [address-policy-wg] RE: Question In-Reply-To: <444CC54A.6060409@CC.UniVie.ac.at> Message-ID: Hi Wilfried, Thanks for the extensive comments. See below, in-line. Regards, Jordi > De: "Wilfried Woeber, UniVie/ACOnet" > Organizaci?n: UniVie - ACOnet > Responder a: > Fecha: Mon, 24 Apr 2006 12:32:10 +0000 > Para: Oliver Bartels > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] RE: Question > > Oliver Bartels wrote: > >> On Mon, 24 Apr 2006 09:10:26 +0200, Marc van Selm wrote: >> >>>> so, let's switch to discussing >>>> >>>> http://www.ripe.net/ripe/policies/proposals/2006-01.html > > [ ... ] > >> I support your argument and the proposal, too. > > > > I very strongly tend to support the proposal, with some questions and > qualifications (peculiar to the NCC) attached: > > - As the proposal is worded now, it implicitely states that an applicant > can "walk in from the street" and ask for an assignment. However, some > time ago, we consciously supported the NCC to _exclusively_ do business > with LIRs. Whenever an entity requests resources that are not "directly" > tied in with an ISP, this entity has to find someone (an existing LIR) > to act on their behalf. Not necessarily. It is still not worded out in the proposal, but I thing that need to be some contractual binging with RIPE NCC for the applicant to get the PI and consequently some yearly recurrent fee. > > - Looking at the text further under the heading "Expiry for Assignments" > there is the possibility to the holder of such an assignment to become an > LIR > > Given that setup, and the fact that (from an RIR's point of view there is > not too much difference in handling when cmparing PA and PI address space, > I would propose to *require* the applicant to become an LIR in the 1st place. That's why I think there should be a contract already, wait an see in my slides today that comparison among both PA and PI cases. > > At that point in time when this LIR does no longer need the resources, and > has returned them properly, it can cancel the contract (and stop paying the > annual fee) I believe only those PI "customers" that really want to become a LIR will do it, and probably will be a reduced numbers if/when we have an alternative solution. > > I have the very strong opinion that any entity requesting "core resources" > from or using services from an an RIR (big address blocks, AS numbers, rev. > delegations,...) should also contribute to the operational cost *and* be > alerted to the responsibilties of holding/using such resources. Agree, I didn't included that in the current proposal text, because I assumed is something worked out by the board or whatever apart from the proposal itself. It will be worded out in the next version. > > Which then goes hand in hand with the privilege of providing guidance to > the RIR's operation by way of e.g. voting rights in the GM. > > Potentially inventing a separate fee structure or dedicated size category > is a minor administrative exercise, I think. > > Please note that the "nice" thing about that approach is to vent a lot of > steam regarding PA(good) and PI(bad). > > Very simplistically put - this proposal is a way around the (dreaded) 200 > "customer" rule, isn't it ;-) I agree that the 200 customer rule is very bad, but not really sure if both things should be mixed up ... > > Wilfried. > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com 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. From kurtis at kurtis.pp.se Mon Apr 24 15:21:28 2006 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 24 Apr 2006 15:21:28 +0200 Subject: [address-policy-wg] Say *YES* to PI space to anyone, but *NO* to small entities In-Reply-To: <444CC197.7030107@necom830.hpcl.titech.ac.jp> References: <200604240919.19143.marc.van.selm@nc3a.nato.int> <444CC197.7030107@necom830.hpcl.titech.ac.jp> Message-ID: <6F70FBD1-C904-460D-A205-3C07CEBF4DC9@kurtis.pp.se> On 24 apr 2006, at 14.16, Masataka Ohta wrote: > > It should be noted that even though I wrote an ID for multi6 WG > that BGP-style policy control works even for ISPs with non-PI > addresses, I was never given any chance of discussion by the > WG chairs, Brian and Kurt, at that time. Isn't this what you presented here http://www3.ietf.org/proceedings/ 03nov/index.html - kurtis - From ripe-lst at eirconnect.net Mon Apr 24 21:19:42 2006 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Mon, 24 Apr 2006 20:19:42 +0100 Subject: [address-policy-wg] RE: Question In-Reply-To: <444CC54A.6060409@CC.UniVie.ac.at> References: <200604240852.k3O8qMip015367@alpha.bartels.de> <444CC54A.6060409@CC.UniVie.ac.at> Message-ID: <200604242019.42609.ripe-lst@eirconnect.net> On Monday 24 April 2006 13:32, Wilfried Woeber, UniVie/ACOnet wrote: > Given that setup, and the fact that (from an RIR's point of view > there is not too much difference in handling when cmparing PA and PI > address space, I would propose to *require* the applicant to become > an LIR in the 1st place. Even though I am practically a member of the "PI for Everyone" camp, I fully agree with this proposal, although I would just change policy so as to require anyone (who isn't just a PA end-user) to simply become a member of a RIR. They don't necessarily need to be a full LIR as they are not likely to ever sub-assign PA space. This should assure equal treatment for all IP users (as much as that is possible) and, as Wilfried states, gives them more of a 'voice' in the address management community. Maybe some of the additional income could also be funnelled into offering training to those that may require it. The downside is that such a policy would be open to challenge as a 'RIR monopoly' and to the establishment, by legislation, of competing 'IP address providers' such as has happened with the DNS system. The thing to keep in mind is, that the goal should be to increase adoption of IPv6 in the first place, otherwise all this is is an academic exercise... rgds, s. From dr at cluenet.de Mon Apr 24 22:07:50 2006 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 24 Apr 2006 22:07:50 +0200 Subject: [address-policy-wg] Re: Say *YES* to PI space to anyone, but *NO* to small entities In-Reply-To: <444CC197.7030107@necom830.hpcl.titech.ac.jp> References: <200604240919.19143.marc.van.selm@nc3a.nato.int> <444CC197.7030107@necom830.hpcl.titech.ac.jp> Message-ID: <20060424200750.GA5164@srv01.cluenet.de> On Mon, Apr 24, 2006 at 09:16:23PM +0900, Masataka Ohta wrote: > If renumbering is so painful and fairness is still required, even > top level ISPs with PI space should also be forced renumbering. Very good point. Actually, only true "tier 1" ISPs (those with no default routing and all external connections being either peers or customers... every ISP tech will understand what I mean, but this definition hair can be spliced infinitely) really _need_ PI. ALL others can use PA. This would bring the DFZ down to a very small 2-figure count of routes. :-) That's the only real fundamental NEED we can identify. All the other "needs" are luxury... and we would debating whom we allow this luxury and whom we do not. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From rogerj at jorgensen.no Mon Apr 24 22:24:00 2006 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Mon, 24 Apr 2006 22:24:00 +0200 (CEST) Subject: [address-policy-wg] Re: Say *YES* to PI space to anyone, but *NO* to small entities In-Reply-To: <20060424200750.GA5164@srv01.cluenet.de> References: <200604240919.19143.marc.van.selm@nc3a.nato.int> <444CC197.7030107@necom830.hpcl.titech.ac.jp> <20060424200750.GA5164@srv01.cluenet.de> Message-ID: On Mon, 24 Apr 2006, Daniel Roesen wrote: > On Mon, Apr 24, 2006 at 09:16:23PM +0900, Masataka Ohta wrote: > > If renumbering is so painful and fairness is still required, even > > top level ISPs with PI space should also be forced renumbering. > Very good point. Actually, only true "tier 1" ISPs (those with no > default routing and all external connections being either peers or > customers... every ISP tech will understand what I mean, but this > definition hair can be spliced infinitely) really _need_ PI. ALL others > can use PA. This would bring the DFZ down to a very small 2-figure count > of routes. :-) Combine this with geoip one way or another and we have something that should solve all multihoming/PI problems as I see it... But do we really want to put all our routes in the hand of a very few ISP's? That's the only problem. Another way of doing this, "tier 1" within a RIR justify a PI allocation? -- ------------------------------ Roger Jorgensen | roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From heldal at eml.cc Mon Apr 24 23:32:27 2006 From: heldal at eml.cc (Per Heldal) Date: Mon, 24 Apr 2006 23:32:27 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060424110703.GU60910@Space.Net> References: <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <200604241457.00064.president@ukraine.su> <20060424110703.GU60910@Space.Net> Message-ID: <1145914347.13646.259825426@webmail.messagingengine.com> On Mon, 24 Apr 2006 13:07:03 +0200, "Gert Doering" said: > IPv4 is legacy anyway, and the sooner it goes away, the better. Maybe in some ways, but there are many arguments in favor of making it last as long as possible too. This thread and similar threads on just about any ip-ops list show that far from everybody agree that there is a complete alternative to v4 yet. Remember, IPv6 and promises about scalable routing was once (mid 90s) one of the last nails in GOSIP's (and it's various national variations') coffin. Considering the development since, or lack thereof, it seems just fine if v4 can cope for a little while longer. //per -- Per Heldal http://heldal.eml.cc/ From heldal at eml.cc Mon Apr 24 23:50:16 2006 From: heldal at eml.cc (Per Heldal) Date: Mon, 24 Apr 2006 23:50:16 +0200 Subject: [address-policy-wg] RE: Question In-Reply-To: <20060424085947.GR60910@Space.Net> References: <200604240910.26454.marc.van.selm@nc3a.nato.int> <200604240852.k3O8qMip015367@alpha.bartels.de> <20060424085947.GR60910@Space.Net> Message-ID: <1145915416.15797.259827313@webmail.messagingengine.com> On Mon, 24 Apr 2006 10:59:47 +0200, "Gert Doering" said: > Does someone have numbers on the amount of IPv6 prefixes that currently > deployed Cisco and Juniper routers can handle? Another interesting statistic in this discussion would be a historic overview of the avg headroom in core backbone routers (unused space in the form of RIB-entries total and % of the the available) going back at least a decade. //per -- Per Heldal http://heldal.eml.cc/ From pekkas at netcore.fi Tue Apr 25 08:10:43 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 25 Apr 2006 09:10:43 +0300 (EEST) Subject: AW: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: Hi, On Fri, 21 Apr 2006, Ruchti, Marcus wrote: > I don't think flapping routes will increase due to the assignments > of PI space, as in the most cases ISP's are requesting those for > customers and offers managed multihoming solutions. So announcing > these routes into BGP is the responsibility of an ISP. First off: there has been some discussion whether 200K routes is a problem or not. If the numbers stayed at that level (how can we ensure that?), that wouldn't be a huge problem. Bigger one is dynamicity. Huston's study indicated that there are folks whose BGP announcements flap (due to TE) intentionally 1000's of times a day. Multiply that by the number of sites (and add sBGP or friends to the stew) and you may start thinking that your DFZ router might have better things to do than process that cruft. And now responding to your specific comment, I do not agree with "So announcing these routes into BGP is the responsibility of an ISP." -- the _sites_ decide how they want to advertise; the biggest decision of the ISP is whether it does BGP flap damping for these or not. Virtually all multihomers use their own AS number -- agree? If you agree, I guess what you're saying is that in most cases the ISPs set up the AS numbers and the multihoming at customer's equipment, customer's premises or colo, customer's AS number, etc.? Indeed, I believe in significant number of cases, a consultant (whether from one of the ISPs or an outsider -- I'd personally prefer an outsider as (s)he wouldn't have a conflict of interest) sets up the multihoming setup. But that doesn't preclude said consultants, other consultants, or local network engineering staff from adjusting the set-up later on. If one of the ISPs had sole management of the setup, that would seem somewhat at odds with the provider independence principle. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nils at druecke.strg-alt-entf.org Tue Apr 25 08:37:39 2006 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Tue, 25 Apr 2006 08:37:39 +0200 Subject: AW: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <20060425063739.GA10120@h8000.serverkompetenz.net> On Tue, Apr 25, 2006 at 09:10:43AM +0300, Pekka Savola wrote: > First off: there has been some discussion whether 200K routes is a > problem or not. If the numbers stayed at that level (how can we > ensure that?), that wouldn't be a huge problem. Bigger one is Well, as most business models are based on the concept of everlasting growth, I assume most ISPs should not try to ensure stagnation there. Though they could (just stop accepting new customers, but I believe you will get into trouble with some of the more commercial oriented departments then). > dynamicity. Huston's study indicated that there are folks whose BGP > announcements flap (due to TE) intentionally 1000's of times a day. > Multiply that by the number of sites (and add sBGP or friends to the > stew) and you may start thinking that your DFZ router might have > better things to do than process that cruft. Well using the max value as the average is a little unusual for a business calculation, but okay, you are expecting the worst case. Good for you, but most customers have no interest in paying for an ISP, that is always ready for the worst case. There is a market segment, though, so thats fine. > I do not agree with "So announcing these routes into BGP is the > responsibility of an ISP." -- the _sites_ decide how they want to > advertise; the biggest decision of the ISP is whether it does BGP flap > damping for these or not. ACK. > Virtually all multihomers use their own AS number -- agree? If you > agree, I guess what you're saying is that in most cases the ISPs set > up the AS numbers and the multihoming at customer's equipment, > customer's premises or colo, customer's AS number, etc.? NACK. In many cases they do it themselves or have externals doing it. Those managing the equipment are mostly not the same delivering the lines, though sometimes they are. Thats at least the perspective I got from customers we have set up interconnections with. Thats mainly large enterprise market, small customers usually do not get connectivity to our network (as they do not need it). Nils From tim.streater at dante.org.uk Tue Apr 25 11:15:54 2006 From: tim.streater at dante.org.uk (Tim Streater) Date: Tue, 25 Apr 2006 10:15:54 +0100 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <088201c664ec$d991ac60$3712fea9@ssprunk> References: <054601c66496$60f6b210$3712fea9@ssprunk> <088201c664ec$d991ac60$3712fea9@ssprunk> Message-ID: <6.2.3.4.2.20060425100335.05206ef8@mail.dante.org.uk> At 03:39 21/04/2006, Stephen Sprunk wrote: >ARIN Region origin ASes present in the Internet Routing Table: 10637 >... >ARIN Region transit ASes present in the Internet Routing Table: 986 > >To me, that says we have 9651 non-transit ASes in ARIN-land today. > >Now, if every one of those ASes got an assignment under 2005-1, we'd kick up the size of the v6 routing table to 14 times its current size -- but it'd still be only 1/18th of the current v4 table. Where's the problem? [...] >OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two pipes or tunnels), and there's not all that many companies doing it. It's not growing much either. The doors are already wide open for a land rush and nobody is taking ARIN up on >it. Why does everyone assume it'll happen with v6 if it's not happening with v4, which _is_ useful today? This is perhaps the most pertinent question to have been asked during this thread and I'm not sure I saw any answer to it. So I'll ask it again. What is the evidence that using v4's PI policy for v6 would lead to a land rush of catastrophic proportions and the routing table becoming huge? All I've seen so far is hand-waving doomsayers. Remember that to get PI space at all you have to know what you are doing, and you have to justify the usage. And the process takes a certain time. All of these would tend to discourage the casual enquirer. -- Tim From mohta at necom830.hpcl.titech.ac.jp Tue Apr 25 11:40:37 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 25 Apr 2006 18:40:37 +0900 Subject: [address-policy-wg] Re: Say *YES* to PI space to anyone, but *NO* to small entities In-Reply-To: References: <200604240919.19143.marc.van.selm@nc3a.nato.int> <444CC197.7030107@necom830.hpcl.titech.ac.jp> <20060424200750.GA5164@srv01.cluenet.de> Message-ID: <444DEE95.5060405@necom830.hpcl.titech.ac.jp> Roger Jorgensen wrote: >>>If renumbering is so painful and fairness is still required, even >>>top level ISPs with PI space should also be forced renumbering. >> >>Very good point. Actually, only true "tier 1" ISPs (those with no >>default routing and all external connections being either peers or >>customers... every ISP tech will understand what I mean, but this >>definition hair can be spliced infinitely) really _need_ PI. ALL others >>can use PA. This would bring the DFZ down to a very small 2-figure count >>of routes. :-) > Combine this with geoip one way or another and we have something that > should solve all multihoming/PI problems as I see it... But do we really > want to put all our routes in the hand of a very few ISP's? That's the > only problem. Doing so is as bad as frequency band auction in Europe. So, let the number of possible tier 1s larger. However, so large number of ASes means so slow convergence time of BGP, which is already unacceptable (though some of you might think the Internet can not be used for mission critical purposes that minutes or tens of minutes of convergence time is fine) with IPv4 Internet today. Thus, my suggestion in WAS: The proper number of TLAs, it seems to the author, should be somewhere between 1024 and 8192. Masataka Ohta From tjc at ecs.soton.ac.uk Tue Apr 25 12:16:16 2006 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 25 Apr 2006 11:16:16 +0100 Subject: AW: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <20060425063739.GA10120@h8000.serverkompetenz.net> References: <20060425063739.GA10120@h8000.serverkompetenz.net> Message-ID: <20060425101616.GG25019@login.ecs.soton.ac.uk> On Tue, Apr 25, 2006 at 08:37:39AM +0200, Nils Ketelsen wrote: > > Thats at least the perspective I got from customers we have set up > interconnections with. Thats mainly large enterprise market, small customers > usually do not get connectivity to our network (as they do not need it). Do we have stats on what percentage of people with PI allocations for IPv4 have it to avoid renumbering (i.e. to change provider much more easily), and how many in addition use it for multihoming? I know of small enterprises that are not interested in multihoming so much (they have good reliability from their ISPs) but who want to be able to react to better connectivity deals (e.g. in a case I saw recently move from 15K pa. to 8K pa. for a service, without losing that advantage with renumbering costs). Just curious. -- Tim/::1 From jeroen at unfix.org Tue Apr 25 13:24:15 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 25 Apr 2006 13:24:15 +0200 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: <200604240925.01156.marc.van.selm@nc3a.nato.int> References: <200604240925.01156.marc.van.selm@nc3a.nato.int> Message-ID: <1145964255.20018.25.camel@firenze.zurich.ibm.com> On Mon, 2006-04-24 at 09:25 +0200, Marc van Selm wrote: On Sunday 23 April 2006 17:42, Lea Roberts wrote: [..] > > IPv6 has made it possible to renumber the network almost automatically. > > it seems possible to make that change without a "flag day" and an outage. > > however, the tools are mostly *NOT* there for similarly easy renumbering > > of router ACLs and firewall configs and DNS, so as the size of the network > > increases, large organizations are saying there is still a significant > > cost to renumbering (at this time...). one can only hope that appropriate > > tools will be developed to make full renumbering reasonably painless. > > Did anyone try that in a mission crytical 200+ site network? That is what I'm > looking at. I'm not conviced yet that one would really like to do that. Is > anyone brave enough to calculate the risks and costs for a network like that? > (We solved it via the LIR route by the way.) Unless you have a record of all the places where you have stored the sites IPv6 addresses and have (semi) direct access to change these, do not rely on having external parties update items on your list then it might be 'easily' done, for large varying values of 'easy'. If you do not meet any of the above then you will be in a large amount of pain in doing so. Especially the remote parties problem will cause a lot amount of pain as they need to do it in sync with you and they need to find out where all the changes have to be made. Even changing a 'home' setup can be hard when your DNS for instance is hosted at a remote site where you do not have direct access to. Renumbering is *NOT* simple and *CAN't* be automated (no remote company will allow you full automatic access to change things in their setup, think firewall rules for instance...) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From tjc at ecs.soton.ac.uk Tue Apr 25 13:49:14 2006 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 25 Apr 2006 12:49:14 +0100 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: <1145964255.20018.25.camel@firenze.zurich.ibm.com> References: <200604240925.01156.marc.van.selm@nc3a.nato.int> <1145964255.20018.25.camel@firenze.zurich.ibm.com> Message-ID: <20060425114914.GQ25019@login.ecs.soton.ac.uk> On Tue, Apr 25, 2006 at 01:24:15PM +0200, Jeroen Massar wrote: > > If you do not meet any of the above then you will be in a large amount > of pain in doing so. Especially the remote parties problem will cause a > lot amount of pain as they need to do it in sync with you and they need > to find out where all the changes have to be made. There's an account of renumbering experiences here from work we did last year: http://www.6net.org/publications/deliverables/D3.6.1.pdf and http://www.6net.org/publications/deliverables/D3.6.2.pdf There's a lot of recommendations (20 or more) on things that would be useful to aid renumbering further. But the basic network oriented approach using prefix advertisements and deprecation works across the operating systems tested. As Jeroen says though, there's a wee bit more to it than that. Perhaps most importantly network management tools need updating to understand that IPv6 hosts may be multi-addressed, and to be able to validate/verify the phases of the renumbering process. -- Tim/::1 From maxtul at merezha.net Mon Apr 24 11:06:10 2006 From: maxtul at merezha.net (Maxim V. Tulyev) Date: Mon, 24 Apr 2006 13:06:10 +0400 Subject: [address-policy-wg] RE: Question In-Reply-To: <20060422082029.GH60910@Space.Net> References: <001e01c65b13$c472c540$8482fea9@ipv6forum> <200604202048.50442.maxtul@merezha.net> <20060422082029.GH60910@Space.Net> Message-ID: <200604241306.10459.maxtul@merezha.net> Hi, > > And when it is not visible - I can't get connectivity at all :( > > Not to people that have no default and decide to filter your more-specific > route, yes. So "in the wild" - I'll loose connectivity. That means more specific is not a way to make backups :( -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From ripe at eirconnect.net Mon Apr 24 21:17:33 2006 From: ripe at eirconnect.net (Sascha Luck) Date: Mon, 24 Apr 2006 20:17:33 +0100 Subject: [address-policy-wg] RE: Question In-Reply-To: <444CC54A.6060409@CC.UniVie.ac.at> References: <200604240852.k3O8qMip015367@alpha.bartels.de> <444CC54A.6060409@CC.UniVie.ac.at> Message-ID: <200604242017.33776.ripe@eirconnect.net> On Monday 24 April 2006 13:32, Wilfried Woeber, UniVie/ACOnet wrote: > Given that setup, and the fact that (from an RIR's point of view > there is not too much difference in handling when cmparing PA and PI > address space, I would propose to *require* the applicant to become > an LIR in the 1st place. Even though I am practically a member of the "PI for Everyone" camp, I fully agree with this proposal, although I would just change policy so as to require anyone (who isn't just a PA end-user) to simply become a member of a RIR. They don't necessarily need to be a full LIR as they are not likely to ever sub-assign PA space. This should assure equal treatment for all IP users (as much as that is possible) and, as Wilfried states, gives them more of a 'voice' in the address management community. Maybe some of the additional income could also be funnelled into offering training to those that may require it. The downside is that such a policy would be open to challenge as a 'RIR monopoly' and to the establishment, by legislation, of competing 'IP address providers' such as has happened with the DNS system. The thing to keep in mind is, that the goal should be to increase adoption of IPv6 in the first place, otherwise all this is is an academic exercise... rgds, s. From jeroen at unfix.org Tue Apr 25 14:48:40 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 25 Apr 2006 14:48:40 +0200 Subject: [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <6.2.3.4.2.20060425100335.05206ef8@mail.dante.org.uk> References: <054601c66496$60f6b210$3712fea9@ssprunk> <088201c664ec$d991ac60$3712fea9@ssprunk> <6.2.3.4.2.20060425100335.05206ef8@mail.dante.org.uk> Message-ID: <1145969320.20018.36.camel@firenze.zurich.ibm.com> On Tue, 2006-04-25 at 10:15 +0100, Tim Streater wrote: > At 03:39 21/04/2006, Stephen Sprunk wrote: [..] > >OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two > >pipes or tunnels), and there's not all that many companies doing > >it. It's not growing much either. The doors are already wide open > >for a land rush and >>nobody is taking ARIN up on it. Why does > >everyone assume it'll happen with v6 if it's not happening with v4, > >which _is_ useful today? > > This is perhaps the most pertinent question to have been asked during > this thread and I'm not sure I saw any answer to it. So I'll ask it > again. What is the evidence that using v4's PI policy for v6 would > lead to a land rush of catastrophic proportions and the routing table > becoming huge? All I've seen so far is hand-waving doomsayers. There is no evidence, but it might just happen ;) Maybe not today, but maybe in a couple of years. IPv6 is intended to be there for the coming decades, not for tomorrow. > Remember that to get PI space at all you have to know what you are doing, > and you have to justify the usage. And the process takes a certain > time. All of these would tend to discourage the casual enquirer. This is indeed the only limit for both IPv6 PA and the new to be coming PI space: you need to know what you are doing. Thus upto the time that somebody writes up a "HOWTO: Multihoming at home" document it should not cause much issues. That said, when/if a landrush would break out, people are still in control of their own routers and it will become very easy to start filtering certain small prefixes. This happened also in IPv4 (try announcing a /28 or so ;). At that point, people who have the cash can keep on doing it that way, other folks will have to resort to different methods like shim6/hip/sctp and a number of other proposals. In the end one will still need "PI" space at most sites anyway. As it is the sole method of making sure that one can stick IP addresses in certain important places like firewall rules and DNS without ever having to think about it again or having to remember that you stuck them there. This is where the above methods come in, they will make the packet, while traveling over the internet be the upstreams src/dst, while being "PI" on the edges. This solves all the issues at hand. For the time being though people can happily use IPv6 PI space in the way they are 'used' to in IPv4. This gives enough time for the new methods to become crystal clear and cover all the known problemspaces so that end-sites can use them happily ever after. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From Michael.Dillon at btradianz.com Tue Apr 25 15:49:52 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 25 Apr 2006 14:49:52 +0100 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: <1145964255.20018.25.camel@firenze.zurich.ibm.com> Message-ID: > Renumbering is *NOT* simple and *CAN't* be automated (no remote company > will allow you full automatic access to change things in their setup, > think firewall rules for instance...) Another example. My company laptop has a VPN client which has two IPv4 addresses in for the main and fallback VPN login servers. Even if there are systems in place for updating these settings when I reboot my laptop, that won't prevent helpdesk calls. For instance, it is common for people to put laptops to sleep without logging out. It may be a week or two between logins. If the network is renumbered, suddenly the VPN login service fails and remote users have to call a helpdesk to find out the new IP addresses. Processing a helpdesk call costs money and downtime due to lack of network access also costs money. It is difficult to foresee these kinds of costs. Now, if one or two companies does a renumber and runs into unforeseen costs and problems because of firewall configurations, VPN configurations, IP addresses stored in mobile phones, PDAs, inventory databases, smartcards, etc., then that will become publicised. Once other companies learn of these problems then they will refuse to renumber and will begin to demand fixed address assignments, i.e. PI addresses. The only way to convince these companies to renumber will be a protocol upgrade such as IPv4 to IPv6. I believe that the majority of companies will not be willing to accept renumbering after they have migrated to IPv6. The IPv6 migration will be THE LAST RENUMBERING!!! --Michael Dillon From Woeber at CC.UniVie.ac.at Tue Apr 25 16:12:03 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 25 Apr 2006 14:12:03 +0000 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: References: Message-ID: <444E2E33.1060806@CC.UniVie.ac.at> Michael.Dillon at btradianz.com wrote: [ ... ] > > Another example. My company laptop has a VPN client which has > two IPv4 addresses in for the main and fallback VPN login servers. Why does the laptop store the *addresses* instead of an (FQ)DN? Wilfried. PS: I can imagine a couple of different answers, but I'd like to get them "from the source" From Michael.Dillon at btradianz.com Tue Apr 25 16:54:42 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 25 Apr 2006 15:54:42 +0100 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: <444E2E33.1060806@CC.UniVie.ac.at> Message-ID: > Why does the laptop store the *addresses* instead of an (FQ)DN? I have no idea. That is the way the IT department sets up things. But given that the VPN is a SECURITY measure, I suspect it has to do with the layers of security philosophy in which you implement many layers. According to this philosophy it is good to use a security layer even if it is not fully effective on its own. A real world example is locks on the doors of a building with glass windows. In this case, the IPv4 address is recorded to circumvent perceived weaknesses with DNS and to eliminate the possibility of man-in-the-middle attacks on the DNS. While some would argue that this is uneccessary since the VPN uses cryptographic security, others would point to SSH v1 vulnerabilities and the fact that RSA keys up to 450 bits have been cracked, to show that there is still a theoretical benefit to extra security layers. In any case, information security basically amounts to making it very complex for an attacker to manage all the contortions needed to break in within the time available to him. I wonder if the security community has put much thought into the kind of contortions which DNS elimination represents. After all, if DNS is used, then an attacker must subvert the DNS server or protocol. If it is not used then the attacker must subvert the IP routing system. Since we know that people are actively subverting routers and the routing system from time to time, I wonder whether the balance has shifted in favour of DNS. Of course, once DNS resolution has been applied, the routing system could still be subverted, but one could argue that round-robin dynamically updated A records could make it harder for the attacker to identify where the routing system needs to be compromised. Indeed, the blackhat community themselves are using this kind of dynamic DNS in order to evade whitehats attacking them. If there were a clearer analysis of these approachs rather than an outright rejection of things like DNS elimination, then I think we might be able to agree on best practices that meet both security needs and the need to keep networks in a maintainable (and renumberable) state. --Michael Dillon From michel at arneill-py.sacramento.ca.us Tue Apr 25 17:43:52 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 25 Apr 2006 08:43:52 -0700 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) Message-ID: > Wilfried Woeber wrote: > Why does the laptop store the *addresses* instead of an (FQ)DN? Mine is configured that way because I want to be able to get in remotely in case of a DNS failure so I can fix the DNS :-D Other reason: VPNs based on FQDNs have a tendency to timeout, especially at the first attempt from a remote location (because the FQDN is not cached and has to go up to the root). Also DNS requests go over UDP, which is unreliable. It happens all the time that Joe Blow traveling somewhere reports the next day that he could not check his email or download the sales report because the VPN was not working (because Joe either is not smart enough to retry or finds it a good excuse to go to the bar instead). Next time he goes out the VPN is configured with the hardcoded IP address of the VPN server. In the end, it does not matter why. It's out there, and has to be dealt with. > Jeroen Massar wrote: > Renumbering is *NOT* simple and *CAN't* be automated (no remote > company will allow you full automatic access to change things in > their setup, think firewall rules for instance...) Indeed. Even if they did, it would be logistically impossible. I'm currently configuring an IPSEC tunnel going to a very large corporation. There are thousands of tunnels, configured on every router brand and model man has ever made; each is unique. An automated tool to change this is not in the realm of possible. This leaves the large company with having to deal with thousands of different people with issues such as half of the techs that originally configured the thing are no longer there, nobody remembers the router's password, etc. Renumbering any sizeable organization is _always_ a very costly proposition. It requires allocating valuable resources for weeks to prepare and more to carry. Plus, in any renumbering I have done some issues popped out for weeks after the renumbering. Renumbering generates a steady flow of trouble tickets that require more resources to deal with _and_ make the network guys look like idiots. Only rookies that have never been in the trenches in the real world consider renumbering easy. Most of the more experienced network managers out there will tell you this: I don't want to go through this again. Michel. From rogerj at jorgensen.no Tue Apr 25 19:41:19 2006 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Tue, 25 Apr 2006 19:41:19 +0200 (CEST) Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space --or how to make it lessdestructive) In-Reply-To: References: Message-ID: On Tue, 25 Apr 2006 Michael.Dillon at btradianz.com wrote: > > Renumbering is *NOT* simple and *CAN't* be automated (no remote company > > will allow you full automatic access to change things in their setup, > > think firewall rules for instance...) > Another example. My company laptop has a VPN client which has > two IPv4 addresses in for the main and fallback VPN login servers. > Even if there are systems in place for updating these settings > when I reboot my laptop, that won't prevent helpdesk calls. > For instance, it is common for people to put laptops to > sleep without logging out. It may be a week or two between > logins. If the network is renumbered, suddenly the VPN login > service fails and remote users have to call a helpdesk to > find out the new IP addresses. Processing a helpdesk call costs > money and downtime due to lack of network access also costs > money. It is difficult to foresee these kinds of costs. really bad example, you never have a 1 or 2 weeks periode (planned time) to renumber, you plan it over monthss to make sure things like you describe don't happen. Good planing avoid alot of issues.. and for the rest of your mail, why can't we all stop thinking in terms of IP addresses and start thinking in terms of hostnames? -- ------------------------------ Roger Jorgensen | roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From jorgen at hovland.cx Tue Apr 25 19:51:32 2006 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Tue, 25 Apr 2006 19:51:32 +0200 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: Message-ID: <001b01c66890$e3906bf0$0200000a@j> Pardon me for saying, but all of this is bollocks. Renumbering is as easy as you want it to be. Make a proper policy and then create the tools for it. It is that easy. I am sure we can discuss poorly designed solutions any (other) time. I support proposal 2006-01. j -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Michel Py Sent: 25. april 2006 17:44 To: Jeroen Massar Cc: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) > Wilfried Woeber wrote: > Why does the laptop store the *addresses* instead of an (FQ)DN? Mine is configured that way because I want to be able to get in remotely in case of a DNS failure so I can fix the DNS :-D Other reason: VPNs based on FQDNs have a tendency to timeout, especially at the first attempt from a remote location (because the FQDN is not cached and has to go up to the root). Also DNS requests go over UDP, which is unreliable. It happens all the time that Joe Blow traveling somewhere reports the next day that he could not check his email or download the sales report because the VPN was not working (because Joe either is not smart enough to retry or finds it a good excuse to go to the bar instead). Next time he goes out the VPN is configured with the hardcoded IP address of the VPN server. In the end, it does not matter why. It's out there, and has to be dealt with. > Jeroen Massar wrote: > Renumbering is *NOT* simple and *CAN't* be automated (no remote > company will allow you full automatic access to change things in > their setup, think firewall rules for instance...) Indeed. Even if they did, it would be logistically impossible. I'm currently configuring an IPSEC tunnel going to a very large corporation. There are thousands of tunnels, configured on every router brand and model man has ever made; each is unique. An automated tool to change this is not in the realm of possible. This leaves the large company with having to deal with thousands of different people with issues such as half of the techs that originally configured the thing are no longer there, nobody remembers the router's password, etc. Renumbering any sizeable organization is _always_ a very costly proposition. It requires allocating valuable resources for weeks to prepare and more to carry. Plus, in any renumbering I have done some issues popped out for weeks after the renumbering. Renumbering generates a steady flow of trouble tickets that require more resources to deal with _and_ make the network guys look like idiots. Only rookies that have never been in the trenches in the real world consider renumbering easy. Most of the more experienced network managers out there will tell you this: I don't want to go through this again. Michel. From nils at druecke.strg-alt-entf.org Tue Apr 25 21:05:26 2006 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Tue, 25 Apr 2006 21:05:26 +0200 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space --or how to make it lessdestructive) In-Reply-To: References: Message-ID: <20060425190526.GA14965@h8000.serverkompetenz.net> On Tue, Apr 25, 2006 at 07:41:19PM +0200, Roger Jorgensen wrote: > really bad example, you never have a 1 or 2 weeks periode (planned time) > to renumber, you plan it over monthss to make sure things like you > describe don't happen. Good planing avoid alot of issues.. Thats the point. You need to invest many man-months to renumber. That is what companies usually consider as being "expensive". Apart from the hassle with customers, telling them about your yearly renumbering and forcing them to do work again. > and for the rest of your mail, why can't we all stop thinking in terms of > IP addresses and start thinking in terms of hostnames? Because IP-Packets are using IP-Addresses and not hostnames to get to their destination. Nils -- This message will self-destruct after the default expiration-time. From nils at druecke.strg-alt-entf.org Tue Apr 25 21:10:19 2006 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Tue, 25 Apr 2006 21:10:19 +0200 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: <001b01c66890$e3906bf0$0200000a@j> References: <001b01c66890$e3906bf0$0200000a@j> Message-ID: <20060425191019.GB14965@h8000.serverkompetenz.net> On Tue, Apr 25, 2006 at 07:51:32PM +0200, J?rgen Hovland wrote: > Pardon me for saying, but all of this is bollocks. Renumbering is as easy as > you want it to be. Make a proper policy and then create the tools for it. It > is that easy. I am sure we can discuss poorly designed solutions any (other) > time. You seem to have a very easy Job, when you can make this proper policy for your customers. I can not, those (about) 100 connecting to my network all have different policies, different needs, different requirements. And we do our best, to fullfill their needs and make it as easy for them as possible. We call that "service". If you do not have to provide this, good for you. But please do not tell me, that my need to have paying customers is bad design. Nils, not in the ISP-Business -- Please let us know if your SunSolve visit saved you a call to Sun Support! Access Denied [komplette Auskunft zu einem Patch auf http://sunsolve.sun.com/] From hank at efes.iucc.ac.il Tue Apr 25 21:35:59 2006 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 25 Apr 2006 22:35:59 +0300 (IDT) Subject: [address-policy-wg] Multi-regional allocation question - transversing RIRs In-Reply-To: <001b01c66890$e3906bf0$0200000a@j> References: <001b01c66890$e3906bf0$0200000a@j> Message-ID: I have a large multi-regional client, who's main base is in the USA. They are about to get a /19 from ARIN since they are multi-homed and have about 32 sites, but they also have about 5 sites in APNIC and the another 5 in the RIPE region. Do they have to become members in each RIR to get multi-homed allocations, or should one RIR handle it all? Would the answer to that above question change if the IP blocks used in APNIC and RIPE wouldn't be announced locally in those regions but would rather be MPLSed back to the USA and from there all Internet access would be allowed (thereby making the IP blocks pseudo-USA blocks)? References: http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html This doc seems to imply with the 1.2 section statement of "Membership is globally open without condition" that ARIN can allocate IPs anywhere, as can RIPE, which sort of contradicts the section "Emergence of the RIRs" located at: http://www.ripe.net/info/resource-admin/rir-system.html So any official guidance is appreciated. Thanks, Hank From gert at space.net Tue Apr 25 22:32:12 2006 From: gert at space.net (Gert Doering) Date: Tue, 25 Apr 2006 22:32:12 +0200 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: References: Message-ID: <20060425203212.GQ60910@Space.Net> Hi, On Tue, Apr 25, 2006 at 08:43:52AM -0700, Michel Py wrote: > Most of the more experienced network managers > out there will tell you this: I don't want to go through this again. But at the same time, most of the more experienced network managers have been through it a couple of time, and will understand the necessity... :-) (We had to change the IP addresses for our recursive DNS servers 3 times by now, and making sure all customers update their configs *was* a nightmare - nevertheless, it was the correct thing to do) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jorgen at hovland.cx Tue Apr 25 23:04:55 2006 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Tue, 25 Apr 2006 23:04:55 +0200 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: <20060425191019.GB14965@h8000.serverkompetenz.net> Message-ID: <004a01c668ab$e76d15a0$0200000a@j> (apologise for being slightly OT) -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Nils Ketelsen > You seem to have a very easy Job, 65% of my day goes to doing stuff a machine could have done. 20% goes to developing software/hardware so the machine can do it instead of us. The rest are coffee breaks and meetings. > when you can make this proper policy for > your customers. Some demand it, a few don't, but they all ask. > I can not, those (about) 100 connecting to my network all > have different policies, different needs, different requirements. And we do > our best, to fullfill their needs and make it as easy for them as possible. I didn't mention it would be in violation to your customers existing policies/needs. You automatically assumed so without even thinking/knowing how it can be implemented. > We call that "service". I surely would call that service, yes. Automatic renumbering service. I bet at least 5 people stole my idea just now. > If you do not have to provide this, good for you. What, service? > But please do not tell me, that my need to have paying customers is bad > design. If your intentions are to get _any_ potential customer, then you obviously need to loosen up on policies as they all have special needs. In that case, I understand you completely. (I dropped a comment here on how not to get huge amount of customers when you adjust policies on demand per customer case) > Nils, not in the ISP-Business j, in the ISP-business (with friends) From michel at arneill-py.sacramento.ca.us Wed Apr 26 00:45:04 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 25 Apr 2006 15:45:04 -0700 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) Message-ID: Gert, >> Michel Py wrote: >> Most of the more experienced network managers out there will >> tell you this: I don't want to go through this again. > But at the same time, most of the more experienced network > managers have been through it a couple of time, and will > understand the necessity... :-) > (We had to change the IP addresses for our recursive DNS servers > 3 times by now, and making sure all customers update their configs > *was* a nightmare Renumbering DNS servers is 1% of renumbering a large enterprise setup. Imagine if you had them change not only DNS, but all of their DHCP scopes, firewall rules, host files, batches, printers, renumber their active directory controllers (ever tried to change the IP address on a windows box that assumes FSMO roles?) etc etc. > - nevertheless, it was the correct thing to do Good for you. In my world, the correct thing to do is the one that has a positive impact on the bottom line. > J?rgen Hovland wrote: > Renumbering is as easy as you want it to be. I love guys like J?rgen. One day they'll find someone fool enough to let them touch a big network, they'll make a mess, and their management will suddenly understand the value of paying me 2k per day so another disaster does not happen. Michel. From dogwallah at gmail.com Wed Apr 26 06:27:24 2006 From: dogwallah at gmail.com (McTim) Date: Wed, 26 Apr 2006 07:27:24 +0300 Subject: [address-policy-wg] Multi-regional allocation question - transversing RIRs In-Reply-To: References: <001b01c66890$e3906bf0$0200000a@j> Message-ID: Hi Hank, On 4/25/06, Hank Nussbacher wrote: > I have a large multi-regional client, who's main base is in the USA. > They are about to get a /19 from ARIN since they are multi-homed and have > about 32 sites, but they also have about 5 sites in APNIC and the another > 5 in the RIPE region. Do they have to become members in each RIR to get > multi-homed allocations, or should one RIR handle it all? IIRC this happens frequently. One RIR can satisfy their global needs. > > Would the answer to that above question change if the IP blocks used in > APNIC and RIPE wouldn't be announced locally in those regions but would > rather be MPLSed back to the USA and from there all Internet access would > be allowed (thereby making the IP blocks pseudo-USA blocks)? No, same answer (obviously). > > > So any official guidance is appreciated. My answer above is just common sense, which may not be the same thing as "official guidance" ;-) -- Cheers, McTim $ whois -h whois.afrinic.net mctim From dmitry at volia.net Wed Apr 26 09:40:06 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Wed, 26 Apr 2006 10:40:06 +0300 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: <20060425191019.GB14965@h8000.serverkompetenz.net> References: <001b01c66890$e3906bf0$0200000a@j> <20060425191019.GB14965@h8000.serverkompetenz.net> Message-ID: <20060426074006.GW705@f17.dmitry.net> On Tue, Apr 25, 2006 at 09:10:19PM +0200, Nils Ketelsen wrote: > > Pardon me for saying, but all of this is bollocks. Renumbering is as easy as > > you want it to be. Make a proper policy and then create the tools for it. It > > is that easy. I am sure we can discuss poorly designed solutions any (other) > > time. > > You seem to have a very easy Job, when you can make this proper policy for > your customers. I can not, those (about) 100 connecting to my network all > have different policies, different needs, different requirements. And we do > our best, to fullfill their needs and make it as easy for them as possible. > We call that "service". If you do not have to provide this, good for you. > But please do not tell me, that my need to have paying customers is bad > design. > > Nils, not in the ISP-Business Opposite example - we serve about 60000 internet customers and have no problem to renumber almost all of them becouse we use DHCP. So, not any ISP/Telco will pain about renumbering. -- Dmitry Kiselev From president at ukraine.su Wed Apr 26 09:57:14 2006 From: president at ukraine.su (Max Tulyev) Date: Wed, 26 Apr 2006 11:57:14 +0400 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: <20060426074006.GW705@f17.dmitry.net> References: <001b01c66890$e3906bf0$0200000a@j> <20060425191019.GB14965@h8000.serverkompetenz.net> <20060426074006.GW705@f17.dmitry.net> Message-ID: <444F27DA.5080203@ukraine.su> Dmitry Kiselev wrote: > Opposite example - we serve about 60000 internet customers and have no > problem to renumber almost all of them becouse we use DHCP. So, not any > ISP/Telco will pain about renumbering. Try to imagine you have 60000 _web_sites_ :) -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From dmitry at volia.net Wed Apr 26 10:13:47 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Wed, 26 Apr 2006 11:13:47 +0300 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: <444F27DA.5080203@ukraine.su> References: <001b01c66890$e3906bf0$0200000a@j> <20060425191019.GB14965@h8000.serverkompetenz.net> <20060426074006.GW705@f17.dmitry.net> <444F27DA.5080203@ukraine.su> Message-ID: <20060426081347.GX705@f17.dmitry.net> On Wed, Apr 26, 2006 at 11:57:14AM +0400, Max Tulyev wrote: > Dmitry Kiselev wrote: > > >Opposite example - we serve about 60000 internet customers and have no > >problem to renumber almost all of them becouse we use DHCP. So, not any > >ISP/Telco will pain about renumbering. > > Try to imagine you have 60000 _web_sites_ :) I just show an example. There are some situations where renumbering become total nigthmare, but in some cases - no. In ISP market it is depend on operator's bussiness model. -- Dmitry Kiselev From jorgen at hovland.cx Wed Apr 26 11:11:40 2006 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Wed, 26 Apr 2006 11:11:40 +0200 Subject: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive) In-Reply-To: Message-ID: <003d01c66911$6e17c590$4a27b3d5@tungemaskin> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Michel Py > I love guys like J?rgen. One day they'll find someone fool enough to let them touch a big network, they'll make a mess, and their management will suddenly understand the value of paying me 2k per day so another disaster does not happen. That day came when I was 17. Imagine that, they paid me to operate their network. Today I operate my own networks. If you think it is better to work with a major tier1 ISP like I did when I was 17, then you are of course free to do so. But please don't tell me my previous boss was a fool. He was actually a nice guy and he might just read this mailing list too. If my background as a MEng software engineer offends your thoughts about how hard it must be to renumber devices, then I do apologise. My original posting stated that it is as easy as you want it to be. You don't seem to want it easy at all. That is fine and is what policies are all about. Like I said, I support the PI proposal. If you don't, please say so and also why. Leave my previous boss out of it. j From thk at telenor.net Thu Apr 27 09:48:06 2006 From: thk at telenor.net (Thor-Henrik Kvandahl) Date: Thu, 27 Apr 2006 09:48:06 +0200 (MEST) Subject: [address-policy-wg] IPv4-HD-Ratio proposal Message-ID: Hi all, here are my *personal* opinion on this proposal. I do not support this proposal, and my reasons for this are: * This proposal increases the rate of consumption of IPv4. * It favourises the large ISPs. * In the presentation on RIPE 52, Tuesday by Filiz Yilmaz, we where told that this proposal was abandoned by ARIN and APNIC, and one representative from LacNIC also stood up and expressed their conserns. I have not heard anything from AfriNIC, but I cannot see why they would want to implement this policy. I feel if will be arrogant of the RIPE community to disregard the other RIRs conserns and implement this policy. And I also have to agree with Gert Doering who said in the address policy WG that there has been very quiet around this proposal, and that the reason for this can be that ETNO claims thay "unanimously support this proposal". -- Thor-Henrik Kvandahl no.telenor From dogwallah at gmail.com Thu Apr 27 11:07:35 2006 From: dogwallah at gmail.com (McTim) Date: Thu, 27 Apr 2006 12:07:35 +0300 Subject: [address-policy-wg] IPv4-HD-Ratio proposal In-Reply-To: References: Message-ID: Hi Thor-Henrik, On 4/27/06, Thor-Henrik Kvandahl wrote: > > Hi all, > > here are my *personal* opinion on this proposal. > > I do not support this proposal, and my reasons for this are: I share your opinion, your lack of support for the IPv4-HD-Ratio proposal, and your reasons to oppose it. -- Cheers, McTim $ whois -h whois.afrinic.net mctim From randy at psg.com Thu Apr 27 11:16:01 2006 From: randy at psg.com (Randy Bush) Date: Thu, 27 Apr 2006 12:16:01 +0300 Subject: [address-policy-wg] IPv4-HD-Ratio proposal References: Message-ID: <17488.35793.620131.197589@roam.psg.com> [ fwiw, i am a stron no on this one ] it is almost amusing how much talk we have on using a linear vs a log function to evaluate utilization, while we spend no effort at real problems such as evaluating utilization in the presence of complex aggregation strategies, i.e. as discussed in arin, when i want to announce a /42 from each of my pops to keep route frag down, yet some are significantly less utilized than others. randy From fgarcia at eurocomercial.es Thu Apr 27 11:31:25 2006 From: fgarcia at eurocomercial.es (=?ISO-8859-1?Q?Fernando_Garc=EDa?=) Date: Thu, 27 Apr 2006 12:31:25 +0300 Subject: [address-policy-wg] IPv4-HD-Ratio proposal In-Reply-To: References: Message-ID: <51AC71B4-F9B4-4C1C-9EBD-CE0DC4EA36BF@eurocomercial.es> I support Thor-Henrik views and opinions. Regards, Fernando El 27/04/2006, a las 10:48, Thor-Henrik Kvandahl escribi?: > > Hi all, > > here are my *personal* opinion on this proposal. > > I do not support this proposal, and my reasons for this are: > > * This proposal increases the rate of consumption of IPv4. > * It favourises the large ISPs. > * In the presentation on RIPE 52, Tuesday by Filiz Yilmaz, we where > told > that this proposal was abandoned by ARIN and APNIC, and one > representative from LacNIC also stood up and expressed their > conserns. > I have not heard anything from AfriNIC, but I cannot see why they > would > want to implement this policy. I feel if will be arrogant of the > RIPE > community to disregard the other RIRs conserns and implement this > policy. > > And I also have to agree with Gert Doering who said in the address > policy > WG that there has been very quiet around this proposal, and that the > reason for this can be that ETNO claims thay "unanimously support this > proposal". > > -- > Thor-Henrik Kvandahl > no.telenor > > ------------------------------------------------ Fernando Garcia |Tel: +34 91 4359687 EUROCOMERCIAL I&C SA |Fax: +34 91 4313240 Valent?n Beato, 5 |e-mail: fgarcia at eurocomercial.es E-28037 Madrid | Spain |http://www.eurocomercial.es From gert at space.net Thu Apr 27 13:56:06 2006 From: gert at space.net (Gert Doering) Date: Thu, 27 Apr 2006 13:56:06 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <63ac96a50604251156i5681cbfbl77c49ccd20254dd1@mail.gmail.com> References: <63ac96a50604251156i5681cbfbl77c49ccd20254dd1@mail.gmail.com> Message-ID: <20060427115606.GS60910@Space.Net> Hi, (removing ppml and global-v6, taking this to the address policy wg list) On Tue, Apr 25, 2006 at 11:56:27AM -0700, Matthew Petach wrote: > I don't see why the discussion is dragging out for so long. This isn't > rocket science. Let's just nail the policy down, and move on with > more productive work. As soon as anyone can come up with a policy draft that we all can *agree* upon, then we can go ahead. What I'm not seeing in your mail is a specific proposal on the rules that should be used in deciding "who will get an address block / routing table slot, and who will not" - and that's the main question here, no matter how the resulting address bits are called. Gert Doering -- RIPE APWG co-chair -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From mpetach at netflight.com Tue Apr 25 20:56:27 2006 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 25 Apr 2006 11:56:27 -0700 Subject: [ppml] [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: References: Message-ID: <63ac96a50604251156i5681cbfbl77c49ccd20254dd1@mail.gmail.com> On 4/24/06, Pekka Savola wrote: > > Hi, > > On Fri, 21 Apr 2006, Ruchti, Marcus wrote: > > I don't think flapping routes will increase due to the assignments > > of PI space, as in the most cases ISP's are requesting those for > > customers and offers managed multihoming solutions. So announcing > > these routes into BGP is the responsibility of an ISP. > > First off: there has been some discussion whether 200K routes is a > problem or not. If the numbers stayed at that level (how can we > ensure that?), that wouldn't be a huge problem. Bigger one is > dynamicity. Huston's study indicated that there are folks whose BGP > announcements flap (due to TE) intentionally 1000's of times a day. > Multiply that by the number of sites (and add sBGP or friends to the > stew) and you may start thinking that your DFZ router might have > better things to do than process that cruft. BGP flap dampening is already well understood for limiting the impact of flapping routes on your CPU, if that's a concern; it has no bearing on address allocation policy decisionmaking. And configuring dampening is up to each _recipient_ network, and is not something that should be codified into an address allocation policy, which is targetted at the _originating_ network. Let's stick to the topic at hand, which is how to craft a useful address allocation policy which allows for provider indepent address allocations, while at the same time showing good stewardship of the overall address pool. The policy cannot allow itself to be shaped by the least-capable routers, or we'll be chaining ourselves to the past,unable to make adequate forward progress so long as there's any network out there that's still running old hardware that's unwilling to upgrade. I agree we need to be reasonable--but please, let's not "dumb down" the v6 internet just because some people aren't willing to step up to the plate and upgrade their routers when needed. Provider independence is here already, period. It's too late to try to put the horse back in the barn--what we *can* try to do is craft a well-thought-out policy 'bridle' for it, and then let it start running (to abuse a metaphor horribly). Trying to stop provider independent addressing in IPv6 is simply another way of saying 'IPv6 addressing is broken, let's just stick with IPv4 instead' -- because that's what the practical outcome is. Any addressing scheme that tries to deny the need for provider independent addressing is less capable for businesses than what they have today in the IPv4 world, and will therefore not be used. So. Given that PI allocations are going to happen in IPv6 just as they have in IPv4, let's put all the rest of the grumbling about it aside, acknowledge the reality of the situation, and simply agree that as a starting point, issuing a /48 out of a reserved /44 to each multi-homed, non-transit-service-providing network which applies and demonstrates it has met the requirements for being multi-homed and obtaining its own AS, is reasonable--if adjustments to the policy are needed, they can be applied in the future as needed, just as we've done in the IPv4 world. I *do* agree that stipulating that only the largest possible aggregate assigned to a given AS *should be* announced by the AS is a reasonable addition to the policy to help encourage aggregation, and prevent stupid routing mistakes like this: * 198.144.160.0/20 195.66.224.82 0 4513 174 6983 8051 i * 198.144.172.0 195.66.224.82 0 4513 701 8051 i (real-world example pulled from route-views; the /24 is announced by the same originating AS, but is not connected to or directly reachable from the network that announces the /20 aggregate, as was pointed out by the end-site when their /24 more specific was filtered out at one point.) That is, if you have discontiguous networks, they should each obtain their own AS, and should pay the registration fees for that AS and the associated IP aggregate which it will announce. I don't see why the discussion is dragging out for so long. This isn't rocket science. Let's just nail the policy down, and move on with more productive work. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ed.Lewis at neustar.biz Wed Apr 26 13:44:46 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 26 Apr 2006 14:44:46 +0300 Subject: [address-policy-wg] comments on IP Assignments for anycasting DNS (2005-2) Message-ID: Referring to: http://www.ripe.net/ripe/policies/proposals/2005-2.html The author's email address on the page is "@localhost". A few thoughts on the restrictions on this: "gTLD" usually means "generic Top Level Domain". There are also "sTLD" - sponsored TLD. (Check http://en.wikipedia.org/wiki/GTLD, at the bottom of the page there's a box that breaks gTLDs into sTLDs and other categories.) Sometimes "interesting" zones are not the TLD but one under the TLD. E.g., .co.tld. or .com.tld. I think that these should be eligible. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From baess at denic.de Thu Apr 27 17:08:27 2006 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Thu, 27 Apr 2006 17:08:27 +0200 Subject: [address-policy-wg] comments on IP Assignments for anycasting DNS (2005-2) In-Reply-To: Message-ID: Hi Ed, > Referring to: http://www.ripe.net/ripe/policies/proposals/2005-2.html > > A few thoughts on the restrictions on this: > > "gTLD" usually means "generic Top Level Domain". There are also > "sTLD" - sponsored TLD. (Check http://en.wikipedia.org/wiki/GTLD, at > the bottom of the page there's a box that breaks gTLDs into sTLDs and > other categories.) > > Sometimes "interesting" zones are not the TLD but one under the TLD. > E.g., .co.tld. or .com.tld. I think that these should be eligible. if you look at the history if the discussion you will find that the scope of the policy scaled down from any domain that may feel the need to deploy anycasting down to gTLDs and ccTLDs. That limitation is the consensus of the discussion process wether teh community will accept the address swamp space and routing entries. I have seen massive resistance against to put sTLDs and/or other "important" domains in the scope of that policy. I would like to stop this discussion at this phase as I have not seen new arguments. I believe that with an increasing acceptance of new TLDs and experience with this policy we may see a policy change to include sTLDs in some future. ccTLDs and gTLDs that organize themselves on the SLD level are in scope of the policy. However all TLDs get the same resources assigned. Currently it will not be possible to get multiple assignments for the same TLD. Regards Andreas Baess From heldal at eml.cc Fri Apr 28 18:38:36 2006 From: heldal at eml.cc (Per Heldal) Date: Fri, 28 Apr 2006 18:38:36 +0200 Subject: [address-policy-wg] IPv4-HD-Ratio proposal In-Reply-To: References: Message-ID: <1146242316.8358.260177796@webmail.messagingengine.com> On Thu, 27 Apr 2006 09:48:06 +0200 (MEST), "Thor-Henrik Kvandahl" said: > I do not support this proposal, and my reasons for this are: > > * This proposal increases the rate of consumption of IPv4. > * It favourises the large ISPs. > * In the presentation on RIPE 52, Tuesday by Filiz Yilmaz, we where told > that this proposal was abandoned by ARIN and APNIC, and one > representative from LacNIC also stood up and expressed their conserns. > I have not heard anything from AfriNIC, but I cannot see why they would > want to implement this policy. I feel if will be arrogant of the RIPE > community to disregard the other RIRs conserns and implement this > policy. I agree with the above. The only one I've heard arguing heavily in favor of the HD-ratio proposal was a representative for a large international backbone who saw this as an opportunity to compensate for bad internal distribution of assigned address-blocks. I don't think any-body's inability to come up with a decent network design is a reason to accept such changes to the policy. > > And I also have to agree with Gert Doering who said in the address policy > WG that there has been very quiet around this proposal, and that the > reason for this can be that ETNO claims thay "unanimously support this > proposal". Does this mean that ETNO assume they have some form of veto in the RIPE community? I can't see any reason why ETNO's vote should count for more than any other _individual's_ opinion regardless of who they claim to represent. //per -- Per Heldal http://heldal.eml.cc/ From fw at deneb.enyo.de Sun Apr 30 14:38:56 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 30 Apr 2006 14:38:56 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060424103855.GT60910@Space.Net> (Gert Doering's message of "Mon, 24 Apr 2006 12:38:55 +0200") References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> Message-ID: <87wtd7me5b.fsf@mid.deneb.enyo.de> * Gert Doering: > Most (if not all) larger hosting providers I know are LIRs, so this > question really doesn't apply. Then we will arrive at "LIRs are global pain to everybody else", and nothing has changed. From tna at telenor.net Sun Apr 30 20:44:35 2006 From: tna at telenor.net (Torunn Narvestad) Date: Sun, 30 Apr 2006 20:44:35 +0200 Subject: [address-policy-wg] IPv4-HD-Ratio proposal In-Reply-To: References: Message-ID: <7.0.1.0.0.20060430203808.01e0c238@telenor.net> Hi, I strongly agree with what Thor-Henrik has written below. I do not at all support this policy proposal. - Torunn At 09:48 27.04.2006, Thor-Henrik Kvandahl wrote: >Hi all, > >here are my *personal* opinion on this proposal. > >I do not support this proposal, and my reasons for this are: > >* This proposal increases the rate of consumption of IPv4. >* It favourises the large ISPs. >* In the presentation on RIPE 52, Tuesday by Filiz Yilmaz, we where told > that this proposal was abandoned by ARIN and APNIC, and one > representative from LacNIC also stood up and expressed their conserns. > I have not heard anything from AfriNIC, but I cannot see why they would > want to implement this policy. I feel if will be arrogant of the RIPE > community to disregard the other RIRs conserns and implement this policy. > >And I also have to agree with Gert Doering who said in the address policy >WG that there has been very quiet around this proposal, and that the >reason for this can be that ETNO claims thay "unanimously support this >proposal". > >-- >Thor-Henrik Kvandahl >no.telenor Torunn Narvestad Telenor Nordic